SiliconSmart ACE

User Guide
Version L-2016.03, March 2016
Copyright and Proprietary Information Notice
© 2016 Synopsys, Inc. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc. and may only be
used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All other use, reproduction,
modification, or distribution of the Synopsys software or the associated documentation is strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.

Synopsys, Inc.
690 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com

ii SiliconSmart ACE User Guide

L-2016.03
SiliconSmart ACE User Guide iii
L-2016.03
iv SiliconSmart ACE User Guide
L-2016.03
 Contents

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lv
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lvi

1.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
SiliconSmart Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
SiliconSmart Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
SiliconSmart Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Entering SiliconSmart Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Specifying Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.
Setting Up SiliconSmart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Managing Your Job Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Setting a Job Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Stand-Alone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Load Sharing Facility (LSF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Sun Grid Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
RTDA NC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Using CDPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
CDPL Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Using CDPL Parameters in SiliconSmart. . . . . . . . . . . . . . . . . . . . . . . . . 15
Launch Control Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Worker Control Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
CDPL Logs and Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Viewing CDPL Runtime Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
CDPL Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Parameters for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Debugging Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Monitoring Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v
Contents

Secondary Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Additional CDPL Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Automatic Reruns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Using RSH to Create a Custom Pool . . . . . . . . . . . . . . . . . . . . . . . . 23
Prevent CDPL from Clogging the Home Directory . . . . . . . . . . . . . . 24
Resetting Farm/Queue Settings During the Flow . . . . . . . . . . . . . . . 24
Managing Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Obtaining a New SiliconSmart License . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Upgrading Licenses . . . . . . . . . . . . . . . . . . 25
Selecting a Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Running with FineSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Running with FineSim Multiple-CPU Simulation . . . . . . . . . . . . . . . . . . . 27
Running with FineSim-Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Compatibility with FineSim-Embedded. . . . . . . . . . . . . . . . . . . . . . . 29
Disk Space Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Using finesim_embedded with Verilog-A Model . . . . . . . . . . . . . . . . 29
Running with HSPICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Running with HSPICE in Client Server Mode . . . . . . . . . . . . . . . . . . . . . 30
Running with HSPICE-Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Setting Simulator Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Specifying Simulator Options for Leakage . . . . . . . . . . . . . . . . . . . . 32
Setting Default Simulator Options . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Setting Up Your Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.
SiliconSmart Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Data Flow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Basic Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Creating the Characterization Point . . . . . . . . . . . . . . . . . . . . . . . . . 36
Setting Global Parameters for all Cells. . . . . . . . . . . . . . . . . . . . . . . 36
Importing Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Customizing Cell Instance Files (Optional) . . . . . . . . . . . . . . . . . . . 37
Precharacterizing (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Configuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Characterizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
New Characterization versus Recharacterization . . . . . . . . . . . . . . . . . . 39
Setting Up for Your Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Requirements for Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

vi
 Contents

Launching SiliconSmart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Modifying the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Creating a Characterization Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Editing the configure.tcl File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Setting Your Characterization Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Selecting a Characterization Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Select by Your Starting Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Select by Characterization Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Recharacterization Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Pure Recharacterization Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Functional Recognition Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Skeleton Liberty-Based Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Incremental Characterization Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Recharacterization with Selective Extraction of Information from an Existing
Liberty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Extracting All Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Extracting Loads and When Conditions . . . . . . . . . . . . . . . . . . . . . . 58
Extracting Slews and When Conditions . . . . . . . . . . . . . . . . . . . . . . 58
Extracting Port Directions and Functional Information . . . . . . . . . . . 59
Combining Import-Based Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Function-Based Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Extracting a Function from the Netlist with FR . . . . . . . . . . . . . . . . . . . . . 60
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Using Commands in this Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Manually Defining a Function in the Instance Files . . . . . . . . . . . . . . . . . 61
Structure-Based Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Automatic Vector Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Using Commands in this Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Manually Defining Simulation Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Sequence-Based Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Additional Flow Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

vii
Contents

Explicitly Generating Load/Slope Indices for Automatic Distribution . . . . 64

Using the Driver Waveform from an Imported Liberty . . . . . . . . . . . . . . . 65
Additional Characterization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Creating a run.tcl File for Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.
Importing and Configuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Editing the configure.tcl File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Global Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Pin Type Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Asymmetric Slew Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Setting Pin Type Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . 73
Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Example configure.tcl File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Importing Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Editing Instance Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Specifying Netlist Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Defining Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Describing Cell Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Specifying Characterization and Modeling Options . . . . . . . . . . . . . . . . . 81
Specifying Pin Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Example Instance Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Example 1 — Complete Instance File . . . . . . . . . . . . . . . . . . . . . . . 83
Example 2 — Two-Input And-Or-Inverted Combinational Cell . . . . . 84
Example 3 — Flip-Flop with Asynchronous Set Pin . . . . . . . . . . . . . 85
Cell Types and Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Combinational Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Boolean functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Truth Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Sequential Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Flops and Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
State Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Complementary Inputs and Differential Pins . . . . . . . . . . . . . . . . . . . . . . 94
Specifying Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Specifying Behavior and Conditions. . . . . . . . . . . . . . . . . . . . . . . . . 96
I/O Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Memory Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Multi-Bit Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

viii
 Contents

Structural Cell Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Constraint Measurements to Internal Nodes . . . . . . . . . . . . . . . . . . . . . . 100
Configuring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Analyzing the Netlist (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Precharacterization (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Using the configure Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Function-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Functional Recognition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Functional Recognition Methodology . . . . . . . . . . . . . . . . . . . . . . . . 106
Using Functional Recognition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Setting Up Functional Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Log Files and Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Defining a Function in Instance Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Structure-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Vector Generator (VG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Using Vector Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
VG State Partitioning Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Sequence-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Adding a User-Defined Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
add_user_stimulus Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
add_user_stimulus Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Multiple Measurements in a Single Stimulus . . . . . . . . . . . . . . . . . . 126
Specifying Constraints for Pulse Generator Cells . . . . . . . . . . . . . . 126
Specifying Transparent Edge Setup Time for Pulse Latch . . . . . . . . 127
Specifying Differential Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Output-to-Output Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring Arcs from Internal Nodes . . . . . . . . . . . . . . . . . . . . . . . 129
Tcl foreach Loops and Variable Substitution for States . . . . . . . . . . 129
Tcl foreach Loops and Variable Substitution for Pins . . . . . . . . . . . . 131
Using not for a Gated Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Creating a run.tcl File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Importing and Configuring Multi-Bit Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Importing Multi-Bit Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Importing an Instance File for Recharacterization . . . . . . . . . . . . . . 133
Creating a New Instance File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Example Instance Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Configuring Multi-Bit Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Mode 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Mode 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

ix
Contents

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Modeling Multi-Bit Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Setting Advanced Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Using the set_config_opt Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Basic Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Specifying set_config_opt -type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Applying Load Harness to a Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Setting Pin Type Parameters for Arc-Based Measurements . . . . . . 152
State Dependent Measurements (State Partitioning). . . . . . . . . . . . 152
State Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Disabling Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Controlling Don’t Care Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Table Dimensions and Sweep Order . . . . . . . . . . . . . . . . . . . . . . . . 157
Controlling the Output Pin in Constraint Measurements . . . . . . . . . 159
Excluding Output Pins during Constraint Measurement. . . . . . . . . . 159
Working with Extreme Constraint Values . . . . . . . . . . . . . . . . . . . . . 161
Multicycle Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Separate Cell Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Specifying Load and Slew Ranges. . . . . . . . . . . . . . . . . . . . . . . . . . 163
Default Arc Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Controlling Generation of Default Arcs . . . . . . . . . . . . . . . . . . . . . . . 166
Generating Default Tables for Constraint Arcs . . . . . . . . . . . . . . . . . 167
Generating Default Tables for Power Arcs . . . . . . . . . . . . . . . . . . . . 168
Generating Default Tables for Leakage Power Arcs . . . . . . . . . . . . . 168
How are Default Tables Created?. . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Changing Characterization Parameters of Pins . . . . . . . . . . . . . . . . . . . . 172
Partial Voltage Swings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
nochange Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Simulation Harnesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Creating a Harness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Output Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Setting Measurement and Stimulus Nodes . . . . . . . . . . . . . . . . . . . 178
Power in Simulation Harnesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Applying a Harness to a Circuit Under Test . . . . . . . . . . . . . . . . . . . 180
Example for Applying a Harness to a Cell . . . . . . . . . . . . . . . . . . . . 181
Weak Drive States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Specifying Weak Drive States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Setting Parameters for Weak Drive States . . . . . . . . . . . . . . . . . . . . 183
Using Different Simulators for Different Measurements . . . . . . . . . . . . . . 183
Autoranging and Automatic Parameter Determination . . . . . . . . . . . . . . . 184
Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Selecting the Driver Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Importing Driver Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

x
 Contents

Using Driver Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Viewing and Removing Driver Cells . . . . . . . . . . . . . . . . . . . . . . . . . 196
Driver Waveform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

5.
Characterizing and Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Precharacterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Before Precharacterization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Simulation-Related Settings for Precharacterization . . . . . . . . . . . . 200
Binning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Using model_expanded_states . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Using the precharacterize Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Additional Precharacterization Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Family-Based Precharacterization . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Event-Based Precharacterization. . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Characterization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Before Characterizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Using the characterize Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Running Selective Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Recharacterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Recharacterizing without a configure.tcl File . . . . . . . . . . . . . . . . . . . . . . 208
Generating Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Using the model Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Distributed Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Generated Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Automatic Default Arc Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Model Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Suggested Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Enabling MPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Using Non-HSPICE Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Running MPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Netlist Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Example Netlists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Liberty Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Supported Construct Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Styling Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Writing Min/Max Capacitance and Min/Max Transition Attributes . . 217
Slew Derating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Generic Slew Derating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

xi
Contents

Modeling Multi-Bit Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Additional Modeling Parameters for Scan . . . . . . . . . . . . . . . . . . . . 222
Adding Attributes to Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Adding Library-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Adding Cell-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Adding Pin-Level Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Adding User-Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Liberty Model Post-Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
HDL Model Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Generating an HDL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Calibrating the Output Verilog Model . . . . . . . . . . . . . . . . . . . . . . . . 227
Generating a test_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
The Distributed Processing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
RSH Support for CDPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Debugging Distributed Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Adaptive Job Manager For all Distributed Process Tasks . . . . . . . . . . . . 235

6.
Memory Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
SiliconSmart Memory Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Supported Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Memory Characterization Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Recommended Memory Characterization Flows . . . . . . . . . . . . . . . . . . . 240
Basic Memory Characterization Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Using this Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Using Commands in this Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Memory Recharacterization Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Using this Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Incremental CCSN Memory Characterization Flow . . . . . . . . . . . . . . . . . 242
Using this Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Using Commands in this Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Excluding Generation of CCSN Models . . . . . . . . . . . . . . . . . . . . . . 245
Generating Single CCBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Example Run Script for CCS-Noise Add-On Flow . . . . . . . . . . . . . . 246
Enabling Donut-Style Memory Netlists for CCS-Noise . . . . . . . . . . . . . . 247
Importing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Creating the Template File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Template File Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Template File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

xii
 Contents

Configuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
configure.tcl Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
configure.tcl File Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Defining the Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Instance File Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Example Instance Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Synchronous 2-port Register File. . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Synchronous 2-port SRAM with Independent Read and Write Operation
267
Synchronous ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Finding Internal Nodes for Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Memory Characterization Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Active Node Based Netlist Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Using Constraint Seeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
FineSim Pro Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Memory Characterization through Back-Annotation . . . . . . . 276
Usage 1 . . . . . . . . . . . . . . . . . . . . . 276
Usage 2 . . . . . . . . . . . . . . . . . . . . . 277
Limitations with Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Liberty Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Input Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Setup/Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
CCS Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Individual Bit Modeling Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Extra-Margin Adjustment Pins in Memories . . . . . . . . . . . . . . . . . . . . . . . 282
Path Based Constraint Support for Memories . . . . . . . . . . . . . . . . . . . . . . . . . 284
User-Defined Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Defining New Pintypes . . . . . . . . . . . . . . . . 287
Auto-Generated Node . . . . . . . . . . . . . . . . . . 287

7. Statistical Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Statistical Format Generation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Configuring Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Netlist Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

xiii
Contents

Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Modeling Statistical Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Sensitivity and Sigma Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Statistical Hold Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
stat_hold Characterization Using the Monte Carlo Approach . . . . . . . . . 300
stat_hold Characterization Using the Simulator Bisection Approach . . . . 300
AOCV/POCV Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
AOCV Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Running AOCV Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Monte Carlo Simulation-Based Methodology . . . . . . . . . . . . . . . . . . 304
Sensitivity-Based Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
AOCV Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
POCV Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Monte Carlo Simulation-Based Methodology . . . . . . . . . . . . . . . . . . 309
Sensitivity-Based Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
LVF Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
POCV Characterization Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Separate Early/Late Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Supported Characterization Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
.........................................................
Process Model Requirements and Simulator Support . . . . . . . . . . . 315
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Sensitivity-Based LVF Characterization: . . . . . . . . . . . . . . . . . . . . . . . . . 316
configure.tcl Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Additional Control Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Monte Carlo-Based LVF Characterization . . . . . . . . . . . . . . . . . . . . . . . . 322
configure.tcl Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Separate Early/Late Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
LVF Add-On Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
LVF Table Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Detailed LVF Table Check Descriptions . . . . . . . . . . . . . . . . . . . . . . 326
Parameters to Control Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
AOCV/POCV (Side File Format) Model Generation from LVF Data . . . . . . . . 329
Flow 1: Using the CCI Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Flow 2: Generate AOCV/POCV Side Files with LVF in a Single Run. . . . 329
Additional Control Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

xiv
 Contents

8.
IBIS Characterization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Introduction to IBIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
IBIS Characterization Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Dynamic Curve Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Static Curve Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
On-Die Termination (ODT) Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Post-Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Regression Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Notes on Parameter Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Adding a Submodel Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Programmable Driver Strength Support . . . . . . . . . . . . . . . . . . . . . . . . . 348
Design of Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Example of ODT and Programmable Driver Cell Setup . . . . . . . . . . . . . . 350
Using IBIS in SiliconSmart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Configuration, Characterization, and Modeling . . . . . . . . . . . . . . . . . . . . 351
Using the active_pvts Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
C_comp Measurement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Setting Up SiliconSmart for IBIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Cells Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Cell Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Final SiliconSmart IBIS Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
IBIS 5.0 Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
IBIS Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Model Name Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Pin Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
IBIS Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
IBIS Pin Type Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
IBIS Pin-Level Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
IBIS Cell-Level Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Eye-Diagram Generation Parameters for IBIS Validation . . . . . . . . . 368
Parameter Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
IBIS Merging Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Using ibis_merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
IBIS-AMI Model Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Checking the Generated IBIS File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
How can I control the number of points in the VT waveform table in an IBIS
model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

xv
Contents

Which parameter (nsamples or voltage_resolution) has the higher priority?

378
Why does SiliconSmart output [GND Clamp] tables in the entire range [-VDD,
2VDD]? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
How can I generate rising waveforms in IBIS for open_sink cells . . 379

9.
Generating Data Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Using the generate_datasheet Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Cell Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Data Sheet Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Example Data Sheet Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Simple Combinational Cell Data Sheet . . . . . . . . . . . . . . . . . . . . . . 386
Sequential Cell Data Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Header and Subheader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Input Pin Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Delay and Output Transition Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Constraint Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Dynamic Energy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Leakage Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Setup and Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Customizing the Provided Data Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Customization Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Setting the Data Sheet Customization File . . . . . . . . . . . . . . . . . . . . . . . 394
Modifying, Adding, and Overriding Parameters . . . . . . . . . . . . . . . . . . . . 395
Modifying and Adding Existing Parameters . . . . . . . . . . . . . . . . . . . 395
Overriding Existing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Setting Transition Time and Load Pin Parameters . . . . . . . . . . . . . . . . . . 396
Reporting a List of Load/Slew Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Customizing Data Sheet Format and Content . . . . . . . . . . . . . . . . . . . . . . . . . 399
General Report Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Table Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Generating User-Supplied Truth Tables . . . . . . . . . . . . . . . . . . . . . . 404
Variable Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

xvi
 Contents

Tcl-Level Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Substitution by define_parameters Command . . . . . . . . . . . . . . . . . . . . . 405
Late Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

10.
Validating the Output Liberty File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Qualifying the Liberty File with qualify_library . . . . . . . . . . . . . . . . . . . . . . . . . 407
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Using qualify_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Library Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Consistency Between CCST and NLDM Timing Models . . . . . . . . . 410
Consistency Between CCSN and NLDM Timing Models . . . . . . . . . 410
Voltage Range Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Cell Sensitivity Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Data Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Minimum Load Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Tolerance Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Addressing Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
qualify_library Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Example run.tcl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Viewing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Comparing Liberty Files with compare_library . . . . . . . . . . . . . . . . . . . . . . . . 419
Using compare_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Basic Library Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Numerical Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Selective Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Adding User-Defined Attributes for Comparison . . . . . . . . . . . . . . . 421
Comparison Tolerances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Viewing Tolerances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Specifying Tolerances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Tolerance Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
compare_library Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Summary File (summary.log) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Difference Files (*.diff) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Numerical Data Files (*.csv). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

xvii
Contents

Running HDL Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

SDF Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
HDL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Timing and Function Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

11.
Timing Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Timing Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Propagation Delays and Transition Time . . . . . . . . . . . . . . . . . . . . . . . . . 434
Differential Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Current Source Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
CCS Timing Waveform Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . 436
CCS Receiver Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
CCS Receiver Capacitance Methodology . . . . . . . . . . . . . . . . . . . . 437
Maximum Capacitance Measurement for TIEH/TIEL Cells . . . . . . . . . . . 439
Output-to-Output Timing Arc Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Tri-State Enable and Disable Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Timing Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Three-State Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Three-State Disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Pin Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Modeling Three-State Pin Capacitance . . . . . . . . . . . . . . . . . . . . . . 446
Output Pin Capacitance on Bi-directional and Tri-state Pins . . . . . . 447
Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Setup/Hold Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Enabling the Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Dependent Measurement Operation . . . . . . . . . . . . . . . . . . . . . . . . 449
Path-Based Constraint Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Enabling Path-Base Constraint Analysis . . . . . . . . . . . . . . . . . . . . . 454
Example of Functional Description. . . . . . . . . . . . . . . . . . . . . . . . . . 455
Measuring Path-Based Setup and Hold . . . . . . . . . . . . . . . . . . . . . . 457
Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Constraint Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Independent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Dependent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Dependent-Setup Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Dependent-Hold Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Debugging Dependent Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Correction for Dependent-Setup & Dependent-Hold Constraint Modes 475

xviii
 Contents

Constraint Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Simulator Bisection Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Simulator Bisection Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Monitoring Internal Nodes for Constraints . . . . . . . . . . . . . . . . . . . . . . . . 484
Pass-Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Relative-Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Slew-Degradation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Delay-Reduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Relative-Slew-Degradation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Pushout-Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Advanced Parameters for Constraint Measurements. . . . . . . . . . . . . . . . 490
Negative Setup + Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Same Data Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Opposite Data Edge (Data Pulse Width) . . . . . . . . . . . . . . . . . . . . . 495
Negative Constraint Sum Modeling . . . . . . . . . . . . . . . . . . . . . . . . . 496
Path-Based Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Summary of Various Constraint Modes and Styles . . . . . . . . . . . . . . . . . 499

12.
Power and Electromigration Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Internal Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Hidden vs. Switching Internal Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Multi-Output Pin Cells Power Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Output Switching Energy Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Splitting default_load Internal Energy Among Multiple Output Pins. . . . . 509
3-D Table Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Filling Power Tables that Do Not Occur . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Pin Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Setting Asymmetric cin Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . 516
Negative Energy Values in internal_power Groups . . . . . . . . . . . . . . . . . . . . . 517
Leakage Energy Subtraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Leakage Energy Stabilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Input Pin Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Leakage Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Gate Leakage Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

xix
Contents

Leakage Power State Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Reducing the Number of Characterized Leakage States . . . . . . . . . 521
Power Measurement Methodology for Antenna Cells . . . . . . . . . . . . . . . 521
Multi-Rail Power Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Multi-Rail Power Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Modeling Current/Power from Multiple PG Pins into One PG Pin in Liberty 529
CCS Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Optimizing the CCS-Power Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
CCS Decoupling Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
MT-CMOS Switch Cells Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
CCS-Power Model Warnings from Synopsys Library Compiler . . . . . . . . 533
Troubleshooting SiliconSmart Power Models. . . . . . . . . . . . . . . . . . . . . . . . . . 533
SiliconSmart Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Active Driver Netlist Subcircuit Definition . . . . . . . . . . . . . . . . . . . . . . . . . 534
Electromigration (EM) Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Electromigration Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
EM Threshold Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
EM Characterization and Modeling . . . . . . . . . . . . . . . . . . . . . . . . . 538
Using EM in SiliconSmart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Incremental EM Characterization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Parameters for EM Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
EM Characterization Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

13.
CCS-Noise Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Overview of CCS-Noise Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Enabling CCS-Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
configure (CCS-Noise) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
characterize (CCS-Noise) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
model (CCS-Noise) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Selectively Choosing Pin-Based Noise Models . . . . . . . . . . . . . . . . . . . . 547
Generating Single CCBs for Input and Output Pins . . . . . . . . . . . . . . . . . 548
CCS-Noise Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
CCS-Noise IV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
CCS-Noise Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
CCS-Noise Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
CCS-Noise Miller Capacitance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550

xx
 Contents

Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

User-Defined CCBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

14.
Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Setup Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
add_back_bias_supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
add_channel_length_variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
add_channel_width_variation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
add_fixed_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
add_flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
add_forbidden_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
add_function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
add_harness_elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
add_latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
add_liberty_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
add_one_hot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
add_opc_grounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
add_opc_statistical_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
add_opc_supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
add_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
add_process_parameter_variation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
add_switch_tuple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
add_switching_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
add_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
add_transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
add_user_stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
analyze_netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
cell_families_by_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
change_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
clear_config_opts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
clear_liberty_attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
clear_liberty_group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
create_harness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
create_operating_condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
define_cell_ccb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601

xxi
Contents

define_differential_receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
define_parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
enable_api . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
expand_side_inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
find_internal_nodes_for_constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
find_potential_internal_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
get_word_line_node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
man . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
pintype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
remove_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
remove_parameter_block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
remove_pintype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
report_arcs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
set_boundary_distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
set_bus_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
set_cell_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
set_config_opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
set_harness_parent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
set_length_unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
set_liberty_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
set_location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
set_log_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
set_log_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
set_log_stdout_level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
set_maskable_enable_control_output . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
set_measurement_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
set_netlist_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
set_opc_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
set_opc_parameter_distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
set_opc_process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
set_opc_temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
set_opc_default_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
set_output_differential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
set_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
set_pins_to_bundle_map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
set_pintype_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
set_points_boundary_distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
set_stimulus_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

xxii
 Contents

set_subckt_ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
set_sweep_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
test_internal_nodes_for_constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
validate_hdl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Query Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
get_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
get_config_opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
get_location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
get_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
get_pintype_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
get_version_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
list_parameter_blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
list_parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
list_pintype_parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
list_pintypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
print_options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
report_drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
report_pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
report_sim_results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
report_sim_stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
write_config_opts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Processing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
characterize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
compare_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
delete_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
generate_datasheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
import_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
precharacterize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
qualify_library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Memory Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Tcl Memory Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
set_memory_type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
set_memory_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
set_mem_internal_node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
set_maximum_addressable_word . . . . . . . . . . . . . . . . . . . . . . . . . . 692

xxiii
Contents

set_rom_code_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
set_separate_statetable_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
set_bypass_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
set_pipeline_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
set_writethrough_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
set_bist_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
set_extramargin_adjustment_mode . . . . . . . . . . . . . . . . . . . . . . . . . 695
set_maskablewrite_enable_control_output . . . . . . . . . . . . . . . . . . . 695
set_light_sleep_enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
set_deep_sleep_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
set_shut_down_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
set_asynchronous_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
set_register_scan_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
create_readwrite_port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Functional Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
set_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
set_address_bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
set_data_bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
set_asynchronous_write_through . . . . . . . . . . . . . . . . . . . . . . . . . . 701
set_asynchronous_write_through_logic . . . . . . . . . . . . . . . . . . . . . . 702
set_output_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
set_read_enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
set_write_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
set_chip_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
set_memory_enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
set_bypass_enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
set_writethrough_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
set_bist_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
set_pipelinemode_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
set_extramargin_adjustment_enable . . . . . . . . . . . . . . . . . . . . . . . . 709
set_extramargin_adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
set_testclk_enable name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
set_maskable_enable_control_output . . . . . . . . . . . . . . . . . . . . . . . 710
set_maskablewrite_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
set_data_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
set_pipeline_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Test Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
set_testmode_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
set_testmode_address_bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
set_testmode_data_bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
set_testmode_read_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
set_testmode_write_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
set_testmode_chip_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
set_testmode_memory_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717

xxiv
 Contents

set_testmode_bypass_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
set_testmode_writethrough_enable . . . . . . . . . . . . . . . . . . . . . . . . . 718
set_testmode_bist_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
set_testmode_pipelinemode_enable . . . . . . . . . . . . . . . . . . . . . . . . 719
set_testmode_extramargin_adjustment_enable. . . . . . . . . . . . . . . . 720
set_testmode_extramargin_adjustment . . . . . . . . . . . . . . . . . . . . . . 720
set_testmode_maskablewrite_enable . . . . . . . . . . . . . . . . . . . . . . . 721
set_testmode_data_output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
set_testmode_pipeline_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
General Memory Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
add_input_pin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
add_output_pin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
set_input_pins_tiedto_low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
set_input_pins_tiedto_high. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
set_internal_supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
set_output_state_on_shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
set_shutdown_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Scan Chain Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
set_scan_chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
set_scan_chain_def . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
set_scan_input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
set_scan_clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
set_scan_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
set_scan_preset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
set_scan_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
set_scan_internal_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729

15. SiliconSmart Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

ibis Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
ibis_package_c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
ibis_package_c_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
ibis_package_c_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
ibis_package_c_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
ibis_package_l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
ibis_package_l_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
ibis_package_l_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
ibis_package_l_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
ibis_package_r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
ibis_package_r_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
ibis_package_r_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
ibis_package_r_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

xxv
Contents

ibis_pulldown_supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
ibis_pullup_supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
ibis_c_comp_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
ibis_c_comp_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
ibis_c_comp_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
ibis_c_series_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
ibis_c_series_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
ibis_c_series_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
ibis_clamping_iv_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
ibis_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
ibis_l_series_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
ibis_l_series_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
ibis_l_series_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
ibis_model_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
ibis_polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
ibis_r_series_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
ibis_r_series_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
ibis_r_series_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
ibis_vdiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
liberty_model Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
delay_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
param Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
absolute_leakage_threshold_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
active_pvts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
add_constraint_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
add_lvf_constraint_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
add_lvf_delay_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
add_lvf_slew_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
add_stat_constraint_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
advanced_dp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
advanced_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
advanced_sof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
aocv_correlation_coeff_between_stages . . . . . . . . . . . . . . . . . . . . . . . . 764
aocv_early_sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
aocv_fanout_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
aocv_fanout_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
aocv_fast_char . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
aocv_input_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765

xxvi
 Contents

aocv_interconnect_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
aocv_late_sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
aocv_mc_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
aocv_num_fanouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
aocv_num_stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
aocv_output_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
aocv_passive_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
aocv_sample_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
aocv_sensitivity_based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
archive_condition_for_pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
archive_condition_on_failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
archive_condition_on_success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
archive_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
auto_fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
back_bias_connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
backup_simulation_tmpdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
bjt_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
bundle_bit_independent_descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
bundle_bit_independent_descriptor_mode . . . . . . . . . . . . . . . . . . . . . . . 770
cap_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
ccb_separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
ccb_single_fanout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
ccb_single_fanout_bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
ccbs_for_input_driving_passgate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
ccs_delay_abs_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
ccs_delay_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
ccs_noise_iv_dc_analysis_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
ccs_noise_miller_resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
ccs_power_modeling_load_indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
ccs_power_modeling_slew_indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
ccs_power_optimize_waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
ccs_receiver1_check_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
ccs_receiver2_check_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
ccs_segment_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
ccsn_add_second_level_ccb_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
ccsn_cmiller_check_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
ccsn_cmiller_default_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
ccsn_exclude_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
ccsn_ignore_char_failures_during_modeling . . . . . . . . . . . . . . . . . . . . . 776

xxvii
Contents

ccsn_initial_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
ccsn_model_default_pin_based_models . . . . . . . . . . . . . . . . . . . . . . . . 777
ccsn_truncate_long_ccb_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
ccsn_model_passgate_ccb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
ccsn_use_enhanced_hw_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
ccsn_use_enhanced_miller_cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
ccsn_use_optimal_node_selection_method . . . . . . . . . . . . . . . . . . . . . . 778
ccsn_use_partial_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
ccsp_cross_point_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
cdpl_alt_submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
cdpl_host_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
cdpl_long_task_alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
cdpl_submission_cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
cdpl_submission_timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
cdpl_task_max_lifespan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
cdpl_worker_max_tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
cdpl_worker_timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
cell_families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
cell_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
char_engine_max_lifespan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
check_pins_in_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
check_sof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
check_templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
combine_delay_and_cin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
combine_energy_and_cin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
combine_lvf_cin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
combine_timing_and_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
compact_ccs_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
configure_all_states_for_ccb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
configure_constraint_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
configure_internal_node_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
configure_from_function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
configure_from_structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
configure_preferred_secondary_input . . . . . . . . . . . . . . . . . . . . . . . . . . 786
configure_write_fugues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
configure_zdisable_pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
constraint_exclude_outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
constraint_glitch_time_delta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
constraint_matched_internal_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788

xxviii
 Contents

constraint_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
constraint_monotonicity_tolerance_pct . . . . . . . . . . . . . . . . . . . . . . . . . . 789
constraint_outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
constraint_pulse_cratering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
constraint_seed_by_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
constraint_seed_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
constraint_seed_values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
constraint_simulated_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
constraint_simulated_seed_acq_based . . . . . . . . . . . . . . . . . . . . . . . . . 791
constraint_simulated_seed_finesim_mode . . . . . . . . . . . . . . . . . . . . . . . 791
constraint_simulated_seed_simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
constraint_simulation_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
constraint_trigger_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
construct_ncx_templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
current_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
current_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
cut_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
cut_stat_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
datasheet_truth_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
dc_current_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
dc_current_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
dc_current_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
dc_current_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
default_load_position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
default_netlist_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
default_position_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
default_slew_position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
delay_based_constraint_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
delay_matching_cin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796
detect_internal_power_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
detect_internal_power_nodes_for_pruning . . . . . . . . . . . . . . . . . . . . . . . 797
differential_delay_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
differential_delay_probe_style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
differential_pair_timing_duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
dio_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
disable_negative_power_adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . 799
disable_sim_stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
do_zero_modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
dontcare_bias_on_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800

xxix
Contents

dontcare_values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
driver_load_steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
ecsm_power_modeling_load_indices . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
ecsm_power_modeling_slew_indices . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
ecsm_threshold_pcts_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
ecsm_threshold_pcts_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
em_analyze_power_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
em_table_with_current_types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
em_threshold_simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
em_threshold_simulator_cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
em_threshold_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
em_use_xba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
enable_ac_decap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
enable_ac_decap_merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
enable_cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
enable_cell_leakage_power_modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 804
enable_dc_leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
enable_exhaustive_modeling_of_ccbs . . . . . . . . . . . . . . . . . . . . . . . . . . 805
enable_external_simulator_pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
enable_fast_sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
enable_fse_log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
enable_gated_hold_constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
enable_macro_pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
enable_memory_pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
enable_netlist_pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
enable_parallel_sweeps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
enable_parasitic_sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
enable_rechar_reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
enable_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
energy_fast_mode_leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
energy_fast_mode_leakage_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
ensure_constraint_monotonicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
event_rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
excluded_acquisitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
extrapolate_ccs_cin_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
finesim_so_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
force_removal_recovery_modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
fr_archive_condition_on_failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
fr_archive_condition_on_success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811

xxx
 Contents

fse_preprocess_cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
fse_user_cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
gate_leakage_time_scaling_factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
generate_all_ccbs_after_passgate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
graphviz_location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
gzip_cellmodel_libs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
harness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
HDL_cell_postprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
hdl_vector_time_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
hierarchy_separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
hsp_keep_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
hspice_client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
ibis_add_submodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
ibis_ami . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
ibis_ami_bit_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
ibis_ami_sample_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
ibis_ami_taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
ibis_ami_weights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
ibis_c_comp_user_only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
ibis_clamping_curve_make_monotonic . . . . . . . . . . . . . . . . . . . . . . . . . 817
ibis_clamping_iv_analysis_mode_dc . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
ibis_clamping_iv_num_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
ibis_cref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818
ibis_diff_pin_single_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
ibis_odt_driver_only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
ibis_odt_linear_regression_max_scale . . . . . . . . . . . . . . . . . . . . . . . . . . 819
ibis_odt_linear_regression_min_scale . . . . . . . . . . . . . . . . . . . . . . . . . . 819
ibis_odt_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
ibis_odt_mode_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
ibis_odt_pulldown_modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
ibis_odt_pullup_modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
ibis_odt_receiver_only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
ibis_pin_alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
ibis_pin_mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
ibis_plan_for_corner_merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
ibis_prog_driver_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
ibis_prog_driver_mode_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
ibis_rref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
ibis_single_pvt_corner_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823

xxxi
Contents

ibis_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
ibis_typ_pvt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
ibis_use_exact_mode_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
ibis_validate_bit_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
ibis_validate_bit_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
ibis_validate_input_pin_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
ibis_validate_prbs_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
ibis_validate_terminating_resistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
ibis_vcross_high . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
ibis_vcross_low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
ibis_vdiff_ac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
ibis_vdiff_dc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
ibis_version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
ibis_vinh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
ibis_vinh_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
ibis_vinh_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
ibis_vinh_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
ibis_vinl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
ibis_vinl_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
ibis_vinl_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
ibis_vinl_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
ibis_vmeas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
ibis_vmeas_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830
ibis_vmeas_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
ibis_vmeas_typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
ibis_vref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
ibis_vt_curve_make_monotonic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
ibischk_cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
ideal_netlist_ext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
import_explicit_points_per_arc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
import_liberty_ndw. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
initial_delay_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
insert_liberty_default_ndw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
init_internal_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
initialization_cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
internal_ground_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
internal_ground_supply_spice_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
internal_nodes_transition_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
internal_power_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835

xxxii
 Contents

internal_power_supply_spice_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
intrinsic_cap_with_phase_diff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
io_retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
job_scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
keep_loading_effect_with_pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
leakage_current_substitution_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
leakage_sum_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
left_bus_identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
liberty_attributes_at_bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
liberty_blackbox_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
liberty_cap_unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
liberty_cell_postprocess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
liberty_combine_complementary_models . . . . . . . . . . . . . . . . . . . . . . . . 840
liberty_constraint_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
liberty_current_unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
liberty_data_reduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
liberty_fast_option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
liberty_fill_out_power_with . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
liberty_flavor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
liberty_increasing_delay_with_ecsm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
liberty_increasing_delay_with_ccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
liberty_increasing_delay_with_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
liberty_increasing_delay_with_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
liberty_increasing_time_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
liberty_increasing_transition_with_load . . . . . . . . . . . . . . . . . . . . . . . . . 844
liberty_leakage_power_unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
liberty_max_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
liberty_max_capacitance_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
liberty_max_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
liberty_min_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
liberty_min_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
liberty_minimize_constraint_when . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
liberty_minimize_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
liberty_minimize_timing_when . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
liberty_multi_rail_format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
liberty_power_down_function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
liberty_power_down_function_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
liberty_resistance_unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
liberty_select_min_period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849

xxxiii
Contents

liberty_select_min_pulse_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
liberty_state_independent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
liberty_statetable_for_gcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
liberty_time_unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
liberty_timing_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
liberty_whens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
lvf_check_errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
lvf_check_sigma_pct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
lvf_check_slew_sigma_pct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
lvf_check_suppress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
lvf_constraint_models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
lvf_constraint_seed_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
lvf_enable_sanity_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
lvf_model_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
lvf_param_abs_threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
lvf_param_rel_threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
lvf_sigma_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
lvf_sigma_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
lvf_sigma_scaling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
lvf_to_ocv_input_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
lvf_to_ocv_load_indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
lvf_to_ocv_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
lvf_to_ocv_slew_indices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
lvf_to_ocv_output_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
lvf_tol_early_to_late . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
lvf_tol_sigma_to_nom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
make_cdb_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
make_small_dc_current_values_as_zero . . . . . . . . . . . . . . . . . . . . . . . . 857
max_constraint_iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
maximum_stack_depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
measure_side_input_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
memory_ccsn_partial_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
miller_capacitance_check_tolerance_pct . . . . . . . . . . . . . . . . . . . . . . . . 858
miller_capacitance_edge_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
miller_output_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
min_disk_space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
min_period_precharge_threshold_factor . . . . . . . . . . . . . . . . . . . . . . . . 859
min_period_with_precharge_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
minimum_constraint_sum_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860

xxxiv
 Contents

model_arc_and_pin_cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
model_as_non_unate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
model_back_bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
model_bundle_bit_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
model_bus_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
model_default_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
model_default_constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
model_default_power_arc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
model_ecsm_threshold_pct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
model_equalize_cap_averaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
model_exclude_supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
model_expanded_states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
model_failed_cells_in_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
model_input_leakage_current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
model_leakage_current_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
model_mpw_attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
model_neg_constraint_chk_opposite_edge . . . . . . . . . . . . . . . . . . . . . . 867
model_neg_constraint_sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
model_neg_constraint_sum_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
model_neg_constraint_sum_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . 868
model_negative_constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
model_negative_delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
model_negative_energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
model_negative_leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
model_normalized_constraint_driver_waveform . . . . . . . . . . . . . . . . . . . 869
model_normalized_driver_waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
model_pg_pin_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
model_pin_cap_calc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
model_power_on_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
model_power_per_supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
model_reverse_polarity_current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
model_rise_fall_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
model_rise_fall_capacitance_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
model_sensitization_vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
model_significant_digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
model_significant_digits_area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
model_uncharacterized_tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
mpw_rail_to_rail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
monitor_internal_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873

xxxv
Contents

mpp_simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
mpw_table_dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
mpw_v2_transition_inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
netlist_max_sweeps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
new_operating_condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
nmos_drn_gate_shorted_model_names . . . . . . . . . . . . . . . . . . . . . . . . 875
nmos_drn_src_shorted_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . 875
nmos_gate_src_shorted_model_names . . . . . . . . . . . . . . . . . . . . . . . . . 876
nmos_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
nochange_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
nochange_variance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
non_scan_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
normal_queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
normalized_driver_significant_digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
nsamples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
opc_grounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
opc_process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
opc_supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
opc_temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
opc_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
output_sweep_order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
param_change_period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
partition_by_output_transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
path_based_clock_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
path_based_signal_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
path_constraint_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
path_constraint_enable_negative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
path_constraint_enable_positive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
path_constraint_feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
path_constraint_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
path_constraint_pintype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
periodic_clock_stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
pin_name_alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
pmos_drn_gate_shorted_model_names . . . . . . . . . . . . . . . . . . . . . . . . 883
pmos_drn_src_shorted_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . 883
pmos_gate_src_shorted_model_names . . . . . . . . . . . . . . . . . . . . . . . . . 884
pmos_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
point_to_point_default_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884

xxxvi
 Contents

potential_internal_node_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
power_dynamic_end_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
power_load_energy_on_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
power_meas_grounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
power_meas_map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
power_meas_supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
power_stabilization_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
power_stabilization_threshold_absolute . . . . . . . . . . . . . . . . . . . . . . . . . 887
prechar_autorange_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
prechar_binning_abs_tol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
prechar_binning_constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
prechar_binning_hidden_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
prechar_binning_max_bins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
prechar_binning_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
prechar_binning_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
prechar_binning_power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
prechar_binning_rel_tol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
prechar_binning_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
prechar_enable_fast_analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
prechar_keep_intermediate_files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
prechar_numsteps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
prechar_sampling_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
prechar_simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
prechar_state_partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
preferred_switching_input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
reduce_ccs_power_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
primary_index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
propagate_warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
publish_internal_pin_states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
receiver_cap_for_zdisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
receiver_trip_threshold_pct_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
receiver_trip_threshold_pct_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
rechar_add_attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
rechar_update_attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
reduce_ecsm_power_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
replace_negative_leakage_with . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
report_constraint_iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
res_model_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
right_bus_identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897

xxxvii
Contents

run_list_maxsize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
running_prechar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
save_farm_logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
scan_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
scan_input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
scan_enable_inverted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
scan_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
scan_output_inverted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
scan_start_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
scan_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
scd_debug_subtract_power_tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
scheduler_poll_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
sdf_cond_equality_operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
secondary_run_list_maxsize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
separate_cell_initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
separate_cell_initialization_levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
signal_capture_pct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
simcomp_version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
simulator_case_sensitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
simulation_max_inactive_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
simulation_max_runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
simulation_node_initialization_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
simulation_tmpdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
simulator_bisection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
simulator_cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
simulator_default_options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
simulator_options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
simulator_warning_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
single_bit_degenerate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
single_cell_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
sis_cell_type_memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
sis_exclude_internal_power_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
sis_gzip_enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
sis_gzip_enable_for_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
sis_pruning_with_flat_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
sishapes_channel_length_offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
sishapes_minimum_feature_length . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
slew_derate_lower_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909

xxxviii
 Contents

slew_derate_upper_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
slew_matching_cin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
spectre_ccb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
spectre_fake_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
spectre_macmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
srf_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
stat_hold_sensitivity_ratios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
state_coverage_exclude_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
state_partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
state_rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
state_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
statistical_avoid_screening_acquisition . . . . . . . . . . . . . . . . . . . . . . . . . 913
statistical_constraint_screening_points . . . . . . . . . . . . . . . . . . . . . . . . . . 913
statistical_constraint_screening_tolerance . . . . . . . . . . . . . . . . . . . . . . . 914
statistical_enable_constraint_sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . 914
statistical_model_sigma_montecarlo . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
statistical_montecarlo_sample_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
statistical_reduction_factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
statistical_screening_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
statistical_screening_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
statistical_significant_transistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
statistical_simulation_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
statistical_simulator_bisection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
statistical_timing_abs_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
statistical_timing_rel_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
statistical_two_sided_screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
statistical_use_pruned_netlist_for_nominal . . . . . . . . . . . . . . . . . . . . . . 917
submit_list_maxsize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
subtract_pin_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
sweep_states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
table_dimension_for_internal_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
table_dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
time_res_high . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
time_res_low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
update_cache_last . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
use_ccs_init_delay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
use_ccs_native_current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
use_ccsn_initial_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
use_exact_when . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921

xxxix
Contents

use_gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
use_measured_slew_for_combined_setuphold . . . . . . . . . . . . . . . . . . . 921
use_save_for_initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
use_simulator_licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
verilog_atpg_syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
verilog_combine_function_timing_blocks . . . . . . . . . . . . . . . . . . . . . . . . 922
verilog_default_combinational_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
verilog_default_constraint_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
verilog_default_sequential_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
verilog_delay_path_polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
verilog_flavor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
verilog_function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
verilog_functional_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
verilog_hierarchy_separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
verilog_model_notifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
verilog_model_power_as_inout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
verilog_model_power_as_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
verilog_model_power_supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
verilog_model_removal_as_hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
verilog_model_use_recrem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
verilog_model_use_setuphold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
verilog_notifier_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
verilog_table_indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
verilog_udp_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
verilog_unit_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
verilog_unused_pins_format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
vg_allow_floating_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
vg_enable_constraint_measurements . . . . . . . . . . . . . . . . . . . . . . . . . . 929
vg_enable_hidden_measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
vg_enable_pulse_measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
vg_enable_steady_measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
vg_enable_switching_measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
vg_explicit_leakage_states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
vg_log_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
vg_max_arcs_per_input_transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
vg_max_leakage_states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
vg_partial_circuit_collapse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
vg_restricted_inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
vg_restricted_states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932

xl
 Contents

vg_state_selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
voltage_name_map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
weak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
whens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
workers_as_daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
pintype Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
acquire_ccs_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
acquire_retaining_arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
aocv_input_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
autorange_height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
autorange_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
autorange_load_minmax_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
autorange_load_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
autorange_timeshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
bundle_from . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
bundle_to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
bundle_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
bus_from . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
bus_to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
bus_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
ccs_max_voltage_error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
ccs_power_max_current_error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
ccsn_dc_normalize_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
ccsn_default_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
ccsn_iv_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
ccsn_numsteps_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
cin_bias_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
cin_high_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
cin_high_threshold_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
cin_high_threshold_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
cin_low_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
cin_low_threshold_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
cin_low_threshold_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
clock_active_period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
clock_inactive_period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
common_differential_cin_input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
configure_delay_from_outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
constraint_alternate_input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
constraint_autorange_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954

xli
Contents

constraint_default_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
constraint_default_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
constraint_dependent_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
constraint_explicit_points_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
constraint_explicit_points_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
constraint_glitch_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
constraint_largest_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
constraint_largest_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
constraint_monotonic_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
constraint_numsteps_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
constraint_numsteps_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
constraint_resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
constraint_scaled_points_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
constraint_scaled_points_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
constraint_smallest_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
constraint_smallest_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
current_resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
cycle_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
decap_fall_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
default_bus_value_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
default_bus_value_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
default_height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
default_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
default_load_index_position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
default_load_index_position_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
default_load_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
default_load_pct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
default_load_scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
default_pintype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
default_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
default_total_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
default_total_slew_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
default_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
default_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
delay_matching_cin_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
delay_matching_cin_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
dependent_max_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
differential_pair_timing_duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
differential_slew_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965

xlii
 Contents

dontcare_bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
dontcare_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
downto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
driver_fall_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
driver_initial_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
driver_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
driver_pwl_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
driver_pwl_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
driver_pwls_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
driver_pwls_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
driver_rise_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
driver_waveform_limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
driver_waveform_min_dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
driver_waveform_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
ecsm_fixed_levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
ecsm_higher_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
ecsm_lower_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
ecsm_threshold_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
ecsm_use_fixed_levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
ecsm_waveform_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
em_table_with_current_types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
emulated_driver_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
enable_clamped_predriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
enable_common_mode_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
enable_multi_threshold_receiver_cap . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
exclude_ecsm_start_end_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
explicit_points_frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
explicit_points_height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
explicit_points_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
explicit_points_rload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
explicit_points_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
explicit_points_timeshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
explicit_points_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
explicit_points_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
failure_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
failure_threshold_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
failure_threshold_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
fallback_threshold_pcts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977

xliii
Contents

force_driver_char_reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
full_transition_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
full_transition_fall_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
full_transition_rise_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
glitch_high_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
glitch_low_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
hyper_coeffs_three_point_method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
ibis_above_rail_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
ibis_acq_to_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
ibis_acq_to_model2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
ibis_below_rail_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
ibis_c_comp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
ibis_composite_current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
ibis_copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
ibis_default_r_fixture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
ibis_disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
ibis_ground_clamp_supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
ibis_input_differential_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
ibis_input_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
ibis_input_pin_open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
ibis_isso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
ibis_iv_diff_pin_v_sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
ibis_manufacturer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
ibis_max_gnd_clamp_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
ibis_max_power_clamp_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
ibis_max_pulldown_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
ibis_max_pullup_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
ibis_min_gnd_clamp_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
ibis_min_power_clamp_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
ibis_min_pulldown_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
ibis_min_pullup_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
ibis_model_to_acq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
ibis_notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
ibis_numsteps_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
ibis_output_differential_nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
ibis_output_node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
ibis_power_clamp_supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
ibis_rail_extrapolate_linear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
ibis_typ_gnd_clamp_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988

xliv
 Contents

ibis_typ_power_clamp_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
ibis_typ_pulldown_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
ibis_typ_pullup_ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
ibis_vt_v_fixture_differential_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
ibis_vt_v_fixture_falling_non_differential_output . . . . . . . . . . . . . . . . . . . 990
ibis_vt_v_fixture_rising_non_differential_output . . . . . . . . . . . . . . . . . . . 990
initial_common_mode_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 990
initial_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
largest_frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
input_fall_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
input_rise_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
largest_height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
largest_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
largest_rload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
largest_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
largest_timeshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
largest_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
largest_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
liberty_bundle_as_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
liberty_bus_as_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
liberty_internal_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
liberty_pin_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
liberty_tmax_input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
liberty_tmax_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
limit_noise_pulse_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
logic_high_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
logic_high_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
logic_high_param_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
logic_high_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
logic_high_threshold_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
logic_high_threshold_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
logic_low_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
logic_low_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
logic_low_param_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
logic_low_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
logic_low_threshold_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
logic_low_threshold_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
max_asynch_recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
max_asynch_removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001

xlv
Contents

max_cmpw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
max_constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
max_constraint_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
max_hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
max_hold_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
max_min_period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
max_ncmpw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
max_recover_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
max_recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
max_removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
max_removal_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
max_setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
max_setup_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
max_tout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
max_width_factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
maxload_tout_resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
min_adjust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
min_asynch_recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
min_asynch_removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
min_cmpw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
min_constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
min_constraint_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
min_hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
min_hold_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
min_min_period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
min_ncmpw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
min_recover_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
min_recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
min_removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
min_removal_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
min_setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
min_setup_hbm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
mpw_min_adjust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
nochange_clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
node_activity_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
node_stability_pruning_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
noise_immunity_current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
noise_immunity_from_prop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011

xlvi
 Contents

noise_immunity_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
num_ccs_samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
numsteps_frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
numsteps_height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
numsteps_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
numsteps_rload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
numsteps_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
numsteps_timeshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
numsteps_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
numsteps_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
opt_load_high . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
opt_load_low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
partial_swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
output_fall_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
output_rise_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
partial_swing_minimum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
passive_glitch_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
peak_ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
phased_inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
pin_category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
pintype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
pocv_input_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
power_period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
prop_delay_current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
prop_delay_inp_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
prop_delay_inp_level_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
prop_delay_inp_level_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
prop_delay_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
prop_delay_out_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
prop_delay_out_level_fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
prop_delay_out_level_rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
rc_filter_capacitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
rc_filter_resistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
scaled_points_frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
scaled_points_height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
scaled_points_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
scaled_points_rload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
scaled_points_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022

xlvii
Contents

scaled_points_timeshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
scaled_points_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
scaled_points_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
si_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
side_pin_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
skip_constraint_outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
slew_based_margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
smallest_frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
smallest_height . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
smallest_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
smallest_rload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
smallest_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
smallest_timeshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
smallest_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
smallest_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
smc_constraint_style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
smc_degrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
smc_degrade_absolute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
smc_degrade_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
smc_degrade_maximum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
smc_degrade_pushout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
smc_max_degrade_absolute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
smc_slew_degrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
smc_slew_degrade_absolute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
soi_transition_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
stable_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
subtract_leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
sweep_method_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
sweep_method_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
switchpoint_default_slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
target_bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
tie_cell_load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
total_slew_multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
trailing_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
use_floating_hiz_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
verilog_attach_edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
voltage_resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
voltage_resolution_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
validation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035

xlviii
 Contents

absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
capacitance_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
capacitance_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
capacitance_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
ccs_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
ccs_noise_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
ccs_noise_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
ccs_noise_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
ccs_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
ccs_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
ccsn_current_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
ccsn_current_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
ccsn_current_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
ccsn_height_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
ccsn_height_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
ccsn_height_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
ccsn_output_voltage_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . 1044
ccsn_output_voltage_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . 1044
ccsn_output_voltage_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . 1045
ccsn_width_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045
ccsn_width_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045
ccsn_width_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
compare_library_interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
compare_library_top_failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
data_range_max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
data_range_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
delay_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
delay_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
delay_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
delay_sensitivity_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
delay_sensitivity_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
delay_sensitivity_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
delay_variance_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
delay_variance_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
delay_variance_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
ecsm_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
ecsm_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
ecsm_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
enable_total_power_comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051

xlix
Contents

energy_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
energy_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
energy_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
gends_config_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
generate_sdf_cmd_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
hdl_target_simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
hdl_target_simulator_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
hold_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
hold_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
hold_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
hyperbolic_noise_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
hyperbolic_noise_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
hyperbolic_noise_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
index_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
input_capacitance_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
input_capacitance_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
input_capacitance_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
leakage_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
leakage_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
leakage_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
mpw_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
mpw_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
mpw_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
nochange_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
nochange_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
nochange_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
noise_immunity_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
noise_immunity_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
noise_immunity_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060
noise_iv_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060
noise_iv_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060
noise_iv_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
noise_prop_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
noise_prop_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
noise_prop_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
qualification_10nm_mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
qualification_data_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
qualification_correlation_lc_shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063

l
 Contents

qualification_lc_compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
qualification_lc_shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
qualification_lc_suppress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
recovery_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
recovery_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
recovery_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
removal_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
removal_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065
removal_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066
retain_slew_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066
retain_slew_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066
retain_slew_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
retaining_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
retaining_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
retaining_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
sdf_source_tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
sdf_source_tool_cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
setup_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
setup_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
setup_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
slew_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
slew_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
slew_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
slew_sensitivity_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
slew_sensitivity_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
slew_sensitivity_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
slew_variance_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
slew_variance_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
slew_variance_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
zdis_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
zdis_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
zdis_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
zen_absolute_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
zen_product_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
zen_relative_tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Selecting the SOI Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
Characterizing and Modeling for SOI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076

li
Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Using Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1080
Looping and Conditional Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
Using the API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086
API Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087
add_obj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
copy_obj. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
del_obj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
get_models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
get_obj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
get_obj_attr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
get_obj_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092
get_obj_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
get_obj_match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
get_obj_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
get_obj_owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
get_obj_type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
get_order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
get_style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
get_style_by_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
read_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
remove_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
set_obj_attr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
set_obj_multi_attr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103
set_obj_name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
set_order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
set_order_by_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
set_style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
set_style_by_id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
unset_obj_attr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
write_model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Signal Extensions for Tcl/Tk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Python 2.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
libjpeg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Tcl/Tk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115

lii
 Contents

TclPro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116
CUDD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
elmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
zlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
itcl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
BLT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
SWIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
Berkeley DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
libedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Graphviz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125
Eclipse Public License - v 1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125
Gnuplot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125
GNU Lesser General Public License v2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127

liii
Contents

liv
 About This Manual

This user guide describes how to use the SiliconSmart tool to perform library
characterization from a set of cell functional descriptions, associated SPICE
netlists, and process model files. This manual is intended for engineers who
create .lib libraries.

Conventions
The following conventions are used in Synopsys documentation.

Convention Description

Courier Indicates command syntax.

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

Purple ■ Within an example, indicates information of special

interest.
■
Within a command-syntax section, indicates a default
value, such as:
include_enclosing = true | false

Bold ■ Within syntax and examples, indicates user input—text

you type verbatim.
■ Indicates a graphical user interface (GUI) element that has
an action associated with it.

[] Denotes optional parameters, such as:

write_file [-f filename]

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

necessary:pin1 pin2 ... pinN

| Indicates a choice among alternatives, such as:

low | medium | high

SiliconSmart ACE User Guide lv

L-2016.03
About This Manual
Customer Support

Convention Description

\ Indicates a continuation of a command-line.

/ Indicates levels of directory structure.

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

Ctrl+C Indicates a keyboard combination, such as holding down the

Ctrl key and pressing the C key.

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

Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles and
answers to frequently asked questions about Synopsys tools. SolvNet also
gives you access to a wide range of Synopsys online services, which include
downloading software, viewing Documentation on the Web, and entering a call
to the Support Center.
To access SolvNet:
1. Go to the SolvNet Web page at https://solvnet.synopsys.com.
2. If prompted, enter your user name and password. If you do not have a
Synopsys user name and password, follow the instructions to register with
SolvNet.
If you need help using SolvNet, click Help on the SolvNet menu bar.

Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys
Technical Support Center in the following ways:

lvi SiliconSmart ACE User Guide

L-2016.03
 About This Manual
Customer Support

■
Open a case with your local support center from the Web by going to
https://solvnet.synopsys.com/EnterACall (Synopsys user name and
password required). Choose the Open A Support Case tab to begin.
■
Send an e-mail message to your local support center.
• E-mail support_center@synopsys.com from within North America.
• Find other local support center e-mail addresses at
http://www.synopsys.com/support/support_ctr.
■
Telephone your local support center.
• Call (800) 245-8005 from within the continental United States.
• Call (650) 584-4200 from Canada.
• Find other local support center telephone numbers at
http://www.synopsys.com/support/support_ctr.

SiliconSmart ACE User Guide lvii

L-2016.03
About This Manual
Customer Support

lviii SiliconSmart ACE User Guide

L-2016.03
 1
1

Introduction

This chapter introduces the SiliconSmart tool, its scope, capabilities, basic
usage and syntax.

The SiliconSmart tool is the industry leading characterization and modeling

solution focused on producing high quality cell libraries for today’s advanced
nanometer processes. It has been designed from the ground up to handle a full
range of cells, from high-performance standard cells to advanced I/O cells
implementing the latest communications protocols, and embedded memories,
including RAMs, ROMs, and register files.
SiliconSmart supports for the latest modeling formats such as Nonlinear Delay
Model (NLDM) format for timing and Nonlinear Power Model (NLPM) for power
analysis, Liberty SI model, Composite Current Source Models (CCS) for timing,
power and noise, Cadence Effective Current Source Models (ECSM) for timing
and power, I/O Buffer Information Specification (IBIS) modeling format, and
variation aware timing models. These modeling extensions enable you to
generate consistent models across multiple tools and multiple vendors.
The following topics are described in this chapter:
■
SiliconSmart Architecture
■
SiliconSmart Usage

SiliconSmart ACE User Guide 1

L-2016.03
Chapter 1: Introduction
SiliconSmart Architecture

SiliconSmart Architecture
The SiliconSmart architecture consists of the following components:
■
SiliconSmart Shell:
• Includes a Tcl shell interface called siliconsmart. This shell has
been extended with SiliconSmart commands that provide a rich set of
features to manage characterization and modeling over a distributed
network.
• Provides access to the SiliconSmart characterization and modeling
engines.
■
Job Management System (JMS):
• Schedules characterization jobs across the network using one of
several job scheduling modes: Platform® Load Sharing Facility (LSF®),
SunSM Grid Engine, NC, or stand-alone.
• Allocates CPU and license resources for the characterization and
modeling engines.
■
Characterization Engine:
• Generates and executes the SPICE simulations necessary to acquire
the data necessary to model the signal integrity behavior of a cell
accurately.
• Builds a central database of the timing, power, and signal integrity data
from the distributed circuit simulations.
■
Modeling Engine:
• Builds Liberty models for a library of standard cells for use with
Synopsys PrimeTime and compatible tools.
• Builds effective current source models (ECSMs) for a library of standard
cells for use with Cadence® SignalStorm™.

2 SiliconSmart ACE User Guide

L-2016.03
 Chapter 1: Introduction
SiliconSmart Usage

The following figure illustrates the SiliconSmart architecture:

Figure 1 SiliconSmart Architecture

SiliconSmart Usage
A basic understanding of the information in this chapter is helpful for successful
usage of the tool and is necessary if you want to integrate SiliconSmart into
your automated library design flow.
The following sections describe basic SiliconSmart usage:
■
SiliconSmart Syntax
■
Entering SiliconSmart Commands
■
Logging

SiliconSmart ACE User Guide 3

L-2016.03
Chapter 1: Introduction
SiliconSmart Usage

SiliconSmart Syntax
You can use the siliconsmart command to launch the SiliconSmart shell or
to execute a command script for automated processing. The siliconsmart
command has the following syntax:
siliconsmart [-help] [-x command] [-commands] [script_file]

The following table describes the optional arguments to the siliconsmart

command.
Table 1 SiliconSmart Command Options

Option Description

-commands Displays a summary of the Tcl commands available

from within siliconsmart.

-help Displays a summary of the command-line options

available for siliconsmart.

-x command Executes command within siliconsmart and then

enters interactive mode.

script_file Name of a Tcl script to be executed by

siliconsmart.

SiliconSmart uses an industry-standard Tcl interpreter as the basis of the

siliconsmart command. This interpreter has been extended with a powerful
set of commands that control characterization and modeling of a set of cells.
Using siliconsmart, you can control all of the SiliconSmart functionality. If
provided with a Tcl script, siliconsmart executes the commands in the Tcl
script and exits when complete. This can be useful for automating frequently
used operations.

Entering SiliconSmart Commands

When used interactively, the SiliconSmart tool follows the Tcl standard of
supporting partial-name completion of all commands. This means that you
must type only enough of a command name to uniquely identify it. For example,
the characterize and configure commands could be entered as char
and config.

4 SiliconSmart ACE User Guide

L-2016.03
 Chapter 1: Introduction
SiliconSmart Usage

Some SiliconSmart commands take additional options and data values.

Command options are specified with option switches. Each option switch
consists of a dash followed by the option name. Similar to command names,
the option name can be shortened by typing only enough characters to
uniquely identify it. Some option switches require a data value as well. This is
entered after the option name, with a space separating the two.
For example, the import command accepts the options –netlist and
–liberty. The –netlist option requires a path to a SiliconSmart
characterization directory. The -extension option requires a file name
extension for the cell netlist.
For example, you can enter the command as follows:
sis_cci> import –liberty my_io.lib –netlist_dir netlists
-extension .spi my_io_cell

You can also abbreviate the options as follows:

Example 1
sis_cci> import –lib my_io.lib –netlist_dir netlists
-ext .spi my_io_cell

For detailed information about SiliconSmart commands, see Chapter 14,

Command Reference.

Command Help
SiliconSmart provides a description of each command through the help
command. Entering the help command by itself displays usage lines for all
commands. The help command also accepts the name of a command or a
wildcard pattern for selecting one or more commands. If a single command is
specified, help displays the usage of the command and a summary of its
behavior. If multiple commands are selected with a wildcard expression, the
help command displays the usage line for all selected commands. For
example, entering the command help *location, produces the following
output:
Example 2
Command Usage
------------------------- -------------------------------------
get_location get_location
set_location set_location directory

SiliconSmart ACE User Guide 5

L-2016.03
Chapter 1: Introduction
SiliconSmart Usage

See Also
■
Command: help

Specifying Cells
Many commands in siliconsmart operate on one or more cells at a time.
For instance, characterize can be used to characterize one cell or a set
of cells. Each of these commands accepts the following forms:
■
All cells — If the keyword all is used, all cells in the current characterization
directory are selected. This is the default when nothing is specified. The
following example characterizes all cells in the current characterization
directory:
characterize all
■
One or more cells — The names of one or more cells can be specified on
the command-line. The following example characterizes the cells BUF1 and
NAND1:
characterize BUF1 NAND1
■
List of cells — A Tcl list of cell names can also be specified as an argument
on the command-line. The following example characterizes the cells BUF1
and NAND1:
set cell_list {BUF1 NAND1}
characterize cell_list
■
Wildcard expression — Any cell names matching the expression are
selected. The following example characterizes all cells beginning with BUF
or NAND:
characterize BUF* NAND*

Logging
SiliconSmart keeps a log file of everything it does. This provides a mechanism
to check for errors or warnings after running the tool. By default, the log file is
named siliconsmart.log. You can change the file name and the directory to
which it is saved with the set_log_file command.
Each logged message has a severity level of ERROR, WARNING, INFO, or
VERBOSE. By default, all messages of informational level or higher are written
to the log file. The level of messages displayed and written to the log file can be

6 SiliconSmart ACE User Guide

L-2016.03
 Chapter 1: Introduction
SiliconSmart Usage

controlled with the commands set_log_level and

set_log_stdout_level, respectively.
With custom scripts, you can write messages to the log as well. You can use
the commands log_error, log_warning, and log_info to write
messages of the appropriate severity.
When processing a complete library of cells, the log file can grow very large.
You can use the command set_log_max_size to set a maximum size for the
log file. When the log reaches this size, the file is renamed with the extension
.old (such as siliconsmart.log.old) and a new log file is created.
See Also
■
Commands: set_log_file, set_log_level, set_log_stdout_level

SiliconSmart ACE User Guide 7

L-2016.03
Chapter 1: Introduction
SiliconSmart Usage

8 SiliconSmart ACE User Guide

L-2016.03
 2
2

Setting Up SiliconSmart

This chapter describes setting up the SiliconSmart tool and performing tasks
required for characterization.

Standard characterization produces timing and power models, such as those

specified in the Liberty format. The SiliconSmart tool is also capable of
capturing signal integrity noise data, current source waveforms (ECSM or
CCS), power data, and other information. The setup procedures described in
this chapter apply to all formats.
The following sections describe tasks required for characterization:
■ Managing Your Job Scheduler
■
Using CDPL
■
Managing Licenses
■ Selecting a Simulator
■
Setting Up Your Environment

Managing Your Job Scheduler

This section introduces job scheduling (or load sharing) and describes the tools
you can use for scheduling jobs in the SiliconSmart tool. Load sharing refers to
the process of distributing a workload across multiple processors within the
same computer system and/or multiple CPUs within local-area and wide-area
networks. The SiliconSmart tool supports load sharing through LSF, Grid
Engine, and NC.

SiliconSmart ACE User Guide 9

L-2016.03
Chapter 2: Setting Up SiliconSmart
Managing Your Job Scheduler

A job generally refers to a characterization sequence for a specific cell. The job
is initiated by the job scheduler with a specified job or process ID. You can use
any of the following methods for job scheduling with SiliconSmart:
■
Stand-alone mode — An operational mode of the SiliconSmart tool in which
load sharing is not used, and tool runs all jobs on the local machine.
■
LSF — Load Sharing Facility, a suite of products created and maintained by
Platform Computing Corporation that maximizes computational resources
by controlling the creation, scheduling, and distribution of jobs across a
network of machines.
■
Grid Engine — Sun Grid Engine, a resource management software solution
from Sun Microsystems™.
■
NC — NetworkComputer, a high performance job scheduler from Runtime
Design Automation™.

Setting a Job Scheduler

To designate a job scheduler, you must set the job_scheduler parameter to
grid, LSF, NC, or standalone. You can set this parameter in the configure.tcl file.
If you leave this parameter undefined, the SiliconSmart tool uses standalone.

Stand-Alone Mode
When you execute the SiliconSmart tool in stand-alone mode, it runs on your
local machine without a network. The SiliconSmart tool submits all cell
characterization jobs to your local machine as a background process.
To run the SiliconSmart tool with this job scheduling option, set the
job_scheduler parameter to standalone in the configure.tcl file. In
stand-alone mode, no queue exists. Therefore, when in stand-alone mode, the
SiliconSmart tool ignores the submit_list_maxsize parameter and uses
run_list_maxsize to determine the number of jobs to run simultaneously.

Load Sharing Facility (LSF)

You or your systems administrator must install and set up LSF. For more
complete information about LSF, see the LSF Installation Guide.

10 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Managing Your Job Scheduler

To configure the SiliconSmart tool to run with your LSF installation, set the
job_scheduler parameter to LSF in your configure.tcl file.
Table 2 describes some of the LSF commands and options that you can use in
the SiliconSmart tool to monitor submitted jobs. For more information about
LSF, see the LSF User’s Guide.
Table 2 LSF Commands and Options

Command Option Description

bjobs - Lists the jobs submitted to the LSF server.

- -J jobname Lists a specific job, specified by the job name.

- -u all Lists all jobs submitted from all users.

bkill - Terminates one or more LSF jobs, or removes them

from the queue.

- -J jobname Terminates a specific job, specified by the job name you

want to terminate.

- 0 Terminates all jobs for the current user.

Table 3 describes the types of status that LSF reports.

Table 3 LSF Status Descriptions

Status Description

pend The job is waiting for an available resource. It has not yet been started.

run The job for the submitted cell is running.

Sun Grid Engine

You or your system administrator must install and set up Grid Engine. For more
complete information about Grid Engine, see the Sun Grid Engine 6.0 Manual.

SiliconSmart ACE User Guide 11

L-2016.03
Chapter 2: Setting Up SiliconSmart
Using CDPL

To configure the SiliconSmart tool to run with your Grid Engine installation,
complete the following steps:
1. Put Grid Engine binaries in your PATH by sourcing the Grid Engine settings
file with the following commands:
• For Bourne shell — source grid_install_path/default/common/
settings.sh
• For C shell — source grid_install_path/default/common/settings.csh
2. If this is a site-wide configuration, set the job_scheduler parameter in
your site_config file as follows:
job_scheduler = "grid";

Grid Engine is implemented using wrapper scripts. For more complete

information about Grid Engine, see the Sun Grid Engine 6.0 Manual.

RTDA NC
The SiliconSmart tool supports Runtime Design Automation's
NetworkComputer (NC) as a job scheduler. This can be used by setting the
name of the parameter job_scheduler to nc. Because a cluster in NC is
equivalent to a queue in LSF, you must specify a cluster name as the value of
normal_queue.

Note: Do not add -q to the beginning of the normal_queue value.

This is added by default and including it will error out the run.

Using CDPL
The Common Distributed Processing Library (CDPL) is a common framework
available to all Synopsys applications needing to incorporate parallel
computing. Parallel computing, a process in which a single task is divided into
smaller tasks which are then executed concurrently, can be used effectively to

12 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Using CDPL

meet the increased demands of certain EDA applications for computation,

performance, memory, and data.
CDPL is invoked internally by default to identify and bundle tasks and submit
and monitor jobs to complete characterization of libraries.
■
Introduction
■
CDPL Interface
■
Using CDPL Parameters in SiliconSmart
■
CDPL Logs and Files
■
CDPL Debugging
■
Secondary Queue
■
Additional CDPL Information

Introduction
CDPL is set as the distributed computing engine when the parameter
advanced_dp is set to 1. It is on by default, which is the preferred and
recommended distributed processing engine.
It supports most standard farm software (LSF, SGE, RTDA-NC, Custom Pool,
Local-Standalone).
Within the SiliconSmart tool, CDPL:
■
Creates a “master” process that identifies which tasks need to be
performed. It then bundles the tasks together and, depending on the user
farm and job scheduler settings, submits the jobs to the farm by sending the
tasks to “workers”.
■ Controls the workers and their tasks (start/stop/kill).
■
Manages any task dependencies and passes any string messages between
the workers and master.
■
Monitors unexpected issues of the workers and master and the channel
between them.

SiliconSmart ACE User Guide 13

L-2016.03
Chapter 2: Setting Up SiliconSmart
Using CDPL

The following figure shows this relationship and process:

CDPL Interface
The CDPL integration in SiliconSmart is seamless for the user. Since it is
turned on by default, the user does not have to make any setup changes.
Several parameters have been made available to control the master and worker
jobs; however, these have set defaults such that the user may not have to
change them unless faced with farm/network problems. See Using CDPL
Parameters in SiliconSmart for more information on these parameters.
Below are some examples of specifying the job_scheduler and
normal_queue parameter values for running SiliconSmart on supported farm
software:
■
For SGE/GRID:
set_config_opt job_scheduler grid
set_config_opt normal_queue {-P bnormal –l mem_free=2G}
■
For LSF:
set_config_opt job_scheduler lsf
set_config_opt normal_queue {bnormal -R "rusage[mem=2000]"}
■
For RTDA-NC:
set_config_opt job_scheduler nc
set_config_opt normal_queue {-r rhel5 –e DEFAULT}

14 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Using CDPL

See Also
■
Command: set_config_opt
■
Parameter: job_scheduler
■
Parameter: normal_queue

Using CDPL Parameters in SiliconSmart

The following sections detail the various types of CDPL parameters and their
usage in the SiliconSmart tool:
■
Launch Control Parameters
■
Worker Control Parameters

Launch Control Parameters

Once a master process is launched, it needs to bundle the tasks to be executed
(configure jobs, simulation jobs, modeling jobs, etc.) and submit workers to
execute these tasks. Due to machine or farm issues, the master process may
or may not be able to submit worker tasks successfully.
A parameter cdpl_submission_timeout is available to define the wait time
before the master declares that the launch command is a failure.
This parameter should be set to a reasonable time value, depending on the
nature and behavior of the farm. Setting it to a very low time value will not allow
sufficient time to be spent waiting for the slots to get assigned on over-stressed
farms. Setting it to a very high time will cause the master to wait for too long in
case there are actual farm issues.
It has been observed that in some customer environments, farm policies forbid
shell modes of general bsub/qsub commands for LSF/SGE. In such scenarios
it is possible to set the parameter cdpl_alt_submission to 1 and provide
the alternative submission command with the cdpl_submission_cmd
parameter.
See Also
■
Parameter: cdpl_alt_submission
■
Parameter: cdpl_submission_cmd
■
Parameter: cdpl_submission_timeout

SiliconSmart ACE User Guide 15

L-2016.03
Chapter 2: Setting Up SiliconSmart
Using CDPL

Worker Control Parameters

Once the master is able to successfully submit workers (and their tasks) on the
farm, the user has certain controls to monitor and control the behavior of the
workers depending on the health of the farm and characterization runtime.
To avoid workers idling for too long (without performing actual work) set
cdpl_worker_timeout to a small value. The default is reasonable and can
be used as-is. However, in some scenarios of scarce farm resources, you may
want to increase this time-out to a larger value so that workers do not give up
their occupied machines.
While running a complex circuit through the characterization flow, there is a
good chance that some arcs (potentially the constraint arcs) may take a long
time to finish. The SiliconSmart tool will print warnings in the run log file
(siliconsmart.log or one set by set_log_file) to alert the existence of such
long running tasks. It is possible to avoid these warnings by setting a large time
value to parameter cdpl_long_task_alert if the run is known to take a
long time to finish.
The warnings provide a JobID and a WorkerID to help the user to kill such jobs
in case of issues. For example:
Example 3
Warning: Job 125 with the following tasks on W22 has been going
on for more than 3600 seconds

setup__A__lh__CLK__lh__ACQ_1 of mycell

Large/complex circuit characterization may typically take longer to finish

characterizing all arcs. It is possible that network/farm policies may prohibit
users from sustaining long running jobs in interest of freeing those machines up
for other users. The parameter char_engine_max_lifespan can be set so
that workers occupying machines exceeding this time interval will be
terminated. Any tasks remaining execution by the terminated workers will be re-
submitted depending on the value of parameter auto_fix. See Automatic
Reruns for more information on this parameter.
See Also
■
Parameter: auto_fix
■
Parameter: cdpl_long_task_alert
■
Parameter: cdpl_worker_timeout
■
Parameter: char_engine_max_lifespan
■
Command: set_log_file

16 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Using CDPL

CDPL Logs and Files

Once a SiliconSmart run is invoked, a new directory will be created under
$charpoint/runtime called “cdpl”.
Example log file:
Example 4
master.amsemt20c30.23404.err
master.amsemt20c30.23404.log

driver_23404.tcl
characterization_23404.tcl
configuration_23404.tcl
modeling_23404.tcl

run_23404.sh*

worker.W1.amsemt20c30.23460.log
worker.W2.amsemt20c30.23580.log
worker.W3.amsemt20c30.26188.log

sis.W1.amsemt20c30.23460.log
sis.W2.amsemt20c30.23580.log
sis.W3.amsemt20c30.26188.log

cell.stat.gz

Viewing CDPL Runtime Logs

Follow the below steps to view CDPL runtime information through the DP
Manager GUI:
1. Set the following environmental variable:
setenv CDPL_HOME </cad/tools/siliconsmart_20XX.XX/
cdpl_runtime

2. Execute the following at the char_point directory level to bring up the GUI:
$CDPL_HOME/bin/dpmanager

3. In the GUI, select File > Open and Analyze. A window appears.
4. In the window, select char_point > runtime > cdpl > master.*.log to view.

SiliconSmart ACE User Guide 17

L-2016.03
Chapter 2: Setting Up SiliconSmart
Using CDPL

CDPL Debugging
There may be a variety of reasons why a run of SiliconSmart launched on a
farm may fail. Outside of actual cell characterization and simulation failures
(which would be a cell, technology, device, methodology, or setup issue), this
section describes some of the best known methods for debugging CDPL and
farm related problems.
Some of the common guidelines to follow before launching jobs are to:
1. Check that the customer Farm Software is supported by CDPL.
2. Check that the machine is able to submit jobs (submit host).
3. Check that the user has appropriate permissions to submit jobs to the
respective farm.
4. Check that your launch scripts work well on standalone tests.
5. Check that all farm settings are sourced correctly through scripts.
6. Know your farm. Can the machine types all run the SiliconSmart tool? Is
there enough available memory? How is the reaction time (slowness,
loaded/stressed, farm conditions)?
Performing these checks ahead of running ensures that an appropriate set of
settings is being used that is conducive to the farm and the complexity of
circuits being characterized.
The following sections detail CDPL debugging:
■
Parameters for Debugging
■
Debugging Steps
■
Monitoring Log Files

Parameters for Debugging

The following parameters are useful for CDPL debugging:
■
Archive settings — these parameters help isolate any simulator-related
issues:
set_config_opt archive_condition_on_success yes
set_config_opt archive_condition_on_failure yes

18 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Using CDPL

■
save_farm_logs — this parameter saves the stderr and stdout logs from
remote machines where jobs were submitted.
■ set_log_level — set this parameter to verbose or debug to report
elaborate information in the log file to help debugging.
See Also
■
Parameter: archive_condition_on_success
■
Parameter: archive_condition_on_failure
■
Parameter: save_farm_logs
■
Command: set_log_level

Debugging Steps
CDPL provides a GUI, called “dpmanager”, which shows the status and health
of a run. It provides valuable information on how many workers were submitted,
how long have they been executing, or staying idle and so on.
To invoke the dpmanager GUI:
prompt> setenv CDPL_HOME <SIS_installation_path>/cdpl_runtime/
prompt> $CDPL_HOME/bin/dpmanager

SiliconSmart ACE User Guide 19

L-2016.03
Chapter 2: Setting Up SiliconSmart
Using CDPL

Select Open and Analyze and choose the master.machine.pid.log file from
$charpoint/runtime/cdpl. This will load all the worker information from the log
files to the user can view them easily.

Figure 2 Dpmanager GUI

When using the dpmanager GUI:

■
Green bars: finished tasks
■
Red bars: processing tasks (if the bar is very long, it’s taking too much time)
■
Grey bars: worker idling (no jobs)
■
Black spaces: a cluster of tiny tasks
■ White spaces: worker idling between phases
CDPL also has a utility called “log2tty”, which makes it simple to view the CDPL
log files in text format.
To invoke the log2tty utility:
prompt> setenv CDPL_HOME <SIS_installation_path>/cdpl_runtime/
prompt> $CDPL_HOME/bin/log2tty worker*log

20 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Using CDPL

Below is an example output from log2tty:

Figure 3 log2tty output

Monitoring Log Files

Typically, any critical farm issues or fatal problems will be reported in the
master.machine.pid.log and master.machine.pid.err file under $charpoint/
runtime/cdpl/
The actual qsub/bsub/nbjob command used for job submission will be present
in the $charpt/runtime/cdpl/master*.log file.
In case of job submission problems, it is worthwhile to check this so that all
your resource requirements and switches are being understood correctly by the
SiliconSmart tool.
To check if individual tasks have run into issues, you can look through the
$charpoint/runtime/cdpl/sis*.log files. These logs can also provide clues if the
run has any license-related issues.

Secondary Queue
The SiliconSmart tool allows a maximum of two different queues to group tasks
with different resource requirements on different machines. For example, a
library may contain simple cells which do not require high memory machines to
run, as well as more complex cells which need higher memory machines. To
avoid having to submit the whole library to a queue with high memory
machines, it is possible to use the secondary queue mechanism in
SiliconSmart/CDPL to categorize and divide.

SiliconSmart ACE User Guide 21

L-2016.03
Chapter 2: Setting Up SiliconSmart
Using CDPL

Consider the below example:

Example 5
set_config_opt job_scheduler lsf

set_config_opt normal_queue {bnormal –R rusage[mem=1000]}

set_config_opt run_list_maxsize 10
set_config_opt -type constraint normal_queue {blong –R
rusage[mem=4000]}

set_config_opt secondary_run_list_maxsize 5

The specification above is:

1. To occupy two queues on LSF farm.
2. All jobs will be submitted to queue “bnormal” with 1G machines, except for
any “constraint” type tasks, which will be submitted to queue “blong” with 4G
machines.
3. 10 workers will be launched on the primary queue and 5 workers will be
launched on the secondary queue.
It is important to understand some of the characteristics of the secondary
queue mechanism:
■
The primary and secondary queues must have the same job_scheduler
■
The secondary queue is supported on all types of job_scheduler values
except for custom
■
The secondary queue is available for the step only
■
Both the primary and secondary queue workers will share same CDPL
control options/parameters
■ Presently only 2 queues are supported
For example:

Example 6
set_config_opt normal_queue {bnormal ….}
set_config_opt –type energy normal_queue {bhuge ….}
set_config_opt –type constraint normal_queue {blong …}

Above, the primary queue will be “bnormal” and secondary queue will be
“blong”
■
The following is required to trigger the secondary queue mechanism:
• The parameter secondary_run_maxlist > 0

22 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Using CDPL

• At least one scoped normal_queue argument is provided

Additional CDPL Information

The following sections provide additional relevant information for using CDPL:
■
Automatic Reruns
■
Using RSH to Create a Custom Pool
■
Prevent CDPL from Clogging the Home Directory
■
Resetting Farm/Queue Settings During the Flow

Automatic Reruns
The SiliconSmart parameter auto_fix allows for automatic re-submission of
failed tasks. This takes care of any tasks/arcs/measurements which may fail
due to any random farm, network, licenses or machine issues.
This mechanism applies to all steps of the flow (import, configure, ,
model).
The failing tasks are immediately re-submitted at least once (the default for
auto_fix = 1). Setting it to a larger integer value will invoke more tries before
giving up on the failing tasks.
See Also
■
Parameter: auto_fix

Using RSH to Create a Custom Pool

CDPL allows for creation of a custom pool by grouping together a bunch of
available machines. For example:
Example 7
set_config_opt job_scheduler custom
set_config_opt cdpl_host_file HSPICE64core.cfg

Here, the file HSPICE64core.cfg contains:

1| mhost1 | 64 | /tmp| RSH | rsh
1| mhost2 | 64 | /tmp| RSH | rsh

The syntax for the file is: (flag | hostname | slots | tmpDir | protocol | command).

SiliconSmart ACE User Guide 23

L-2016.03
Chapter 2: Setting Up SiliconSmart
Using CDPL

The above example creates a customer pool specifying a 128 worker, 2 node
configuration for a distributed processing run.

Prevent CDPL from Clogging the Home Directory

By default, CDPL generates some broadcast files (.bcast files) which allow the
DP Manager GUI to monitor and track running and completed DP jobs. The
default directory for the broadcast files is $HOME/.synopsys/cdpl
To prevent clogging of the user home directory with a lot of these files, it is
possible to disable broadcast file creation altogether by setting the environment
variable CDPL_BCASTDIR to /dev/null.
It is also possible to set the broadcast directory CDPL_BCASTDIR to some
directory that is already being cleaned up regularly.

Resetting Farm/Queue Settings During the Flow

In some scenarios, there may be a need to use different queues for different
steps of the flow. The SiliconSmart tool provides a command
cdplResetMaster for this.
For example:
Example 8
set_config_opt job_scheduler lsf
set_config_opt run_list_maxsize 100
set_config_opt normal_queue {short -R rusage[mem=4000]}

configure -timing

cdplResetMaster

set_config_opt run_list_maxsize 10
set_config_opt normal_queue {long -R rusage[mem=2000]}

characterize

model -timing

The above example switches submission queue between configure and /

model flow steps.

24 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Managing Licenses

Managing Licenses
This section describes how to start, support, and maintain your license server.
Sometimes you must reconfigure or restart the license server, such as when a
license or software application is upgraded or when a license has been
terminated. Licenses require restarting in these instances.
If you have received a new license or a software upgrade, review the Upgrading
Licenses section.

Obtaining a New SiliconSmart License

Contact Synopsys for new licenses. You must provide the host ID of the
computer you want to use as your license server. On Solaris systems, type
hostid to obtain this number. For redundant license server configurations, you
must provide three host IDs and their respective host names.

Upgrading Licenses
For the purpose of this explanation, your license file is referred to as
license.dat. Use the license file name already in use at your site and complete
the following steps to upgrade your license:
1. Either edit your existing license file to include new license keys, or rename
your existing license file and create a new license file containing the new
keys.
2. Execute a license reread to inform the FLEXlm license daemon that the keys
have changed as follows:
install_path/lmgr/platform/lmreread -c /
path_to_license_file/ \ license.dat

3. Generate a status report to ensure the licenses have been reread correctly,
as follows:
install_path/lmgr/platform/lmstat -a -c /
path_to_license_file/ \ license.dat

SiliconSmart ACE User Guide 25

L-2016.03
Chapter 2: Setting Up SiliconSmart
Selecting a Simulator

Selecting a Simulator
The SiliconSmart tool supports the following simulators for characterization.

Simulator Parameter to Specify Simulator

Synopsys FineSim SPICE finesim

Embedded FineSim SPICE finesim_embedded

FineSim Parallel finesim_parallel

Synopsys HSPICE hspice

HSPICE Client Server Mode hspice_cs

Embedded HSPICE hspice_embedded

To select the simulator, set the simulator parameter to the desired name:
set simulator simulator_name

The following sections are described below:

■
Running with FineSim
■
Running with FineSim Multiple-CPU Simulation
■ Running with FineSim-Embedded
■
Running with HSPICE
■ Running with HSPICE in Client Server Mode
■ Running with HSPICE-Embedded
■
Setting Simulator Options

Running with FineSim

To select the FineSim simulator:
set simulator finesim
set simulator_cmd {finesim -w <input_deck> -o <listing_file> >&/
dev/null}

26 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Selecting a Simulator

where simulator_cmd specifies the binary and version to run.

Running with FineSim Multiple-CPU Simulation

The SiliconSmart tool supports multi-CPU FineSim Simulation capabilities,
which leverages the multi-CPU simulation capabilities of FineSim. Multi-CPU
FineSim Simulations can also be used for active driver characterization, in
addition to regular characterizations.
The following SiliconSmart-specific changes are required for using multi-CPU
simulation. For the examples, we are using 4-CPU FineSim simulations:
1. Set simulator as finesim_parallel and set simulator_cmd to
show multi-processing or multi-threading arguments:
set simulator finesim_parallel
set simulator_cmd {finesim –np 4 –spice –w input_deck -o
listing_file}

Older versions of FineSim will require the use of the finesim_parallel

executable:
set simulator_cmd {finesim_parallel –np 4 –spice –w input_deck
-o listing_file}

2. Depending on the multi-processing or multi-threading options used, you

need to make a corresponding change to the job_scheduler.
3. Specify simulator options under a separate finesim_parallel tag, as
shown below:
set simulator_options {
"common,finesim_parallel: finesim_mode=prohd numdgt=9
measdgt=9"
}

4. For standalone simulations, you need to make sure that the SiliconSmart
tool is invoked on a machine with the right configuration.
For LSF, instruct bsub to lock the desired CPUs and CPU distribution:
set normal_queue {regression –n 4 -R "rusage[mem=2000]
span[hosts=1]"}

The -n argument specifies the CPUs to be reserved, while span specifies

the CPU distribution. The span[hosts=1] configuration is recommended.
Please refer to Platform LSF documentation for more information.

SiliconSmart ACE User Guide 27

L-2016.03
Chapter 2: Setting Up SiliconSmart
Selecting a Simulator

5. For fair resource sharing, you need to make a corresponding change to

run_list_maxsize:
set run_list_maxsize 50

Note: Please note that a -n 4 argument to bsub would mean that

4*run_list_maxsize number of LSF slots will be
attempted for acquisition.

Below is a complete example of specifying the required changes:

Example 9
set simulator finesim
set simulator_cmd {finesim –np 4 –spice –w input_deck -o
listing_file}
set normal_queue {regression –n 4 -R "rusage[mem=2000]
span[hosts=1]"}
set run_list_maxsize 50

The above example implies:

■
50 LSF jobs will be submitted with 50 JOBIDs.
■
50*4=200 effective LSF slots will be attempted for acquisition.
It might be necessary to run multi-CPU FineSim simulations on selective
acquisitions/simulations to leverage the correct performance improvements. To
do this, use the -match option with the characterize command to throw
selective simulations onto multi-CPU FineSim simulations:
characterize –match {setup__*|hold__*} cells

The -match option must be given an expression; it accepts wild cards in the
Tcl regexp format.

Running with FineSim-Embedded

The SiliconSmart tool supports an embedded version of FineSim SPICE which
upgrades each characterization engine to include a copy of the embedded
version of FineSim SPICE, meaning that no external simulator (or simulator
license) is required. Embedding the simulator directly into the SiliconSmart tool
allows characterization-specific algorithms to be embedded into the simulator.
When setting simulator options, it is not necessary to define separate
finesim_embedded options. FineSim options will be used for

28 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Selecting a Simulator

finesim_embedded unless separate finesim_embedded options are

defined, which will take precedence over the same option defined for FineSim.

Compatibility with FineSim-Embedded

For details about SiliconSmart and FineSim-embedded compatibility, see the
SiliconSmart - FineSim-Embedded Compatibility Table on SolvNet
(https://solvnet.synopsys.com/retrieve/039800.html).

Note: A SolvNet user name and password are required. Information

regarding SolvNet access can be found at the following location:
https://solvnet.synopsys.com

Disk Space Usage

To minimize disk space usage, the FineSim simulation output log file is disabled
by default when the simulator is set to finesim_embedded. For debugging
purposes, standalone FineSim must be used to generate the log file.

Using finesim_embedded with Verilog-A Model

When using finesim_embedded as the simulator with the Verilog A process
model, the following environmental variables must be set during library
characterization:
■
FINESIM_VA2C_INCLUDE — the directory for finesim_embedded to
include the required system files to generate the .so file. This should be set
to the directory in the SiliconSmart install tree.
■
FINESIM_VA2C_SO_DIR — the directory where the user will store .so files
that are generated dynamically. This directory can be an directory, but it
must point to an absolute path and must exist before characterization
begins.

Example 10
setenv FINESIM_VA2C_INCLUDE install_dir/SiliconSmart-2015.06/
etc/va2c_include/
setenv FINESIM_VA2C_SO_DIR charpt_location/so_dir

SiliconSmart ACE User Guide 29

L-2016.03
Chapter 2: Setting Up SiliconSmart
Selecting a Simulator

Running with HSPICE

To select the HSPICE simulator:
set simulator hspice
set simulator_cmd {hspice <input_deck> -o <listing_file>}

where simulator_cmd specifies the binary and version to run.

Running with HSPICE in Client Server Mode

HSPICE supports a client server mode for characterization in which it starts a
server that multiple jobs can be fed to. This reduces characterization time
significantly (reported to be ~25%) due to not having to re-load process models
and check licenses, etc. for each simulation.
To select the HSPICE client/server mode, set the simulator parameter to
hspice_cs instead of hspice. This causes the SiliconSmart tool to
automatically start the server when the first simulation is to be run and to shut it
down on completion.
The default for simulator_cmd for hspice_cs mode is:
hspice -CC <input_deck> -port <port_num> -o <listing_file>

Note: The order of the command-line switches is very important;

HSPICE requires this ordering. See the HSPICE manual for a
description of the advanced client/server mode.

Running with HSPICE-Embedded

HSPICE-embedded uses HSPICE as the simulator for characterization without
checking-out HSPICE licenses; only SiliconSmart core licenses are checked-
out.

Note: This option is only valid with the SiliconSmart and HSPICE
product packaging introduced in the 2015.06 release. It requires
the 2015.06 (or later) versions of HSPICE and will not work with
previous HSPICE versions.

30 SiliconSmart ACE User Guide

L-2016.03
 Chapter 2: Setting Up SiliconSmart
Selecting a Simulator

As with running HSPICE, the parameter simulator_cmd must be specified:

set simulator hspice_embedded
set simulator_cmd {<path to 2015.06/later Hspice binary>
<input_deck> -o <listing_file>}

Setting Simulator Options

You can set the simulator options based on the type of simulation to be
performed by setting the simulator_options parameter in the configure.tcl
file.
The value of this parameter is a list of strings in which each string specifies a
set of option settings, a tag indicating the type of simulation it applies to and,
optionally, the name of a simulator.
Each line has the following format:
tag[,simulator]: options

Arguments
tag
One of the following simulation types:
• common — used in all simulations.
• leakage — used for leakage decks.
• power — used for power characterization simulations.
• tran — used for transient simulations.
• optimize — used for optimization simulations, such as automatic load
ranging.
• csm — higher resolution options used for capturing ECSM and CCS
waveforms.
simulator
One of the supported simulator flavors.
options
A string of simulator-specific options that are to be added to each of the
simulations. The order of the lines is preserved, meaning later lines can
override earlier ones.

SiliconSmart ACE User Guide 31

L-2016.03
Chapter 2: Setting Up SiliconSmart
Setting Up Your Environment

Specifying Simulator Options for Leakage

You can specify simulator options specifically for leakage power measurements
directly via the simulator_options parameter in configure.tcl or
set_parameter calls. Leakage specific options can be specified as shown in
the following examples:
Example 11
set simulator_options {"leakage,hspice: method=gear"}

set simulator_options {
"common,finesim: probe=1 finesim_mode=spicehd"
"leakage,finesim: finesim_method=gear"
}

Setting Default Simulator Options

It is recommended to set the parameter simulator_default_options to 1,
which has the SiliconSmart tool add its own simulator options to the deck. You
can then add your own options as well, which will override these default
options.
Some of the SiliconSmart options can not be overridden. If you do not want the
SiliconSmart tool to add any default simulator options, set
simulator_default_options to 0. Please note that this means no
simulator options will be added at all, and you must set all simulator options
manually.
See Also
■
Parameter: simulator_options
■
Parameter: simulator_default_options

Setting Up Your Environment

Refer to the SiliconSmart Installation Guide for information on setting up the
user environment, setting license the file environmental variable, and verifying
the SiliconSmart installation.

32 SiliconSmart ACE User Guide

L-2016.03
 3
3

SiliconSmart Data Flow

This chapter guides you through basic SiliconSmart characterization flows.

Before you launch SiliconSmart, make sure follow the steps in Chapter 2,
Setting Up SiliconSmart to set up the SiliconSmart tool and prepare your
environment.
The following sections will guide you through a SiliconSmart characterization
session:
■
Data Flow Overview
■
Setting Up for Your Characterization
■ Selecting a Characterization Flow
• Recharacterization Flow
• Incremental Characterization Flow
• Function-Based Flow
• Structure-Based Flow
• Sequence-Based Flow
• Additional Flow Options
• Additional Characterization Flows
■
Creating a run.tcl File for Characterization

SiliconSmart ACE User Guide 33

L-2016.03
Chapter 3: SiliconSmart Data Flow
Data Flow Overview

Data Flow Overview

The following sections give a brief overview for the SiliconSmart data flow.
■
Basic Data Flow
■
New Characterization versus Recharacterization

34 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Data Flow Overview

Basic Data Flow

The following figure illustrates the SiliconSmart data flow:

Figure 4 SiliconSmart Basic Data Flow

SiliconSmart ACE User Guide 35

L-2016.03
Chapter 3: SiliconSmart Data Flow
Data Flow Overview

These steps are described briefly below:

■
Creating the Characterization Point
■
Setting Global Parameters for all Cells
■
Importing Cells
■
Customizing Cell Instance Files (Optional)
■
Precharacterizing (Optional)
■
Configuring
■
Characterizing
■
Modeling

Creating the Characterization Point

The SiliconSmart tool works within a predefined characterization directory
structure. Relevant files are expected to reside within this structure and are
generated in specific subdirectories. If you are not working in an existing
characterization directory (char_dir), then you must create the directory.
See Also
■
Creating a Characterization Directory
■
Command: create

Setting Global Parameters for all Cells

You will need to import a configure.tcl file into the created characterization
directory, which can be used to set global parameters and settings which will
apply to all cells of the characterization.
See Also
■
Editing the configure.tcl File

Importing Cells
SiliconSmart begins with an extracted netlist and optionally, a Liberty model for
a set of cells. For each cell netlist that is imported, an instance file is created.
A SiliconSmart instance file describes the structure (pins and pin directions),
logical behavior, electrical characteristics, and characterization options.

36 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Data Flow Overview

The SiliconSmart tool will always attempt to create a complete instance file for
each cell netlist:
■ If a netlist is imported and a Liberty model is available for the cell, the
SiliconSmart tool will import the functional description of the cell from the
netlist (if Functional Recognition is enabled) and timing and power models
from the Liberty model.
■
If a netlist is imported and a Liberty model is not provided, the SiliconSmart
tool will attempt to extract the function from the netlist. If successful, the
instance file will contain the function; if not the instance file will contain only
pin information.
After creating or setting your characterization point, you will need to use the
import command to import cells from a Liberty (.lib) file, a SPICE netlist, or a
SiliconSmart characterization directory into an existing characterization
directory.
The use of this command depends on the characterization flow you will be
using. Please see the Selecting a Characterization Flow section for a guide on
using this command based on your chosen flow.
See Also
■
Importing Cells
■
Command: import

Customizing Cell Instance Files (Optional)

When a cell is imported from a netlist, an instance file (.inst) is created for each
cell. This instance file defines the behavior of the cell, including information,
function, characterization and modeling configuration options. Editing these
files is optional, depending on whether customization is needed.
See Also
■ Editing Instance Files
■
Example Instance Files

Precharacterizing (Optional)
The precharacterization step uses binning or grouping states with similar delay,
constraint or energy characteristics, and by multi-corner load ranging to reduce
overall characterization time. The precharacterization step is optional, and must
be used before running the configure command.

SiliconSmart ACE User Guide 37

L-2016.03
Chapter 3: SiliconSmart Data Flow
Data Flow Overview

See Also
■
Precharacterization
■
Command: precharacterize

Configuring
Once all of the cell instance files are correct, a characterization plan must be
generated for each one. The configure command analyzes each cell and
generates the plans.
See Also
■
Configuring Cells
■
Command: configure

Characterizing
The characterize command uses the SiliconSmart JMS to efficiently
distribute the characterization simulation jobs across your network, taking
advantage of the CPUs and simulation licenses you have made available.
SiliconSmart supports LSF, Grid Engine, and NC load balancing software and
third-party simulators (such as Mentor Graphic Eldo and Cadence Spectre®).
See Also
■
Characterization
■ Command: characterize

Modeling
Once the simulations are complete, you can use the model command to
generate models of one or more cells.
See Also
■
Generating Models
■
Command: model

38 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Data Flow Overview

New Characterization versus Recharacterization

The SiliconSmart tool provides recharacterization and incremental
characterization flows which can be used instead of a new characterization
when you want to characterize arcs from an existing model.
■
New Characterization Flow
This flow requires a SPICE netlist as a starting point.
In this flow, the SiliconSmart tool generates the full set of arcs for each cell,
automatically determines the load ranges, and generates timing and power
models for each cell. This flow produces models tailored to each cell.
■
Recharacterization Flow
This flow requires a SPICE netlist and an existing Liberty model of a cell as
a starting point.
In this flow, the SiliconSmart tool characterizes only the timing and power
arcs present in the original model, using the original slew and load points,
and then rewrites the model with the updated timing and power numbers.
Use this flow when you want to preserve the structure of the model but need
accurate timing and power data or want to characterize the cells at a new
operating condition.
■
Incremental Characterization Flow
Similar to recharacterization, this flow requires a SPICE netlist and an
existing Liberty model of a cell as a starting point.
In this flow, the SiliconSmart tool will copy all existing data of the Liberty
model and only characterize the new additional data.
Use this flow when you want to preserve the existing data of a model but
need to characterize new data.
Use of these flows is not mutually exclusive. When starting with a Liberty model
you can produce both a new Liberty model as well as a recharacterized one.
However, the recharacterization and incremental characterization flows do
require that you have imported an original Liberty model.
After importing, if you make any changes to the .inst file for additional arcs or
events, you cannot get those additional arcs in the recharacterization flow
because the specification of the recharacterization flow always preserves the
referenced Liberty format. You can get those additional arcs if you instead use

SiliconSmart ACE User Guide 39

L-2016.03
Chapter 3: SiliconSmart Data Flow
Setting Up for Your Characterization

the standard characterization flow with the -create_new_model option while

modeling.

Setting Up for Your Characterization

The following steps will launch SiliconSmart and prepare it for your
characterization. These steps are used in all SiliconSmart flows.
■
Requirements for Characterization
■
Launching SiliconSmart
■
Creating a Characterization Directory
■
Editing the configure.tcl File
■
Setting Your Characterization Point

Requirements for Characterization

Before attempting a characterization, you must be prepared with:
■
Chapter 2, Setting Up SiliconSmart:
• Setting a Job Scheduler
• Setting Up Your Environment
• Selecting a Simulator
• Managing Licenses
■
Necessary Files for Characterization:
• A netlist for each cell to be characterized.
• A reference Liberty model (for recharacterization or incremental
characterization).
■
Minimum Information Necessary for the Characterization:
• The UNIX® command used to invoke your SPICE simulator.
• SPICE simulator options you want to use (found in configure.tcl).
• The power and ground node names in your SPICE netlists.
• The largest input and output slew rates expected across all cells.

40 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Setting Up for Your Characterization

• The input and output slew thresholds you want to use for slew
measurements.
• The input and output propagation delay thresholds.
• The process, voltage and temperature combinations you want to
characterize.
Note: Much of the above information may already be in your existing
Liberty model (if you have one).

Launching SiliconSmart
Before you launch the SiliconSmart tool, be aware that the location from which
you launch siliconsmart will be the directory that contains the SiliconSmart
session log file (siliconsmart.log). This section briefly explains how to launch
and exit the SiliconSmart tool. Complete the following steps:
1. To launch the SiliconSmart interactive client, enter the following command:
siliconsmart

Information about the SiliconSmart version is displayed, and the UNIX

prompt changes to the SiliconSmart prompt:
sis_cci>

2. To exit the shell, enter the following command:

exit

When launched, the SiliconSmart tool loads ~/.siliconsmartrc. This file can
contain custom scripts that run every time the SiliconSmart tool is launched.
For example:
set_log_level VERBOSE
proc time { args } {
set start [clock seconds]
eval $args
set end [clock seconds]
puts "Elapsed time: [expr $end - $start]"
}

SiliconSmart ACE User Guide 41

L-2016.03
Chapter 3: SiliconSmart Data Flow
Setting Up for Your Characterization

Modifying the Log File

If you would like the session log file to be saved in a specific directory (such as
the characterization directory) or saved with a different name, use the
set_log_file command:
sis_cci> set_log_file path/filename

If you do not specify a file name or directory, the SiliconSmart log file defaults to
siliconsmart.log and is saved in the directory from which you launched
SiliconSmart.
See Also
■
Logging
■
Command: set_log_file

Creating a Characterization Directory

The first step in a characterization is to create a new characterization directory
which will contain your characterization and cell data. The root of this structure
is referred to as char_dir throughout the remainder of the document. This
directory will store all of the data required for characterization as well as the
results.
To create your characterization directory:
1. Before launching the SiliconSmart tool, ensure that you are in the directory
which you want to contain the session log file.
2. Launch the SiliconSmart tool with the following command:
siliconsmart

Information about the SiliconSmart version is displayed, and the UNIX

prompt changes to the SiliconSmart prompt:
sis_cci>

3. Issue the following command:

create char_dir

If the specified directory (char_dir) already exists, the directory structure

under char_dir is not overwritten or destroyed. You must then import a
configure.tcl file to specify the electrical environment under which
characterization will be performed.

42 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Setting Up for Your Characterization

Note: Use the -clean argument with the create command to

delete the characterization directory before creating it, if one
exists.

4. Change to the new char_dir directory:

cd char_dir

5. Review the directory structure and the folders within char_dir.

6. When finished, return to your home directory with the following command:
cd ..

The following figure shows the new characterization directory structure:

char_dir

validation ¹ÅÄŰ½ control etc runtime

netlists models templates import spice

SPICE

reports results cell_name ¹ÅÄŰ½ËÈ·Ê¿ÅÄ cell_name

datasheet cell_name Ê»ÃÆ·ʻŰÂ»É precharacterization simulation

controls

characterization simulation
decks

cdpl

¹ºÆÂÂŽŰ»É

Figure 5 Characterization Directory Structure

See Also
■
Editing the configure.tcl File
■ Command: create

SiliconSmart ACE User Guide 43

L-2016.03
Chapter 3: SiliconSmart Data Flow
Setting Up for Your Characterization

Editing the configure.tcl File

You often must override some characterization parameter values. Parameters
affect the manner in which cell characterization occurs and the ranges over
which measurements are taken. Parameters set in the configure.tcl file are
global and affect all cells for a given characterization directory. See the Editing
Instance Files section for how to set parameters in a cell’s instance file which
will only affect that particular cell.
The configure.tcl file has several sections in it and includes the following major
parameter blocks:
■
GLOBAL CONFIGURATION PARAMETERS — This section includes the
global parameters that control high-level characterization settings and
integration with third-party tools (SPICE, load sharing, and so on)
■
DEFAULT PIN CONFIGURATION PARAMETERS — The parameters in this
section control the characterization settings for a class of pins—for example,
setting the output load range for a set of pins.
■
OPERATING CONDITIONS — The parameters in this section specify the
process, voltage, and temperature for the characterization.
To edit the configure.tcl file:
1. As a precaution, back up the existing configure.tcl file before you begin:
cp char_dir/config/configure.tcl \
char_dir/config/configure.tcl.bak

2. Open the char_dir/config/configure.tcl file with the text editor of your choice.
3. Modify the simulator parameters to reflect FineSim or the simulator you are
using, as shown in the following example:
set simulator finesim
set simulator_cmd {finesim input_deck -o listing_file}

4. Example: Modify parameters in the DEFAULT PIN CONFIGURATION

PARAMETERS section with the set command:
set parameter value

5. Example: Set the location of the SPICE process models, in the

OPERATING CONDITIONS section, as shown below:
set_opc_process op_cond {
{.inc "/home/location/example.mod"}
}

44 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Setting Up for Your Characterization

where the above is the location of the data on your system.

6. Example: Add values for VSS and VDD, and a temperature for the operating
condition.
add_opc_supplies op_cond VSS 0.0 VDD 1.0
set_opc_temperature op_cond 0

7. Save and close the configure.tcl file.

8. Use the set_location command to reload the updated configuration file:
set_location char_dir

After overriding parameter values, you have completed the configuration of the
library, and can now import and configure your cells in preparation for
characterization.
See Also
■
Editing the configure.tcl File
■
Example configure.tcl File
■
Command: set_location
■
Command: set_opc_process
■
Command: set_config_opt

Setting Your Characterization Point

Setting the characterization directory location at the beginning of a work
session is important because this tells the SiliconSmart tool which
characterization directory you want to work with, establishes its configuration,
and initializes the job manager. Subsequent commands you enter will work with
the specified characterization directory. If at any time you exit and reenter the
system, you must set the location to the appropriate characterization directory
before you begin working.
1. After you create the characterization directory structure, set the location with
the following command:
set_location char_dir

This forces the SiliconSmart tool to re-load the configure.tcl file and use the
specified characterization directory for all subsequent operations.

SiliconSmart ACE User Guide 45

L-2016.03
Chapter 3: SiliconSmart Data Flow
Selecting a Characterization Flow

Note: If you make changes to the configure.tcl file, you must reload
the file with the above command to retrieve the changed file.

2. To confirm you have set the correct location, issue the following command:
get_location

The prompt should return:

$HOME/home_directory/char_dir

See Also
■
Command: get_location
■
Command: set_location

Selecting a Characterization Flow

Once you have launched the SiliconSmart tool and set your characterization
point, you must decide upon your characterization approach.
If you know the flow you would like to use, skip to the Selecting a
Characterization Flow section. Otherwise, use the below sections to determine
your flow:
■
Select by Your Starting Point
■
Select by Characterization Approach

46 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Selecting a Characterization Flow

Select by Your Starting Point

Use the chart below to determine your characterization approach based on
your starting point and the files available:

Pure Recharacterization
Flow

Functional Recognition
Flow

Extracting a Function from

the Netlist with FR

Manually Defining a Function

in the Instance Files

Automatic Vector
Simulation

Manually Defining
Simulation Vectors

SiliconSmart ACE User Guide 47

L-2016.03
Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

Select by Characterization Approach

The basic approaches for characterizing with the SiliconSmart tool are:
■
Recharacterization Flow — This approach will recharacterize data in an
existing Liberty model or add new data to an existing Liberty model.
■
Function-Based Flow — The function-based approach uses functions to
automatically determine configuration.
• Structure-Based Flow — A function-based approach that uses functions
and automatic vector simulation based on the structure of the circuit.
■
Sequence-Based Flow — The sequence based approach adds a user-
defined input stimulus to specify arcs to be characterized and the sequence
to be performed, without using automated methods.

Recharacterization Flow
Recharacterization requires an existing Liberty model. This flow imports a
Liberty model and preserves as much of the structure and formatting of the
library as possible while replacing the data tables with the newly characterized
data.
The recharacterization flow is usually performed in scenarios where there is a
need to regenerate the same Liberty at a different PVT condition, or with
different netlists, and so on. The typical requirement is to be maintain the same
Liberty structure, load/slope conditions, attributes, when conditions.

Note: Recharacterization is the default mode if a Liberty model has

been imported for a given cell.

The following detail the recharacterization flows of the SiliconSmart tool:

■
Pure Recharacterization Flow — this flow extracts all necessary data from
an existing Liberty model. It requires minimal input from the user.
■
Functional Recognition Flow — this specialized flow recognizes the function
from the netlist of a cell and extract the slews/loads/timing arcs from an
existing Liberty model, removing the dependency on the function attributes
in a Liberty model.

48 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

■
Skeleton Liberty-Based Flow — this flow generates a new Liberty model
from scratch (employing user inputs for load/slope/when conditions) while
preserving the attributes and other groups from the reference Liberty. Any
processing performed previously on the reference Liberty can be carried
over into the brand new Liberty model.
■
Incremental Characterization Flow — this is another specialized form of the
Recharacterization flow which allows the user to only characterizes a new
view and add to an existing Liberty model while preserving all the original
data as is. An example would be to add CCS-Noise to an existing NLDM
Liberty.

Pure Recharacterization Flow

The pure recharacterization flow extracts all of the necessary information
(function, slews/loads/timing arcs) from the existing Liberty model. This simple
flow requires only basic input from the user.

Requirements
This flow requires the following:
■
An existing Liberty model which contains functional information and data for
slews/loads/timing arcs.
■
Netlist and corresponding process files.
Note: A configure.tcl is not required for this flow. If you do not
provide one, it will be created automatically. See
Recharacterizing without a configure.tcl File for more
information.

Flow Steps
The following details the steps in this flow:
1. Prepare for characterization:
• Set/create charpoint.
• Set log file.
• Set location.
• Source cells.
2. Set farm and any required general settings.

SiliconSmart ACE User Guide 49

L-2016.03
Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

3. import the following:

• An existing Liberty model that contains functional information and
slews/loads/timing arcs.
• The netlist.
• The cells to be recharacterized.
Note: In the absence of a configure.tcl file, a basic configuration file
will be created automatically with information taken from the
Liberty. See Recharacterizing without a configure.tcl File for
more information.

4. configure the characterization plan.

5. characterize.
6. model the specified data; the SiliconSmart tool will only replace that data,
preserving the rest of the library as before.
An example flow is shown below:
Example 12 Pure Recharacterization Flow
set charpt chp
create $charpt
set_log_file $charpt/sis.log
set_location $charpt
source cells.tcl

#Farm Settings
set_config_opt job_scheduler grid
set_config_opt run_list_maxsize 100
set_config_opt normal_queue {-P bnormal -l "mem_free=4G”}

#Other General Settings, if any required

set_config_opt model_bundle_bit_level 1

#Flow
import -fast -liberty $lib_file -netlist_dir $netlist_dir
-extension .spf -overwrite $cells

set pvt [get_config_opt active_pvts]

set_opc_process $pvt { {.lib "process_files/process.lib" tttt} }

configure –timing –power $cells

characterize $cells
model –timing –power $cells

50 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

See Also
■
Recharacterization

Functional Recognition Flow

This hybrid flow gives the user the flexibility to determine the function of the
cells from the netlist while extracting the slews/loads/timing arcs from an
existing Liberty model. This removes the dependency on the function attributes
from the Liberty model.
To be able to run Functional Recognition in SiliconSmart, you need to make a
few special parameter settings. Please refer to Setting Up Functional
Recognition before using the flow examples in this section.

Requirements
This flow requires the following:
■
An existing Liberty model which contains data for slews/loads/timing arcs.
■
Netlist and corresponding process files.
■
A configure file.
Note: This is optional; if a configure.tcl is not included for this flow,
a basic configure.tcl file will be created automatically. See
Recharacterizing without a configure.tcl File for more
information.

Flow Steps
The following details the steps in this flow:
1. Prepare for characterization:
• Set/create charpoint.
• Set log file.
• Set location.
• Source cells.
2. Set farm and any required general settings.
3. import the following:

SiliconSmart ACE User Guide 51

L-2016.03
Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

• An existing Liberty model that contains functional information and

slews/loads/timing arcs.
• The netlist.
• The cells to be recharacterized.
• Use the -recognize switch to activate Functional Recognition, which
is otherwise disabled by default when importing a Liberty model. Using
this switch will automatically import the function from the netlist, while
importing the other data from the existing Liberty model.
Note: See Using Functional Recognition for information on
additional optional switches to be used with Functional
Recognition for more complex cells.

4. configure the characterization plan.

5. characterize.
6. model the specified data; the SiliconSmart tool will only replace that data,
preserving the rest of the library as before. If you are adding data to arcs,
those arcs must already exist in the model or else they must be
characterized (if a new model is being generated).
An example flow is shown below:
Example 13 Functional Recognition Flow
set charpt chp
create $charpt
set_log_file $charpt/sis.log
set_location $charpt
source cells.tcl

#Farm Settings
set_config_opt job_scheduler grid
set_config_opt run_list_maxsize 100
set_config_opt normal_queue {-P bnormal -l "mem_free=4G”}

#Other General Settings, if any required

#Flow
import -recognize -liberty $lib_file -netlist_dir $netlist_dir
-ext .spf -overwrite $cells
configure –timing –power $cells
characterize $cells
model –timing –power $cells

52 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

See Also
■
Recharacterization

Skeleton Liberty-Based Flow

This flow maintains only the attributes and structure of the Liberty while using
recharacterization to create a new Liberty model. This is primarily useful in
flows where the user can provide custom load/slope/when conditions but wants
to keep the attributes, custom library modifications, headers, comments, etc.,
from the imported Liberty.
This flow uses the -skeleton switch, available for the import and model
commands, which does the following:
■
The SiliconSmart tool will discard all timing, constraint, internal_power, and
CCS timing/power/noise tables from the reference Liberty.
■
As usual, an instance file will be created in the $charpoint/control directory
for each cell with the interface and functional information. All of the load/
slope/when conditions from the reference Liberty will be discarded.
You can choose from the available index selection methods (auto-ranging,
numsteps_slew/load, smallest_slew/load, etc.) to pick new load/slews. See
Autoranging and Automatic Parameter Determination for more information. You
can also specify a custom state_partitions for different measurements or
allow the SiliconSmart to choose a default, which is state_partitions one
for all measurements.

Requirements
This flow requires the following:
■ An existing Liberty model with information you wish to preserve.
■
Netlist and corresponding process files.
Note: A configure.tcl is not required for this flow. If you do not
provide one, it will be created automatically. See
Recharacterizing without a configure.tcl File for more
information.

SiliconSmart ACE User Guide 53

L-2016.03
Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

Flow Steps
The following details the steps in this flow:
1. Prepare for characterization:
• Set/create charpoint.
• Set log file.
• Set location.
• Source cells.
2. Set farm and any required general settings.
3. import the following:
• An existing Liberty model that contains the information you wish to
preserve.
• The netlist.
• The cells to be recharacterized.
Note: In the absence of a configure.tcl file, a basic configuration file
will be created automatically with information taken from the
Liberty. See Recharacterizing without a configure.tcl File for
more information.

4. configure the characterization plan.

5. characterize.
6. model the specified data. When invoked with the -skeleton switch, the
Liberty produced will be a as if a brand new Liberty but with all the attributes,
custom groups, test_cell, statetable, header, etc., information from the
imported Liberty preserved at library/cell/pin-level.

54 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

An example flow is shown below:

Example 14 Skeleton Liberty-Based Flow
set charpt chp
create $charpt
set_log_file $charpt/sis.log
exec cp configure.tcl $charpt/config/configure.tcl
set_location $charpt
source cells.tcl

import -fast -skeleton -liberty $lib_file -netlist_dir

$netlist_dir -extension .spf -overwrite $cells

set_config_opt –type {timing energy} state_partitions all

set_config_opt –type {constraint} state_partitions none

configure –timing –power $cells

characterize $cells
model –skeleton –timing –power $cells

See Also
■
Recharacterization

Incremental Characterization Flow

Using the incremental characterization flow is similar to recharacterization in
that all data from an existing Liberty model is imported. In this flow, only
additional data added to that Liberty model will be characterized; existing data
in the model will be preserved.

Requirements
This flow requires the following:
■
An existing Liberty model which contains functional information and data for
slews/loads/timing arcs.
■
Netlist and corresponding process files.
Note: In the absence of a configure.tcl file, a basic configuration file
will be created automatically with information taken from the
Liberty. See Recharacterizing without a configure.tcl File for
more information.

SiliconSmart ACE User Guide 55

L-2016.03
Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

Flow Steps
The following details the steps in this flow:
1. Prepare for characterization:
• Set/create charpoint.
• Set log file.
• Set location.
• Source cells.
2. Set farm and any required general settings.
3. import the following:
• An existing Liberty model that contains functional information and
slews/loads/timing arcs.
• The netlist.
• The cells to be recharacterized.
Note: In the absence of a configure.tcl file, a basic configuration file
will be created automatically with information taken from the
Liberty. See Recharacterizing without a configure.tcl File for
more information.

4. configure the characterization plan.

5. characterize.
Note: Use the -match switch to run selective simulations. It must
specify an expression and it accepts wildcards in the Tcl
regexp format.

6. model the specified data; the SiliconSmart tool will only add that data,
preserving the rest of the library as before. If you are adding data to arcs,
those arcs must already exist in the model or else they must be
characterized (if a new model is being generated).

56 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

An example flow is shown below:

Example 15 Incremental Characterization Flow
set netlist_dir ./netlists
set lib_file ./input_liberty_models/nldm.lib
set configure_file ./configure.tcl

set charpt chp

create $charpt
set_log_file $charpt/sis.log
exec cp $configure_file $charpt/config/configure.tcl
set_location $charpt

#Source the cell list

source cells.tcl

import -fast -liberty $lib_file -netlist_dir $netlist_dir

-extension .spf -overwrite $cells
configure -fast -timing -ccs_noise $cells
characterize -match (ccs_noise_*|miller_ccs_*) $cells
model -ccs_noise -output with_ccsn $cells

See Also
■
Recharacterization

Recharacterization with Selective Extraction of

Information from an Existing Liberty
In addition to the above flows, the SiliconSmart tool allows the user to pick and
choose the amount of information to be extracted from an existing/reference
Liberty model. The user can choose to import load/slope/when conditions, just
the loads, just the slopes, or just the function and port directions. Following is a
description of examples flows to do the same.
Here are some example flows for choosing what to extract from the Liberty
(slews, loads, when conditions):
■
Extracting All Information
■
Extracting Loads and When Conditions
■
Extracting Slews and When Conditions
■
Extracting Port Directions and Functional Information

SiliconSmart ACE User Guide 57

L-2016.03
Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

Extracting All Information

The following example will extract all load/slew/whens from the Liberty and
write it to the instance file:
import -liberty $import_lib -netlist_dir $netlist_dir -ext $ext
$cells
configure $cells
characterize $cells
model $cells

Extracting Loads and When Conditions

The following example will extract all load and when conditions from the Liberty
and write it to the instance file. However, the slews will not be extracted from
the Liberty. The slews used for characterization will be determined through
automatic distribution using the provided smallest_slew, largest_slew
and numsteps_slew parameter settings.
import -liberty $import_lib -netlist_dir $netlist_dir -ext $ext
–use_default_slews $cells
configure $cells
characterize $cells
model $cells

Extracting Slews and When Conditions

The following example will extract all slew and when conditions from the Liberty
and write it to the instance file. However, the loads however will not be
extracted from the Liberty. The loads used for characterization will be
determined through automatic distribution using the smallest_load,
largest_load, and numsteps_load parameters, or through provided auto-
ranging parameter settings.
import -liberty $import_lib -netlist_dir $netlist_dir -ext $ext
–use_default_loads $cells
configure $cells
characterize $cells
model $cells

58 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Recharacterization Flow

Extracting Port Directions and Functional Information

The following example will only extract the port directions and functional
information of the cells and write them to the instance file:
import -liberty $import_lib -netlist_dir $netlist_dir -ext $ext
–use_default_whens $cells
configure $cells
characterize $cells
model $cells

No load/slew/when conditions will be extracted from the Liberty. The slews

used for characterization will be determined through automatic distribution
using the provided smallest_slew, largest_slew, and numsteps_slew
parameter settings.
The loads used for characterization will be determined through automatic
distribution using the smallest_load, largest_load, and
numsteps_load or through provided auto-ranging parameter settings.
The whens (or side input sensitizations) used for characterization will be
determined by the state_partitions specified by the user.
See Also
■
Recharacterization
■
State Dependent Measurements (State Partitioning)
■
Autoranging and Automatic Parameter Determination
■
Function-Based Flow

Combining Import-Based Flows

It is possible to invoke import in Pure Recharacterization Flow mode while also
using functional recognition. It can be run with or without a golden configure.tcl
file.
import –liberty $import_lib –netlist_dir $netlist_dir –ext $ext
–recognize

It is possible to combine this command while suppressing the import of loads

and slopes to allow importing only the when conditions:
import –liberty $import_lib –netlist_dir $netlist_dir –ext $ext
–recognize –use_default_slews –use_default_loads

SiliconSmart ACE User Guide 59

L-2016.03
Chapter 3: SiliconSmart Data Flow
Function-Based Flow

You have the flexibility to choose what to import from a Liberty: extract a
function from a netlist, keep the attributes from the Liberty, create final Liberty
models from scratch, or use hybrid modeling.

Function-Based Flow
Function-based flow is the most automated approach, where cells are
characterized based on a function in one of the following ways:
■
Extracting a Function from the Netlist with FR — uses Functional
Recognition to discover and use a pre-defined function in the netlist.
• Functional Recognition Flow — uses Functional Recognition to import
a function from a netlist and import other data from an existing Liberty
model (often for Recharacterization Flow).
• Automatic Vector Simulation — uses Functional Recognition and Vector
Generation based on the structure of the circuit.
■
Manually Defining a Function in the Instance Files — manually defines a
function in the instance files.

Extracting a Function from the Netlist with FR

This flow uses Functional Recognition to find and use a function defined in the
netlist. This function will be automatically be placed in the .inst file for the
affected cell.
Before using Functional Recognition, see the Setting Up Functional
Recognition section.

Requirements
This flow requires the following:
■
A netlist containing functional information — a netlist which contains the
necessary behavioral information for the cell.
■
configure.tcl — the configure file for characterization.
■
run.tcl — the flow file for characterization.

60 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Function-Based Flow

Using Commands in this Flow

This flow uses the following commands as shown below:
■
import — specify the following:
• You do not need to use the -recognize switch to activate Functional
Recognition, as it is automatically enabled when not importing a Liberty
model.
• The netlist which contains the functional information.
• The cells to be characterized.
■
precharacterize (optional) — create binning and grouping configurations.
■
configure — specify the data to be characterized and for which cells.
■
characterize — characterize the cells.
■
model — specify the data and format to be modeled.
An example of this is shown below:
Example 16 Using a Function from the Netlist
import -netlist_dir netlist_dir -ext ext cells
configure -data_to_be_characterized cells
characterize cells
model -data_to_be_modeled -modeling_formats cells

In the above example:

■
-data_to_be_characterized — data to be characterized, as allowed
by the configure command.
■
-data_to_added — data to be modeled with the model command.
■
-modeling_formats — modeling formats to be included, as allowed by
the model command.
See Also
■ Functional Recognition
■
Functional Recognition Flow

Manually Defining a Function in the Instance Files

To define a function in the instance files, you will need to edit the cell instance
files as detailed in the Editing Instance Files and Defining a Function in
Instance Files sections.

SiliconSmart ACE User Guide 61

L-2016.03
Chapter 3: SiliconSmart Data Flow
Structure-Based Flow

Structure-Based Flow
This approach characterizes by targeting specific arcs or locations and
simulating vectors, rather than characterizing specific cells. This approach can
work for more cells at a time, and is recommended to be used when running
into capacity limitations in other flows. The following flows are available:
■
Automatic Vector Simulation — uses Functional Recognition and Vector
Generation to find and characterize arcs based on an existing function.
■ Manually Defining Simulation Vectors— uses a user-defined stimulus to
specify arcs, rather then allowing functions to find them automatically.

Automatic Vector Simulation

This flow uses Functional Recognition and Vector Generation to look inside the
netlist to check the cell structure and generate an efficient and more complete
set of vectors, based on Boolean logic. Use this flow only for new modeling and
characterization, not for recharacterization or incremental characterization.

Note: It is recommended to use Vector Generation when running into

capacity limitations during the configure step of standard flows.

Before using Functional Recognition, see the Setting Up Functional

Recognition section.

Requirements
This flow requires the following:
■
A netlist containing functional information — a netlist which contains the
necessary behavioral information for the cell.
■
configure.tcl — the configure file for characterization.
■
run.tcl — the flow file for characterization.

62 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Structure-Based Flow

Using Commands in this Flow

This flow uses the following commands as shown below:
■
set_parameter — set the following:
• set_parameter configure_from_structure to true to activate
Vector Generation.
• set_parameter state_partitions to one of the values specified
in the Using Vector Generation section to determine which arcs will be
characterized.
■
import — specify the following:
• Use the -recognize switch to activate Functional Recognition, which
is otherwise disabled by default when importing a Liberty model.
• The netlist which contains the functional information.
• Specify to use default slews/loads/timing arcs during characterization
and not to extract the information from the Liberty model.
• The cells to be characterized.
■
configure — specify the data to be characterized and for which cells.
■
characterize — characterize the cells.
■
model — specify the data and format to be modeled (and whether to create
a new model).
An example of this is shown below:
Example 17 Using Vector Generation to Automatically Characterize Arcs
set_parameter configure_from_structure true
set_parameter state_partitions value
import -fast -recognize -netlist_dir netlist_dir
-use_default_whens -use_default_slews -use_default_loads
-extension ext cells
configure -fast -data cells
characterize cells
model -data -create_new_model cells

See Also
■
Functional Recognition
■
Using Vector Generation
■
Command: set_parameter

SiliconSmart ACE User Guide 63

L-2016.03
Chapter 3: SiliconSmart Data Flow
Sequence-Based Flow

■
Parameter: configure_from_structure
■
Parameter: state_partitions

Manually Defining Simulation Vectors

Manual definition of simulation vectors is done through the
add_user_stimulus command, which is detailed in the Adding a User-
Defined Stimulus section.

Sequence-Based Flow
The sequence-based characterization approach characterizes by using a user-
defined input stimulus to specify arcs to be characterized and the sequence to
be performed, without using automated methods. This is the most user-
intensive flow, as it does not use functions. This approach is useful when a
function is too complex or is not being recognized by the SiliconSmart tool.
Sequence-based flow is done through the add_user_stimulus command,
which is detailed in the Adding a User-Defined Stimulus section.

Additional Flow Options

The following sections describe additional options which can be used with
existing characterization flows:
■
Explicitly Generating Load/Slope Indices for Automatic Distribution
■ Using the Driver Waveform from an Imported Liberty

Explicitly Generating Load/Slope Indices for Automatic

Distribution
There are several options for specifying and distributing load/slope indices to
be used for characterization (see Autoranging and Automatic Parameter
Determination). Typically, when an automatic index distribution algorithm is

64 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Additional Flow Options

used, the SiliconSmart tool will perform this distribution internally and use it
directly for simulation purposes.
Alternatively, you can specify custom load/slew with
explicit_points_load and explicit_points_slew, which makes the
load/slew information easily visible in the instance or flow files.
If you need to read, edit, or source this explicit load/slope information, you can
use the generate_auto_index command to create an auto index file which
includes these explicit slew and load points. The generated file will be
<cell>.auto_indx, located in the <charpoint>/<control> directory with
set_config_opt commands for explicit_points_load and
explicit_points_slew.
In a typical flow, you may not need to read or edit this auto index file and it will
automatically be sourced. However, if there is a need to read or edit the file, you
must use generate_auto_index before the configure command; any
interceptions may be made right then after the command completes execution
and then the configure, characterize, and model steps of the flow will
proceed as normal.
See Also
■
Command: generate_auto_index
■
Parameter: explicit_points_load
■
Parameter: explicit_points_slew
■
Autoranging and Automatic Parameter Determination

Using the Driver Waveform from an Imported Liberty

During recharacterization, if the imported liberty file has normalized driver
waveform constructs and you wish to characterize the library using the driver
waveform from this reference library, set the parameter
import_liberty_ndw to 1. This must be set before the import step.
By default, this parameter is set to 0, which means the tool will use the driver
defined in the driver_mode parameter in configure.tcl.
See Also
■
Parameter: driver_mode
■
Parameter: import_liberty_ndw

SiliconSmart ACE User Guide 65

L-2016.03
Chapter 3: SiliconSmart Data Flow
Additional Characterization Flows

Additional Characterization Flows

The SiliconSmart tool supports additional characterization methodologies and
flows, which are described in the following chapters:
■
Chapter 6, Memory Characterization — characterizes memory components
such as RAMs, ROMs, and register files.
■
Chapter 7, Statistical Characterization — characterizes the sensitivity of the
delay through cells with respect to process model variations.
■
Chapter 8, IBIS Characterization — supports I/O Buffer Information
Specification (IBIS).

Creating a run.tcl File for Characterization

Each characterization flow can also be performed by creating a running a TCL
script containing the flow commands. This allows an automated way of running
and rerunning the same characterization flow. There is no naming convention
for this flow file/script.
To create the run.tcl file:
1. In a tcl editor, create a new file named run.tcl.
2. Add a command to create a new characterization directory:
create char_dir

3. Add a command to specify the location and name of the log file which you
want to use to save the messages (info/warning/error) of the current
SiliconSmart session:
set_log_file char_dir/siliconsmart.log

4. Copy your configure.tcl file to the new characterization directory, located:

file copy path/golden_configure.tcl char_dir/config/
configure.tcl

5. Add a command to set the characterization directory location (see Setting

Your Characterization Point for more information):
set_location char_dir

66 SiliconSmart ACE User Guide

L-2016.03
 Chapter 3: SiliconSmart Data Flow
Creating a run.tcl File for Characterization

6. Add the flow commands import, configure, characterize, and

model with the necessary arguments as described above each flow. See
Selecting a Characterization Flow for more information on the different
characterization flows.
7. Add a command to quit the SiliconSmart tool when finished:
quit

8. Save the run.tcl file.

9. To run the characterization using the created file, type the following into the
SiliconSmart shell:
sis_cci> run.tcl

The complexity of the above flow file will depend on the complexity of the flow.
For example, if specific cell types require special overrides, or any pre or post
processing that needs to be performed, or any other customized step. These
will all need to be added to the flow file.

SiliconSmart ACE User Guide 67

L-2016.03
Chapter 3: SiliconSmart Data Flow
Creating a run.tcl File for Characterization

68 SiliconSmart ACE User Guide

L-2016.03
 4
4

Importing and Configuring

This chapter describes importing and configuring the set of functions for
describing a cell’s function and behavior.

To begin a characterization of any kind, the characterization directory must first

be prepared with the inputs required by the tool.
Importing will prepare the characterization point with the input netlists and
instance files (obtained from or created by the netlists or Liberty model).
Configuring will provide the engine with the stimulus patterns and information
on which arcs to simulate and how to simulate them.

Note: Before importing and configuring cells, make sure that you have
set up the tool by following the steps in the Setting Up for Your
Characterization section.

The below sections detail the flow and the necessary steps to import and
configure in preparation for characterization:
■ Editing the configure.tcl File
■ Importing Cells
• Cell Types and Behavior
• Describing Cell Behavior
■ Editing Instance Files
■
Creating a run.tcl File
■
Configuring Cells
• Function-Based Configuration
• Structure-Based Configuration

SiliconSmart ACE User Guide 69

L-2016.03
Chapter 4: Importing and Configuring
Editing the configure.tcl File

• Sequence-Based Configuration
• Setting Advanced Configuration Options

Editing the configure.tcl File

Before running characterization, you must set up the operating environment by
editing the configure file, configure.tcl. You can generate the configure.tcl file
from scratch or you can use the create –legacy mycharpoint command
to copy the default configure.tcl file from the install_path/etc/configure.tcl file to
the mycharpoint/config/ directory automatically.
The configuration file defines three types of data:
■
Global Configuration Parameters
■
Pin Type Definitions
■
Operating Conditions
■
Example configure.tcl File

Global Configuration Parameters

Global configuration parameters specify information that is pertinent to all cells
within a given characterization directory structure. You must edit the default
values for some of the following parameters before characterization:
■
active_pvts (block: param)
■
job_scheduler (block: param)
■ normal_queue (block: param)
■
power_meas_supplies (block: param)
■ power_period (block: pintype)
■
run_list_maxsize (block: param)
■
simulator (block: param)
■
simulator_cmd (block: param)
■
simulator_options (block: param)

70 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Editing the configure.tcl File

■
time_res_high (block: param)
■
trailing_delay (block: pintype)
See Chapter 15, SiliconSmart Parameters for more information on these
parameters and their usage.

Pin Type Definitions

Pin type definitions allow attributes to be described for each type of pin on a
CUT. This allows both digital and analog attributes to be defined along with
other common attributes. Attributes for a specific pin type are described within
a pin type group. You can specify a pin type group with the pintype command.
Normally, one of the standard SiliconSmart pin type parameters is specified for
the parameter argument, but user-defined parameters are allowed (though
meaningless to SiliconSmart). The standard SiliconSmart pin type parameters
are enumerated in Chapter 15, SiliconSmart Parameters.

Example 18 Example of a Pin Type Definition

pintype default {
set logic_high_name VDD
set logic_high_threshold 0.9
}

The default configure.tcl file contains one pin type called default. When
working with I/O cells or others with level-translation capability, you must create
additional pin type definitions. You must create as many pin type definitions as
required to fully capture all the level translation features of the CUT.
Pin type blocks can be inherited from one another. To do this, use the ->
operator as follows:
Example 19
pintype io_pad -> default {
set logic_low_name VSS
set logic_high_name VDD3
}

In this example, all parameters defined in pin type default are copied into the
new pin type (io_pad). The logic_low_name and logic_high_name
parameters are immediately overridden for the CUT pins that are associated
with the io_pad pin type. The original parameters within the default pin type
are not modified.

SiliconSmart ACE User Guide 71

L-2016.03
Chapter 4: Importing and Configuring
Editing the configure.tcl File

Slew points are determined by the parameters smallest_slew,

largest_slew, numsteps_slew, and explicit_points_slew. All
measurements related to model characterization are made using input
transition times implied by these parameters. Slew values (actually transition
times) are in units of seconds. Transition times are defined as the time required
for the signal of interest to transition between the defined logic thresholds,
specifically logic_low_threshold and logic_high_threshold.
The explicit_points_slew parameter takes precedence over the other
parameters. It is a list with monotonically ascending transition times. Consider
the following example:
set explicit_points_slew {
0.1e-9 0.2e-9 0.3e-9 0.4e-9 0.5e-9
}

This indicates transition times from 100ps to 500ps. If absent, SiliconSmart

generates a list with the number of points specified by numsteps_slew
between smallest_slew and largest_slew. The list contains the values
specified by:
smallest_slew +  (largest_slew–smallest_slew)
2.5 1.75
I + I  -
and:  = ---------------------------------------------
2.5 1.75
Imax + Imax
where integer I varies from 0 to Imax , and Imax = numsteps_slew-1.

Asymmetric Slew Thresholds

SiliconSmart allows individual high/low and rise/fall logic thresholds with the
following four parameters in the configure.tcl file:
Example 20
logic_low_threshold_fall 0.25
logic_high_threshold_fall 0.55
logic_low_threshold_rise 0.25
logic_high_threshold_rise 0.55

These parameters are added in the pin type group. These parameters override
the previous more encompassing parameters:
Example 21
Logic_low_threshold 0.25
Logic_high_threshold 0.55

72 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Editing the configure.tcl File

For symmetric thresholds, only the previous two parameters would need to be
specified as before. The rest of the more specific parameters, would be derived
from these 2 general parameters automatically.
The slew derate feature will be disabled automatically if a real asymmetrical
slew thresholds are used (i.e., logic_high_threshold_rise !=
logic_high_threshold_fall AND/OR logic_low_threshold_rise
!= logic_low_threshold_fall). If slew thresholds are not asymmetrical,
slew derate feature will be enabled and the value will be calculated based on
value of parameters logic_high_threshold_rise &
logic_low_threshold_rise and slew_derate_upper_threshold &
slew_derate_lower_threshold.
The definition of these parameters corresponds to Liberty modeling parameters
for rise and fall slew thresholds, as follows:
Example 22
logic_high_threshold_rise -> slew_upper_threshold_pct_rise
logic_low_threshold_rise -> slew_lower_threshold_pct_rise
logic_high_threshold_fall -> slew_upper_threshold_pct_fall
logic_low_threshold_fall -> slew_lower_threshold_pct_fall

Setting Pin Type Parameter Defaults

The default values of the following pin type parameters often need to be
modified before characterization:
■
explicit_points_load
■
explicit_points_slew
■
initial_delay
■
largest_load
■
largest_slew
■
logic_high_name
■
logic_high_threshold
■
logic_low_name
■
logic_low_threshold_fall
■
numsteps_load
■
numsteps_slew
■
prop_delay_current

SiliconSmart ACE User Guide 73

L-2016.03
Chapter 4: Importing and Configuring
Editing the configure.tcl File

■
prop_delay_level
■
smallest_slew
■
smallest_load
See Chapter 15, SiliconSmart Parameters for more information on these
parameters and their usage.

Operating Conditions
Process, voltage, and temperature (PVT) conditions are specific to your
environment and must always be specified in the configure.tcl file. In the default
configure.tcl file, one operating condition is defined. You must edit this
operating condition to describe your specific environment. You can define any
number of operating conditions, but each must have a unique name. An
operating condition is created with the create_operating_condition
command.
Each operating condition requires definitions for process, voltage, and
temperature. The process definition is a list of strings that indicate the process
technology files. These strings are placed verbatim into the generated SPICE
decks. The process definitions are specified with the command
set_opc_process. This command takes the name of an existing operating
condition and a list of process strings as its arguments.
The voltage definitions define a name and value pair. All defined voltages are
available as global nodes in the SPICE decks generated by the tool. The
temperature definition specifies the temperature at which the CUT is
characterized. The voltage pairs are added with the command
add_opc_supplies. One or more pairs may be added with each call.
set_opc_temperature is used to set the operating temperature.

74 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Editing the configure.tcl File

The following example shows how to define two operating conditions:

Example 23
# Create an operating condition called 'best_pvt'.
create_operating_condition best_pvt

# Specify the process lines. The following lines are included in the
# SPICE deck verbatim and must be correct for the given simulator.
set_opc_process best_pvt {
{.lib "/home/charWiz/spiceModels/process.lib" FF}
{.lib "/home/charWiz/spiceModels/process.lib" FF_3V}
}

# This defines the supply rails and sets the operating temperature.
add_opc_supplies best_pvt VSS 0.0 VDD 1.1 VDD3 3.63
set_opc_temperature best_pvt 0

# This is a second operating condition named 'worst_pvt'.

create_operating_condition worst_pvt
set_opc_process worst_pvt {
{.lib "/home/charWiz/spiceModels/process.lib" SS}
{.lib "/home/charWiz/spiceModels/process.lib" SS_3V}
}
add_opc_supplies worst_pvt VSS 0.0 VDD 0.9 VDD3 2.97
set_opc_temperature worst_pvt 125

You can now use the operating condition name, best_pvt, as an element in
the active_pvts described in the example to generate a Liberty model at this
process corner. Consider the following example:
Example 24
set active_pvts {best_pvt}

This statement indicates to SiliconSmart the PVT that will be used for
characterization and model generation. Only one PVT should be specified with
active_pvts. If a multi-PVT characterization is desired, it is recommended to
run characterization for each PVT separately in its own respective charpoint.

Note: When generating IBIS models, the active_pvts parameter

can take multiple operating conditions and is order-dependent.
See Chapter 8, IBIS Characterization for more information on
IBIS support in SiliconSmart.

Parameters can be set on an operating condition and referenced in a harness

circuit. The parameters can be used to adjust the harness based on operating
condition to change circuit element values or change pin settings by changing

SiliconSmart ACE User Guide 75

L-2016.03
Chapter 4: Importing and Configuring
Importing Cells

DC voltage source values. Parameters are set using the

set_opc_parameter command.

Example configure.tcl File

An example configure.tcl file is included in the SiliconSmart tool’s install
directory with comments with explanations about and for setting parameters.

Importing Cells
Use the import command to import the cells from a Liberty (.lib) file, a SPICE
netlist, or a SiliconSmart characterization directory into an existing
characterization directory.

Example 25 Importing from a Liberty File

import [-liberty liberty_file]
[-netlist netlist_file] [-recognize] [-overwrite]
[-configure] [-fast] [-flatten] [-inouts inouts]
[-inputs inputs] [-outputs outputs] [-powers powers]
[-netlist_dir dir] [-no_copy 0|1]
[-extension netlist_ext] [-ideal_netlist_ext netlist_ext]
[-rechar] [-state_independent]
[-use_default_slews] [-use_default_loads]
[-use_constraint_seeds] [-use_default_whens]
[-compress_flops] [-write_internal_nodes] [-noheader]
[-nocellmodel] [cells]

In the above example, assume you have a Liberty model and want to add one
or more cells to the SiliconSmart characterization directory. Use the –liberty
option to import a set of cells from the Liberty file. The Liberty model of each
cell is saved and an instance file is generated for each cell. A netlist file for each
cell must also be imported.
If the netlists are available in an existing directory, the directory can be
specified with the -netlist_dir switch and SiliconSmart will copy the netlist
file for each cell and automatically invoke Functional Recognition to try and
discover the function. Otherwise, each cell's netlist must be copied into the
netlists directory. Use this option to recharacterize the cell or produce a new
model.

76 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Importing Cells

Example 26 Importing from a Netlist:

import [-netlist netlist_file] [-overwrite] cells

In the above example, assume you only have a netlist for a cell and want to
generate a new model. If you use the –netlist option to import the cell’s
netlist, a skeleton instance file will be generated for the cell. SiliconSmart will
read the netlist and attempt to figure out the direction of each pin on the
subcircuit definition and generate the appropriate instance file. You must then
edit the instance file to provide the behavioral definition of the cell.

Note: You cannot use both the -netlist and -recognize switches
together with the import command.

Example 27 Importing from a SiliconSmart Characterization Directory:

import [-overwrite] [-configure] [-state_independent]
[-use_default_slews] [-use_default_loads]
[-use_default_whens] cells

In the above example, the import command copies the Liberty model of each
cell, the cell’s SPICE netlist, and generates an instance file for the cell. If the
-configure option is specified, a new configure.tcl file will be generated
based on the configuration parameters from SiliconSmart.
The following example illustrates the effect of the various import switches. This
example will focus on a 4-to-1 multiplexer with select pins S0 and S1, data
inputs A0, A1, A2, and A3, and an output pin Z. When pin S0 transitions, the
logical value of Z depends only on pins A0 and A1. However, the electrical
behavior may change depending on the states of A2 and A3.

SiliconSmart ACE User Guide 77

L-2016.03
Chapter 4: Importing and Configuring
Importing Cells

Importing this cell using the default options will generate the following calls in
the cell’s instance file for the S0 to Z arc where both transition from low to high:
Example 28
set_config_opt -from S0 -to Z state_partitions explicit
set_config_opt -from S0 -to Z whens
{A0&!A1&!A2&!A3 A0&!A1&!A2&A3 A0&!A1&A2&A3 A0&!A1&A2&!A3}

# Save the load points.

set_config_opt -from S0 -to Z -to_dir lh -pin Z \
explicit_points_load {1e-15 3e-15 10e-15 25e-15 100e-15}
set_config_opt -from S0 -to Z -to_dir hl -pin Z \
explicit_points_load {1e-15 3e-15 10e-15 25e-15 100e-15}

# Save the slew points.

set_config_opt -from S0 -to Z -to_dir lh -pin S0 \
explicit_points_slew {10e-12 20e-12 100e-12 200e-12}
set_config_opt -from S0 -to Z -to_dir hl -pin S0 \
explicit_points_slew {10e-12 20e-12 100e-12 200e-12}

In this example, the first line specifies that the when clauses for this arc will be
specified explicitly. In this case, there are four cases as extracted from the
Liberty file and they appear in the second line. The next two sets of lines record
the load and slew points from the Liberty model. This makes the simulations
use the same points that the timing models use.
If the model is instead imported using the following command:
Example 29
import -state_independent -use_default_slews -use_default_loads
MUX41

then the following lines will be generated in the cell’s instance file:
Example 30
set_config_opt -from S0 -to Z state_partitions one

The option state_partitions is now set to one, indicating that a single

secondary state will be selected for this arc, aside from the required settings for
A0 and A1. Also, the explicit_points_load and
explicit_points_slew lines are gone. Instead, the values come from the
pin type for the appropriate pin, which is usually present in the configure.tcl file.

78 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Editing Instance Files

Editing Instance Files

An instance file is a short Tcl script that describes the structure of a cell, its
logical behavior, and specifies any configuration options that provide additional
control over how the cell is characterized and modeled.
When a cell is imported, the SiliconSmart tool will automatically create an
instance file, which contains the functionality and interface (input/output pin)
information. During configuration, the SiliconSmart tool automatically reads this
file and executes the commands contained in it whenever it needs to know the
structure or function of a cell.
In some cases, you will need to customize and edit instance files. Using the
Example 1 — Complete Instance File shown in the Example Instance Files
section, the following sections describe the contents of an instance file:
■
Specifying Netlist Location
■
Defining Pins
■
Describing Cell Behavior
■
Specifying Characterization and Modeling Options
■
Specifying Pin Usage
■
Example Instance Files

Specifying Netlist Location

The first section, consisting of the set_netlist_file and add_pin
commands specifies the location of the cell’s netlist and describes the structure
of the cell in terms of the pins and their electrical characteristics. This is shown
below:
Example 31
set_netlist_file [get_location]/netlists/HDBUFD1.cir

##
## Pin definitions
##
add_pin A default -input
add_pin Z default -output

SiliconSmart ACE User Guide 79

L-2016.03
Chapter 4: Importing and Configuring
Editing Instance Files

The netlist file can be stored anywhere in the network file system, but typically
SiliconSmart copies them into the char_dir/netlists directory to make them
easily available. In this case, the path contains the command get_location
to make the location independent of the actual location of the characterization
directory. A typical example looks like this:
Example 32
set_netlist_file [get_location]/netlists/BUF1.cir

Defining Pins
The first section of the instance file also specifies each of the pins on the cell
and its electrical characteristics with the add_pin command. Using this
command, you can specify the name of a pin, its pin type, and the direction of
the pin.
As an example, the following commands define three pins on a simple
bidirectional I/O cell where pin PAD has a pin type of pad_3v instead of
default:
Example 33
add_pin A default –input
add_pin PAD pad_3v –inout
add_pin Z default –output

Three special direction switches are also provided. The switch –clock
indicates that the pin is an input pin used as a clocking signal. When the cell is
modeled, clock pins are identified as appropriate for the model format.
The switch –supply is used for adding supply pins such as VDD or VSS.
The switches –internal and –spice_node are used to create internal
nodes, which are described in more detail in the I/O Cells section.
The switch -retention is used for defining retention pins, which are
described in more detail in the Defining a Retention Cell section.

80 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Editing Instance Files

Describing Cell Behavior

The second section describes the logical behavior of the cell, which is, in this
case, merely the add_function call:
Example 34
##
## Cell function definition
##
add_function Z A

Specifying Characterization and Modeling Options

The final section, identified by the set of set_config_opt commands,
specifies the characterization and modeling options. These options determine
the measurements to be taken. The instance file in the example was imported
from an existing Liberty model so the options are specified to reproduce the
original, including the slew and load points for the timing and power arcs:
Example 35
##
## User-specified characterization and modeling configuration
options
##

## state_partitions option
set_config_opt -type timing state_partitions none
set_config_opt -type constraint state_partitions none
set_config_opt -type mpw state_partitions none
set_config_opt -type energy state_partitions none
set_config_opt -type leakage_power state_partitions none
set_config_opt -type noise state_partitions one
set_config_opt -type leakage_power state_partitions one
set_config_opt -type { noise timing } -from A -to Z
state_partitions one

## explicit_points_load option
set_config_opt -type { noise timing } -from A -from_dir lh -to Z
-to_dir lh -pin Z explicit_points_load { 0 3.692e-15 9.179e-15
2.972e-14 1.186e-13 1.524e-13 1.914e-13 }

set_config_opt -type { noise timing } -from A -from_dir hl -to Z

-to_dir hl -pin Z explicit_points_load { 0 2.13e-15 2.389e-14
4.614e-14 7.735e-14 2.334e-13 4.982e-13 }

SiliconSmart ACE User Guide 81

L-2016.03
Chapter 4: Importing and Configuring
Editing Instance Files

## explicit_points_slew option
set_config_opt -type { noise timing } -from A -from_dir lh -to Z
-to_dir lh -pin A explicit_points_slew { 8.811e-12 2.558e-11
8.822e-11 1.427e-10 2.115e-10 2.956e-10 5.292e-10 6.9e-10 8.614e-
10 }

set_config_opt -type { noise timing } -from A -from_dir hl -to Z

-to_dir hl -pin A explicit_points_slew { 1.09e-11 5.259e-11
9.137e-11 1.458e-10 2.146e-10 3.008e-10 4.067e-10 5.399e-10
6.854e-10 8.769e-10 }

Specifying Pin Usage

The parameter pin_category allows the particular use of a pin to be
specified rather than relying on SiliconSmart to infer this from the behavior.
set_config_opt -pin shift pin_category sync_control

Example Instance Files

In general, it is often unnecessary to edit the majority of instance files created
when importing from a Liberty file. However, if you are importing from a netlist
file, or have a complex cell, you will have to fill in the details and will probably
want to specify additional options.
■
Example 1 — Complete Instance File
■
Example 2 — Two-Input And-Or-Inverted Combinational Cell
■
Example 3 — Flip-Flop with Asynchronous Set Pin

82 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Editing Instance Files

Example 1 — Complete Instance File

Below is an example instance file, combined from the previous sections.
Example 36 Complete Instance File
###############################################################
# Cell instance file for BUF1 generated by SiliconSmart 20xx.x. #
# #
# Copyright (C) 2013 Synopsys, Inc. #
# This file contains confidential and proprietary information. #
# All rights reserved. #
# #
# File generated on Thu Feb 24 11:26:17 CST 2013. #
###############################################################

set_netlist_file [get_location]/netlists/HDBUFD1.cir

##
## Pin definitions
##
add_pin A default -input
add_pin Z default -output

##
## Cell function definition
##
add_function Z A

##
## User-specified characterization and modeling configuration
options
##

## state_partitions option
set_config_opt -type timing state_partitions none
set_config_opt -type constraint state_partitions none
set_config_opt -type mpw state_partitions none
set_config_opt -type energy state_partitions none
set_config_opt -type leakage_power state_partitions none
set_config_opt -type noise state_partitions one
set_config_opt -type leakage_power state_partitions one
set_config_opt -type { noise timing } -from A -to Z
state_partitions one

## explicit_points_load option
set_config_opt -type { noise timing } -from A -from_dir lh -to Z
-to_dir lh -pin Z explicit_points_load { 0 3.692e-15 9.179e-15
2.972e-14 1.186e-13 1.524e-13 1.914e-13 }

SiliconSmart ACE User Guide 83

L-2016.03
Chapter 4: Importing and Configuring
Editing Instance Files

set_config_opt -type { noise timing } -from A -from_dir hl -to Z

-to_dir hl -pin Z explicit_points_load { 0 2.13e-15 2.389e-14
4.614e-14 7.735e-14 2.334e-13 4.982e-13 }
## explicit_points_slew option

set_config_opt -type { noise timing } -from A -from_dir lh -to Z

-to_dir lh -pin A explicit_points_slew { 8.811e-12 2.558e-11
8.822e-11 1.427e-10 2.115e-10 2.956e-10 5.292e-10 6.9e-10 8.614e-
10 }

set_config_opt -type { noise timing } -from A -from_dir hl -to Z

-to_dir hl -pin A explicit_points_slew { 1.09e-11 5.259e-11
9.137e-11 1.458e-10 2.146e-10 3.008e-10 4.067e-10 5.399e-10
6.854e-10 8.769e-10 }

Example 2 — Two-Input And-Or-Inverted Combinational Cell

The following example shows a combinational cell, which has a two-input AND-
OR-INV type of functionality.
Example 37 Two-Input And-Or Inverted Combinational Cell Example
## Location of the netlist for this cell
set_netlist_file [get_location]/netlists/AOI22D4.cir

## Pin definitions
add_pin A0 default -input
add_pin A1 default -input
add_pin B0 default -input
add_pin B1 default -input
add_pin Y default -output

## Boolean description of the cell

add_function Y {!((A0&A1)|(B0&B1))}

84 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

Example 3 — Flip-Flop with Asynchronous Set Pin

The following example shows a flip-flop with an asynchronous set pin and
inverting and non-inverting outputs.
Example 38 Flip-Flop with an Asynchronous Set Pin Example
## Location of the netlist for this cell
set_netlist_file [get_location]/netlists/DFFSD3.cir

## Pin definitions
add_pin D default -input
add_pin SN default -input
add_pin CK default -clock
add_pin Q default -output
add_pin QN default -output

## Cell function definition

add_flop IQ IQN CK D -preset {!SN}
add_function Q IQ
add_function QN IQN

Cell Types and Behavior

To characterize a cell, the SiliconSmart tool must have a complete
understanding of the switching behavior of the circuit it is to analyze. For
standard cells and I/Os, SiliconSmart can automatically compute this
information from a logical description of the cell. The logic description consists
of a set of Boolean equations describing the output function of each pin and,
optionally, any sequential elements contained in the cell.
The SiliconSmart tool has a powerful set of functions for easily describing a
cell’s function, whether the cell is a simple buffer or a complex cell containing
multiple sequential elements.
The following sections describe basic cell types and behavior:
■
Combinational Cells
■
Sequential Cells
■
Complementary Inputs and Differential Pins
■
I/O Cells
■ Memory Cells
■
Multi-Bit Cells

SiliconSmart ACE User Guide 85

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

■
Structural Cell Description
■
Constraint Measurements to Internal Nodes

Combinational Cells
Combinational cells are those in which each output pin is a function of only one
or more input pins and the cell contains no state information. These cells can
be imported through Functional Recognition, recharacterization, or a new
characterization flow:
■
Adders
■
Buffers
■
Inverters
■
Multiplexers (and one-hot)
■
Level-shifters
■
Arithmetic cells
■
Other translation function cells
The SiliconSmart tool provides Tcl commands for describing their behavior
using a combination of Boolean functions and truth tables. This section
describes the use of both mechanisms.
The order of the commands is important. In case of conflict, the initial
command takes priority with subsequent commands serving to fill in undefined
states.
The following sections describe combinational cells:
■
Boolean functions
■ Truth Tables

Boolean functions
The simplest command for specifying a cell’s function is the add_function
command.
In the simplest form, this command accepts the name of an output pin and a
Boolean expression defining its logical function. The Boolean expression can
be a function of any input or bidirectional pin, internal pins (see the Constraint
Measurements to Internal Nodes section), or state registers (see the
Sequential Cells section).

86 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

The command to define a two-input NAND gate is:

Example 39
add_function Z {!(A&B)}

The add_function command also accepts optional switches to specify an

expression for high-impedance and illegal states. High-impedance states are
those when the pin is not driven to any logic level. For example, the following
command creates a tri-state buffer where the output pin is enabled when pin EN
is high:
Example 40
add_function Z A –hi_z {!EN}

SiliconSmart does not attempt to simulate illegal states, such as when the
output is undefined and in which the cell is not expected to enter under normal
operation. These can occur in cells with differential inputs or in one-hot
multiplexers where two input pins can not be in the same state. As an example,
the following command defines the function of a buffer with differential input
pins:
Example 41
add_function Z {DP&!DN} –illegal {DP&DN | !DP&!DN}

In this example, Z follows the differential pair DP and DN and is undefined if the
pins are not in different states. See the Complementary Inputs and Differential
Pins section for more information on differential signaling and one-hot
multiplexers.

Truth Tables
SiliconSmart supports the use of truth tables to describe the logical function of
combinational cells. Truth tables can be easier to understand when working
with logically complex cells. A truth table can take as input the same inputs as a
Boolean function. That is, a combination of input and bi-directional pins,
internal pins, and state registers. These appear as columns in the left side of
the table. Columns on the right side define the output values and can consist of
output or bidirectional cells and internal pins.
A truth table is created with the add_table command.

SiliconSmart ACE User Guide 87

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

For example, the truth table for a NAND gate looks like this:
Example 42
add_table {
A B : Z
0 0 : 1
0 1 : 1
1 0 : 1
1 1 : 0
}

Each value in the input_pin_settings and output_pin_results

consists of one or more tokens representing the value of that input or output
pin. See Table 33 for a complete list of tokens supported by add_table.
Multiple values for a pin can be listed in a single column, separated by slashes.
If more than one column in a row has multiple values then each must have the
same number of values. This is equivalent to a separate row for each value with
single value columns repeated.
The following example is a more compact version of the NAND gate example
from above:
Example 43
add_table {
A B : Z
0/0/1 0/1/0 : 1
1 1 : 0
}

Bi-directional cells are represented in a truth table by showing any bi-directional

signals on both the input and output side of the table. However, the way
SiliconSmart interprets the table is very specific and care must be taken to
make sure that the table correctly represents the behavior of the cell. The value
listed as the output value is the value being driven by the cell itself and the input
value is interpreted as the value of the pin itself–not the value being driven by
an external source. That means that when the cell is driving a value, that value
must be shown in both columns for the pin. If the cell is not driving a value (the
output is in tri-state mode), then the input column reflects the value being
driven externally and the output column should have the Z token.

88 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

As an example, consider a cell with input A, tri-state control pin EN, a bi-
directional pin PAD, and an output Z. The following table reflects the typical
behavior:
Example 44
add_table {
A EN PAD : PAD Z
0/1 1 0/1 : 0/1 0/1
- 0 0/1 : Z 0/1
- 0 Z : Z X
}

The first row in the table reflects the case where PAD is enabled and the value
on A and driven onto PAD. Notice that the value appears in both columns for
PAD. Pin Z reflects the value of PAD.
The second row covers the case where PAD is in tri-state mode and is being
driven externally. The input column shows the value being driven externally and
the output column indicates that the driver is disabled. Again, pin Z reflects the
state of PAD.
Finally, the last row covers the case where PAD is not driven internally or
externally. In this case, the value of Z is undefined.

Sequential Cells
Sequential cells are any cells capable of retaining one or more bits of state
information. These can include:
■
Flip-flops (edge-triggered)
■
Latches (level-triggered)
■
Retention logic cells
■ Dynamic cells
For standard sequential cells, you can import the functions from a Liberty or
extract the functions with a Functional Recognition flow. For more complex
sequential cells (such as retention logic cells), it is more difficult for the
SiliconSmart tool to define the nuances of the cell functionality. In this case, it is
best to first add necessary information to the cell instance files, and then, if
necessary, use add_user_stimulus if the complex functionality cannot be
expressed using any of the standard TCL functions.
SiliconSmart provides two methods for describing sequential cells: the
add_flop and add_latch commands for describing standard flops and

SiliconSmart ACE User Guide 89

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

latches, and state tables via the add_table command for specifying complex
circuits.
This following sections describes the use of each of these functions.
■
Flops and Latches
■
State Tables

Flops and Latches

The commands add_flop and add_latch provide a simple method for
describing the behavior of most flops and latches found in a standard library.
The only difference in the usage of the two commands is the clock_expr and
enable_expr arguments. A flop is triggered when clock_expr transitions to
a true state whereas a latch is enabled (transparent) anytime enable_expr is
true.
The arguments register and inv_register specify the names of the state
register and the inverted state register, respectively. The register names can be
treated as input pin names and thus used in the Boolean expressions of other
commands such as add_function or other calls to add_flop or
add_latch, or even in the data expression argument of the same call.
The -preset and -clear switches allow you to specify the asynchronous
preset and clear conditions. When either of these conditions is true the flop or
latch is placed into a preset or clear state, respectively. When both switches are
specified, there is a possibility that both conditions could be true at the same
time. By default, SiliconSmart considers this an undefined condition. However,
if the state registers go to a known state, that state can be specified with the
–preset_clear switch. This switch takes a pair of values (0 or 1) indicating
the value of the register and inverting register, respectively. See the following
example.
As a simple example, the following command describes a basic D-flip flop:
Example 45
add_flop IQ IQN CK D

This flop has two registers, IQ and IQN, and the data pin D is clocked in
whenever CK rises (transitions to true). The following command could then
use the state register IQ to control an output pin Q:
Example 46
add_function Q IQ

90 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

As mentioned previously, the state register of a flop can also be used in the
data expression of the flop itself. For example, the following command
describes a toggle flop in which the output either captures the D input or toggles
based on whether the enable pin EN is true, respectively:
Example 47
add_flop IQ IQN CK {D&EN | IQN&!EN}

The state register of one element can also be used in the data expression of a
second element. For example, the following commands create two simple
latches in series that implement a standard D-flip flop:
Example 48
add_latch IQ1 IQN1 !EN D
add_latch IQ2 IQN2 EN IQ1

Notice that the data expression of the second is the state register of the first.
This description is logically equivalent to using a single call to add_flop.

Defining a Retention Cell

Retention cells are sequential cells that can hold their internal state when the
primary power supply is shut down and restore the state when the power is
brought up.
Retention flops are generally comprised of one of the following:
■
A regular flip-flop with a slave or master latch that stores data in place during
the retention operation.
■
An extra latch with special control logic to store the state of the cell when it
is powered down.
Typically, this special latch is implemented with high-threshold transistors
and is powered by a ‘backup’ power supply, which is an additional power
supply. In addition, the ‘Save & Restore’ signal pins control the storage of
the data in the special latch or enable data transfer from the regular flip-flop
to the special latch and back, depending on the mode of operation (normal
active mode and retention mode).

SiliconSmart ACE User Guide 91

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

Following is a simple example of a 1 bit retention flop (without the reset & clear
functionality):
■ Input pins: SCANIN, CLOCK, DATA, SHIFT, BACKUPPOWER (retention
pin)
■
Output pins: OUT, SCANOUT
■
Additional Power supplies: vdd_backup (power supply for retention latch)
In this example, the retention pin is for a slave latch and can also function as a
scan cell. The retention pins are generally defined as -retention.
The following should be added to the instance file:
add_pin scanin default -input
add_pin data default -input
add_pin scanenable default -input
add_pin clk default –clock
add_pin RETN backuppower -retention
add_pin out default -output
add_pin scanout default –output
add_pin -supply vdd default
add_pin -supply vdd_backup backup_power
add_pin –supply vss_backup backup_power
add_pin -supply vss default
set_liberty_attribute -pin vdd_backup pg_type backuppower

You can now define the cell logic function for the retention flop using add_flop
or add_function:
add_flop IQ IQN CLK
{(((SCANENABLE&(!SCANIN))|((!SCANENABLE)&DATA))&(!RETN))}

Finally, define the backup_power as a pin_type in the configure.tcl file:

pintype backup_power -> default {
set logic_high_name vdd_backup
set logic_low_name vss_backup
}

State Tables
State tables are similar to truth tables, but instead of specifying the value of
output pins, they define the value of a set of state registers in terms of the input
pins and the current value of the state registers. State tables are a powerful
means of describing complex state machines in table format.

92 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

A state table looks similar to a truth table and is created with the same
command. However, instead of having two sets of columns it has three: input
pin state, current state, and next state.
For example, the state table for a latch looks like this:
Example 49
add_table {
D EN : IQ : IQ
0/1 1 : - : 0/1
- 0 : 0/1 : 0/1
}

Each value in the input_pin_settings, current_state_regs, and

next_state_regs consists of one or more tokens representing the value of
that input pin or state register. See Table 33 for a complete list of tokens
supported by add_table.
One token particularly useful for state tables is the no-change token n. This
value in the next_state_settings column indicates that a particular
register does not change value. This token can be used to simplify the latch
description from above:
Example 50
add_table {
D EN : IQ : IQ
0/1 1 : - : 0/1
- 0 : - : n
}

State tables can be used to describe edge-triggered behaviors as well. The

following state table describes a standard D-flop using the r token to indicate
rising-edge-triggered behavior:
Example 51
add_table {
D CK : IQ IQN : IQ IQN
0/1 r : - - : 0/1 1/0
- ~r : - - : n n
}

The tilde (~) in front of the r token in the second line is the negation token and
is true any time CK is not rising. The example also uses two state registers, IQ
and IQN. Any number of state registers can be defined so long as all the
registers appear in the same order in both the current_state_regs and the
next_state_regs groups.

SiliconSmart ACE User Guide 93

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

Complementary Inputs and Differential Pins

Characterization of most cells is performed under the default assumption that
only a single input pin transitions at any given time. This is true for most cells,
but some classes of cells have a set of input pins that must transition in pairs
with the pins transitioning in opposite directions or, sometimes, in the same
direction. The simplest case of this is a pair of differential inputs in which the
two pins are always in opposite states. One-hot multiplexers are a more
complex case.
One-hot multiplexers are cells in which one and only one select line is active
(hot) at any time. The simplest implementation is a collection of three-state
buffers in which each select line enables a single buffer. Disabling all of the
select inputs is typically illegal as it would result in the output not being driven.
Characterizing the select pins thus requires two simultaneous transitions, one
disabling the current active select line and a second activating a second line. In
Figure 6, this could mean applying a falling transition to S0 and a rising
transition to S1. By default, SiliconSmart does not look for cases in which
multiple transitions are required so this must be declared explicitly.

D0

S0

D1 Y

S1

D2

S2
Figure 6 One-Hot Mux

94 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

The following sections describe options for complementary outputs and

differential pins:
■ Specifying Pins
■
Specifying Behavior and Conditions

Specifying Pins
The following commands are used to specify pins:
■
add_switching_set — A general-purpose command that allows you to
specify a set of pins of which any individual pin can transition independently
or any pair of pins can transition together. A set of pins can be a simple pair,
such as a complementary clock pair, or a larger set, such as in a one-hot
multiplexer.
This command can be called multiple times to define multiple sets of pins.
When specifying a set of pins that switch in pairs it is important to describe
the function of the cell to include only the valid states and not the illegal
ones.
■
add_switch_tuple — Similar to add_switching_set but operates at a lower-
level and provides greater control. The input to this command is a list of pins
that are allowed to switch simultaneously. SiliconSmart will then look for
switching events in which each of those pins all switch together. This allows
groups where more than two inputs can switch together. However, it also
means that all possible combinations of pins must be specified.
For example, the following commands allow any set of four pins to switch
together out of a set of 6:
add_switch_tuple { S0 S0B S1 S1B }
add_switch_tuple { S0 S0B S2 S2B }
add_switch_tuple { S1 S1B S2 S2B }

This case would occur in a one-hot mux in which the select lines are
complementary.
■
define_differential_receiver — Specifies a pair of differential input pins and
the output that is the result of the inputs. This is similar to the
add_switching_set command, except that only the specified output is a
differential function. This means that SiliconSmart will only look for
transitions where the two input pins transition opposite each other for the
specified output and normal (nondifferential) transitions for all other output
pins. This case arises in some I/O cells in which the inputs do not always
behave differentially, such as USB cells.

SiliconSmart ACE User Guide 95

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

define_differential_receiver output { input1 input2 }

The following circuit is described by the command below it:

INP
OUT
INN

define_differential_receiver OUT { INP INN }

■ set_output_differential — Defines a pair of differential output pins.
This means that SiliconSmart automatically ensures that the output load on
each pin is the same.
Using set_output_differntial on a pair of output signals indicates to
SiliconSmart that the waveforms on both signals must be monitored to
determine the exact steady state values of the signal. The waveform is then
post-processed to determine the correct trip points for delay and slew
calculation.

Specifying Behavior and Conditions

The following commands are used to specify behavior and conditions:
■
add_function — Specifies the logical function of a pin, including both the
output equation and the illegal states.
For example, consider a buffer with complementary inputs A and B. The
correct add_function command is as follows:
add_function Y {A&!B} -illegal {A&B|!A&!B}

This command specifies that the output is high when A is high and B is low.
It also specifies that A and B can never both be high or both low as would be
true for complementary inputs. If the illegal states are not defined,
SiliconSmart will also find the transitions in which a single pin transitions.
SiliconSmart assumes that each of the pairs of pins within a switching set
are equivalent and only generates a single rising and single falling event for
each pin, independent of the pin it happens to be paired with. For example,
if there are three input pins A, B, and C, only one arc will be generated where
A is rising. If A is paired with B falling, it will not necessarily generate the

96 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

case of A rising and C falling. The reason is that the characterization time
quickly becomes unreasonable and the Liberty format, among others, does
not support modeling these cases.
■
add_forbidden_state — Specifies a Boolean equation that, when true, is an
illegal condition. SiliconSmart will not consider any illegal condition when
generating a simulation. Using the example of add_switch_tuple, shown
above, the illegal conditions could be defined using
add_forbidden_state as follows:
add_forbidden_state { !(S0^S0B) }
add_forbidden_state { !(S1^S1B) }
add_forbidden_state { !(S2^S2B) }
# Only one select pair can be true at any given time
add_forbidden_state {S0&S1 | S0&S2 | S1&S2}

A second use of this command is in defining a flop with complementary

clocks. The add_switching_set command allows CK and CKB to switch
together, but the behavior of the cell must be limited to the case where they
are always complementary. In this case the description of the cell looks like
this:
add_flop IQ IQN {CK & !CKB} D
add_switching_set { CK CKB }
add_forbidden_state { !(CK^CKB) }
■
add_one_hot — A convenience function for defining the behavior of one-hot
multiplexers. One-hot multiplexers are cells in which one and only one select
line is active (hot) at any time.
Defining the behavior requires a function definition that defines the output in
terms of the select and data lines, and also specifies as illegal any state in
which zero or two or more select lines are active at once. All illegal states
are tagged as forbidden states. This command internally calls the
add_function, add_switch_tuple and add_forbidden_state
commands to describe this behavior.
■
add_fixed_value — Allows an input or bidirectional pin to be set to a
constant state (0, 1).

I/O Cells
I/O cells have more complex logical behaviors that must be described. Many of
these cells can use Functional Recognition to discover functions, or as a

SiliconSmart ACE User Guide 97

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

starting point for manually defining a complex function with add_function/

add_table constructs or add_user_stimulus.

Memory Cells
Although memory cells cannot be configured with Functional Recognition or
Vector Generation, memory characterization can be performed in a specialized
template-based flow which will construct the functionality using a state table for
conforming memories. Functions can also be defined manually with the
add_user_stimuls command.
See Chapter 6, Memory Characterization for more information on memory
cells, including details on configuration and characterization.

Multi-Bit Cells
A multi-bit register is a collection of multiple, single-bit flops, where each single-
bit flop shares control signals with the other flops and performs an identical
function.
See Importing and Configuring Multi-Bit Cells for information on importing and
configuring multi-bit cells, or Modeling Multi-Bit Cells for information on
modeling multi-bit cells.

Structural Cell Description

With SiliconSmart, you can describe a cell structurally, as it would appear in a
block diagram. You can combine multiple elements—flops, latches, functions,
and tables—to build up the description of a cell. The example using two latches
to describe a flop is a very simple example of using a structural description.
Figure 7 describes a more complex example.

98 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Cell Types and Behavior

D1 IQ1

0
Z
D2 IQ2
1

CK
Figure 7 Two Flops Feeding A Multiplexor

This circuit can be described using the following commands:

Example 52
add_flop IQ1 IQN1 CK D1
add_flop IQ2 IQN2 !CK D2
add_function Z {IQ1&!CK | IQ2&CK}

In the example, the add_function command created a definition of the mux

that combines the outputs of the two flops by using the register values directly.
The state registers make it convenient to use their value in the mux, but they
are not the only option; internal pins as created with the add_pin command
can also be used. Figure 8 adds a mux to the front of each flop.

D1 0
node 1 IQ1

SD1 1

SE
0
D2 0 Z
node 2 IQ2
1
SD2 1

CK
Figure 8 Muxes in Front of Flops Feeding A Mux

SiliconSmart ACE User Guide 99

L-2016.03
Chapter 4: Importing and Configuring
Cell Types and Behavior

These could be added by modifying the data expression of the flops or by using
two add_function commands with internal pins, shown here:
Example 53
add_pin node1 default -internal
add_pin node2 default -internal
add_function node1 {D1&!SE | SD1&SE}
add_function node2 {D2&!SE | SD2&SE}
add_flop IQ1 IQN1 CK node1
add_flop IQ2 IQN2 !CK node2
add_function Z {IQ1&!CK | IQ2&CK}

The advantage of using separate add_function statements instead of

putting the expression in the add_flop lines is the expanded form tends to be
easier to read when the logical expression is very complex. However, it is a
matter of personal preference as both are logically equivalent.
One case where the two descriptions are not equivalent is when it comes to
constraint measurements. In this case, it can be important to use the internal
node description as covered in the next section.

Constraint Measurements to Internal Nodes

The circuit shown in Figure 7 presents a challenge for constraint
measurements. Consider a setup constraint. To make this measurement,
SiliconSmart applies a transition on the D pin and then clocks the flop. It must
then be able to directly observe the state of the flop. In this case, the state can’t
be directly observed because not only does the value have to propagate
through the mux at the output, but the select line being tied to the clock means
that the output is delayed by half a clock cycle. SiliconSmart will not generate
these constraint measurements because the output is not directly observable.
To handle this case, you must find a node internal to the circuit at the output of
each flop and create an internal pin. If the internal nodes are named n576 and
n250, the cell would be described with the following commands:
Example 54
add_pin node1 default -internal -spice_node n576
add_pin node2 default -internal -spice_node n250
add_flop IQ1 IQN1 CK D1
add_flop IQ2 IQN2 !CK D2
add_function node1 IQ1
add_function node2 IQ2
add_function Z {node1&!CK | node2&CK}

100 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Configuring Cells

Note: In this example, node1 and node2 are dummy node names,
which can be used at any point in the instance file when that
particular internal node needs to be referenced. It can be
associated with a -spice_node switch, where the value of the
spice_node is the actual netlist node name. So, in this
example, n576 is an actual SPICE node name from the netlist.

The first two lines create the internal pins. By providing the SPICE node name
of each internal pin, SiliconSmart is able to make measurements to these pins.
When a constraint measurement is to be made on the first flop, node1 will be
used as the output pin.

Configuring Cells
Before running characterization, you must set up the characterization plan by
setting up, importing, and/or editing a configure.tcl file for the characterization
and instance files for each cell. Once you have set up the below, you can then
run the configure command.
■
Editing the configure.tcl File — setting global behavior and parameters for
all cells.
■
Importing Cells — importing cells into the characterization directory.
■
Editing Instance Files — setting behavior for individual cells.
■
Analyzing the Netlist (Optional) — recognizes structure to reduce overall
characterization time.
■
Precharacterization (Optional) — uses binning and grouping to reduce
overall characterization time.
■ Using the configure Command — configures the cells and creates
characterization plans.

Analyzing the Netlist (Optional)

This process is optional for standard timing, power, and noise characterization,
though it helps to reduce overall characterization time.
The analyze_netlists command performs two important functions. First, it
is used to recognize the transistor structure of sequential cells to better

SiliconSmart ACE User Guide 101

L-2016.03
Chapter 4: Importing and Configuring
Configuring Cells

optimize the acquisition of constraints. This is known as path-based constraint

analysis and is described in detail in the sections that follow.
The second function of the analyze_netlists command is to prepare the
netlists for statistical characterization. This function is part of the SiliconSmart
DFM package and only necessary when performing statistical characterization.
See Also
■
Chapter 7, Statistical Characterization
■
Path-Based Constraint Analysis
■ Command: analyze_netlists

Precharacterization (Optional)
An optional step for configuring is precharacterization. This steps analyzes the
state-dependent behavior of any state-dependent arcs and again reduces the
overall characterization time by collapsing states with similar timing and power
characteristics. Precharacterization only needs be performed once for a given
library.
See Also
■
Precharacterization
■
Command: precharacterize

Using the configure Command

The process of converting the behavioral description of a cell to a set of
characterization results is performed in two steps: configuration and
characterization. The configuration step takes the behavioral description of
each cell and the configuration settings and generates a characterization plan.
The characterization plan describes each of the measurements to be
performed, the stimulus to be applied, and other pertinent information. The
characterization plan is stored in a template file in the char_point/etc/template
directory.
The configure command is used to configure specified cells for
characterization and generate the characterization plan:
Example 55
configure -options cells

102 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Configuring Cells

Note: When no flags are specified, -timing and -power are

activated by default.

Note: By default, the configure command runs in parallel mode on

farm machines with the -fast option enabled.

As SiliconSmart proceeds, you will receive information about what

SiliconSmart is doing. For each cell, SiliconSmart will read the instance file,
and then configure the cell for characterization by generating the tests for
timing, power, ECSM and CCS characterization.
When SiliconSmart finishes configuring a cell, the following message appears
the siliconsmart.log file (or the log file specified with set_log_file):
Info: Cell cellname configured for characterization.

The template files created by the configuration process are saved in your
char_dir/etc/templates directory. For each successfully configured cell, a file is
created with the name of the cell and a .t file extension.
Once characterization plans have been generated, the cells can be
characterized. The characterization process takes the characterization plan for
each cell and generates the file necessary to describe each measurement to
be performed. Each cell has a corresponding charpt/results/$cell directory. This
$charpt/results is considered the cache storage of the current characterization
run.
The caching stores information about a run, so that if these cells/arcs are run
again and certain pre-determined criteria have not changed, then those cells/
arcs will not be rerun again. Instead they will be considered as "cached". This
helps in saving valuable runtime.
Below are examples of scenarios during characterization where the tool will
consider if there is a cache hit or cache miss if parameter enable_cache is
turned on (default is off).
Cache Hit:
■
Changed a modeling related parameter (for example, min vs. max
capacitance selection method)
■
Changed LSF to grid or used AMD vs. Intel machines, etc.
■
Added model_api code to post process Liberty files
■
Tweaked settings for 1 out of 1000 cells; there will be cache hit for 999 cells

SiliconSmart ACE User Guide 103

L-2016.03
Chapter 4: Importing and Configuring
Configuring Cells

Cache Miss:
■
Changed a simulation related parameter (for example,
constraint_resolution)
■
Chose a different simulator
■
Contents of process models is identical but the directory location is different
■
Changed configuration mechanism (for example, the parameter
combine_timing_and_power is turned off when rerun)
The rest of this chapter describes setting configuration behavior for cells in
order to generate the characterization plan.
See Also
■
Chapter 5, Characterizing and Modeling
■
Command: configure

104 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Function-Based Configuration

Function-Based Configuration
There are several function-based configuration flows for extracting, defining,
and importing a function for characterization. Figure 9 provides a high-level
illustration of these various import flows.

Figure 9 Logical and Functional Recognition Flow

The following sections describe how to configure cells based on functions:

■
Functional Recognition
■
Defining a Function in Instance Files

Functional Recognition
This section describes the functional recognition feature (SiliconSmart FR)
included with SiliconSmart. To facilitate setting up libraries for characterization

SiliconSmart ACE User Guide 105

L-2016.03
Chapter 4: Importing and Configuring
Function-Based Configuration

with SiliconSmart, you can use the functional recognition (FR) feature for cases
in which an existing Liberty model is not available. FR is also useful as a
validation step to verify whether the function extracted from the netlist does
indeed match the function that may be available in a pre-existing Liberty model.
Additionally, FR is useful for extracting functions for complex cells whose
functional description is not available in Boolean form (perhaps it only exists in
behavioral Verilog.)
See Function-Based Flow for a step-by-step Functional Recognition flow.
The following sections describe functional recognition in SiliconSmart:
■
Functional Recognition Methodology
■
Using Functional Recognition
■
Setting Up Functional Recognition
■
Log Files and Debugging

Functional Recognition Methodology

The SiliconSmart Functional Recognition methodology recognizes functional
clusters of logic composed of some base primitive types:
■
Storage elements (flop or latch)
■
Arbitrary combinational logic clusters
A Boolean functional description for the complete cell is created from the
cluster level functions. For standard cells, this Boolean description is directly
used in the SiliconSmart .inst file to drive characterization via logical functions
(same as the Liberty-based flow from this point forward).

Using Functional Recognition

The SiliconSmart FR flow is similar to the existing Liberty model import-based
flow. With FR, all functional information can be extracted from the netlist and
optionally complemented with other library, cell, and pin-level data available in a
pre-existing Liberty model.
SiliconSmart FR is simply another way to import a library of cells, and thus, is
accessible via the SiliconSmart import command. You can use the –
recognize switch to enable functional recognition explicitly. When no Liberty
model is specified, FR is invoked automatically.

106 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Function-Based Configuration

When SiliconSmart FR has trouble identifying the port direction, you must
provide the port direction using -inputs, -clocks, and -outputs switches if
the cell Liberty file is not available.
The various modes in which you may use the import command are as follows:
■
Case 1 — function extracted from Liberty; slew/loads/whens also extracted
from Liberty (recharacterization flow). Consider the following example:

Example 56
import -liberty import_lib -netlist_dir netlist_dir -ext ext
cells
■
Case 2 — function extracted using FR. Only the function is placed in the .inst
file via FR: new model flow. Note that the -recognize switch is not needed
because it’s the default if the -liberty switch is not specified. Consider the
following example:

Example 57
import -netlist_dir netlist_dir -ext ext cells
■
Case 3 — function extracted from FR; port directions extracted from Liberty
file.
This case is useful when FR has a difficult time figuring out port directions
for some cells. In this case, the port directions in the Liberty file will be used
instead.
Consider the following example:

Example 58
import -recognize -liberty import_lib -netlist_dir netlist_dir
-ext ext –use_default_whens –use_default_slews
–use_default_loads cells
■ Case 4 — hybrid flow, function extracted from FR; slew/load/whens/port-
directions extracted from Liberty file. Consider the following example:

Example 59
import -recognize -liberty import_lib -netlist_dir netlist_dir
-ext ext cells

SiliconSmart ACE User Guide 107

L-2016.03
Chapter 4: Importing and Configuring
Function-Based Configuration

■
Case 5 — hybrid flow, function extracted from FR; slew/loads/whens from
autoranging and state partitioning settings; port directions from Liberty file.
Although slew/loads/whens are not extracted from the model, this still allows
re-char modeling flow to preserve model structure. Consider the following
example:

Example 60
import -recognize -liberty import_lib -overwrite -netlist_dir
netlist_dir -ext ext -use_default_whens cells

Note: For the hybrid cases 3 and 4, the FR function overrides the
function in the Liberty model. See Figure 9 for a high-level
illustration of the various flows.

You can use the following switches with the import command (in the
SiliconSmart FR flow).
■
-flatten — flattens hierarchical netlists.
■
-model_file — specifies the process model file to be used by FR for
finding transistor models. It overrides any model files specified in the
set_opc_process commands within the configure.tcl file.
■
-inputs, -outputs, -inouts, -powers, -grounds — specify input
ports, output ports, inout ports, power rails, and ground ports explicitly for
complex cells when it may not be possible to detect the direction of ports
automatically from the netlist file.
■
-extension — Specifies the file name extension for the file netlist. This is
used when generating the cell instance files when importing from a Liberty
file. If used with the -netlist_dir switch it also specifies the extension of
the files to be copied.
■ -merge_reg_out_inv — FR will generate the function Q and QN with IQ
and IQN, instead of !IQ and !QN.
■ -clocks — Identifies clock pins. Regular expressions can be used in the
-clocks switch.

Setting Up Functional Recognition

SiliconSmart FR has the inputs shown below. The import command reads the
configure.tcl file to obtain the following configuration information for FR:

108 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Function-Based Configuration

■
SPICE netlists (1 file per cell):
• Berkeley SPICE compatible format only. Native Spectre netlists not yet
supported.
■
Process models:
• Complete definition of the process model files via the
add_opc_process command in the configure.tcl file.
■
Power rails:
• Complete add_opc_supplies definition in the configure.tcl file
• power_meas_supplies and power_meas_grounds parameters.
■
Clock pins:
• These must be identified when importing sequential cells using the
-clocks switch on the import command. Consider the following example:

Example 61
import -recognize -netlist_dir netlist_dir -ext ext –clocks
{clk tclk} cells

You must list the clock pin as both a clock pin and an input pin, otherwise
SiliconSmart FR will have trouble identifying the clock direction.
Consider the following example:

Example 62
import -netlist_dir {netlists} -extension .cir -clocks {CLK}
-inputs {CLK ZTDATA} -outputs {Q} {cells}
■
Model names:
• If using subcircuit wrappers for all transistors in the netlists (as would be
the case for statistical characterization netlists), the
nmos_model_names and pmos_model_names parameters must also
be defined.
• If there are diodes in the netlist, the dio_model_names parameter
must be defined.
• If there are capacitor models in the netlist (instead of flat capacitor
values), the cap_model_names parameter must be defined.
• If there are resistors in the design, the res_model_names parameter
must be defined.

SiliconSmart ACE User Guide 109

L-2016.03
Chapter 4: Importing and Configuring
Function-Based Configuration

Note: FR will fail if required model names are left undefined.

Log Files and Debugging

All logs for FR are saved to the char_dir/runtime/fr directory. The main FR log
file is named fr.log in this directory. If FR fails, please check this file for error
messages. Typically, errors are caused when one of the necessary inputs is not
provided correctly. See the Setting Up Functional Recognition section for more
details.
Another file found in this directory is named spiceLibFile. This single contains a
concatenation of all the files found in the add_opc_process definition in the
configure.tcl file. This is done to maintain any subcircuit definitions found in any
of the process model files.
For debugging purposes, a functional cluster level Verilog model can be found
in the char_dir/runtime/fr/cellname/cellname_tx.v directory. You can use this file
to see channel connected block (CCB) level cluster connectivity. The functional
definition of each one of these clusters can be found in Liberty format in the file
named cellname_tx.lib.

Defining a Function in Instance Files

Boolean expressions are used in add_function, add_flop, and
add_latch and other commands. The syntax for the expressions is the same
for all commands. Each function consists of a series of input pins and logical
operators. Bidirectional pins are allowed.
The following table lists the valid Boolean operations in order of precedence
(highest first).
Table 4 Function Operations

Operations Valid Syntax

not !A, ~A, or A'

and A*B, A&B, A B

xor A^B

or A+B, A|B

110 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Structure-Based Configuration

A blank between pin names implies an and operation. You can change
operator precedence with parentheses, as in the example (A+B)*C.
White space between pin names and operators is allowed, but in this case the
expression must be written as a Tcl list by enclosing the entire expression
within curly braces, { }. The following statements are equivalent:
Example 63
add_function Y C*(A+B)
add_function Y { C (A + B) }

Structure-Based Configuration
Structure-based flow targets specific arcs or locations and simulating vectors,
rather than characterizing specific cells. This approach can work for more cells
at a time, and is recommended to be used when running into capacity
limitations in other flows.
■
Vector Generator (VG)
■
Adding a User-Defined Stimulus

Vector Generator (VG)

SiliconSmart Function Recognition functionality includes a characterization
vector generation capability. This functionality is referred to as VG. This
capability has several benefits over the standard characterization vector
generation flow:
■
Performs white box vector generation by actually looking inside the netlist
and checking the cell structure to generate a more efficient and complete
set of vectors.
■
Since VG performs a complete vector expansion based on Boolean logic
function alone, it can handle much high capacities in terms of number of pins
and the complexity of the functions for a given cell.
■
Since VG uses a path tracing within the cell netlist to figure out which vectors
are relevant, it could potentially create a good usable set of vectors without
requiring precharacterization.

SiliconSmart ACE User Guide 111

L-2016.03
Chapter 4: Importing and Configuring
Structure-Based Configuration

Note: It is recommended only to use Vector Generation when running

into capacity limitations during the configure step with the default
flow. For all other cases, use the default Function-Based Flow.
The following sections describe using Vector Generation:
■
Using Vector Generation
■
VG State Partitioning Modes

Using Vector Generation

VG must always be used in conjunction with FR, so be sure to use the
-recognize switch on the import command to invoke FR when planning to
use VG functionality.
VG needs to be enabled in the configure.tcl file or your run script before running
any of the main flow commands in SiliconSmart such as import or
configure.
To enable VG, set the following parameter the default parameter block:
Example 64
set configure_from_structure true

You can also set it in a run script, or you can set the following right after the
set_location command:
Example 65
set_location char_point
set_parameter configure_from_structure true

VG State Partitioning Modes

While using the VG flow, the parameter state_partitions must be a value
from the set {one, one_per_path, one_per_block_set,
all_per_path, all_per_block_set}. The operation of each of these
options is as follows:
■
one — one acquisition for each input to output transition combination.
■
one_per_path — one acquisition for each unique switching path from an
input to an output. Only one side input setting is considered.
■
one_per_block_set — similar to one_per_path except that
terminations on different non-switching blocks (ie., the hidden branches) are
treated as separate acquisitions. Only one side input setting is considered.

112 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Structure-Based Configuration

■
all_per_path — similar to one_per_path except that all possible
combinations of side input settings are considered.
■ all_per_block_set — similar to one_per_block_set except that all
possible combinations of side input settings are considered.
Other values for state_partitions (all, explicit, ones_count) are
not permitted and should not be used with VG.
As usual, setting state_partitions to none will disable some set of arcs.
For instance, the following command in the instance file will disable all delay
arcs from A to Y:
set_config_opt -type delay -from A -to Y state_partitions none

SiliconSmart ACE User Guide 113

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

Use VG only with the new characterization and modeling flow. Thus, always
use the import command with the -use_default_whens,
-use_default_loads, and -use_default_slews switches.
Example 66
//a complete flow:

# create a working char point directory structure

create charpt

# copy in a pre-prepared configure.tcl file

exec cp ./configure.tcl charpt/config

# set location of charpt dir

set_location charpt

# Enable VG
set_parameter configure_from_structure true

# Select the VG partitioning mode

set_parameter state_partitions one

# Run FR in parallel
import -fast -recognize -netlist_dir data/netlists
-use_default_whens -use_default_slews -use_default_loads
-liberty data/import.lib -extension .cir cells

# configure the cells

configure -fast -timing -power cells

# run characterization
characterize cells

# generate the model

model -timing -power -create_new_model cells

Sequence-Based Configuration
The sequence-based flow characterizes by using a user-defined input stimulus
to specify arcs to be characterized and the sequence to be performed, without
using automated methods. This is the most user-intensive flow, as it does not

114 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

use functions. This approach is useful when a function is too complex or is not
being recognized by the SiliconSmart tool.
The following sections describe using a user-defined input stimulus:
■
Adding a User-Defined Stimulus
■
add_user_stimulus Examples

Adding a User-Defined Stimulus

The add_user_stimulus adds user-defined input stimulus and
measurements for cases which are not handled by the automated methods.
This is useful for specialized circuits such as analog circuits, pulse latches, and
large complex circuits, where automatic function recognition cannot be
performed.
Other advantages include:
■
Stimulus defined by add_user_stimulus automatically replaces
SiliconSmart generated stimulus for matching arcs
■
Multiple measurements can be combined into a single waveform sequence.
■
Additional measurements are automatically made where relevant. For
example, defining a delay measurement with add_user_stimulus
automatically creates measurements for slew, input capacitance, and
switching energy.
■
A variety of complex arcs can be defined with a small amount of Tcl code.
Each row specifies the driven inputs (in), the observed outputs (out) or the
outputs not expected (not), and measurements which can be taken at that
point in the stimulus (meas).
The measurement specification is similar to that for set_config_opt. The
type is a subset of the -type from set_config_opt. The states field is a
logic expression describing all states to which the measurement applies (as
well as the one actually measured).
The possible types used for AUS type are:
■
energy
■
leakage
■
timing

SiliconSmart ACE User Guide 115

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

timing child types:

• delay
■
constraint
constraint child types:
• setup
• hold
• recovery
• removal
■
mpw
■
snps_mtcmos_iv
For example, the following adds a AUS for delay for a flop:
add_user_stimulus {
{ in { CP 0 D 0 } out { Q X } } 1
{ in { CP 1 } out { Q 0 } } 2
{ in { D 1 } } 3
{ in { CP 0 } } 4
{ in { CP 1 } out { Q 1 } 5
meas { type delay from CP to Q states }
}
}

116 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

where each numbered line corresponds to the following waveforms:

add_user_stimulus Constructs
The following sections describe AUS constructs:
■
Specifying Initial States
■
-rise_fall Construct
■
-all_permutations Construct
■
-explicit_permutations Construct
■
-cell Construct
■
-substitute Construct

Specifying Initial States

The initial option is used to specify pins, both internal and output, that must
be initialized to the prescribed value. It can only occur on the first stimulus row.
Syntax
add_user_stimulus {
{in {internal_pin} out {output_pin} initial
{pins_to_be_initialized}
...
}

SiliconSmart ACE User Guide 117

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

Examples
add_user_stimulus {
{ in {D 0 CP 0} out {Q X} initial {IQ 1 IQN 0} }
{ in {CP 1} out {Q 0} }
{ in {D 1}}
{ in {CP 0}}
{ in {CP 1} out {Q 1}
meas {type delay from CP to Q}}
}

will create:
delay__CP__lh__Q__lh__ACQ_1.typ_pvt.initialization
.ic

* IQ = 1
+XDFQD1BWP_inst.IQ = 1.10

* IQN = 0
+XDFQD1BWP_inst.IQN = 0.00

-rise_fall Construct
The -rise_fall construct produces two AUS stimuli, one with the
subsequent AUS as is and a second stimuli with the pins listed in the argument
having inverted polarity.
Syntax
add_user_stimulus -rise_fall {pin_list}
Description
All pin(s) specified as argument to-rise_fall must be associated with a
switching activity in the AUS stimuli. Pin(s) associated with a Z state are legal in
the argument, provided it switches state, and the Z state shall remain
untouched by –rise_fall.
The pin(s) under AUS’s initial block will not be touched by –rise_fall
construct, even if a pin that found its way accidentally in initial block is part of
the rise_fall pin_list argument.
This is typically used to automatically derive the HL (LH) stimuli from the LH
(HL) stimuli that we specified using an AUS.

118 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

Examples

Example 67
add_user_stimulus \
{
{ in { bin 0 } out { bout 0 } }
{ in { bin 1 } out { bout 1 }
meas { type delay from bin to bout states “1” }
}
}

The above AUS stimulus produces the delay arc

delay__bin__lh__bout__lh. In most cases, the stimulus for
delay__bin__hl__bout__hl would necessitate just a change in bin and
bout.

Example 68
add_user_stimulus \
-rise_fall { bin bout } \
{
{ in { bin 0 } out { bout 0 } }
{ in { bin 1 } out { bout 1 }
meas { type delay from bin to bout states “1” }
}
}

Thus, the –rise_fall construct comes handy as in above to produce

delay__bin__lh__bout__lh and delay__bin__hl__bout__hl.

-all_permutations Construct
-all_permutations replicates the subsequent AUS stimulus as an initial
value setting for all binary combinations of the argument (pin_list).
Syntax
add_user_stimulus -all_permutations {pin_list}
Description
The state of each permutation will be ANDed (logical AND) with the state of the
AUS stimuli. Associating a logic level (0/1/Z) to the permuted pin(s) in the
AUS stimuli is not illegal, but defeats the purpose of permutation. You need to
make sure that the permuted pin(s) don’t appear in the AUS stimuli, unless
there is an exceptional requirement.

SiliconSmart ACE User Guide 119

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

Please note the following:

■
-all_permutations can accept wildcards for pin/port names as an
argument in pin_list.
■
An AUS stimuli with X permuted pins would produce strictly 2^X stimuli.
■
-all_permutations can be typically employed to replicate an arc/
stimulus for all possible binary combinations of select pins like drive-
strength control pins.
Examples

Example 69
add_user_stimulus -all_permutations {PIN0 PIN1 PIN2} {
{in {OE 1 D0 0} out {PAD 0} }
{in {OE 1 D0 1} out {PAD 1}
meas {type delay from D0 to PAD states "OE"} }
}

set_config_opt -type delay -from D0 -to PAD state_partitions

as_given

Note: For this particular arc, it is necessary to specify as_given as the

state_partitions for these particular set of states to
materialize (otherwise, these states/arcs will not get generated).

The above AUS stimulus produces all 8 combinations of PIN0, PIN1, PIN2:
Example 70
OE&!PIN0&!PIN1&!PIN2
OE&!PIN0&!PIN1&PIN2
OE&!PIN0&PIN1&!PIN2
OE&!PIN0&PIN1&PIN2
OE&PIN0&!PIN1&!PIN2
OE&PIN0&!PIN1&PIN2
OE&PIN0&PIN1&!PIN2
OE&PIN0&PIN1&PIN2

120 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

The power of -rise_fall and -all_permutations could be leveraged

together to create another 8 states for positive_unate falling DO->PAD arc,
with a simple addition as follows:
Example 71
add_user_stimulus \
-rise_fall { DO PAD } \
-all_permutations { PIN0 PIN1 PIN2 } \
{
{ in { OE 1 DO 0 } out { PAD 0 } }
{ in { OE 1 DO 1 } out { PAD 1 }
meas { type delay from DO to PAD states “OE” }
}
}

Wildcard application in –all_permutations:

Example 72
add_user_stimulus -all_permutations {PIN*} {
{in {OE 1 D0 0} out {PAD 0} }
{in {OE 1 D0 1} out {PAD 1}
meas {type delay from D0 to PAD states "OE"} }
}

set_config_opt -type delay -from D0 -to PAD state_partitions

as_given

Note: For this particular arc, it is necessary to specify as_given as the

state_partitions for these particular set of states to
materialize (otherwise, these states/arcs will not get generated).

-explicit_permutations Construct
-explicit_permutations is used to specify explicit or selective
combinations of states for an AUS stimuli. It replicates the subsequent AUS
stimulus for all the specified state in the argument.
Syntax
add_user_stimulus -explicit_permutation { {pin_names}
{pin’s_state_0} {pin’s_state_1} ... {pin’s_state_N}}
Description
-explicit_permutations, as the name implies, is used to specify explicit
or selective combinations of states for an AUS stimuli. It replicates the
subsequent AUS stimulus for all of the specified states in the argument.

SiliconSmart ACE User Guide 121

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

The arguments to -explicit_permutations are of the form: {{d0 d1

d2} {0 0 0} {0 1 1} .. {1 1 1}}, etc.
The 1st Tcl list specifies the pin names while the 2nd to Nth Tcl list specifies
logic levels to the pins. Each Tcl list subsequent to the first Tcl list represents a
state and is called a permuted state.
The length of the pin_names Tcl list and all pin’s_state list(s) should
match. This should hold good when wildcards are expanded.
The state of each permuted combination will be ANDed (logical AND) with the
state of the AUS stimuli. Associating a logic level (0/1/Z) to the permuted
pin(s) in the AUS stimuli is not illegal, but nevertheless, it defeats the purpose
of permutation. User need to make sure that the permuted pin(s) don’t appear
in the AUS stimuli, unless there is an exceptional requirement.
-explicit_permutations can accept wildcards for pin/port names as an
argument in pin_names.
Specifying -explicit_permutations and –all_permutations in the
same AUS stimuli is illegal.
This can be typically employed to replicate an arc/stimulus for explicit
combinations of select pins.
Examples

Example 73
add_user_stimulus -explicit_permutations {{PIN0 PIN1 PIN2} {0 0
1} {0 1 1}} {
{in {OE 1 D0 0} out {PAD 0} }
{in {OE 1 D0 1} out {PAD 1}
meas {type delay from D0 to PAD states "OE"} }
}

set_config_opt -type delay -from D0 -to PAD state_partitions

as_given

Note: For this particular arc, it is necessary to specify as_given as the

state_partitions for these particular set of states to
materialize (otherwise, these states/arcs will not get generated).

122 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

This generates the following states:

Example 74
PIN0 0
PIN1 0
PIN2 1

PIN0 0
PIN1 1
PIN2 1

Wildcard application in –explicit_permutations:

Example 75
add_user_stimulus -explicit_permutations {{PIN*} {0 0 1} {0 1 1}}
{
{in {OE 1 D0 0} out {PAD 0} }
{in {OE 1 D0 1} out {PAD 1}
meas {type delay from D0 to PAD states "OE"} }
}

set_config_opt -type delay -from D0 -to PAD state_partitions

as_given

Note: For this particular arc, it is necessary to specify as_given as the

state_partitions for these particular set of states to
materialize (otherwise, these states/arcs will not get generated).

This generates the following states:

Example 76
PIN0 1
PIN1 0
PIN2 0

PIN0 1
PIN1 1
PIN2 0

Note: The states generated with the wildcard are not the same as the
previous example; the wildcard assumes an order of PIN2-
PIN1-PIN0.

-cell Construct
The –cell construct takes a list a cell(s) as the argument, and applies the
subsequent AUS stimulus to all the specified cells.

SiliconSmart ACE User Guide 123

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

Syntax
add_user_stimulus -cell {cell_list}
Description
The mode of application/usage would be to create a master AUS file, which has
stimuli that is common for a set/subset of cells. This master AUS file could then
be simply referenced in each of the applicable cell’s instance files.
The –cell construct can accept wildcards as argument in cell_list.
Sourcing an AUS stimuli (or file) with –cell {X Y Z} construct, in the
instance file of X is legal.
Examples

Example 77
add_user_stimulus \
-cell { PAD1 PAD2 PAD3 PAD4 } \
-rise_fall { DO PAD } \
-all_permutations { PIN0 PIN1 PIN2 } \
{
{ in { OE 1 DO 0 } out { PAD 0 } }
{ in { OE 1 DO 1 } out { PAD 1 }
meas { type delay from DO to PAD states “OE” }
}
}

-substitute Construct
The -substitute construct is useful in representing a set/group of pins by a
user specified pattern, and use the pattern in the subsequent AUS stimulus.
–substitute helps in applying an AUS stimulus or method across the
pattern.
Syntax
add_user_stimulus -substitute {pattern1 pin_list_1 pattern2
pin_list_2 ... patternN pin_list_N}
Description
A pattern can be thought of as a variable that doesn’t require a Tcl subst
invocation, and uses the cross-product across all the specified patterns. An
example specification such as:

Example 78
-substitute { dpin {d0 d1} epin {e0 e1}}

124 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

would typically generate 4 arcs viz. d0->e0, d0->e1, d1->e0, and d1->e1.
The pin_list_N Tcl list can accept wildcards as an argument on pins.
For any given cell, a pattern must match at least one of the cell’s pins.
Examples

Example 79
# Measure LH hidden energy for pins d0 and d1
add_user_stimulus -substitute { dpin { d0 d1 } } \
{
{ in { dpin 0 } out { p 0 } }
{ in { dpin 1 }
meas { type energy from dpin } }
}

# Measure positive_unate rising delay from all ‘d*’ pins to ‘p0’

and ‘p1’ arcs
add_user_stimulus -substitute { dpin { d* } ppin { p0 p1 } } \
{
{ in { dpin 0 } out { ppin 0 } }
{ in { dpin 1 } out { ppin 1 }
meas { type delay from dpin to ppin } }
}

add_user_stimulus Examples
The following examples describe various AUS functions:
■
Multiple Measurements in a Single Stimulus
■
Specifying Constraints for Pulse Generator Cells
■
Specifying Transparent Edge Setup Time for Pulse Latch
■
Specifying Differential Arcs
■
Output-to-Output Delays
■
Configuring Arcs from Internal Nodes
■
Tcl foreach Loops and Variable Substitution for States
■
Tcl foreach Loops and Variable Substitution for Pins
■
Using not for a Gated Constraint

SiliconSmart ACE User Guide 125

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

Multiple Measurements in a Single Stimulus

The following example shows multiple measurements/arcs in a single stimulus:
Example 80
add_user_stimulus \
{
{ in { a 0 } out { y1 0 y2 0 } }
{ in { a 1 } out { y1 1 y2 1 }
meas { type delay from a to y1 states “1”}
meas { type delay from a to y2 states “1”} }
}

Example 81
add_user_stimulus \
-substitute { apin { a1 a2 } ypin { y1 y2 } } \
{
{ in { apin 0 } out { ypin 0 } }
{ in { apin 1 } out { ypin 1 }
meas { type delay from apin to ypin states “1”} }
}

Specifying Constraints for Pulse Generator Cells

Setting smc_constraint_style pulse-degradation should be used for
measuring the constraint on the pulse. This tests constraint validity by
measuring the width of the output pulse and failing if the pulse width varies
from the nominal by an amount specified by smc_degrade and
smc_degrade_absolute parameters.
Example 82
add_user_stimulus \
{
{ in { CKI 0 E 0 } out { CKO 0 } }
{ in { E 1} }
{ in { CKI 1} out { CKO 1 }
meas { type delay from CKI to CKO }
}
{ out { CKO 0 }
meas { type delay from CKI to CKO }
meas { type constraint from E ref CKI }
}
}

set_config_opt smc_constraint_style pulse-degradation

126 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

Specifying Transparent Edge Setup Time for Pulse Latch

Adding transparent edge setup time can be done using user-specified stimulus.
In this case the desired constraint event is specified, and delay-degradation
mode is used. The output should correspond with the enable edge instead of
the data.
Example 83
add_user_stimulus \
{
{ in { D 0 E 1 } out { Q 0 } }
{ in { E 0 } } { in { D 1 } }
{ in { E 1 } out { Q 1 }
meas { type constraint from D ref E }
}
}

Specifying Differential Arcs

Differential arc measurements can be specified as any multiple arc/
measurement. However, you must use other constructs (such as
define_differential_receiver, set_output_differential,
add_switching_tuple/set) and similar commands to establish the
relationship between complementary/differential inputs and outputs. Then,
write the AUS.
When differential parameters have been set properly in the instance file, the
Siliconsmart tool considers measurements from core_out, core_out_n and
towards pad, pad_n as differential.
Example 84
add_user_stimulus \
-rise_fall { core_out core_out_n pad pad_n } \
{
{ in { core_out 1 core_out_n 0 oe 1 } out { pad 1 pad_n 0 } }
{ in { core_out 0 core_out_n 1 } out { pad 0 pad_n 1 }
meas { type delay from core_out to pad states “1” }
meas { type delay from core_out to pad_n states “1” }
meas { type delay from core_out_n to pad states “1” }
meas { type delay from core_out_n to pad_n states “1” }
}
}

SiliconSmart ACE User Guide 127

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

Output-to-Output Delays
The following specification can be used to get all four measurements (two
clk_in -> out-lh and two delayed_clk_in -> out-hl):
Example 85
add_user_stimulus -all_permutations {sel} {
{in {clk_in 0} out {delayed_clkin 0 out 0}}
{in {clk_in 1} out {out 1}
meas {type delay from clk_in to out}}
{out {delayed_clkin 1 out 0}
meas {type delay from clk_in to delayed_clkin}
meas {type delay from clk_in to out}}
{in {clk_in 0} out {out 1}
meas {type delay from clk_in to out}}
{out {delayed_clkin 0 out 0}
meas {type delay from clk_in to delayed_clkin}
meas {type delay from clk_in to out}}
}

set_config_opt -pin out configure_delay_from_outputs

delayed_clkin

The main requirement is that the row which has the output-to-output
measurement must have measurements from the input to both outputs
specified.
The above AUS will generate the following arcs:
■
Input->Output arcs:
delay__clk_in__hl__delayed_clkin__hl
delay__clk_in__hl__out__lh
delay__clk_in__lh__delayed_clkin__lh
delay__clk_in__lh__out__lh
■
Output->Output arcs:
delay__delayed_clkin__hl__out__hl
delay__delayed_clkin__lh__out__hl

128 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

Configuring Arcs from Internal Nodes

For complex cells, some arcs or measurements involve using internal nodes.
The add_user_stimulus command allows the use of internal nodes just as
inputs or outputs.
Example 86
add_pin INT default -internal -spice_node C/D/E/INT
set_config_opt -pin INT liberty_internal_pin true

add_user_stimulus {
{ in {INT 0 EN 1} out {Q 0} }
{ in {INT 1} out {Q 1} meas {type delay from INT to Q} } }

Tcl foreach Loops and Variable Substitution for States

AUS is Tcl based and thus the power of Tcl can be leveraged in coding AUS
stimuli. The Tcl foreach loop is one of the most useful construct to simplify
AUS stimuli specification. This example also showcases the use of Tcl
variables in AUS.
Use foreach loop to associate a custom state to each permutation of drive
control pins. Consider the following example:
Example 87
add_pin d default -input
add_pin c default -input
add_pin q default -output

foreach { d0 d1 q0 q1 } {
0 1 0 1
1 0 1 0
} {
add_user_stimulus [subst {
{ in { d $d0 c 0 } }
{ in { c 1 } out { q $q0 } }
{ in { d $d1 c 0 } }
{ in { c 1 } out { q $q1 } meas { type delay from d to q } }
}]
}

This will generate the following arcs:

delay__d__lh__q__lh
delay__d__hl__q__hl

SiliconSmart ACE User Guide 129

L-2016.03
Chapter 4: Importing and Configuring
Sequence-Based Configuration

And a more complex example:

Example 88
foreach { vd2 vd1 vd0 state } {
0 0 0 "!drive_en*!drive_2*!drive_1*!drive_0"
0 0 1 "!drive_en*!drive_2*!drive_1*drive_0"
0 1 0 "!drive_en*!drive_2*drive_1*!drive_0"
0 1 1 "!drive_en*!drive_2*drive_1*drive_0"
1 0 0 "!drive_en*drive_2*!drive_1*!drive_0"
1 0 1 "!drive_en*drive_2*!drive_1*drive_0"
1 1 0 "!drive_en*drive_2*drive_1*!drive_0"
1 1 1 "!drive_en*drive_2*drive_1*drive_0"
} {
add_user_stimulus \
[subst {
{ in { drive_en 0 drive_2 $vd2 drive_1 $vd1 drive_0
$vd0 oe 1 d0 0 } out { pad 0 } }
{ in { d0 1 } out { pad 1 }
meas { type delay from d0 to pad states $state
}}
}]
}

130 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Sequence-Based Configuration

Tcl foreach Loops and Variable Substitution for Pins

Use foreach loops to measure LH/HL delays from a host of _IN pins to _OUT
pins. This example also showcases the use of Tcl variables on pins:
Example 89
foreach { x_in x_out } { \
bypass_in bypass_out \
en_in en_out \
shift_in shift_out \
update_in update_out \
jd_ctl_in jd_ctl_out \
jd_hd2_in jd_hd2_out \
jd_hd1_in jd_hd1_out \
jd_hd0_in jd_hd0_out \
jd_pull_b1_in jd_pull_b1_out \
jd_pull_b0_in jd_pull_b0_out \
jd_mode_in jd_mode_out \
scan_in scan_out \
} {

add_user_stimulus -rise_fall [subst { $x_in $x_out }] \

[subst {
{ in { $x_in 0 } out { $x_out 0 } }
{ in { $x_in 1 } out { $x_out 1 }
meas { type delay from $x_in to $x_out states "1" }
}
}]
}

Using not for a Gated Constraint

In the following example, the data transitions after clock, so this is a hold time.
The not keyword indicates no change; the output should maintain the previous
state and not change with the input pin transition.
Example 90
add_user_stimulus {
{ in { CP 0 D 1 } out { Q X } }
{ in { CP 1 } out { Q 1 } }
{ in { CP 0 } }
{ in { CP 1 } }
{ in { D 0} not {Q 0} meas { type constraint from CP ref D } }
}

SiliconSmart ACE User Guide 131

L-2016.03
Chapter 4: Importing and Configuring
Creating a run.tcl File

The above example will result in a hold measurement for D with respect to CP
where output Q should not change:
hold__D__hl__CP__lh__ACQ_1

Creating a run.tcl File

Each characterization flow can also be performed by creating a running a TCL
script containing the flow commands. This allows an automated way of running
and rerunning the same characterization flow. See Creating a run.tcl File for
Characterization for more information.

Importing and Configuring Multi-Bit Cells

Multi-bit registers are either unstitched or stitched, and can be with or without
scan chains. For synthesis and physical implementation tools to correctly
recognize a multi-bit registers, these cells should meet the Library
requirements (for such cells). Multi-bit registers are typically described in the
Liberty file with the ff_bank, latch_bank, or statetable groups. The bus/
bundle syntax is generally used to group pins with similar functionality.
Multi-bit cell configuration is described in the following sections:
■
Importing Multi-Bit Cells
■
Configuring Multi-Bit Cells
■
Modeling Multi-Bit Cells

Importing Multi-Bit Cells

The following sections describe importing multi-bit cells:
■
Importing an Instance File for Recharacterization
■
Creating a New Instance File
■
Example Instance Files

132 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

Importing an Instance File for Recharacterization

For multi-bit cell recharacterization, bundle pins for a multi-bit cell can be
represented in the Liberty model at either the bundle-level or at the individual
member level. The SiliconSmart tool supports either the bundle format or the
individual member format, but not both together.
Following is an example of bundle syntax in a Liberty model:
bundle(Q) {
members (Q0, Q1);
function : IQ;
pin(Q0) {
direction : output;
related_power_pin : VDD;
related_ground_pin : VSS;
timing() {
related_pin : "CK" ;
timing_type : rising_edge ;
}
}

pin(Q1) {
direction : output;
related_power_pin : VDD;
related_ground_pin : VSS;
timing() {
related_pin : "CK" ;
timing_type : rising_edge ;
}
}
}

When the imported multi-bit cell is modeled at the individual member level, the
parameter model_bundle_bit_level must be enabled before the import
command. When enabled, the tool will automatically create the instance file at
the member level, where:
■ Each member of the bundle is defined as a pin
■
The functionality is defined for each bit of the multi-bit flip-flop
■
Members are mapped to the bundle

SiliconSmart ACE User Guide 133

L-2016.03
Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

Creating a New Instance File

If you are not importing an input library and instead manually creating a new
instance file:
■
Member level: to have the final Liberty at the member level, the instance file
has to be defined as shown in Member level: Unstitched 4-Bit Flip-Flop:
• Add all member pins
• Define the function for each member pin
• Use set_pins_to_bundle_map to map member pins to a bundle
• Note that set_pins_to_bundle_map must be defined for IQ/IQN
also (internal registers defined by add_flop/add_latch)
• The parameter model_bundle_bit_level must be enabled (before
the configure command)
■
Bundle level: to have the final Liberty is desired at the bundle level, the
instance file has to be defined as shown in Bundle level: 4-bit Unstitched
Flip-Flop.

Example Instance Files

The following sections describe examples of instance files defined at member
and bundle levels:
■
Member level: Unstitched 4-Bit Flip-Flop
■
Member level: Stitched 4-Bit Flip-Flop
■
Bundle level: 4-bit Unstitched Flip-Flop

134 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

Member level: Unstitched 4-Bit Flip-Flop

Given below is an example of an unstitched 4-bit flip-flop and the instance file
defined at the member level.

Figure 10 Example of an unstitched 4-bit flip-flop

SiliconSmart ACE User Guide 135

L-2016.03
Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

An unstitched multi-bit flip-flop has parallel data and scan inputs, and parallel
functional and scan outputs. The output of a bit is not chained to the next
register bit.
Instance file:
##Defining individual pins
add_pin CK default –clock
add_pin D0 default –input
add_pin D1 default –input
add_pin D2 default –input
add_pin D3 default –input
add_pin SI0 default –input
add_pin SI1 default –input
add_pin SI2 default –input
add_pin SI3 default –input
add_pin SE default –input
add_pin Q0 default –output
add_pin Q1 default –output
add_pin Q2 default –output
add_pin Q3 default –output
##Function definition at pin level
add_flop IQ0 IQN0 CK {((D0&(!SE))|(SI0&SE))}
add_flop IQ1 IQN1 CK {((D1&(!SE))|(SI1&SE))}
add_flop IQ2 IQN2 CK {((D2&(!SE))|(SI2&SE))}
add_flop IQ3 IQN3 CK {((D3&(!SE))|(SI3&SE))}
add_function Q0 IQ0
add_function Q1 IQ1
add_function Q2 IQ2
add_function Q3 IQ3
##Mapping the pins to bundles
set_pins_to_bundle_map -bundle Q -pins { Q0 Q1 Q2 Q3 }
set_pins_to_bundle_map -bundle IQ -pins { IQ0 IQ1 IQ2 IQ3 }
set_pins_to_bundle_map -bundle SI -pins { SI0 SI1 SI2 SI3 }
set_pins_to_bundle_map -bundle IQN -pins { IQN0 IQN1 IQN2 IQN3 }
set_pins_to_bundle_map -bundle D -pins { D0 D1 D2 D3 }

136 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

Member level: Stitched 4-Bit Flip-Flop

Given below is an example of a stitched 4-bit flip-flop and the instance file
defined at the member level.

Figure 11 Example of a stitched 4-bit flip-flop

SiliconSmart ACE User Guide 137

L-2016.03
Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

A stitched multi-bit flip-flop has a serial scan chain. It has a single shared or
dedicated output pin to output the scan signal, that is, each output is chained to
the next register bit.
Instance file:
##Defining individual pins
add_pin CK default –clock
add_pin D0 default –input
add_pin D1 default –input
add_pin D2 default –input
add_pin D3 default –input
add_pin SI default –input
add_pin SE default –input
add_pin Q0 default –output
add_pin Q1 default –output
add_pin Q2 default –output
add_pin Q3 default –output
##Function definition at pin level
add_flop IQ0 IQN0 CK {((D0&(!SE))|(SI&SE))}
add_flop IQ1 IQN1 CK {((D1&(!SE))|(IQ0&SE))}
add_flop IQ2 IQN2 CK {((D2&(!SE))|(IQ1&SE))}
add_flop IQ3 IQN3 CK {((D3&(!SE))|(IQ2&SE))}
add_function Q0 IQ0
add_function Q1 IQ1
add_function Q2 IQ2
add_function Q3 IQ3
##Mapping the pins to bundles
set_pins_to_bundle_map -bundle Q -pins { Q0 Q1 Q2 Q3 }
set_pins_to_bundle_map -bundle IQ -pins { IQ0 IQ1 IQ2 IQ3 }
set_pins_to_bundle_map -bundle IQN -pins { IQN0 IQN1 IQN2 IQN3 }
set_pins_to_bundle_map -bundle D -pins { D0 D1 D2 D3 }

138 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

Bundle level: 4-bit Unstitched Flip-Flop

Given below is an example of a 4-bit unstitched flip-flop instance file defined at
the bundle level.
Instance file:
##Defining bundles
add_pin CK default –clock
add_pin D default –input
add_pin SI default –input
add_pin SE default –input
add_pin Q default –output
##Function definition at bundle level
add_flop IQ IQN CK {((D&(!SE))|(SI&SE))}
add_function Q IQ
##Define members present in the bundle
set_config_opt –pin Q -members { Q0 Q1 Q2 Q3 }
set_config_opt -pin D -members { D0 D1 D2 D3 }
set_config_opt -pin SI -members { SI0 SI1 SI2 SI3 }

Configuring Multi-Bit Cells

The numbers of states to be characterized for a multi-bit register increases
nearly exponentially as the number of bits in the register increases. Given
below is an example of the increase in the number of states for a typical multi-
bit flip-flop with D, CK, SI, SE and Q pins.

N-bit # of pins # of states of leakage_power

1 2+2+1=5 2^4=16

2 2+(2+1)*2=8 2^6=64

4 2+(2+1)*4=14 2^10=1024

8 2+(2+1)*8=26 2^18=262144

16 2+(2+1)*16=50 2^34=1.7e+10

As seen in the table above, the number of states that can be captured becomes
prohibitive for multi-bit cells with 4-bits and above.

SiliconSmart ACE User Guide 139

L-2016.03
Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

There are three different modes for multi-bit register characterization modes,
controlled by the parameters bundle_bit_independent_descriptor and
bundle_bit_independent_descriptor_mode.
The options for these two parameters are given in the table below.

Mode bundle_bit_independent_descriptor bundle_bit_independent_descriptor_mode

Default 0 N/A

Mode 1 1 1

Mode 2 1 2

The following sections describe these modes in detail:

■ Default
■
Mode 1
■
Mode 2
■ Example

Default
When the parameter bundle_bit_independent_descriptor is disabled
(default), all representative states can be captured from the full state space.
This is not recommended for multi-bit cells that are 4-bits and above, as this
can be prohibitive in performance and size.

Mode 1
When parameters bundle_bit_independent_descriptor and
bundle_bit_independent_descriptor_mode are both set to 1, the
SiliconSmart tool treats each 1-bit entity of the multi-bit register independently,
reducing the number of states to be characterized by restricting the states of
the cross-bit input pins.

Mode 2
When the parameter bundle_bit_independent_descriptor is set to 1
and bundle_bit_independent_descriptor_mode is set to 2, in addition
to the states allowed by Mode 1, the SiliconSmart tool allows additional states
of the cross-bit inputs for constraints, leakage power and internal power

140 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Importing and Configuring Multi-Bit Cells

acquisitions. The states allowed for timing arcs are the same as in Mode 1. The
state coverage in Mode 2 is improved (compared to Mode 1), thereby improving
the accuracy in STA and power analysis.

Note: With any of the three modes explained above,

state_partitions can be set to one, all, or explicit. The
restricted states will be automatically dropped.

Example
Consider the following 4-bit flip-flop.

For the above, consider a constraint arc between D0 and CK.

In Mode 1, since each 1-bit entity is considered independent, this arc is
configured only for the different states of SI0, keeping D1, SI1, D2, SI2, D3, SI3
(cross-bits) at 0. So, this arc can be configured only for the states:
1. !D1&!D2&!D3&!SE&!SI0&!SI1&!SI2&!SI3
2. !D1&!D2&!D3&!SE&SI0&!SI1&!SI2&!SI3

SiliconSmart ACE User Guide 141

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

In Mode 2, additional states of the cross-bit inputs are allowed, in addition to

the states allowed by Mode 1. This arc can be configured for the following
states:
1. !D1&!D2&!D3&!SE&!SI0&!SI1&!SI2&!SI3
2. !D1&!D2&!D3&!SE&SI0&!SI1&!SI2&!SI3
3. !D1&D2&!D3&!SE&!SI0&!SI1&!SI2&!SI3
4. !D1&D2&D3&!SE&!SI0&!SI1&!SI2&!SI3
5. D1&!D2&!D3&!SE&!SI0&!SI1&!SI2&!SI3
6. D1&D2&D3&!SE&!SI0&SI1&SI2&SI3
7. D1&D2&D3&!SE&SI0&SI1&SI2&SI3

Modeling Multi-Bit Cells

See Modeling Multi-Bit Cells for information on modeling multi-bit cells.

Setting Advanced Configuration Options

So far, we have described how to obtain a functional description of the circuit
from the Liberty/ netlist or through user-specified information. The SiliconSmart
tool will use that information to figure out which arcs to characterize and how to
perform measurements.
The following sections provide information on how to customize the behavior of
the tool for specific cell types, arcs types, measurement types, and other
behavior. It also provides valuable information on different types of parameters
and settings available to control the simulation methodology for specific cell
types.
These sections are summarized below:
■
Using the set_config_opt Command — this section provides usage and
examples for the set_config_opt command.
■
Default Arc Modeling — this section describes generating default arcs.

142 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

■
Changing Characterization Parameters of Pins — this section describes the
cases (normally state-dependent characterization) in which it is necessary
to vary the characterization parameters, such as SPICE options or load
ranges, based on the state of inputs to the cell.
■
Simulation Harnesses — this section describes simulation harnesses for
adding an additional load to a cell, such as a resistor termination network,
or circuitry between input pins and the stimulus driving them.
■
Weak Drive States — this section describes how to handle cells in which the
drive strength of a pin can vary over a large range. Weak states typically
occur when a pad pin can be pulled high or low by a very low-drive source,
such as pull-up and pull-down resistors.
■
Using Different Simulators for Different Measurements — this section
describes using different simulators for different types of data.
■
Autoranging and Automatic Parameter Determination — these sections
describe options for improving the accuracy of characterization by allowing
the SiliconSmart tool to automatically determine the load range of a cell and
how to use actual cells to drive the input stimulus to a cell.
■
Multicycle Initialization — this section describes how to handle cells that
must be run through one or more simulation cycles before the
measurements are taken.
■
Drivers — this section describes methods of driving input transitions.

Using the set_config_opt Command

The set_config_opt command provides a mechanism for setting global
parameters and pin type parameters on a per-cell, per-measurement, or per-
measurement-type basis. This command is used throughout the rest of the
chapter.
The following sections describe using the set_config_opt command:
■
Basic Usage
■
Specifying set_config_opt -type
■
Applying Load Harness to a Cell
■
Setting Pin Type Parameters for Arc-Based Measurements
■ State Dependent Measurements (State Partitioning)
■
State Selection

SiliconSmart ACE User Guide 143

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

■
Disabling Measurements
■
Controlling Don’t Care Pins
■
Table Dimensions and Sweep Order
■
Controlling the Output Pin in Constraint Measurements
■
Excluding Output Pins during Constraint Measurement
■
Working with Extreme Constraint Values
■
Multicycle Initialization
■
Separate Cell Initialization
■
Specifying Load and Slew Ranges

Basic Usage
Below is the basic syntax and usage for set_config_opt.
Syntax
set_config_opt
-cell cell -ccb ccb -opcond opcond
[-type (decap | decap_ccs | delay | zen | zdis | energy | timing
| setup | hold | recovery | asynch_recover | removal |
asynch_removal | leakage_power | constraint | cmpw | ncmpw | mpw
| input_capacitance | nochange | nochange_hold | nochange_setup
| noise | noise_iv | noise_immunity | noise_prop | ccs_noise |
ibis_iv | ibis_vt | statistical_delay | stat_leakage_power |
statistical_hold | statistical_setup | binning | binning_timing
| binning_energy | binning_constraints | nldm_noise)]
[-from (pin | pin_list)]
[-from_direction (direction | direction_list)]
[-reference pin]
[-reference_direction (direction | direction_list)]
[-pin pin]
[-to (pin|pin_list|none)]
[-to_direction (direction | direction_list)]
[-when expression]
option value

144 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

See Also
■
Command: set_config_opt

Examples
To have SiliconSmart select a single state for the delay arc from pins A to Z,
use the following command:
set_config_opt -type delay -from A -to Z state_partitions one

Enter the following commands to generalize the previous example to set the
state partitioning for all timing (delay, Z-enable, and Z-disable) arcs ending at
pin Z:
Example 91
set_config_opt -type timing -to Z state_paritions one

The pin name none is used for measurements that may involve only an input
pin, such as energy measurements. To set the when clauses for all hidden
energy measurements involving pins A, A_SCAN, and OE, use the following
commands:
Example 92
set when_clauses { ... user defined when clause expressions ... }
set_config_opt -type energy -from {A A_SCAN OE} -to none
state_partitions explicit
set_config_opt -type energy -from {A A_SCAN OE} -to none whens
when_clauses

Currently, SiliconSmart does not support 3D table imports from source Liberty
but gives you an informative error while importing. The requirement of doing 3D
characterization is very rare and it depends on designs in which an output is
not buffered and secondary output(s) are connected directly from that.
SiliconSmart does not support the import of 3D tables but it does support 3D
characterization. So if you need 3D tables, you can update the .inst file for the
same.

SiliconSmart ACE User Guide 145

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Consider an ADDER cell with S and CO outputs. If you want to do 3D power

characterization for arc A->S, you must add the following lines in the .inst file
and follow the rest of the flow:
Example 93
set_config_opt -type energy table_dimensions 3
set_config_opt -type energy -from A -to S -to_dir lh -pin S
explicit_points_load { . . . . .}
set_config_opt -type energy -from A -to S -to_dir lh -pin CO
explicit_points_load {. . . . . }
set_config_opt -type energy -from A -to S -to_dir hl -pin S
explicit_points_load { . . . . . . }
set_config_opt -type energy -from A -to S -to_dir hl -pin CO
explicit_points_load {. . . . . }

set_config_opt -type energy -from A -to S -to_dir hl -pin A

explicit_points_slew {. . . . . }
set_config_opt -type energy -from A -to S -to_dir lh -pin A
explicit_points_slew { . . . . .}

Remember to update the slew and load points as per your source Liberty file.
You can override the default values for slews specified in the configure.tcl file on
a per-cell basis by using the set_config_opt command in the instance file.
The import command generates instance files using set_config_opt in
conjunction with explicit_points_slew for all types of measurements to
record the slew (and load) points to be used, arc-by-arc.
However, as we describe here, it is necessary to specify slew values for
constraint measurements in a slightly different manner compared to the
standard timing and noise measurements. Consider the following example of a
configure.tcl file that contains the following line:
Example 94
set explicit_point_slews { 1 2 3 4 5 }

Without any other mention of slews in the instance file, you will see 5-valued
slew tables in the .lib for all types of measurements.
To override timing/power/noise measurements, you would write in the *.inst file:
Example 95
set_config_opt -type { timing noise } -pin { CK D }
explicit_points_slew { 10 20 30 40 50 60 70 }

This will produce 7-valued slew tables in the .lib for timing and noise.
To override the explicit slew rates for constraint measurements (setup, hold,
recover, removal, and MPW), the pin type parameter

146 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

constraint_explicit_points_slew must be used instead of

explicit_points_slew, as shown in the following example:
Example 96
set_config_opt -type { constraint } -pin { CK D }
constraint_explicit_points_slew { 100 200 300 }

This produces 3-valued slew tables in .lib for the constraint measurements.
Suppose the following line was specified in the instance file instead:
Example 97
set_config_opt -type { constraint } -pin { CK D }
explicit_points_slew { 100 200 300 }

This would have no effect on the constraint measurements and in fact they
would revert back to the 5 slew points from the original configure.tcl file. This is
because the pin type parameter constraint_explicit_points_slew
defaults to the value of explicit_points_slew when this pin type
parameter is set and must explicitly be overridden.
This can be a problem if you are using an instance file generated by a previous
version of SiliconSmart that does not support the
constraint_explicit_points_slew parameter. Your instance file would
have explicit_points_slew instead of
constraint_explicit_points_slew. You can work around this issue as
follows:
■
Directly edit the instance file to replace the string
explicit_points_slew with constraint_explicit_points_slew
for constraint measurements. This is the simplest option if it is feasible to
individually modify each cell's instance file.
■
Re-import an existing .lib in a recharacterization flow. The import command
has been modified to use constraint_explicit_points_slew
instead of explicit_points_slew in all the instance files for constraints.

Specifying set_config_opt -type

Used with set_config_opt, the -type switch applies setting/parameter
variations to particular measurement types. It can also accept a variety of
different options. In addition to specifying individual measurement types, it is
possible to specify a parent measurement type, which will then apply that use
of the set_config_opt command to all children under that parent type.

SiliconSmart ACE User Guide 147

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

This usage works as a shortcut for controlling all child types at once. Specifying
any type that is a parent type (contains at least one child) will automatically
apply the usage of set_config_opt to that parent and all of its children.
Below are examples of different -type parent/child relations, shown in tree
structures.Note that these do not include all of the set_config_opt types.
■
Timing
■
Constraint
■
Noise
■
Binning

Timing
The type timing applies to all timing-related measurements including delay,
slew, zenable, zdisable, binning_timing (for timing arcs during pre-
characterization), and retain measurements.

Figure 12 set_config_opt timing types

148 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Constraint
The type constraint applies to all the different types of constraint or
relational measurement types available within the SiliconSmart tool: setup,
hold, recovery, removal, asynch_recover, asynch_removal, binning_constraint,
binning_setup, binning_hold, etc.

Note: The constraint tree is too large to display here in one image
and has been broken up into the below three figures. Please note
that the removal and setup types are direct children of the
constraint type and included in that type.

SiliconSmart ACE User Guide 149

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Figure 13 set_config_opt constraint types

150 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Noise
The type noise includes both NLDM noise (SI) as well as CCS-Noise. Each
has further child types, as shown in the following figure.

Figure 14 set_config_opt noise types

Binning
The type binning applies to all the corresponding timing, constraint, energy
measurements for precharacterization.

Figure 15 set_config_opt binning types

SiliconSmart ACE User Guide 151

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Applying Load Harness to a Cell

The set_config_opt command’s -when switch can be used to conditionally
apply a load harness to a cell. This allows a harness to be applied to a cell
based on the state of one or more input pins.
Consider the following example:
Example 98
set_config_opt -type delay –to PAD -when {!A&B} harness “res_term”

This example applies the harness res_term to the cell on delay measurements
to the pin PAD when !A&B is true.

Setting Pin Type Parameters for Arc-Based Measurements

You can use the set_config_opt command to set the pin type parameters
logic_high_name and logic_low_name for different arc-based
measurements in the instance file of the cells. The value of this option is used
during characterization. However, the values for the Liberty pin-level attribute
input_signal_level and output_signal_level that gets modeled in
the output Liberty will be the value of the parameter logic_high_name of the
pin type block, as specified in the instance file using the add_pin command
rather than the one you specify wit the set_config_opt command.

State Dependent Measurements (State Partitioning)

State dependent measurements occur when secondary inputs can be in more
than one state to satisfy a given timing/power/noise arc. Secondary states are
determined using the set_config_opt command and the
state_partitions parameter.
The simplest option is one. This indicates that the electrical behavior of the
given measurement is independent of the secondary pin settings and
SiliconSmart will set the pins according to the current don’t care values. See
the Controlling Don’t Care Pins section for more information. Only a single state
will be simulated.
The opposite function is full state dependency, selected by setting
state_partitions to all. This option causes SiliconSmart to generate all
possible combinations of secondary pin settings and characterize each state.

152 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The resulting model will include data for each case with a when condition
indicating the state of the secondary pins.
The middle ground between these options is the explicit setting. This allows
you to explicitly define the conditions under which an arc is to be characterized
by specifying a set of Boolean expressions that define the when conditions for
the arc. The actual when conditions are specified by setting the whens option to
a list of Boolean expressions. SiliconSmart sets the secondary pins necessary
to fulfill the requirements of each when clause and use the don’t care settings
to tie off any remaining pins.

The following sections detail using the state_partitions option with the
above example:
■
Full State Dependency
■
Single State Partitions
■
Explicit State Partitions
■
Disabling Measurements
■
Controlling Don’t Care Pins
■
Specifying Constant Values

Full State Dependency

Set state_partitions to all for full state dependency. For example, the
timing of the delay from A-to-Y may vary depending on the values of input B
and C and the structure of cell design:
set_config_opt -type delay -from A state_partitions all

SiliconSmart ACE User Guide 153

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Results in:
delay A-hl Y-hl (B-1 C-1 S0-0 S1-0)
delay A-hl Y-hl (B-1 C-0 S0-0 S1-0)
delay A-hl Y-hl (B-0 C-1 S0-0 S1-0)
delay A-hl Y-hl (B-0 C-0 S0-0 S1-0)
delay A-lh Y-lh (B-1 C-1 S0-0 S1-0)
delay A-lh Y-lh (B-1 C-0 S0-0 S1-0)
delay A-lh Y-lh (B-0 C-1 S0-0 S1-0)
delay A-lh Y-lh (B-0 C-0 S0-0 S1-0)

Single State Partitions

Set state_partitions to one to cover a single state, as shown below:
set_config_opt -type delay -from A state_partitions one

Results in:
delay A-hl Y-hl (B-0 C-0 S0-0 S1-0)
delay A-lh Y-lh (B-0 C-0 S0-0 S1-0)

Please note that the state of don’t care pins are chosen arbitrarily by the
SiliconSmart tool.

Explicit State Partitions

Set state_partitions to explicit to cover states explicitly, as shown
below:
set_config_opt -type delay -from A state_partitions explicit
set_config_opt -type delay -from A whens {!B&C }

Results in:
delay A-hl Y-hl (B-0 C-1 S0-0 S1-0)
delay A-lh Y-lh (B-0 C-1 S0-0 S1-0)

Disabling Measurements
Set state_partitions to none to disable certain measurements, as shown
below.
To disable all measurements:
set_config_opt state_partitions none

To disable energy (power) measurements:

set_config_opt -type energy state_partitions none

154 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The option none is a further detailed in the Disabling Measurements section.

Controlling Don’t Care Pins

Use the parameter dontcare_bias to control the value assigned to don’t care
pins, as shown below:
set_config_opt -type delay -from A state_partitions one
set_config_opt -type delay -from A –pin C dontcare_bias 1

Results in:
delay A-hl Y-hl (B-0 C-1 S0-0 S1-0)
delay A-lh Y-lh (B-0 C-1 S0-0 S1-0)

where B-0 is determined by the SiliconSmart tool and C-1 is specified by the
set_config_opt command.

Specifying Constant Values

The add_fixed_value command allows an input or bidirectional pin to be set
to a constant state (0, 1, Z). You can use this for pins that do not affect the
logical function of a circuit, and are not expected to transition in an
implementation.
When this function is used, the SiliconSmart tool will not measure the input pin
capacitance or any hidden (non-switching) energy for this pin.
The syntax for this command is:
add_fixed_value [port] [value]

For example:
add_fixed_value A 1

State Selection
When multiple states are available to satisfy a particular when condition, the
actual state characterized can be controlled with the state_rank and
state_selection parameters:
■
state_selection — specifies whether to choose the best or the worst
case as specified by the state_rank list. A state_selection of
arbitrary selects a state in a deterministic but arbitrary manner.
■
state_rank — specifies a list of possible states in order from best to
worst.

SiliconSmart ACE User Guide 155

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The list need not be exhaustive. Unspecified states will be considered only if no
state in the list can actually occur. The expressions in the list may cover states
not actually available for a given arc. Those states will not be considered. For
example, the list {A !A} is valid even for arcs that can only occur when B. In
that case the list will be equivalent to {A&B !A&B}.
State ranking is used with the state binning feature described in the
Precharacterization section. In this case, multiple states are combined into a
single simulation and the when condition is set to the OR of each of these
states. The state ranking feature is then used to select the best or worst of
these states.
For example, consider the arc A->Y. The conditions B&C&!D and B&!C&D have
very similar timing but the worst-case is B&!C&D. These can be combined by
setting the when condition to B&C&!D | B&!C&D and then using the state
ranking feature to select the worst case. The commands would be:
Example 99
set_config_opt -from A -to Y state_partitions explicit
set_config_opt -from A -to Y whens { "B&C&!D | B&!C&D" ... }
set_config_opt -from A -to Y state_rank { "B&C&!D" "B&!C&D" }
set_config_opt -from A -to Y state_selection worst

Disabling Measurements
At times it is useful to disable particular measurements to prevent them from
being characterized and appearing in the model. This is done by setting the
configuration option state_partitions to none. When this value is
specified for one or more measurements, no states are processed and the
measurement is removed from the system.
For example, consider a cell with a drive strength control pin DS that controls
the electrical behavior of the PAD pin. If this pin is not expected to switch in a
design, the switching and internal energy measurements can be disabled. The
following command does this:
Example 100
set_config_opt -type energy -from DS state_partitions none

The resulting model will not contain the internal_energy groups for this pin.

Controlling Don’t Care Pins

Any input pins on a cell that do not need to be tied to a specific value for a given
simulation are termed don’t care pins. Their value does not affect the logical

156 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

behavior of the cell. However, the state of these pins can affect the electrical
behavior of the cell by changing the internal state of the circuit or because the
pins intentionally control some electrical aspects of the circuit.
The configuration option dontcare_value controls the value assigned to the
don’t care pins. This option controls the value assigned to all don't care pins for
the measurement. If more control is needed, the value can be specified for a
specific pin by using the -pin option to specify the name of a pin. For example,
the following commands set the default value for all pins to 1, except for pins
DS1 and DS2 which are set to 0 for any delay arcs to PAD:
Example 101
set_config_opt dontcare_value 1
set_config_opt -type delay -to PAD -pin DS1 dontcare_value 0
set_config_opt -type delay -to PAD -pin DS2 dontcare_value 0

Table Dimensions and Sweep Order

The Liberty format provides several options for modeling delay and energy arcs
in which multiple output pins transition in response to a single input transition. A
typical case of this is shown in Figure 16.

Figure 16 Typical Bidirectional Buffer

In this example, when pin A transitions, pins PAD and Z both transition. In the
Liberty format the delay through arc A-to-PAD can be represented by a 2-D or
3-D delay table. A 2-D table includes the input slew rate on A and the output
load on PAD. A 3-D table adds the output load on Z. The decision of which table

SiliconSmart ACE User Guide 157

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

to use depends on the design of the cell, and whether the load on Z
significantly impacts the delay from A to PAD.
The table dimensions are controlled through the configuration option
table_dimensions. By default, this option is set to 2, which limits the model
to 2-D lookup tables, forcing this case to be modeled as two separate arcs. If
this option is set to 3, 3-D tables are used as appropriate. The following
example sets the table dimension for all delay arcs to 3:
Example 102
set_config_opt –type delay table_dimensions 3

The Liberty format does not support table dimensions greater than 3. In
Figure 16, 3-D tables would be selected for the arc from A to PAD because Z
also switches.
The Liberty power events behave somewhat differently than the delay arcs.
Because the energy events are only concerned with which pins are
transitioning, the three pins in the example cannot be separated and a single
Liberty internal_energy event will be generated. The table_dimensions
configuration option still determines the dimensions of the table, which
determines the number of output pins on which the load is swept. A table
dimension of 2 relates to a single swept output load.
When more outputs exists than table dimensions permit to be swept,
SiliconSmart arbitrarily selects a set of output pins. When necessary, the pins
selected can be controlled with the configuration option
output_sweep_order. This specifies a priority list of pins to be swept, the
first pin being the one that is always swept over. The first swept pin is also the
pin on which the energy event will be placed in the Liberty model.
Using the example in Figure 16 for the switching event where A, PAD, and Z all
switch, SiliconSmart defaults to generating a 2-D energy table. Because two
output pins are switching, SiliconSmart chooses either the PAD or Z pins.
However, because the PAD pin is typically preferred in this case, the following
command forces SiliconSmart to preferentially select PAD over Z:
Example 103
set_config_opt output_sweep_order {PAD Z}

The result is that the capacitive load is swept on pin PAD and not on Z. In the
generated Liberty model the internal_energy event will be placed on pin
PAD.

158 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Controlling the Output Pin in Constraint Measurements

Constraint measurements look at how closely two transitions, on one signal or
between two signals, can occur before the cell fails to function correctly.
Success or failure is determined by examining an output of the cell.
SiliconSmart, by default, uses all switching outputs and switching internal
nodes, so that if one output fails before another, the constraint measurement
takes that into account.
The default behavior is to measure against all output pins and internal nodes
that are a function of the constraint being measured. The internal pins used are
those created via the add_pin command with the -spice_node switch,
which specifies the location in the cell's netlist to be monitored. The set of
nodes to be used can be restricted by specifying an alternative set via the
configuration parameter constraint_outputs. This parameter can be set to
a list of one or more output pins or internal nodes. SiliconSmart measures the
constraint against all of the nodes in the list that are appropriate to the given
constraint.
For example, to include internal node node1 and output Q but exclude output
QN, constraint_outputs would be set like this:
Example 104
set_config_opt constraint_outputs { node1 Q }

Excluding Output Pins during Constraint Measurement

The constraint_exclude_outputs parameter lists output pins to be
excluded from the stimulus while performing a constraint measurement. It
accepts a list of output pins.
Its usage is relevant in the context of reducing the observable nodes for
constraints when multiple choices are available for a given arc. It is
recommended that the user not define a list that contains all observable nodes,
as no constraint measurement would be possible in that case.
If an output port is included in both the constraint_exclude_outputs and
constraint_outputs parameters, it will be excluded for the stimulus for that
particular constraint measurement.

SiliconSmart ACE User Guide 159

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Usage Examples

Example 105
set_config_opt -type {setup recovery} constraint_outputs {o so}

set_config_opt -type {hold removal} constraint_outputs {o

IQ1_internal IQ1_internal_1 IQ13_internal IQ5_internal
IQ5_internal_1}

In the above example, for any setup/recovery measurements, only nodes o and
so will be used for checking constraint criteria. For any hold/removal
measurements, 5 internal nodes will be tested for criteria, in addition to the
primary output o.

Example 106
set_config_opt -type {setup recovery} constraint_outputs {o so}

set_config_opt -type {hold removal} constraint_exclude_outputs

{so}

In the above example, For any setup/recovery measurements, only nodes o

and so will be used for checking constraint criteria. For any hold/removal
measurements, all relevant primary outputs and defined internal nodes (along
with their corresponding functions) will be tested for constraints, except for so,
which has been excluded.

Example 107
set_config_opt -type {hold removal} constraint_exclude_outputs
{o so IQ1_internal IQ1_internal_1 IQ13_internal IQ5_internal
IQ5_internal_1}

Assume that the above list of nodes contains all of the nodes possible for this
particular example where constraints can be tested. If all of the nodes are
included in the exclude list, the SiliconSmart tool will generate the following
warning:
Warning: Cannot exclude all outputs ['o', 'so', 'IQ1_internal',
'IQ1_internal_1', 'IQ13_internal', 'IQ5_internal',
'IQ5_internal_1']. This setting will be ignored.

It will then ignore this list and consider all the nodes for constraint tests/
measurements.

160 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Example 108
set_config_opt -type {setup recovery} constraint_outputs {o so
dummy6}

set_config_opt -type {hold removal} constraint_exclude_outputs

{dummy1 so dummy2 dummy3 IQ13_internal}

In the above example, if either the constraint_outputs or

constraint_exclude_outputs lists have any irrelevant or dummy nodes,
they will simply be ignored. No errors or warnings will be issued.

Working with Extreme Constraint Values

At times, you might need to work with extreme constraint values, understand
how they occur, or how they can be avoided when using dependent-hold or
dependent-setup constraint mode. SiliconSmart has a solution for the extreme
fluctuations in hold (setup) times that can result from the use of the dependent-
hold (setup) constraint mode. These outliers resulted because, when a failure
criteria set is met, the previous, passing constraint value was chosen as the
solution.
However, this solution was then somewhere within a
constraint_resolution of failure. As that distance approaches zero (0)
the second constraint becomes acutely sensitive to the value of the first. Not
knowing how close a solution was to meeting the failure criteria meant that the
optimized solution for the second constraint could vary wildly. Although these
were real solutions, they resulted in unacceptable errors when used for
interpolation.
The purpose of the pin type parameter constraint_dependent_margin is
to ensure that the setup (hold) time used for the hold (setup) optimization
avoids a region of the solution space in which the second constraint value is
acutely sensitive to that of the first.
In summary, the first constraint value is padded slightly, to prevent real but
problematic values for the second constraint. This is important so tables
interpolate without large, if conservative, errors.
The default value for constraint_dependent_margin is
constraint_resolution. This feature can be disabled by setting
constraint_dependent_margin to zero (0).
For more information, please refer to the Constraints section.

SiliconSmart ACE User Guide 161

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Multicycle Initialization
Due to their design or the process technology used, some cells must be run
through multiple cycles before accurate timing or power data can be collected.
SiliconSmart supports the ability to simulate any timing, switching power, or
hidden power arc for additional cycles prior to collecting the data. SiliconSmart
automatically determines the stimulus sequence necessary to cycle between
the states.
The number of initialization cycles performed is controlled through the
configuration option initialization_cycles. This option is set with the
set_config_opt command to an integer value of zero or more.
The following example causes SiliconSmart to execute each switching and
hidden power simulation for two additional cycles at the start before initiating
the actual measurement to be taken:
Example 109
set_config_opt -type energy initialization_cycles 2

The cycle time of the initialization cycles is controlled by the pin type parameter
cycle_time.

Separate Cell Initialization

SiliconSmart runs initialization stimuli in separate simulations from the actual
transitions under test. This is implemented using either the .IC or .NODESET
SPICE directives to save and restore the post-stimulus values of circuit nodes,
and it is aimed at reducing the overhead involved in acquiring multiple
measurements with the same initialization stimulus. By sharing the stimulus,
these measurements are now much shorter, and the stimulus is only simulated
once, with the resulting savings in simulation time.
Separate cell initialization is also required by Silicon-On-Insulator
characterization, in order to isolate the SOI transitions being tested from the
preceding stimuli. The separate initialization mode is controlled using the
parameters separate_cell_initialization and
separate_cell_initialization_levels:
■
separate_cell_initialization can have values of off, nodeset,
and ic (the default value). A value of off disables separate initialization,
and nodeset and ic enable it using the selected directive.
■
separate_cell_initialization_levels may be set to all (the
default value) or top-internal-only. Setting it to all causes all nodes
in the cell to be initialized by nodeset or ic. Occasionally it may be

162 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

desirable to have only the internal nodes from the top-level circuitry in the
netlist have their voltages initialized by nodeset or ic. In this case,
parameter separate_cell_initialization_levels should be set to
top-internal-only.

Specifying Load and Slew Ranges

SiliconSmart provides several methods for specifying the load and slew index
points to be used during characterization. At the library level (in configure.tcl),
the bounds can be set by setting the pin type parameters smallest_slew,
largest_slew, and numsteps_slew in the pin type parameter block (and
the equivalent load parameters) for each pin type. Using these parameters, a
geometric sequence of the specified number of steps will be generated within
this range.
If the parameter autorange_load is set to on, the largest_load will be
equal to the max_load at the output pin.
By default, the SiliconSmart tool uses a polynomial algorithm for generating
slew and load indices if the parameter explicit_points_slew/
explicit_points_load/scaled_points_slew/scaled_points_load’
is not set.
There are additional algorithm modes available (log, log2x, linear2x):
■
log — In this mode, the SiliconSmart generates a logarithmically-
distributed set of index values within a specified range.
The following parameter settings are required in the pintype default block to
enable this mode:
set sweep_method_slew log
set sweep_method_load log

You can enable this mode on a per-cell or per-pin basis by using

set_config_opt command. For example:
set_config_opt -cell $cells -pin <input_pin> /
sweep_method_slew log
set_config_opt -cell $cells -pin <output_pin> /
sweep_method_load log
■
log2x — In this mode, the SiliconSmart tool first computes indices using
log mode, then adjusts successive indices to be 2X apart, except for the
last index. A warning is issued if last index pair is more than 3X apart.
The following parameter settings are required in the pintype default block to
enable this mode:

SiliconSmart ACE User Guide 163

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

set sweep_method_slew log2X

set sweep_method_load log2X

The set_config_opt command can be used to enable this mode on per-

cell or per-pin basis.
■
linear2x — In this mode, the SiliconSmart tool computes a linearly-
distributed set of index values within a specified range, then checks the list
and adjusts successive indices to be 2X apart except for the last index. A
warning is issued if last index pair is more than 3X apart.
The following parameter settings are required in the pintype default block to
enable this mode:
set sweep_method_slew linear2X
set sweep_method_load linear2X

The set_config_opt command can be used to enable this mode on per-

cell or per-pin basis.
For example, assume the following:
numsteps_slew =7
smallest_slew= 1ps
largest_slew = 1000ps

The generated slew indices, using different algorithms for index values
generation, will be as follows:
■
log: 1.0p 3.16p 10p 31.62p 100p 316.22p 1000p
■
log2x: 1p 2p 4p 8p 16p 32p 1000p
■
linear2x: 1p 2p 4p 8p 16p 32p 1000p

164 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

1200
Log
1000 Log2x

800

600

400

200

0
1 2 3 4 5 6 7

Figure 17 Examples of generated slew indices using log and log2x algorithms

If the pin type parameter explicit_points_slew

(explicit_points_load) is set, it overrides the range specified by
smallest_slew and largest_slew (smallest_load and
largest_load). These parameters can be used for better control over the
chosen points.
Finally, the set_config_opt command can be used to specify a set of
explicit slew and load points on a per-arc and per-state basis for a given cell.
These commands appear in each cell’s instance file and can be automatically
generated when a cell is imported via the import command. When specified,
these values override any settings in the pin type definition.
The following example shows the load and slew points would be set for an
inverter with pins A and Y:
Example 110
set_config_opt -from A -to Y -to_dir lh -pin Y \
explicit_points_load { 1.0e-15 6.7e-15 15e-15 }
set_config_opt -from A -to Y -to_dir hl -pin Y \
explicit_points_load { 1.0e-15 7.2e-15 15e-15 }

set_config_opt -from A -to Y -pin A explicit_points_slew \

{ 10e-12 50e-12 200e-12 }

SiliconSmart ACE User Guide 165

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Notice that two different sets of load points are used, one for a rising output
transition and a different one for the falling transition. In the case of the explicit
slew points, the -to_direction option (abbreviated -to_dir) is omitted so
the points apply to both the rising and falling cases.

Default Arc Modeling

The following sections describe generating default arcs in the SiliconSmart tool:
■
Controlling Generation of Default Arcs
■
Generating Default Tables for Constraint Arcs
■
Generating Default Tables for Power Arcs
■
Generating Default Tables for Leakage Power Arcs
■
How are Default Tables Created?

Controlling Generation of Default Arcs

The generation of default arcs in the SiliconSmart tool is controlled by:
1. Setting the model_default_arcs parameter
2. Setting the -library_type switch with the model command

Setting the model_default_arcs Parameter

Setting the appropriate value to the parameter model_default_arcs will
trigger the generation of default tables for timing groups (cell_rise,
cell_fall, rise_transition, fall_transition, retaining_rise,
and retaining_fall).
Please not that enabling model_default_arcs will not generate default
tables for constraint/power/leakage arcs. Generating default arcs for
constraints, internal_power, and leakage_power are detailed in the
following sections.

166 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The model_default_arcs parameter has the following behavior:

■
Set to 0, off, no, never, false — No default arcs will be modeled.
However, if an arc can be characterized at one and only one when condition,
the SiliconSmart tool will omit this when condition. Such a table may appear
to be a default table (as it will not have a when condition).
■
Set to 1, on, yes, always, true — Default tables will be modeled.
■
Set to 2, cond, conditional — Default tables will be modeled if and only
if all possible when conditions are already not covered.

Setting the -library_type Switch with the model Command

Once you have chosen whether to model default arcs or not, it is necessary to
specify -library_type switch to the model command to inform the
SiliconSmart tool how to model the default tables.
The -library_type switch chooses the default table to be the worst/best/
average of the existing conditional tables for timing groups (cell_rise,
cell_fall, rise_transition, fall_transition, retaining_rise,
and retaining_fall), leakage_power, and internal_power groups.
Possible values are best, typ, and worst. Default is worst.
For example, for a worst-case library, the default arcs would be the slowest and
the cell leakage power would be the maximum of the measured leakage power
states.

Generating Default Tables for Constraint Arcs

To generate default tables for constraint arcs (setup, hold, recovery,
removal, mpw, min_period), you should first enable the parameter
model_default_arcs and choose how the default table for constraints will
be created by setting the parameter model_default_constraints.
For example:
set_config_opt model_default_arcs 1
set_config_opt model_default_constraints max/min/mean

By default, the parameter model_default_constraints is set to off,

meaning no default tables will be created for constraints.
Please note that no point-to-point selection is available for default table
generation for constraint arcs.

SiliconSmart ACE User Guide 167

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Note: Default tables for constraints are not controlled by specifying the
-library_type switch to the model command.

Generating Default Tables for Power Arcs

The generation of default arcs for internal_power is controlled by the parameter
model_default_power_arc. When set to 1 or true, the SiliconSmart tool
will choose a max/min/ave default power table based on the -library_type
switch (specified to the model command).
This is independent of model_default_arcs, meaning you can choose to
generate default tables for power irrespective of whether default tables are
generated for other groups.
It is a simple selection of max/min/ave default tables based on currently
modeled (based on chosen state_partitions for energy)
internal_power tables on input and output pins (i.e., either path power or
hidden power). Each internal_power (dynamic or hidden) is assumed to
correctly constructed, so the default table selection is a simple number
selection.
rise_power and fall_power are evaluated for default table generation
independently and can come from different when conditions.
Please note that no point-to-point selection is available for default table
generation for constraint arcs.

Generating Default Tables for Leakage Power Arcs

For leakage_power groups, the switch -leakage_power_calc should be
specified to the model command to select the method of determining the
default cell leakage power value. The value for this switch can be best, typ, or
worst. The default is to use the type specified by the -library_type switch
(default is worst).

Note: Currently, the parameter model_default_arcs does not apply

to leakage_power groups.

How are Default Tables Created?

The following sections detail default table creation methodology:
■
How is a Timing or Power Default Table Created?
■
How is a Constraint Default Table Created?

168 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

How is a Timing or Power Default Table Created?

For each when condition, the single largest value is identified for each of the
cell_rise, cell_fall, rise_transition, fall_transition tables.
The table which has the single largest value will be chosen for the default arc.
The whole table will be used as is for the default arc. The default behavior (for
the -library_type switch) is to choose the worst case for default tables,
(this can be changed to pick minimum or average).
The process of selecting the minimum or maximum of values is easy to
understand. Selecting the average default table is slightly more involved and
can be explained with the following example:
If a timing table has four when conditions w1, w2, w3, w4, then the SiliconSmart
tool will take the mean from each table, say:
■
mean=m1 for values from table for when=w1
■
mean=m2 for values from table for when=w2
■
mean=m3 for values from table for when=w3
■
mean=m4 for values from table for when=w4
The overall average will be calculated as m = (m1+m2+m3+m4)/4
The table which has the smallest delta, where delta = m – mi (i is
from 1 to 4), will be chosen as the default table.
Say, m-m2 < m-m1 < m-m3 < m-m4, then table corresponding to when=w2
will be chosen as default table.
The minimum/maximum/average for the default table is chosen for each of the
cell_rise, cell_fall, rise_transition, fall_transition groups
independently. Thus, in a default table for a particular arc, each of the 4 groups
cell_rise, cell_fall, rise_transition, and fall_transition can
potentially come from different when conditions.
An exception to the above behavior is when the library is being characterized
for NLDM as well as CCS views.
To avoid reference_time misalignment in CCS-timing groups, in libraries
with CCS-timing views, the cell_rise and rise_transition are always
held in tandem. Similarly, cell_fall and fall_transition are also held in
tandem. Thus, depending on the best/worst/typ choice of -
library_type, both cell_rise and rise_transition will be picked
from the same when condition (cell_rise will be used to determine the
default table). The cell_fall and fall_transition will be picked from the
same when condition (cell_fall will be used to determine the default table).

SiliconSmart ACE User Guide 169

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The above concept can be explained with an example. Consider a cell with a
timing arc which has four when conditions w1, w2, w3, w4. The
-library_type is set to be worst.

170 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

For an NLDM-only Liberty modeling, the default table will be made up as

follows:

NLDM-only Liberty w1 w2 w3 w4 Default Arc

cell_rise max cell_rise from w1

cell_fall max cell_fall from w2

rise_transition max rise_transition from w3

fall_transition max fall_transition from w4

For the same cell, with a NLDM and CCST Liberty, the default table will be
made up as follows:

NLDM + CCST Liberty w1 w2 w3 w4 Default Arc

cell_rise max cell_rise from w1

cell_fall max cell_fall from w2

rise_transition max rise_transition from w1

fall_transition max fall_transition from w2

It is possible that for some arcs, some when conditions, only rise or fall tables
may be present. In such cases, the default table will be made up as follows:

NLDM + CCST w1 w2 w3 w4 w5 w6 Default Arc

Liberty

cell_rise no_cell_rise cell_rise from w1

cell_fall max no cell_fall cell_rise from w6

rise_transition no rise_transition rise_transition from w6

fall_transition no fall_transition fall_transition from w5

SiliconSmart ACE User Guide 171

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

How is a Constraint Default Table Created?

For clarification, the constraint arcs for the purposes of this explanation are
considered to be setup, hold, recover, removal, mpw, and min_period
arcs. Construction of default tables for these constraints is very similar to that of
timing tables.
For each timing_type (setup_rising, setup_falling, hold_rising,
hold_falling, recovery_rising, recovery_falling,
removal_rising, removal_falling, min_pulse_width,
minimum_period) typically two groups exist: fall_constraint and
rise_constraint.
For default table generation purposes, each of the groups (rise_constraint
and fall_constraint) for each timing_type will be considered
independently.
For example:
■
The SiliconSmart tool will choose a single largest value (for max) and single
smallest value (for min) from all fall_constraint tables of the same
timing_type to determine one fall_constraint table for default table
of that timing_type.
■
The SiliconSmart tool will choose a single largest values (for max) and
single smallest value (for min) from all rise_constraint tables of the
same timing_type to determine one rise_constraint table for default
table of that timing_type.
Thus, in the default table for each constraint timing_type, the
rise_constraint and fall_constraint can potentially be picked from
conditional tables with different when conditions.

Changing Characterization Parameters of Pins

SiliconSmart provides two methods of handling pins that have different
electrical behaviors at different times. The most common case is output pins
where the drive strength is controlled by a set of input pins, but cases also arise
where a pin is driven to different voltage levels. SiliconSmart provides two
methods for handling these cases: the ability to change the pin type of a pin for
a specific measurement and/or state of the input pins and the ability to sample
the signal level to determine the actual voltage range.
You can directly set any pin type parameter or change the whole pin type of the
pin by setting the option pintype. The changes can by applied to any

172 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

combination of measurement type, from/to pin, and input pin state (when
condition). Typical uses include changing the load range of a pin based on drive
strength or changing the expected voltage levels.
To use this feature, create two pin types where one is a duplicate of the other,
except for the specific changes. Apply the first pin type to the pin in the cell's
instance file using the add_pin command. For the measurements in which the
second pin type is needed, use the set_config_opt command to set the pin
type.
For example, assume pin PAD is typically of pin type pad_2v. The following
commands create a second pin type, named pad_3v, where the logic high
voltage is changed to VDD3:
Example 111
pintype pad_3v->pad_2v {
set logic_high_name VDD3
}

In the cell's instance file, the new pin type can be applied for any delay
measurements in which the PAD pin is being driven and the pin HV is high with
the following command:
Example 112
set_config_opt -type delay -to PAD -when HV -pin PAD pintype pad_3v

The -pin option is used to indicate that the pin type of pin PAD is being set.
This case can also be accomplished by a single line directly setting
logic_high_name:
Example 113
set_config_opt -type delay -to PAD -when HV -pin PAD
logic_high_name VDD3

Two parameters, logic_low_level and logic_high_level, can be used

to define the rail voltages of the pin to which they apply. The applied voltage is
independent of the supplies defined for that pin. When both are set to the
default, the supplies, logic_high_name, and logic_low_name define the
rails as before. The default for logic_low_level and logic_high_level
is 0.
Example 114
set_config_opt –pin {dp dn} {
logic_low_level 0.4
logic_high_level 0.6 }

SiliconSmart ACE User Guide 173

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Partial Voltage Swings

The SiliconSmart tool supports using the actual voltage swing of the signal,
even if it changes between measurements. SiliconSmart samples the
waveform and automatically determines the high and low signal levels. Using
this data, SiliconSmart can then compute the delay and slew information based
on the actual signal levels. This behavior is enabled by setting the pin type
parameter partial_swing to 1.
For example, applying a resistor termination harness to a PAD pin may prevent
it from swinging through the full voltage range. Setting partial_swing to 1
on this pins allows SiliconSmart to automatically adjust for this and compute
the timing results based on the actual voltage range.
The following commands apply the harness and enable the partial swing mode:
Example 115
set_config_opt -type timing -to PAD harness class1_term
set_config_opt -type timing -to PAD -pin PAD partial_swing 1

This method can also be used to change other electrical aspects of a pin, such
as load or slew ranges. The import command handles the setting of load and
slew ranges this way to preserve the load and slew table values from the
original Liberty model.

nochange Constraints
Liberty nochange arcs are used to describe a time period in which one signal
must not change relative to transitions on another signal.
By default, nochange measurements are not performed. To enable these
measurements, the pin type parameter nochange_clock must be set to 1 in
the pin type of the clock pin.
Additionally, two other parameters must be set in the parameter block default.
These parameters control the failure criteria for active and inactive setup and
hold constraints:
■
nochange_variance — specifies an absolute allowable amount of delay
variance in seconds. The default is four times the high simulation resolution
as set in the parameter time_res_high.
■
nochange_threshold — specifies a voltage threshold as a percentage of
the full-rail swing beyond which the output must not fluctuate. The default
value is 0.10, meaning that the output can not vary by more than 10% of its
full rail swing.

174 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

With these parameters set, SiliconSmart generates the necessary simulations

and adds the Liberty nochange constructs to the resulting model.

Internal Node Detection

nochange constraints can be detected at internal nodes, like other constraints.
For the test case, the following lines should be added to the .inst file in order to
enable the nochange test between E and C:
Example 116
add_pin G default -internal -spice_node I1cn
add_function G C&!E
set_config_opt -pin C nochange_clock 1
set_config_opt -type nochange state_partitions none
set_config_opt -type nochange -from E state_partitions one
set_config_opt -type nochange constraint_outputs G

The first 3 lines enable measurement of the nochange and the last 3 prevent
nochange from being measured with pins other than E and C and at nodes
other than G.

Modeling Sequential Constraints as nochange

The parameter liberty_constraint_type has values default,
nochange, non_seq, setup_hold, and recovery_removal. This allows
the constraint type to be overridden whenever the desired type differs from that
determined by SiliconSmart. To get all the possible nochange models it may be
necessary to measure constraints at the master latch output.
The .inst mods for this are:
Example 117
add_pin L1 default -internal -spice_node nm
add_function L1 IQ0
set_config_opt -type constraint -from C -reference E
liberty_constraint_type nochange

With this and internal node detection, it should be possible to get all interesting
nochange models in the Liberty without requiring model_api post-processing.

Simulation Harnesses
Simulation harnesses are collections of circuit elements, passive or active
devices or sources, that are connected to a CUT during characterization. A

SiliconSmart ACE User Guide 175

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

simulation can add an additional load to a cell, such as a resistor termination

network, or circuitry between input pins and the stimulus driving them.
The following sections describe simulation harnesses:
■
Creating a Harness
■
Output Loads
■
Setting Measurement and Stimulus Nodes
■
Power in Simulation Harnesses
■
Applying a Harness to a Circuit Under Test
■
Example for Applying a Harness to a Cell

Creating a Harness
A harness is created by calling the create_harness command with the name
of the harness to be created. This creates an empty harness container to which
elements can be added with the add_harness_elements command, as
shown below:
Example 118
create_harness name
add_harness_elements name { elements … }

The circuit elements are provided as a list to add_harness_elements, one

per line, using a format similar to SPICE. Each line has the following format:
Example 119
code name node1 … nodeN parameter

where Code is the code for one of the elements in Table 5. Each element type
requires a specific number of nodes (connections) to be specified. A node is a
unique name representing a connection point, similar to nodes in SPICE.
Table 5 Harness Elements

Type Code Nodes Parameter

Resistor R 2 Resistance (ohms)

Capacitor C 2 Capacitance (farads)

Inductor L 2 Inductance (henrys)

176 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Table 5 Harness Elements

Type Code Nodes Parameter

Subcircuit X User-defined Subcircuit name

Voltage-controlled VCVS 4 Voltage ratio

voltage source

Voltage-controlled VCR 4 Resistance/voltage

resistor (ohms/volt)

Voltage-controlled VCCS 4 Current/voltage (amps/

current source volt)

Current source I 2 Current (amps)

Voltage source V 2 Voltage (volt)

Each pin on the CUT and supply defined in the current operating condition is a
node that can be connected. Additional nodes are created implicitly as they are
referenced.
For example, the following command creates a voltage divider termination
circuit that connects between the PAD pin and the supply name VTT:
Example 120
add_harness_elements harness1 {
R rs PAD node1 25
R rt node1 VTT 25
C Cload PAD 0 load_pad
}

In this example, two 25 ohm resistors, rs and rt, are created. Resistor rs
connects the PAD pin to node node1; resistor rt connects node1 to supply
VTT. The capacitor Cload is the output load on the PAD pin. See the Output
Loads section for details.
User-supplied subcircuits can be included in the harness. In this case, the
number of nodes depends on the specific subcircuit. The subcircuit definition
must be included in the simulation by adding the appropriate lines to the
process lines of the operating condition in the configure.tcl file.

SiliconSmart ACE User Guide 177

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Output Loads
The capacitive load does not need to be connected directly to the output pins,
but must effectively load the pin.

Note: When a harness is created, it must provide a load capacitor for

each output on the cell regardless of whether other elements are
connected to the output.

The value of the capacitor must be a parameter that will be swept through a
range of values by SiliconSmart during characterization.
You can use the set_sweep_parameter command to specify a capacitor
parameter that relates to the load for a given pin. For example, consider the
following harness:
Example 121
add_harness_elements harness1 {
R rs PAD node1 25
R rt node1 VTT 25
C Cload PAD 0 load_pad
}

In this case, capacitor Cload is the load on pin PAD and the parameter
load_pad is the parameter that will be swept during characterization. You can
specify this with the following command:
Example 122
set_sweep_parameter harness1 -load PAD load_pad

If the cell had additional outputs, additional capacitors would be needed and
the set_sweep_parameter command would have to be called for each.

Setting Measurement and Stimulus Nodes

In some harnesses it is necessary to change the node where measurements
are taken or where stimulus is applied. By default all measurements are taken
at the output pin itself and input stimulus is applied directly to the input pin.
The set_measurement_node command specifies an alternate node for
measurements on a given output pin and has the following usage:
Example 123
set_measurement_node harness_name pin node

178 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

This command takes the name of an existing harness, the name of an output or
bidirectional pin, and the name of a node to associate with the pin. For
example, if the resistor termination harness from the last section is used,
measurements for pin PAD could be taken from node node1.
The command to do this is as follows:
Example 124
set_measurement_node harness1 PAD node1

Similarly, the set_stimulus_node command specifies an alternate stimulus

node for input pins. This command takes the same arguments as
set_measurement_node. Using the same resistor termination harness, if the
PAD pin is assumed to be bidirectional the stimulus for PAD can be applied to
node1 instead with the following command:
Example 125
set_stimulus_node harness1 PAD node1

Power in Simulation Harnesses

SiliconSmart computes the internal power (switching and hidden) for a cell
using the following method. For each supply, the dynamic energy (supply de ) is
computed by totaling the total energy ( supply te ) drawn from the supply and
subtracting the leakage energy drawn from the supply ( supply lk ):

supply de = supply te – supply lk

The second term reflects the steady-state (leakage) current of the cell over the
duration of the simulation and removes this from the dynamic energy value.
The dynamic energy consumed by the cell is the sum of the dynamic energies
for each supply listed in the power_meas_supplies parameter, minus the
energy used to charge the interconnect capacitances.
The charge applied to the interconnect is estimated as CV2, where C is the
capacitive load on the output pin and V is the voltage range of the output pin.
Because of this estimation, it is important that the capacitive load for a cell is
always directly attached to the output pin(s).

SiliconSmart ACE User Guide 179

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

In the following figure, circuit (A) shows the correct way to connect a capacitive
load and circuit (B) shows the incorrect way.

Figure 18 Correct and Incorrect Ways to Connect a Capacitive Load

If necessary, two different harnesses can be used, one for timing delay and one
for power measurement. The set_config_opt command allows the harness
to be set per measurement type.

Applying a Harness to a Circuit Under Test

Once a harness has been created, it can be applied to a CUT for one or more
measurements. A harness is applied by setting the harness configuration
option using the set_config_opt command. This command allows options
to be set based on measurement types and/or pin combinations.
For example, to apply the harness harness1 to all delay measurements to pin
PAD, the following command would be added to the cell’s control file:
Example 126
set_config_opt -type delay -to PAD harness harness1

180 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Example for Applying a Harness to a Cell

This section goes through a short example that illustrates how to apply a
harness to a cell. The following figure shows a simple bidirectional cell with
differential pins on the chip side.

Figure 19 Bidirectional Cell with Differential Pins

The harness is a simple resistor divider network from the output pin (DP and
DM) to a termination voltage VTT. The measurements for pins DP and DM will be
taken at the intermediate nodes in the resistor network. Additionally, it needs to
supply load capacitors for the output pins DP, DM, and Z.
The following creates the harness and sets it up appropriately:
Example 127
create harness1
add_harness_elements harness1 {
R dp_res1 DP dp_node 25
R dp_res2 dp_node VTT 25
R dm_res1 DM dm_node 25
R dm_res2 dm_node VTT 25
C dp_cap DP 0 dp_load
C dm_cap DM 0 dm_load
C z_cap Z 0 z_load
}
set_measurement_node harness1 DP dp_node
set_measurement_node harness1 DM dm_node
set_sweep_parameter harness1 -load DP dp_load
set_sweep_parameter harness1 -load DM dm_load
set_sweep_parameter harness1 -load Z z_load

SiliconSmart ACE User Guide 181

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The harness will be applied for all delay arcs and switching events to pins DP,
DM and the leakage power measurements. This is done by adding the following
commands to the cell’s control file:
Example 128
set_config_opt -type delay -to DP harness harness1
set_config_opt -type delay -to DM harness harness1
set_config_opt -type energy -to DP harness harness1
set_config_opt -type energy -to DM harness harness1
set_config_opt -type leakage_power harness harness1

Weak Drive States

Weak pull-ups and pull-downs are a common feature of I/O cells. These weak
drive states can cause problems during characterization because different
simulation parameters are often needed when simulating transitions to these
states. For example, the transition from 0 to weak 1 will normally be much
slower than a transition from 0 to 1. Successfully simulating these transitions
requires different simulation parameters. This section describes how to specify
weak drive states and different simulation parameters for them.
The following sections describe weak drive states:
■
Specifying Weak Drive States
■
Setting Parameters for Weak Drive States

Specifying Weak Drive States

You can specify weak drive states using the weak configuration option in the
instance file. Use this option to specify a boolean expression for when the cell’s
drive strength is weak.
For example, consider a typical three-state buffer with weak pull-up and pull-
down as shown in the following truth table:
Example 129
add_table {
A OEN PU PD : PAD
0 0 - - : 0
1 0 - - : 1
- 1 1 0 : 1 # Weak pull-up
- 1 0 1 : 0 # Weak pull-down
1 0 0 0 : Z
}

182 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

In this case you would specify the weak drive states with the following
command:
Example 130
set_config_opt weak {OEN&(PU&!PD|PD&!PU)}

Setting Parameters for Weak Drive States

Once the weak drive states have been specified with the weak option, you can
specify different parameters for the weak drive states by creating a parameter
block called weak. Typically, this block inherits most of its parameters from the
default parameter block.
For example, to increase the trailing delay for weak drive states, enter the
following text in the configure.tcl file:
Example 131
define_parameters weak -> default {
set trailing_delay [expr trailing_delay + 50e-9] ;
# Increase by 50ns
}

Using Different Simulators for Different Measurements

You can change the simulator and the simulation options using the
set_config_opt command to set the simulator and simulator_options
parameters. This feature means that you can use different simulators for
different types of data.
For example, to override the choice of simulator used for a set of I/O cells, the
following command could be used from the command prompt:
Example 132
set_config_opt -cell { list of I/O cells } simulator finesim
set_config_opt -cell { list of I/O cells } simulator_cmd {/tools/
cad/Synopsys/Finesim/bin/finesim <input_deck> -o <listing_file>}

When using the set_config_opt command to change the simulator options,

the typical method is to append to the existing options. This can be done as
follows:
Example 133
set original_opts [get_parameter default simulator_options]
set_config_opt -to PAD simulator_options [join [list
original_opts tran,hspice: converge=3"] \n]

SiliconSmart ACE User Guide 183

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

This Tcl code first gets the current value of simulator_options and then
creates a new value by using the Tcl join command to combine the original
values with the new line (tran: converge=3). The \n at the end of the
command tells the join command to combine the lines with a new-line
character. In this case, the switches to set_config_opt indicate that the new
options should be applied to add arcs to the pin PAD. This is a common
scenario where a few specific arcs of a complex I/O cell do not converge in the
simulator.

Autoranging and Automatic Parameter Determination

Autoranging is the process of automatically determining a minimum or
maximum value for a given parameter by analyzing the electrical characteristics
of a cell. Three types of parameters are autoranged by SiliconSmart: load,
glitch height, and timeshift.
Load optimization refers to a process that determines the output load required
to achieve a specified maximum output transition. This load is then used in
subsequent simulations as the upper bound of the output load range. This
process is typically used on the core side output pins where the load variation
as a result of PVT and secondary pin state variation can be large. Automatically
determining the load range helps ensure that extrapolation of delay values (due
to out-of-range loads) is not required for table-based calculations.
Load optimization can be performed per-output pin or per-arc-state. Per-output
characterization selects a single arc and single state that causes each output
pin to transition high-to-low and low-to-high. It finds the maximum load for both
directions, takes the minimum, and uses that value for all arcs terminating at
that pin. This mode requires the least simulation time and is usually sufficient
for standard cells. This mode is referred to as pin-based and is selected by
setting the pin type parameter autorange_load to pin.
The second mode finds the output load independently for each state (when
condition) of each arc. This method is most appropriate for output pins in which
the drive strength varies greatly depending on the arc or state and is usually
used for I/O pads. This mode is referred to as state-based and is selected by
setting autorange_load to state.

Note: Previous releases of SiliconSmart used the values 1 and 0 for the
autorange_load parameter. These values now map to pin
and off.

184 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

You can identify an arc as a possible source for load autoranging

measurements with the autorange_load_source parameter. By default, all
types or arcs will be considered as candidates, but you can selectively enable/
disable certain types of arcs as a source of load autoranging measurements.
Example 134
set_config_opt -type mpw autorange_load_source 0

In the above example, mpw arcs will not be considered candidates for the
autoranging load measurements.
The scaled_points_* parameters specify the location of the points relative
to the specified or auto-ranged smallest and largest values. The
explicit_points_* parameters have precedence if they are non-empty.
Example 135
set_config_opt -cell DFF -pin Q {
autorange_load pin
explicit_points_load {}
scaled_points_load {0 0.1 0.3 0.6 1}
}

Height optimization is a similar concept, but automatically determines the

switching threshold of the input pin for each arc. This value is used to control
the range of input glitch heights during noise propagation simulations. Because
input glitches smaller than this value typically produce no output response, this
option can significantly improve the quality of the characterized data and focus
the simulation time on the important height regions, reducing the overall
characterization time. Because of this, this option is enabled by default.
The timeshift concept is used in characterizing noise effects on synchronous
data pins of sequential cells; the timeshift is the difference in time between the
arrival of a glitch on the synchronous data pin and the arrival of a clocking

SiliconSmart ACE User Guide 185

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

event. This is shown in Figure 20.

Figure 20 Time Shift

The timeshift value corresponds well to the setup value for the pin to clock
constraint. To autorange the value, SiliconSmart performs a single setup
measurement using a fast slew rate on the data pin and the same slew rate
used during the noise immunity data (default slew) on the clock pin. By default,
timeshift autoranging is enabled as it yields the best noise immunity results.
To activate load optimization, set the following parameters in the pintype
block:
■
explicit_points_load — This parameter must not be defined.
■
autorange_load — This parameter must be set to pin or state.
■
max_tout — This parameter must be set to the expected maximum output
transition time on the output pin.
■
maxload_tout_resolution — The resolution to which the actual output
transition time must match the desired (max_tout). Value is in seconds and
defaults to 10e-12.
■ opt_load_low/opt_load_high — These parameters define the range
over which the optimizer attempts to determine the load required to achieve
the specified maximum transition time, max_tout, on the pin.
■
smallest_load — Load autoranging is used only to determine the largest
load. The smallest load must be explicitly specified with this parameter.

186 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

To activate height optimization, set the following parameters in the pintype

block:
■ explicit_points_height — This parameter must not be defined.
■
autorange_height — This parameter must be set to 1, the default value.
Setting it to 0 disables this feature.
■
largest_height — Determines the upper bound of input glitch heights.
The default is (logic_high_name - logic_low_name) and should
usually not be changed.
To active timeshift optimization, set the following parameters in the pintype
block:
■
explicit_points_timeshift — This parameter must not be defined.
■
autorange_timeshift — The parameter must be set to 1, the default
value. Setting it to 0 disables this feature.
The following pin type defines realistic values for these parameters:
Example 136
pintype core {
set autorange_load pin
set autorange_height 1
set max_tout .75e-9
set opt_load_high 1e-12
set opt_load_low 10e-15
set smallest_load 10e-15
set autorange_timeshift 1
}

Drivers
The SiliconSmart tool supports the following methods of driving input
transitions:
■
A simple linear piecewise-linear (PWL) source.
■
An emulated active driver using a nonlinear PWL source.
■
True active drivers using an actual cell to drive the transition.
■
An active waveform driver using a waveform that recreates the output of
active driver
■ Custom drivers using a user-specified waveform.
By default, the SiliconSmart tool uses a linear ramp.

SiliconSmart ACE User Guide 187

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The following sections describe drivers in SiliconSmart:

■
Selecting the Driver Type
■
Importing Driver Cells
■
Using Driver Cells
■
Viewing and Removing Driver Cells
■
Driver Waveform Support

Selecting the Driver Type

The driver mode is specified by setting two pin type parameters, driver_mode
and driver. The pin type parameter driver_mode can be set to pwl,
emulated, active-waveform, custom, or active corresponding to the
selection of a linear PWL ramp, an emulated active driver, active-waveform, or
an active driver. When set to active, the pin type parameter driver must be
set to the name of an imported driver (see the Importing Driver Cells section).
The following driver types are available:
■
Emulated Drivers
■
Custom Driver
■
Custom Pew-Slew Drivers
■
Active Drivers
■
Active Waveform Drivers
■
Active-Direct Drivers

Emulated Drivers
Emulated drivers are a new nonlinear waveform that emulates the shape of a
realistic waveform from a typical timing path. This driver mode has the
advantage of fast simulation times associated with linear PWLs with the same
or better accuracy than true active drivers. This is because true active drivers
often retain some ideal characteristics due to the ideal waveform they are
driven with. For this reason, emulated active drivers are the recommended
driver model whenever characterizing for ECSM or CCS models.
The emulated active driver waveform is generated as the average of a ramp
and an exponential which intersects the ramp at the slew threshold points. The
waveform is sampled at even time intervals of 1/10 of the ramp rail-to-rail
voltage swing. The final point is where the waveform voltage would pass the

188 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

rail. This is pulled back to the rail without changing the time—that is, it is not
interpolated.
Emulated driver parameters:
■
emulated_driver_ratio — when the driver_mode is emulated, this
parameter is used to construct a voltage waveform that is a weighted sum
of a linear voltage curve and an exponential voltage ramp.
■
enable_clamped_predriver — when the driver_mode is ccs-
predriver, this parameter is used to construct a voltage waveform that is
a weighted sum of a clamped linear voltage curve and an exponential
voltage ramp.
To select emulated drivers, set the pin type parameter driver_mode to
emulated:
Example 137
set driver_mode emulated

Note: Be aware that ccs-driver is an alias for emulated. Even

when driver_mode is set to emulated, the driver_mode
parameter returns ccs-driver as its value.

Note: Your simulation can fail with assertion when using the emulated
(non-linear) driver model when the propagation delay threshold
(prop_delay_level) is less than the lower slew threshold
(logic_low_threshold) or greater than the upper slew
threshold (logic_high_threshold). This is a valid error as
these are requirements of the emulated driver model. If your
simulation fails for these reasons, SiliconSmart reports an error
message.

Custom Driver
Delays can depend significantly on the shapes of input waveforms, so some
mechanism is needed to set the shapes of the input wave form. You can control
the shape of the waveforms by setting the driver_mode parameter to
custom. The input waveform should be in normalized form (that is, the values
should be within the range of 0 to 1). To set a custom driver, set the
driver_mode parameter to custom.
The same waveform shape will be used for all slews. If you intend to use a
different waveform shape for each slew, use Custom Pew-Slew Drivers.

SiliconSmart ACE User Guide 189

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The custom driver mode uses two parameters, driver_pwl_rise and

driver_pwl_fall, to control the shapes of the rise and fall PWL pre-drivers,
respectively. You must explicitly set these two parameters. They are lists of
floating point values between 0 and 1 (normalized) and the lengths of these
lists must be equivalent. According to the list values, SiliconSmart scales the
rise and fall waveforms.
Example 138
set driver_mode custom
set driver_pwl_rise {0 0 0.1 0 0.2 0 0.35 0.2 0.55 0.8 0.7 1 1 1}
set driver_pwl_fall {0 1 0.1 1 0.2 0.8 0.35 0.6 0.55 0.4 0.7 0.3 1 0}

Custom Pew-Slew Drivers

A cell being characterized needs to be subjected to different input slews (1ps,
5ps, 10ps, 100ps, 500ps). The shape of the waveform (rise or fall) for each of
these slews will depend on the driver you use (for example, when using
active/active-waveform, the shape will be the output of the driver). If you
know what the input waveform should look like, you can provide the shape by
setting driver_mode to custom, which gives the points between 0->1 as
percentages applied to VDD (0.1VDD, 0.5VDD, 0.7VDD, 0.99VDD).
The same waveform shape will apply for all slews required.
If you want a different waveform shape for each slew, set driver_mode to
custom-perslew. You must then specify a list for each slew, instead of a
single list for all slews. You can include full blown time-voltage pairs to prevent
the SiliconSmart tool from assuming anything.
Custom per-slew parameters:
■
driver_pwls_fall and driver_pwls_rise — these each represent the set of
falling/rising driver waveforms and the values should be a tcl list of lists. The
voltage levels used in each waveform should be the same and normalized
and the time points should be in absolute seconds.
For driver_pwls_rise the voltage values should be from 0 -> 1.
For driver_pwls_fall the voltage values should be from 1 -> 0.
The format should be:
{{slew1} {t11 v1 t12 v2 ... t1n vn} ... {slewm} {tm1 v1 tm2
v2 ... tmn vn}}

190 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Following is an example for one slew. You can add as many such list items for
as many slews as you have.
set driver_pwls_rise {
{0.001e-12}
{ 0 0
0.0542e-12 0.0200
0.1258e-12 0.0800
0.1356e-12 0.1000
0.1869e-12 0.2000
0.2440e-12 0.3000
0.3090e-12 0.4000
0.3832e-12 0.5000
0.4688e-12 0.6000
0.5711e-12 0.7000
0.6899e-12 0.8000
0.8316e-12 0.9000
0.9649e-12 0.9800
1.0000e-12 1.0000
}
}

set driver_pwls_fall {
{0.001e-12}
{ 0 1.0000
0.0542e-12 0.9800
0.1356e-12 0.9000
0.1869e-12 0.8000
0.2440e-12 0.7000
0.3090e-12 0.6000
0.3832e-12 0.5000
0.4688e-12 0.4000
0.5711e-12 0.3000
0.6899e-12 0.2000
0.8316e-12 0.1000
0.8615e-12 0.0800
0.9649e-12 0.0200
1.0000e-12 0
}
}

Active Drivers
The development of accurate models depends on using active drivers during
cell characterization. Especially for high-drive cells, the shape and slew of the
driving waveform significantly affects intrinsic delay and effective input pin
capacitance.

SiliconSmart ACE User Guide 191

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

The SiliconSmart tool requires either a non-inverting buffer cell (or

combinational cell configured as a buffer) or an inverter to be used as the active
driver. If an inverter is used as a driver then the -inverting switch should be
added to the import_driver command.
This cell will be characterized to create tables of output transitions versus
output load. To maximize the resolution of these tables, choose a cell with high
drive-strength as the driver. After stringent characterization and analysis,
SiliconSmart uses this cell, now known as the driver, as the input for all other
cells.
The active driver is attached to each cell-under-test (CUT) through an ideal
voltage-controlled voltage source (VCVS). For more information, see Figure 21.

Figure 21 Active Driver Cell

The VCVS removes the effect of the active driver presence from the analysis.
Further, the use of the VCVS, an infinite source of current, nullifies the effect of
the CUT input capacitance, CIN, when acquiring the CUT intrinsic delay.
Removing the effect of CIN from the acquisition of intrinsic delay improves
synthesis accuracy.

Active Waveform Drivers

To drive characterization, SiliconSmart has the option to use an active driver
cell to generate a realistic waveform at the input of the cell being characterized.
However, using an active driver has the disadvantage that it slows down
characterization because every SPICE deck generated would have an instance
of the driver cell. Because typically the buffer with highest drive strength in the
library is taken as the driver cell, the driver may have tens of transistors. Thus
using active driver can slow down characterization significantly due to the

192 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

additional driver cell transistors being simulated for every measurement (almost
a 2x performance hit in some cases).
SiliconSmart uses a method called active waveform, which eliminates this
performance problem while still maintaining accuracy. The active waveform
methodology recreates the driver waveform and applies it as a multi-point
piecewise linear waveform (PWL) which is derived by curve fitting the actual
driver cell waveform, and thus achieving significant performance improvements
will little or no accuracy penalty.
The flow for using the active-waveform is very similar to the active driver flow.
The driver cell still must be characterized before actual characterization starts.
This provides waveforms for different required input slews. During actual
characterization, depending on the input slews required, PWL waveforms are
generated and applied to the input; the actual driver cell is no longer
instantiated.
The parameter driver_mode accepts a value of active-waveform. Setting
driver_mode to active-waveform and the driver parameter to a valid
driver cell name causes SiliconSmart to use a waveform-based active driver.

Note: A driver cell must be imported using the import_driver

command.

Use the driver_waveform_points parameter, which contains a list of

floating point numbers between 0 and 1.0 in ascending order. The default value
is {0.02 0.05 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.80 0.90
0.95 0.98}. Specifying more points will cause the waveform to be more
similar to the actual driver waveform. In general, the defaults for this parameter
shows good correlation when compared to active driver mode.
By default, driver_waveform_points requires spacing between points to
be 0.1ps or more in order to achieve the minimum slew. You can replace this
0.1ps limit by setting the parameter driver_waveform_min_dt to the value
of the desired limit.
When you provide your driver_waveform_points to be too close (many
points in the range 0-100%), then the driver_waveform_min_dt will
activate. The SiliconSmart tool will determine that two voltage points should be
at least driver_waveform_min_dt interval apart to satisfy the spice engine.
If voltage point separation is too close, the second point will be moved so that
the separation is at least driver_waveform_min_dt.

SiliconSmart ACE User Guide 193

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

An example for these settings is as follows. In configure.tcl:

pintype default {
...
...
set driver_mode active
set driver BUF
set driver_waveform_points { 0.05 0.10 0.20 0.30 0.40 0.45
0.5 0.55 0.6 0.7 0.8 0.9 0.95}
set driver_waveform_min_dt 0.5e-13
}

See Also
■
Parameter: driver_waveform_min_dt
■
Parameter: driver_waveform_points

Active-Direct Drivers
SiliconSmart supports active-direct drivers. To enable this feature, set the pin
type parameter driver_mode to active-direct. Usually an active driver is
not connected directly to an input pin. A voltage controlled voltage source is
used. But in active-direct mode, the active driver output is directly connected to
the input pin of the cell to be characterized.

Note: Be warned that connecting the driver directly to the input pin will
affect the slew seen at the pin. Measured slew will be used during
modeling. Use this feature only under very specific
circumstances.

Importing Driver Cells

SiliconSmart can import simple, two-pin buffers and inverters for use as a driver
cell. To do this use the import_driver command as follows:
Example 139
import_driver cell_name -netlist netlist_file -input_pin pin \
-output_pin pin

In this usage, cell_name is the name of a subcircuit defined in the file

netlist_file. The switches -input_pin and -output_pin specify the
names of the input and output pins in the cell’s simulator subcircuit definition.
The cell is assumed to be a buffer.

194 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

Note: To get correct power numbers, it is vital that the simulator

subcircuit definition include the ground and power supplies. This
allows SiliconSmart to connect it to different voltage supplies
than the cell-under-test. If this is not done the power consumed
by the active driver will be included in the cell's power numbers.

For example, the following command imports the cell BUF20 with pins A and Z
for use as a driver:
Example 140
import_driver BUF20 -netlist BUF20.sp -input_pin A -output_pin Z

BUF20 can be used to drive input transitions on the CUT.

Inverting Active Drivers

SiliconSmart supports using an inverter as an active driver. To use this feature,
issue the -inverting flag with the import_driver command, as shown in
the following example:
Example 141
import_driver INVX2 -netlist INVX2.CIR -input_pin A -output_pin
Y -inverting

Using Driver Cells

Once a driver cell has been imported, it can be used in characterization by
selecting it in the appropriate pin type definition by setting the pin type
parameter driver. By default this parameter is set to pwl, selecting an ideal
piecewise-linear driver model. Setting driver to the name of a cell imported
with import_driver causes SiliconSmart to use that cell to drive all
transitioning inputs on the CUT.
For example, a new pin type named buf_driver can be created to use the
BUF20 cell imported in the previous example with the following command:
Example 142
pintype buf_driver -> default {
set driver BUF20
}

During characterization, SiliconSmart instantiates a BUF20 cell to drive each

input pin of pin type buf_driver.
For precharacterization, if the binning_delay option is used with
set_config_opt and simulator_options (set_config_opt -type

SiliconSmart ACE User Guide 195

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

binning_delay simulator_options options), then driver

characterization will consider the simulator options (options) during the
precharacterization step. Otherwise, the SiliconSmart tool will consider the
simulator options to be set globally.

Viewing and Removing Driver Cells

SiliconSmart provides commands for looking at the set of imported driver cells
and, if necessary, removing a driver. The command report_drivers is used
to display information about each driver cell. It has the following usage:
Example 143
report_drivers [-verbose] [pattern]

The report_drivers command displays a textual report of each imported

driver as shown in the following example:
Example 144
siliconsmart> report_drivers
*
* Report: driver cells as of Tue Nov 12 15:48:23 CST 2002
*

Cell: INV12 Arc: A -> Y (inverting)

File: INV12.CIR

Cell: BUF20 Arc: A -> Y (noninverting)

File: BUF20.CIR

Cell: INV2 Arc: A -> Y (inverting)

File: INV2.CIR

The pattern argument allows the display to be restricted to only those drivers
matching a wildcard expression. The -verbose switch turns on additional

196 SiliconSmart ACE User Guide

L-2016.03
 Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

information about the conditions under which the cell has been characterized
as shown in the following example:
Example 145
siliconsmart> report_drivers BUF* -verbose
*
* Report: driver cells as of Tue Nov 12 15:52:16 CST 2002
*

Cell: BUF20 Arc: A -> Y (non-inverting)

File: BUF20.CIR
Characterized at:
Operating cond. = WORST Temperature = 125 vdd = 3.13 vss = 0.0
Operating cond. = WORST Temperature = 125 vdd = 2.97 vss = 0.0

In this example, only the drivers matching the pattern BUF* are displayed. Cell
BUF20 has been characterized using the operating condition WORST at 125
degrees, with supply voltages of 3.13V and 2.97V.
You can remove driver cells using the remove_driver command as follows:
Example 146
remove_driver name

The specified driver is removed and must be reimported before it can be used
again.
Once characterized, the driver data will be stored in the charpt/config/driver.db
file. If a driver is characterized in one charpt, the driver.db can now be copied
and used in another charpt for active-waveform mode. This will work even if the
op_cond and pintype info do not match. The netlist should not be copied
since that will cause SiliconSmart to attempt to characterize it.

Driver Waveform Support

SiliconSmart supports driver waveform syntax in Liberty format. The driver
waveform syntax helps facilitate the characterization process for existing
libraries and correlation checking.
The Liberty model will contain normalized_driver_waveform groups. Set
the parameter model_normalized_driver_waveform to 0 to disable this.

Creating a Default Unnamed normalized_driver_waveform

For Liberty specifications, the default normalized_driver_waveform
(NDW) is unnamed. In the SiliconSmart tool, these default NDWs have been

SiliconSmart ACE User Guide 197

L-2016.03
Chapter 4: Importing and Configuring
Setting Advanced Configuration Options

denoted by using the names driver_waveform_default_rise and

driver_waveform_default_fall.
To create a default normalized_driver_waveform with no name, set the
insert_liberty_default_ndw parameter to 1. The SiliconSmart tool will
search the list of NDWs for a named NDW, using the string "default" as part of
the name, and copy that NDW into a new, unnamed NDW.

Example 147
set_config_opt insert_liberty_default_ndw 1

Both the original named NDW and the new unnamed NDW will be in the output
Liberty file.If multiple NDWs are listed with "default" in the name, the last NDW
will be taken. If an unnamed NDW is imported from a Liberty file, this feature
will not add an additional default (unnamed) NDW.

198 SiliconSmart ACE User Guide

L-2016.03
 5
5

Characterizing and Modeling

This chapter describes the process of characterizing and modeling a library of

cells.

Once cells have been configured, the tool flow continues with bundling jobs,
submitting for simulations, collecting results, and modeling.
The following sections describe characterization in the SiliconSmart tool:
■ Precharacterization
■
Characterization
■
Recharacterization
■ Generating Models
• Model Preprocessing
• Modeling Multi-Bit Cells
■ The Distributed Processing Engine

Precharacterization
SiliconSmart provides a precharacterization command that can be used to
reduce overall characterization time. The precharacterization step does this by
binning or grouping states with similar delay, constraint or energy
characteristics, and by multi-corner load ranging. The precharacterization step
is optional, and must be used before running the configure command.

SiliconSmart ACE User Guide 199

L-2016.03
Chapter 5: Characterizing and Modeling
Precharacterization

Precharacterization consists of three phases:

1. Configuration — examine the cell behavior and identify arcs with multiple
possible secondary states.
2. Characterization — run quick, low-resolution simulations for such arcs.
3. Evaluate results — analyzes the results of the simulations and produce the
appropriate binning configurations.
After precharacterization, a cell.prechar file (to accompany the existing cell.inst
file) is produced in the control directory. This file contains the required settings
for the following parameters: state_rank, state_selection,
state_partitions and whens. These settings are then used during the
configuration process to significantly reduce the number of arcs that require
characterization.
The following sections describe precharacterization in SiliconSmart:
■
Before Precharacterization
■
Using the precharacterize Command
■
Additional Precharacterization Flows

Before Precharacterization
Before running precharacterization, you can decide how the
precharacterization should proceed by controlling the parameters and settings
described in the below sections. These settings affect the way simulations are
performed during precharacterization and control how the different states
should be binned.
The following sections describe these settings:
■
Simulation-Related Settings for Precharacterization
■ Binning
■
Using model_expanded_states

Simulation-Related Settings for Precharacterization

The precharacterization phase uses the simulator value specified in the
prechar_simulator parameter to run the simulations (the default is

200 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Precharacterization

finesim_embedded and requires that you have a FineSim embedded

license).
■ The boolean parameter prechar_keep_intermediate_files
determines if the precharacterization simulation files should be retained for
further examination.
■
The prechar_numsteps parameter controls the number of load/slew
points used for characterization.
■
If explicit_points are specified for load/slew (for instance, in a
recharacterization flow) and prechar_numsteps is specified to be 1 or 2
then it is considered a special case and a single average value or the pair of
minimum/maximum values in the explicit_points are chosen for
characterization.

Binning
Binning is particularly useful for cells with state-dependent arcs. State
dependent arcs are those with multiple possible secondary pin states (when
conditions). Precharacterization is not required for arcs with just a single state.
For a given arc, grouping states with similar characteristics effectively reduces
the number of arcs that reduces full detailed simulation.
■
Tolerance and max_bins
■
Precharacterization Binning Modes
■
Delay Binning
■
Constraint Binning
■
Energy Binning

Tolerance and max_bins

The number of bins produced is controlled by both the tolerance requirement
and the max_bins requirement. The tolerance controlling parameters are
prechar_binning_abs_tol and prechar_binning_rel_tol. The
prechar_binning_abs_tol (default = 3*time_res_high) parameter is
the maximum range of a single bin in absolute units.
The prechar_binning_rel_tol (default = 0.0) parameter is the maximum
range of a single bin scaled to the maximum of the absolute measurement
values across all bins. The larger of the absolute and relative tolerance is
chosen. The minimum number of bins which satisfies the tolerances is
computed unless the value specified in prechar_binning_max_bins

SiliconSmart ACE User Guide 201

L-2016.03
Chapter 5: Characterizing and Modeling
Precharacterization

(default = 9999) is exceeded. If the value of tolerance is very small and

prechar_binning_max_bins is not large enough, then it is possible that the
final binning configuration will not meet the tolerance requirement.
The set_config_opt command can be used to specify absolute/relative
tolerances separately for each measurement. The relevant arguments to
-type are binning_timing, binning_constraints, binning_mpw,
binning_energy and binning (which covers all the other four types).

Precharacterization Binning Modes

After the binning process is completed, SiliconSmart provides various modes to
use these binned states during the partitioning process in the configuration
step. The modes provided by SiliconSmart are:
■
all — a partition is created for each bin and each bin covers all states in
that bin. The state_selection parameter is set to
best_median_worst which will pick the overall best or worst if it is part of
a bin and otherwise use a median state from that bin.
■
best — use a single partition with the overall best state across all the bins.
■
worst — use a single partition with the overall worst state across all bins.
■
all_best — similar to all except that from each bin, the best state will be
used.
■
all_worst — similar to all except that from each bin, the worst state will
be used.
■
explicit — no partition is created; the user-specified partitioning scheme
is used and precharacterization only generates the state ranking for a
selection within a bin.
■ none — used to disable precharacterization for certain types of arcs.
Using best/worst will effectively create a single bin regardless of the number
of secondary states for a given arc. The explicit mode is primarily relevant when
precharacterization is used in the recharacterization flow. In such a scenario,
the partitioning scheme (state_partitions/whens) is already derived from
the imported Liberty model and precharacterization only produces the
applicable settings for ranking (state_rank) and selecting
(state_selection) the states.
The precharacterize command also supports multi-corner automatic load auto-
ranging across different operating conditions. This is controlled by the boolean
parameter prechar_autorange_load. Among the resulting load values, the

202 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Precharacterization

worst-case load is then selected. This enables all .lib files to be generated with
the same load points, a requirement for voltage scaling in some analysis tools.

Delay Binning
Precharacterization for delay arcs is controlled by the
prechar_binning_timing parameter. This parameter can be set to one of
the seven binning modes. While analyzing simulation results, the binning
algorithm accounts for the values of both output delay and output slew.

Constraint Binning
For sequential cells, SiliconSmart supports constraint binning for setup, hold,
recovery, removal, asynchronous recovery/removal and mpw arcs. This is
controlled by the prechar_binning_constraints parameter that can be
set one of the seven binning modes.

Energy Binning
Precharacterization for energy arcs is controlled by the
prechar_binning_power parameter. This parameter can be set to one of
the seven binning modes. Precharacterization for hidden energy arcs is
controlled by the boolean flag called prechar_binning_hidden_power.
Additionally, SiliconSmart provides an option to analyze delay and the
corresponding switching energy in unison or independently. This option is
controlled by the prechar_binning_method parameter. When set to all-
by-timing, only the binning delay arc is simulated and its binning results are
adopted directly for the corresponding switching energy arc. When set to
independent, the binning delay and switching energy arcs are analyzed
separately.
The default value for prechar_binning_abs_tol is specified as 3e-12
which corresponds to 3pJ, a value that is typically very large compared to the
simulation values for energy. It is therefore necessary to reset it to a smaller,
more meaningful value for energy. For instance:

Example 148
set_config_opt –type binning_energy prechar_binning_abs_tol 5e-
15.

SiliconSmart ACE User Guide 203

L-2016.03
Chapter 5: Characterizing and Modeling
Precharacterization

Using model_expanded_states
While precharacterization reduces the number of states required for simulation,
it is possible to still produce a Liberty model that contains all the states for each
arc. This process is controlled by the model_expanded_states parameter
which copies the simulation results of the simulated state to all other states in
its bin.
For instance, suppose an arc with eight states is grouped into three different
bins. Setting this parameter to true will produce a Liberty model with eight
states instead of three. The trade-off is between running eight full-scale
simulations compared to running eight low-resolution simulations plus three
full-scale simulations.

Using the precharacterize Command

The below describes the usage and syntax of the precharacterize
command:
Example 149
precharacterize [-fast] [-by_family] [-reanalyze]
[-report report_file] cells

The –fast option is useful to run the precharacterization related configuration

and analysis jobs in a distributed fashion. The simulation tasks during
precharacterization are always distributed if job_scheduler is not set to
standalone.
The –by_family option enables family-based precharacterization and
requires the cell_families parameter to be set appropriately.
The –reanalyze switch skips the first two phases and only performs the
results analysis of third phase. This option is particularly useful when the
tolerance parameters are tweaked to obtain a different binning configuration.
The –report option writes a detailed precharacterization summary to the
report file. This file includes a list of precharacterization parameters as well as
a variety of statistical items to describe the precharacterization reduction on a
per arc as well as a per cell basis.

204 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Precharacterization

See Also
■
Command: precharacterize

Additional Precharacterization Flows

The following sections describe additional precharacterization options:
■
Family-Based Precharacterization
■
Event-Based Precharacterization

Family-Based Precharacterization
When a library contains various families of cells, it is frequently seen that the
arc characteristics of the different cells within a family are identical. Within a
certain family, it is likely that there are strong similarities in the groupings of
states for a given arc irrespective of the size of a cell. SiliconSmart leverages
this characteristic by providing an option to perform family-based
precharacterization.
This process is controlled by the –by_family and the cell_families
parameter, which accepts a list of lists of cell names where each list
corresponds to a separate family. This classification of the library into families
can be done by hand or by using the convenience function called
cell_families_by_name.
For instance, suppose we have set cell_families to { {invx1 invx2
invx4} {andx2 andx1} }. The first element in each family is taken as the
representative for that family. Precharacterization will then perform simulations
for only invx1 and andx2 instead of the full list of cells. However, the prechar
files will be produced for all five cells since the representative cell’s binning
results will be copied over to the other elements in the family.
To use this option, all cells must be assigned to some family. Moreover, it is not
possible to precharacterize a member cell of some family when the
representative cell is also not being precharacterized.

Event-Based Precharacterization
In certain complex cells, some arcs can correspond to a single state but arise
from separate different events due to the presence of switching inputs. For
instance, consider an AOI cell with inputs A,B,C and output Y = ( (A&B) |
(B&C) | (C&A) ). In this cell, arc A (01) -> Y (01) requires the side

SiliconSmart ACE User Guide 205

L-2016.03
Chapter 5: Characterizing and Modeling
Characterization

inputs B and C to be at 0 initially. However, we can also have either B or C also

have a rising transition and still obtain the required A->Y arc.
Such instances with multiple switching inputs cannot be represented by the
Liberty model since it differentiates arcs only according to the state but not with
events. However, we may still need to examine all three cases to identify the
worst case scenario in terms of energy consumption.
In such a scenario, precharacterization can be used to differentiate these
different events. This can be done through the use of add_user_stimulus
and the event_rank parameter. First, we define three separate events
corresponding to the cases of B,C fixed at 0, B rise + C fixed at 0 and finally B
fixed at 0 + C rise. The three events have separate event_id tags.
Precharacterization will then simulate all three cases, determine the best/worst
case and produce the appropriate event_rank parameter in the prechar file.

Characterization
Once characterization plans have been generated, the cells can be
characterized. The characterization process takes the characterization plan for
each cell and generates the file necessary to describe each measurement to
be performed. Each simulation is checked against the fault tolerant cache and
each missing simulation is performed.
The following sections describe characterization options:
■
Before Characterizing
■
Using the characterize Command

Before Characterizing
Before characterizing, you should have prepared for the characterization with
the following Requirements for Characterization:
■
Creating the Characterization Point
■
Editing the configure.tcl File
■
Importing Cells
■
Editing Instance Files

206 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Characterization

■
Precharacterizing (Optional)
■
Configuring Cells

Using the characterize Command

The characterize command uses the distributed processing engine to run
all of the simulation jobs in the compute farm on specified cells:
Example 150
characterize cells

It reports the process as the jobs complete and returns when all jobs have
completed.

Note: SiliconSmart caches characterization information so that if you

rerun characterize on a set of cells, only cells with an
updated .inst file or an updated configure.tcl file are
characterized again.

For details on distributed processing in characterization, see the Generating

Models section.

Running Selective Simulations

Use the -match switch with the characterize command to run selective
simulations. It must specify an expression and it accepts wildcards in the Tcl
regexp format. For example:

Example 151
characterize –match {setup__*|hold__*} cells

SiliconSmart ACE User Guide 207

L-2016.03
Chapter 5: Characterizing and Modeling
Recharacterization

See Also
■
Command: characterize

Recharacterization
Recharacterization is a characterization flow that requires an existing Liberty
model. It is designed to replace existing values in the model or add new
constructs to the model. Some of the benefits include:
■
Preserving the original Liberty model while just replacing values or adding
new constructs.
■
Providing the ability to easily compare the previous and newly
recharacterized model.
■
Providing an easy path to add some of the advanced characterization
constructs to an existing model you’ve already validated.
The recharacterization mode takes a Liberty model that was imported via the
import command and preserves as much of the structure and formatting of
the library as possible while replacing the data tables with the newly
characterized data.
Like all characterizations, recharacterization options are set during the
configure and import steps of a characterization.

Note: This mode is the default if a Liberty model has been imported for
a given cell.

Recharacterizing without a configure.tcl File

When import is run with a Liberty model and netlists, the SiliconSmart tool
will automatically create a basic configure.tcl file and place it in the $charpoint/
config/ area in the absence of a golden configuration file.
This configure.tcl will contain information read from the Liberty model, such as
operating conditions, power_meas_* lists, different pintypes for multi-rail cells,
high/low logic thresholds, largest_slew, max_tout extracted from the Liberty,
and so on. The default operating condition from the Liberty will be used to
create the operating condition in this configure.tcl.

208 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

The SiliconSmart tool immediately sources the configure.tcl after import so that
all these settings imported from the Liberty can take effect in the flow.
The SiliconSmart tool will also create the corresponding cell instance files with
correct pintypes which correspond to the ones created in the configure.tcl.
Since the automatically generated configure.tcl can only have the information
extracted from the Liberty, the user is free to set any custom settings related to
farm, or simulator version/options, new operating conditions, etc., before or
after the import step. These custom settings will also be applied, in addition to
the default settings from the newly created configure.tcl.
The rest of the flow steps of configure and can then be performed as usual.

Note: To be able to maintain the Liberty structure, attributes and other

aspects, the model step must be run without the
-create_new_model switch.

See Also
■
Pure Recharacterization Flow
■
Functional Recognition Flow
■
Incremental Characterization Flow

Generating Models
This section describes how to generate models from the characterization data
produced by SiliconSmart and add user-defined attributes. It also details the
supported Liberty constructs and how to trace back to the origin of a given
construct.
The following sections describe generating models in SiliconSmart:
■
Using the model Command
■
Model Preprocessing
■
Liberty Models
■
Slew Derating
■
Modeling Multi-Bit Cells
■
Adding Attributes to Models

SiliconSmart ACE User Guide 209

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

■
HDL Model Generation
■
Generating a test_cell

Using the model Command

Use the model command to generate models from the collected
characterization data for one or more cells. SiliconSmart can generate models
in a variety of formats containing a wide range of characterization data.

Example 152
model -options cells

where cells is a Tcl list of one or more cells for which characterization has
already been performed with the current characterization directory structure.
If no Liberty model has been imported or the –create_new_model switch is
used, a new model is created. In this mode, SiliconSmart starts with an empty
library and adds the parameters specified in the liberty_model parameter
block of the configure.tcl file. The resulting model is formatted such that the
order of the cells, pin, arcs, and when conditions remains consistent across
product releases.
If an existing Liberty model has been imported, the recharacterization mode is
used. See the Recharacterization section for more information on
recharacterization.

Note: Both -ecsm* and -ccs* can be modeled at the same time in
the same Liberty with one use of the model command, allowing
all views (NLDM, NLPM, CCST, CCSN, CCSP, ECSMT, ECSMP)
to be modeled at once in one Liberty.

Distributed Modeling
The model command uses the distributed processing engine (see the
Generating Models section) to dramatically reduce the time required to model a
library. When the model command is invoked, it starts a set of characterization
engines and dynamically distributes the modeling tasks to all of the available
engines. The results are combined back into a single .lib file and published as
part of the final results.
Two exceptions exist to this rule. First, the IBIS formats are not distributed.
When modeling this format, all of the cells will be run on the local machine.

210 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

Second, you can force SiliconSmart to run the modeling jobs locally by setting
the job_scheduler to standalone and run_list_maxsize to 1. In this
case, the modeling jobs are run in the current process. This can be faster when
modeling a small number of cells. The settings can be changed by executing
the following commands:

Example 153
set_parameter default job_scheduler standalone
set_parameter default run_list_maxsize 1

Generated Files
Model generation results in the creation of the following files:
■
Liberty models — Liberty model files reside in the char_dir/models/liberty
directory and have .lib file extensions. There is one model file for each
unique operating condition. Each file contains one or more cells. The file
name format of a model file is liberty_op_pt.lib, (liberty _typ_pvt.lib, for
example).
■
Verilog models — Verilog models are written to the char_dir/models/verilog
directory and have the .v file extension. A single model file is written out with
the default name verilog.v.
■
IBIS models — IBIS models are written to the char_dir/models/ibis directory
and have the .ibs file extension. A single model file is written out with the
default name ibis.ibs.
The base name of the files can be changed with the -output switch to the
model command.

Automatic Default Arc Selection

SiliconSmart automatically selects default timing arcs based on best-case,
average, or worst-case conditions. Specify a best, typ, or worst library type
by using the -library_type option of the model command. This enables
SiliconSmart to select the appropriate default arc. If unspecified, the library
type defaults to worst-case. This switch also controls the computation of the
cell_leakage_power Liberty attribute. The library type of best, typ,
worst computes the cell_leakage_power as the minimum, average, and
maximum of the leakage_power groups.

SiliconSmart ACE User Guide 211

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

For example, the following commands generate two libraries, one best-case
and one worst-case:
model –operating_condition fast_3.3v –library_type best
MY_IO_CELL
model –operating_condition slow_3.0v –library_type worst
MY_IO_CELL

Model Preprocessing
Model preprocessing (MPP) consumes the process model file and produces
per-cell model/netlist files with all of the resolved device parameters and
equations. Using model preprocessing greatly reduces the I/O of parsing
process files for each simulation during the distributed characterization,
improving performance without losing accuracy.
MPP can be run on a charpoint and you can come back and continue (or rerun)
the flow at a later point. It reruns each time with the first step (either import or
configure), even if there is no change in the original netlists and process
files.
Model preprocessing supports the following:
■
Precharacterization based flows
■
HSPICE, FineSim, FSE based characterizations
■
EM & LVF characterizations
■
Different driver modes
The following sections describe model preprocessing:
■
Suggested Usage
■ Enabling MPP
■
Using Non-HSPICE Simulators
■ Running MPP
■
Netlist Locations
■
Failures
■
Example Netlists

212 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

Suggested Usage
The following steps are recommended:
1. For every node and new extraction, pick 1 cell per family.
2. Run the characterization with and without MPP.
3. Compare the data (delay/slew/constraints/etc.)
4. If the comparison shows very close data (which is expected), then enable
MPP for the entire library.

Enabling MPP
Enable MPP by setting the parameter advanced_node to 1 in either in the
default params block of the configure file or with set_config_opt in the
run.tcl file. The default of advanced_node is 0, which disables MPP.
If you set advanced_node in the run.tcl file, you must set it before the first
command of the SiliconSmart flow begins (which will be either import or
configure).
For example:
set_config_opt advanced_node 1

Note: Please note that MPP will be automatically disabled if a flow

already has optimize_process_models enabled.

Using Non-HSPICE Simulators

An HSPICE parser is used for preprocessing. If you are using an HSPICE
simulator, the parser is picked up automatically. If you are running your
simulations using non-HSPICE simulators, then you must point the MPP
engine to an HSPICE parser with the mpp_simulator parameter:
set_config_opt mpp_simulator /global/apps5/hspice_2015.06-SP1/
hspice/bin/hspice

Running MPP
MPP is automatically invoked before the first step of your SiliconSmart flow
(either import or configure), no separate command is required to invoke it.

Netlist Locations
The original netlist is preserved in the charpoint, saved as: <cell>.<extn>.orig

SiliconSmart ACE User Guide 213

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

The new netlists are located as soft links in the netlists directory. The actual
post-MPP netlists are located in: <charpt>/runtime/<pvt>/PP/NewNetlists

Failures
If MPP fails (due to tool version/process files incompatibility or other license
issues), it will not stop the flow. The SiliconSmart tool will give a warning and
will unset the advanced_node parameter and continue the flow as usual as if
it were run without MPP, falling back on the normal netlists.

Example Netlists
Using MPP will not change the original netlist. A new copy of the netlist will be
prepared and saved in the charpoint. The original netlist will be soft-linked in
the charpoint.
For example, below is the original netlist:
*Example Netlist
*Buffer 2
*Pins: VDD VSS A Y
M1 N1 A VSS VSS NCH W=0.4U L=0.25U
M2 VDD A N1 VDD PCH W=0.8U L=0.25U
M3 Y N1 VSS VSS NCH W=0.8U L=0.25U
M4 VDD N1 Y VDD PCH W=0.16U L=0.25U

214 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

And the model preprocessed netlist:

*BUFF2 subckt
.SUBCKT BUFF2 VDD VSS A Y
m_M1 N1 A VSS VSS BUFF2_nch
+ w=4e-07
+ l=2.5e-07
+ m=1
+ delvto=0
+ mulu0=1
+ mulua=1
+ mulub=1
+u0mult=1
m_M2 VDD A N1 VDD BUFF2_pch
+ w=8e-07
+ l=2.5e-07
+ m=1
+ delvto=0
+ mulu0=1
+ mulua=1
+ mulub=1
+u0mult=1
m_M3 Y N1 VSS VSS BUFF2_nch
+ w=8e-07
+ l=2.5e-07
+ m=1
+ delvto=0
+ mulu0=1
+ mulua=1
+ mulub=1
+u0mult=1
m_M4 VDD N1 Y VDD BUFF2_pch
+ w=1.6e-07
+ l=2.5e-07
+ m=1
+ delvto=0
+ mulu0=1
+ mulua=1
+ mulub=1
+u0mult=1
.ENDS BUFF2

Liberty Models
A Liberty model consists primarily of two types of data: timing characteristics
and power characteristics. Timing characteristics represent intrinsic pin-to-pin
delays, output slews, setup/hold times, and recovery/removal measurements. It

SiliconSmart ACE User Guide 215

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

also includes MPW and minimum period measurements. Power characteristics

include leakage power plus switching and hidden energy measurements. In
addition to timing and power measurements, each model also contains pin
capacitance measurements.

Supported Construct Types

Liberty models are structured such that each type of data is encapsulated
within a specific Liberty construct. SiliconSmart supports the Liberty constructs
described below in Table 6.
Table 6 Liberty Constructs Supported by SiliconSmart

Construct Type Construct Names Description

Delay cell_rise Models the intrinsic pin-to-pin

cell_fall delay for rising and falling input
transitions.

Transition time rise_transition Models the output transition

fall_transition time for rising and falling output
transitions.

Constraint rise_constraint Models setup and hold times for

fall_constraint rising and falling data
transitions.

Pulse width min_pulse_width_high Models the minimum required

min_pulse_width_low pulse width for control inputs.

Pin capacitance capacitance Models the dynamic input pin

rise_capacitance capacitance.
fall_capacitance

Power rise_power Models the switching power for

fall_power each transition and leakage
cell_leakage_power power (transition independent).

Styling Options
SiliconSmart provides several options for controlling stylistic aspects of the
published Liberty model. The stylistic control allows you to adjust the units and
precision of the data in the published library, filter out nonmonotonic data, and

216 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

bind constraints to nonnegative values. Each of the options is controlled via the
following parameters in the default parameter block:
■ liberty_cap_unit — specifies the units to use for capacitance values.
■
liberty_time_unit — specifies the units to use for time values.
■
liberty_increasing_delay_with_load — specifies the minimum
delta between delay values in a table as load increases.
■
liberty_increasing_delay_with_slew — specifies the minimum
delta between delay values in a table as slew increases.
■
model_negative_constraints — when set to false, negative
constraint values are forced to 0.
■
model_negative_delays — when set to false, forces negative delay
values to 0. Otherwise, negative delay values are generated in the model.
■
model_negative_energy — when set to false, negative energy values
are forced to 0. Otherwise, the exact values are modeled.
■
model_negative_leakage — when set to false, negative leakage
values are forced to 0. Otherwise, the exact values are modeled.
■
model_significant_digits — specifies the number of significant
digits to use for the data in the model.
■
liberty_max_capacitance — controls the generation of the Liberty
max_capacitance attribute. See the following section for details.
■
liberty_max_transition, calculate_max_transition,
liberty_tmax_input, liberty_tmax_output — controls the
generation and value of the Liberty max_transition attribute. See the
following section for details.
■
model_mpw_attribute — when true, minimum pulse width data is
modeled as Liberty attributes. When false, MPW data is modeled as a
table.

Writing Min/Max Capacitance and Min/Max Transition Attributes

The timing LUT tables in Liberty are for a defined range of transitions (at inputs)
and capacitance load (at outputs). If any port/net on a timing path is
experiencing a value of transition/capacitance load beyond this range, the STA
tool extrapolates the desired value from existing LUT tables. The STA tool does

SiliconSmart ACE User Guide 217

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

not guarantee accuracy for extrapolated values. The min/max attributes will
inform you about these potential extrapolation problems.
These attributes define the valid input slew and output load ranges, which are
then used by the STA tool to inform the designer if a port/net is experiencing a
transition or load beyond this valid range. These attributes are also known as
DRC (Design Rule Constraint) attributes.
You can use the SiliconSmart tool to control the following Liberty pin attributes
in a new or existing Liberty model:
■
Writing min_capacitance and min_transition
■
Writing max_capacitance
■
Writing max_transition for New Liberty Models
■
Writing max_transition for Recharacterized Models

Writing min_capacitance and min_transition

These Liberty attributes are set as follows:
■
min_capacitance — the SiliconSmart tool will set this attribute for all
output pins as the maximum of the minimum load index for each pin.
■
min_transition — the SiliconSmart tool will set this attribute for all inout
pins as the maximum of the minimum slew index for each pin.
By default, the min_capacitance and min_transition attributes will be
generated for a new model and updated when recharacterizing an existing
model. For recharacterization, the min_capacitance or min_transition
attributes will be generated if they do not already exist in the Liberty.
To disable the generation of these attributes for new models, or to disable the
modification of these attributes when recharacterizing an existing Liberty
model, set the parameters liberty_min_capacitance and/or
liberty_min_transition to 0.
You can also use the set_liberty_attribute command to force a hard-
coded min_capacitance or min_transition to pins, as shown below:
set_liberty_attribute –cell cell –pin Y min_capacitance value

Writing max_capacitance
By default, the max_capacitance attribute is set for all output pins as the
upper limit of capacitance load for output and inout pins; it selects the minimum

218 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

of the maximum among all capacitive load indices for all timing arcs that
terminate at that pin (output/inout).
You can instead have the max_capacitance value determined by the output
capacitance, where the output transition = max_tout. If max_tout is larger
than the largest tout in the rise/fall_transition tables, it will instead be
determined by the maximum capacitance index. Set the parameter
liberty_max_capacitance_mode to 2 to enable this behavior.
By default, the max_capacitance attribute will be generated for a new model
and updated when recharacterizing an existing Liberty model. For
recharacterization, the max_capacitance attribute will be generated if it does
not already exist in the Liberty.
To disable the generation of the max_capacitance attribute for new models,
or to disable modifying this attribute when recharacterizing an existing model,
set the parameter liberty_max_capacitance to 0.
You can also use the set_liberty_attribute command to set a hard-
coded max_capacitance value to pins, ignoring the value determined by
liberty_max_capacitance_mode, as shown below:
set_liberty_attribute –cell cell_name –pin Y max_capacitance 0.06

Writing max_transition for New Liberty Models

For a new Liberty model, the max_transition attribute is set as follows:
■
For input pins, max_transition is set as the maximum index value of slew
indices (i.e., input_net_transition).
■
For output pins, max_transition is set as the maximum value from all the
rise/fall_transition tables.
You can have the max_transition attribute set to the values of the
parameters liberty_tmax_input and liberty_tmax_output by setting
the parameter calculate_max_transition to 0 and the parameter
liberty_max_transition to 1 (default). If the liberty_tmax_input/
output parameters are not found, the max_transition attribute will instead
be set to largest_slew and max_tout.

Note: When using liberty_tmax_input/output parameter

values, the liberty_max_transition parameter must be set
to 1 (default) in order to generate the max_transition attribute
in the new Liberty model.

SiliconSmart ACE User Guide 219

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

By default, the max_transition attribute will be generated for new models.

To disable generation of this attribute, set the parameter
liberty_max_transition to 0.

Writing max_transition for Recharacterized Models

For a recharacterization-based flow, the max_transition attribute is set as
follows:
■
For input pins, max_transition is recalculated as the maximum index
value of slew indices (i.e., input_net_transition.
constrained_pin_transition, related_pin_transition).
■
For output pins, max_transition is recalculated as the maximum value
from all the rise/fall_transition tables.
By default, the max_transition attribute will be recalculated and updated
when recharacterizing an existing Liberty model. The attribute will be
generated if it does not already exist in the Liberty.
To disable recalculating and updating this attribute when recharacterizing an
existing Liberty model, set the parameter liberty_max_transition to 0.

Slew Derating
The Liberty format supports a concept known as slew derating in which slew
rates are derated (scaled) to a different set of slew thresholds. This allows the
slew rates to be measured at one set of slew thresholds and then scaled to a
different set, perhaps to match existing intellectual property. SiliconSmart
supports this capability in both the recharacterized model flow and the new
model flow.
For the recharacterization flow, the input Liberty model should have the Liberty
attribute slew_derate_from_library set to a value less than 1.0.
SiliconSmart reads the slew derating factor from the input Liberty model and
scales the slew values accordingly for characterization. You must verify that the
characterization trip points are correct in the configure.tcl file through the
logic_low_threshold and logic_high_threshold parameters. When
the output Liberty model is generated, SiliconSmart scales the slew values
back to match the input Liberty model, again using the
slew_derate_from_library attribute from the input Liberty model to
determine the scaling.

220 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

For example, if the original .lib file has slew thresholds of 10% and 90% and
slew_derate_from_library is set to 0.5, then a slew rate of 1.2ns in the
.lib file will be scaled to 0.6ns (1.2ns * 0.5) and written into the instance file
(.inst) for the cell. Additionally, the logic_high_name and logic_low_name
parameters should be set to 0.7 and 0.3, respectively. (The slew rate is the ratio
of the parameters: 0.5 = (0.7 - 0.3) / (0.90 - 0.10)).
For the characterization flow, two parameters,
slew_derate_upper_threshold and
slew_derate_lower_threshold, can be set in the default parameter block
in the configure.tcl file. These parameters are used to calculate the Liberty
slew_derate_from_library attribute based on the characterization
thresholds as specified by the logic_high_threshold and
logic_low_threshold parameters of the default pin type block.
All slew values in the output Liberty model will be scaled based on the settings
of these parameters. For example, consider the case where characterization
was performed with logic_high_threshold set to 0.7 and
logic_low_threshold set to 0.3. If slew_derate_upper_threshold is
set to 0.9 and slew_derate_lower_theshold is set to 0.1, the Liberty
attribute slew_derate_from_library will be computed as (0.7 - 0.3) /
(0.9 - 0.1) = 0.5. A slew rate measured as 0.6ns measured from 30% to 70%
will be scaled as 0.6 / slew_derate_from_library = 0.6 / 0.5 = 1.2ns. This
is the value that will appear in the generated .lib file.

Generic Slew Derating

SiliconSmart supports slew derating. Two parameters that control derating are
included in the configure.tcl file inside the default parameter block. The
parameters are slew_derate_upper_threshold and
slew_derate_lower_threshold. These parameters calculate the slew
derate factor based on the characterization thresholds as specified by the
logic_high_threshold and logic_low_threshold of the default pin
type block.
■
slew_derate_upper_threshold — this parameter specifies the upper
threshold value for slew derating. The value of this parameter should be
between 0.0 and 1.0. The default value of this parameter is 0.8.
■
slew_derate_lower_threshold — this parameter specifies the lower
threshold value for slew derating. The value of this parameter should be
between 0.0 and 1.0. The default value of this parameter is 0.2.

SiliconSmart ACE User Guide 221

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

Modeling Multi-Bit Cells

The SiliconSmart tool follows the latest Liberty syntax guidelines for modeling
multi-bit cells. The supported structures and the Liberty syntax requirements
are given in the table below.

Multi-Bit Cell Type Liberty Syntax

Parallel scan bits without a dedicated scan-out bus ff_bank

Parallel scan bits with a dedicated scan-out bus statetable

Serial scan chain with a dedicated scan-out pin statetable

Serial scan chain without a dedicated scan-out pin statetable

Refer to the Library Compiler User Guide for detailed examples of Liberty
format for different multi-bit flip-flop structures.

Note: The SiliconSmart tool does not support bus syntax for multi-bit
cells.

For multi-bit cells with scan, the test_cell group must be defined in the
Liberty model. Follow the same rules given for test_cell modeling as
detailed in Generating a test_cell.

Additional Modeling Parameters for Scan

Given below are additional (optional) modeling parameters related to multi-bit
flip-flop modeling. These parameters share the same names as the Liberty
attributes and are specific to multi-bit flip-flops with scan. They are defined

222 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

under the cell scope. These parameters specify these attributes intended for
the final library of the dedicated cell:
■ single_bit_degenerate — this parameter defines a corresponding
layout-related attribute in Liberty syntax. It defines a name of a single-bit
library cell for use on multi-bit bundle cells that are black boxes. This allows
synthesis and implementation tools to perform mapping from the single-bit
cell to the multi-bit cell.
■
scan_start_pin — this parameter defines a corresponding attribute in
Liberty syntax. It specifies the scan output pin of a sequential element of the
multi-bit scan cell, where the internal scan chain begins. It is defined in the
bus or bundle group.

Adding Attributes to Models

This section describes how to add attributes to models at the various levels
available:
■
Adding Library-Level Attributes
■
Adding Cell-Level Attributes
■
Adding Pin-Level Attributes
■
Adding User-Defined Attributes
■
Liberty Model Post-Processing

Adding Library-Level Attributes

Library-level attributes apply to the content of the entire library. Examples of
such attributes are units, default values, and so on. To add these attributes to a
model prior to its generation by SiliconSmart, define the desired parameters in
the parameter block liberty_model. Each parameter defined in this
parameter block will be copied into the header of the Liberty model.
For example, to add the Liberty attribute default_fanout_load with value
1.0, add the following line to the liberty_model parameter block definition in
configure.tcl:
Example 154
set default_fanout_load 1.0

SiliconSmart ACE User Guide 223

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

The following example is a Liberty parameter block definition in configure.tcl:

Example 155
# parameter block ‘liberty_model’section of configure.tcl
define_parameters liberty_model {
set delay_model "table_lookup"
set default_fanout_load 1.0
set default_inout_pin_cap 1.0
set default_input_pin_cap 1.0
set default_output_pin_cap 0.0
set default_cell_leakage_power 0.0
set slew_lower_threshold_pct_rise 20.0
set slew_lower_threshold_pct_fall 20.0
set slew_upper_threshold_pct_rise 80.0
}

Attributes for the various units must be set so the library model results are
properly scaled (as required by the applications that use the models). For
example, the voltage unit must equal the current unit multiplied by the pulling
resistance unit. SiliconSmart allows you to set the time, capacitance, and
resistance units and derives the other units as appropriate.
The default values for each of the unit attributes are as follows:
Example 156
time_unit 1ns
voltage_unit 1V
current_unit 1mA
leakage_power_unit 1uW
capacitive_load_unit 1pf
pulling_resistance_unit 1ohm

Most of these unit attributes can be set in the default block of configure.tcl
with the corresponding SiliconSmart parameters, as shown below. The values
for these parameters are case-sensitive.
set liberty_time_unit 1ps|10ps|100ps|1ns
set liberty_cap_unit 1ff|10ff|100ff|1pf|10pf|100pf
set liberty_resistance_unit 1ohm|1kohm|1mohm

Adding Cell-Level Attributes

To add cell-level Liberty attributes to a cell model prior to generation by
SiliconSmart, create a parameter block with the same name as the cell.
For example, to add the Liberty attribute area, with value 1.54 for cell mybuf,
add the following line to the parameter block mybuff in the mybuf.inst file:

224 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

This line would appear as follows in the definition in mybuf.inst:

Example 157
# section of mybuf.inst
define_parameters mybuf {
set_liberty_attribute –cell mybuf area 1.54
}

SiliconSmart supports a special parameter named

liberty_blackbox_model that can be set as a cell-level attribute. If this
parameter is set to 1 then the cell model will be produced with no functional
description. This is often necessary when modeling particularly complex cells
with behaviors beyond the scope of what can be described in a Liberty model.

Adding Pin-Level Attributes

To add pin-level Liberty attributes to a cell model prior to generation by
SiliconSmart, define the parameter block liberty_model within the pin type
definition (in configure.tcl) for that pin.
For example, to add Liberty attribute is_pad with value true, add a set
command to the liberty_model parameter block definition under the
appropriate pin type in configure.tcl as shown in the following example:
Example 158
# section of configure.tcl
pintype pad -> default {
define_parameters liberty_model {
set is_pad true
}
}

Only those attributes that are supported by the Liberty format actually appears
in the model. Others are ignored.

Adding User-Defined Attributes

In addition to characterization data, contents of the Liberty model also include
various attributes that you have added to the configuration and instance files
(configure.tcl and cellname.inst, respectively). Although these attributes are
meaningless to SiliconSmart, they are included in the generated model for
purposes required by your applications.

SiliconSmart ACE User Guide 225

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

Liberty Model Post-Processing

It is possible to post-process the whole Liberty at once, or post-process the
Liberty on a per-cell level in a distributed mode along with modeling by using
the parameter liberty_cell_postprocess.
See Also
■
Parameter: liberty_cell_postprocess

HDL Model Generation

SiliconSmart supports the generation of Verilog timing and behavioral models
for standard cells. These HDL models are composed of three file components:
■
*_udp.v
This file contains the behavior description of the cell as derived from the
functional representation of the cell specified in the cell instance file. If the
function is described through the use of simple add_function statements,
the Verilog model will use generic and/or/not primitives. For descriptions
using add_flop or add_latch, the Verilog model will be in the form of
UDP tables that SiliconSmart generates internally. For table-based
descriptions using add_table, the Verilog model will use UDP state tables
(sequential cells) or UDP truth tables (combinational cells).
■
*.v
This file contains the specify block that describes the behavior of the timing
arcs. The timing constructs specified are combinational arcs (including
conditional arc instances), sequential and non-unate arcs, constraint arcs
such as setup/hold/recovery/removal, minimum pulse width and minimum
period instances. These constructs are inferred directly from the
accompanying Liberty model that is generated in conjunction with the HDL
model. When conditional arcs are present, the conditions are the same as
the standard delay format (SDF) conditions in the matching Liberty model to
support easy back annotation of timing results.
■
*_test.v
This file contains the testbench that can be used to exercise the functional
HDL model to verify functional correctness. This testbench is formulated by
concatenating the various stimuli used to generate the timing and constraint
arcs during configuration.

226 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

Generating an HDL Model

To generate an HDL model, you need to attach a –verilog tag to the model
command. For instance:

Example 159
model –verilog –output tag cells

This will produce the tag.v, tag_udp.v and tag_test.v files in the models/verilog/
directory. Note that internally, SiliconSmart also constructs a simple timing-only
Liberty model prior to generating the Verilog files. The timing constructs in the
specify block of the Verilog file are then directly derived from this timing model.
As a result, the preceding model command will also produce a tag_pvt.lib
Liberty model in the models/liberty/ directory.

Calibrating the Output Verilog Model

SiliconSmart provides a number of parameters to tune the Verilog output model
format:
■
Unit Delay
■
Constraint Constructs
■
Support for Multiple SDF Versions
■
Notifier
■
Combine function/timing Blocks
■
User-Specified Verilog Models

Unit Delay
A Boolean parameter verilog_unit_delay controls if the unit delay model
is produced. This unit delay model is particularly useful in a back annotation
flow. The parameters verilog_default_combinational_delay,
verilog_default_sequential_delay and
verilog_default_constraint_delay determine the default delay to be
used for combinational, sequential and constraint arcs when the unit delay
model is used.

Constraint Constructs
The Boolean parameters verilog_use_setuphold and
verilog_use_recrem determine if setup/hold and recovery/removal
constructs are modeled as a single construct. The Boolean parameter

SiliconSmart ACE User Guide 227

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

verilog_model_removal_as_hold produces hold instead of removal

constructs.

Support for Multiple SDF Versions

Removal constructs are recent additions to the SDF format. To comply with the
older SDF version 2.1, we need to set verilog_model_removal_as_hold
to true and verilog_model_use_recrem to false. For the newer SDF
version 3.0, the usage of removal constructs is permitted.

Notifier
When the Boolean parameter verilog_model_notifier is set to true, a
notifier column is added to the UDP tables generated for a generic flop or a
latch. The name of the notifier column can be specified using the
verilog_notifier_name parameter.

Combine function/timing Blocks

By setting the Boolean parameter
verilog_combine_function_timing_blocks to true, the function
definition in the *_udp.v file can be transferred to the *.v file containing the
timing/specify blocks.

User-Specified Verilog Models

Although SiliconSmart does not support a standard recharacterization flow for
the Verilog models, it is still possible to apply the user-supplied Verilog
information to the output Verilog model. If the parameter verilog_udp_file
is set to point to a user-supplied behavioral description file, SiliconSmart will
not rely on the instance file information and instead directly use that file’s
contents when producing the *_udp.v file. If the parameter
verilog_functional_file is set to point to a user-supplied timing
information file, SiliconSmart will parse that file for the specify/endspecify
tags and insert the appropriate timing constructs in that portion of the file.

Generating a test_cell
Typically, the scan version of a flop/latch is identified by linking it appropriately
with its corresponding non-scan version. The Liberty model for scan cells will
contain an additional test_cell group. The Verilog model for scan cells will

228 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
Generating Models

contain an additional scan_definition group if ATPG syntax is requested

using the parameter verilog_atpg_syntax.
The SiliconSmart will automatically generate these test_cell groups in the
Liberty model for scan cells. For a given library, the scan cells are identified by
correctly specifying the corresponding non_scan_model parameters. The
scan_input, scan_enable, and scan_output parameters must be
specified.
Example 160
set_config_opt -cell SDFF non_scan_model DFF

The test_cell group will contain all pins of the parent cell, with the scan pins
containing an additional signal_type attribute. The next_state attribute in
the ff group of the test_cell group is evaluated by disabling the
scan_enable pin in the next_state attribute in the ff group of the parent
cell.
To produce the test_scan_out_inverted attribute in test_cell groups
for scan flops/latches, specify the scan_output_inverted parameter.

Note: If the non-scan cell does not exist in the given library, then the
user needs to provide a non-empty string as a placeholder for the
non_scan_model parameter.

SiliconSmart ACE User Guide 229

L-2016.03
Chapter 5: Characterizing and Modeling
Generating Models

The following example shows how to generate a test_cell when the non-
scan cell does not exist in the given library:
Example 161 Generating test_cell when non-scan model does not exist
add_pin CK clockpin -clock
add_pin R default -input
add_pin SE default -input
add_pin SI default -input
add_pin Q0 default -output
add_pin Q1 default -output
add_pin D0 default -input
add_pin D1 default -input

##
## Cell function definition.
##
add_flop IQ0 IQN0 CK {(!SE&D0)|(SE&SI)} -clear R

add_flop IQ1 IQN1 CK {(!SE&D1)|(SE&IQ0)} -clear R

add_function Q0 IQ0
add_function Q1 IQ1
# bundle setup
set_config_opt model_bundle_bit_level 1
set_pins_to_bundle_map -pins {Q0 Q1} -bundle Q
set_pins_to_bundle_map -pins {IQ0 IQ1} -bundle IQ
set_pins_to_bundle_map -pins {IQN0 IQN1} -bundle IQN
set_pins_to_bundle_map -pins {D0 D1} -bundle D
#test_cell setup
set_config_opt non_scan_model _CELL_NOT_EXIST_
set_config_opt scan_input SI
set_config_opt scan_enable SE
set_config_opt scan_output Q

The following examples uses the SiliconSmart tool’s built-in command

add_liberty_group to add the test_cell construct. You can define
test_cell from command-line or from a run script, without altering the cell
instance file.
Example 162 Generating test_cell without editing the cell instance file
set tc "ff(IQ,IQN) { clock : C; next_state : D; } \
pin(C) { clock : true; direction:input; } \
pin(D) { direction:input; } \
pin(Q) { direction: output; function : IQ; }"
add_liberty_group -explicit -cell cell test_cell "\"$tc\""

230 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
The Distributed Processing Engine

The Distributed Processing Engine

SiliconSmart includes a distributed processing engine capable of handling a
very large number of sometimes interdependent tasks, and efficiently
distributing the jobs across a farm of computer resources. Each task is a single,
indivisible operation such as a single simulation (or set of related simulations)
or model generation for a single cell.
The following sections describe the distributed processing engine:
■ Methodology
■
Debugging Distributed Jobs
■
Adaptive Job Manager For all Distributed Process Tasks

Methodology
When a distributed process step starts, SiliconSmart starts up a set of
characterization engines via your chosen load sharing system - Sun GRID,
RTDA's NetworkComputer (NC), or LSF. The number of characterization
engines to be started is controlled via the run_list_maxsize parameter,
which specifies the maximum number of CPUs to use for a given task.
SiliconSmart submits each of these as a separate job to LSF, NC, or Grid, or, if
run in standalone mode, starts it as a separate process.
Each characterization engine process connects back to the original
SiliconSmart process via a socket to request tasks to run. As a characterization
engine completes a task, the results are posted back to the client and
additional work is requested. This system allows SiliconSmart to dynamically
balance the load across as many CPUs as are available and across CPUs of
different processing speeds.
As the distributed processing engine runs, it reports the percentage of tasks
that have completed. SiliconSmart schedules the largest cells and the slowest
measurements first (for example, setup measurements before simple delay
measurements) to help keep the load balanced until the very end of the run to
maximize throughput. This means that the first 50% of the characterization run
requires more time than the last 50% because the hardest jobs are done first.
The characterization engines run for the complete duration of the given
command until there are no more tasks to run. When working with a shared
compute farm, it can be desirable to have the characterization engine

SiliconSmart ACE User Guide 231

L-2016.03
Chapter 5: Characterizing and Modeling
The Distributed Processing Engine

processes stop and restart in order to allow other uses access to the same
CPU slot. This feature is supported via the cdpl_worker_timeout
parameter, which specifies a maximum runtime in minutes for each
characterization engine.
The parameter scheduler_poll_time controls the SiliconSmart status
update mechanism. It is the number of seconds SiliconSmart waits between
polling the load sharing system for job status. The time difference between two
status updates for SiliconSmart during characterization is at least the value of
scheduler_poll_time and the percentage difference should be at least 2
percent.
As the processing continues, SiliconSmart updates the percentage complete in
increments of 2%. The 2% increments keep the logs from filling up with status
messages, but it does mean that the time between messages can be 15
minutes or more for long characterization runs, especially at the start of a run.
One way to verify whether everything is running correctly is to use the LSF
bjobs or GRID qstat commands to verify whether the characterization
engines have been submitted correctly and whether they have started running.

232 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
The Distributed Processing Engine

An example display from a characterization run is as follows.

Example 163
Info: Wed Feb 26 10:35:02 PST 2014 : running characterize...
Info: ======================================================
Info: Wed Feb 26 10:35:02 PST 2014: Begin characterize stage
Info: Simulator used is hspice I-2013.12-1
Info: Simulator command is /global/apps5/hspice_2013.12-1/
hspice/bin/hspice
Info: Optimizing cell order for efficiency...
Info: Checking templates...
Info: Loading information for 4209 cells...
Info: Start generating characterization tasks. ...
Info: Generated 131422 tasks. Bundling tasks into jobs and
submitting...
Info: Characterization starting, distributing work via adaptive
job manager...
Info: Using 64 lsf slots with options { benchmark -R
"rusage[mem=1000]" }
Info: [CDPL] Total: 131422, Scheduled: 27932, Pending: 26052,
Running: 63, Done: 1817 (1.4%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 33257, Pending: 30830,
Running: 63, Done: 2364 (1.8%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 40987, Pending: 38038,
Running: 63, Done: 2886 (2.2%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 46870, Pending: 43375,
Running: 63, Done: 3432 (2.6%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 51426, Pending: 47385,
Running: 63, Done: 3978 (3.0%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 53217, Pending: 48857,
Running: 63, Done: 4297 (3.3%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 53503, Pending: 49001,
Running: 63, Done: 4439 (3.4%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 53756, Pending: 49132,
Running: 63, Done: 4561 (3.5%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 53789, Pending: 49093,
Running: 63, Done: 4633 (3.5%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 54075, Pending: 49249,
Running: 63, Done: 4763 (3.6%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 54075, Pending: 49214,
Running: 63, Done: 4798 (3.7%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 54301, Pending: 49340,
Running: 63, Done: 4898 (3.7%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 54361, Pending: 49325,
Running: 63, Done: 4973 (3.8%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 55302, Pending: 50039,
Running: 63, Done: 5200 (4.0%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 57172, Pending: 51521,
Running: 63, Done: 5588 (4.3%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 59050, Pending: 53011,

SiliconSmart ACE User Guide 233

L-2016.03
Chapter 5: Characterizing and Modeling
The Distributed Processing Engine

Running: 63, Done: 5976 (4.5%) | Failed: 0, Cached: 0

Info: [CDPL] Total: 131422, Scheduled: 60934, Pending: 54487,
Running: 63, Done: 6384 (4.9%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 62165, Pending: 55397,
Running: 63, Done: 6705 (5.1%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 62177, Pending: 55314,
Running: 63, Done: 6800 (5.2%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 62461, Pending: 55474,
Running: 63, Done: 6924 (5.3%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 62743, Pending: 55631,
Running: 63, Done: 7049 (5.4%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 62747, Pending: 55567,
Running: 63, Done: 7117 (5.4%) | Failed: 0, Cached: 0
Info: [CDPL] Total: 131422, Scheduled: 63033, Pending: 55733,
Running: 63, Done: 7237 (5.5%) | Failed: 0, Cached: 0

RSH Support for CDPL

Use the cdpl_host_file parameter to submit jobs to user-specified remote
machines with the rsh command:
Example 164
set_config_opt job_scheduler custom
set_config_opt cdpl_hosts_file hspice64core.cfg

where hspice64core.cfg has:

1| hspice64core1 | 64 | /tmp| RSH | rsh
1| hspice64core2 | 64 | /tmp| RSH | rsh
flag|hostname|slots|tmpDir|protocol|command

The above example specifies a 128 worker, 2 node configuration for a

distributed processing run.

Debugging Distributed Jobs

To help you debug distributed jobs, SiliconSmart keeps logs from each job. The
log files can be found in the following directories:
■
For characterization: char_dir/runtime/cdpl
■
For modeling: char_dir/runtime/cdpl

234 SiliconSmart ACE User Guide

L-2016.03
 Chapter 5: Characterizing and Modeling
The Distributed Processing Engine

Adaptive Job Manager For all Distributed Process

Tasks
The adaptive job manager is a job distribution engine in SiliconSmart that
reduces characterization time by evenly distributing the work while also
reducing the load on your load sharing system (LSF, Grid, NC). This job
manager is automatically invoked. This job scheduler does not impact the
accuracy of the results in any way. It makes more efficient use of the compute
farm resources and reduces overhead.
The adaptive job manager works by submitting one characterization engine job
for each CPU that is to be used in the CPU farm. That is, if you want to use 50
CPUs (parameter run_list_maxsize set to 50), SiliconSmart only submits
50 jobs to LSF, Grid, or NC. Each of these characterization engines connect
back to the user interface process via a socket to request work and post results
from completed tasks. This setup allows the adaptive job manager to
dynamically allocate work to CPUs and thus adjust for faster or slower CPUs
and handle the case where not all of the requested CPUs are immediately
available.
Each of the characterization engine tasks can be set to run for the entire
duration of the characterization run. This places the minimal load on the load
sharing system because new jobs do not need to be resubmitted and the
startup overhead is kept to a minimum, but also means that other users’ jobs
will not be given a slot until the entire run is complete.

SiliconSmart ACE User Guide 235

L-2016.03
Chapter 5: Characterizing and Modeling
The Distributed Processing Engine

236 SiliconSmart ACE User Guide

L-2016.03
 6
6

Memory Characterization

This chapter describes the methods for characterizing memory components

such as RAMs, ROMs, and register files.

SiliconSmart memory characterization allows you to characterize both

embedded and compiler-generated memories to the SiliconSmart tool.
The setup for memory characterization is similar to standard cell
characterization but requires a slightly different input format. This chapter
describes the bus input format and interface memory description as well as a
variety of example characterization flows.
For information on commands, refer to Memory Commands.
The following sections will guide you through SiliconSmart memory
characterization:
■ SiliconSmart Memory Support
■
Memory Characterization Data Flow
• Recommended Memory Characterization Flows
• Importing
• Creating the Template File
• Configuring
• Defining the Interface
• Finding Internal Nodes for Constraints
■
Memory Characterization Optimizations
■ Liberty Output
■
Path Based Constraint Support for Memories

SiliconSmart ACE User Guide 237

L-2016.03
Chapter 6: Memory Characterization
SiliconSmart Memory Support

SiliconSmart Memory Support

In comparison to standard cells, memories are large, complex structures that
must be characterized using a sophisticated divide and conquer approach.
While characterizing a large memory, block-level simulation is very inefficient
because it requires the processing of vast amounts of data points for even
moderately sized memories.
Memory characterization can be run with a fully extracted SPICE netlist, or by
using a hierarchical netlist with back-annotation flow of FineSim where the
parasitics are back-annotated in the netlist by FineSim.
SiliconSmart supports the characterization of embedded and compiler-
generated memories such as single and multi-port SRAMs, register files, and
ROMs. This capability is focused on recharacterizing such memories to
produce updated models at new process/voltage/temperature points, more
accurate timing and power models, or additional modeling formats not
supported by the compiler.
SiliconSmart supports characterizing standard fundamental timing
measurements, NLDM timing, CCS-noise, CCS-timing, CCS-power, and power
models. Fundamental timing refers to the following common set of timing
measurements: delay, clock-to output, tri-state enable measurements, and
setup, hold, recover, and removal constraints. It does not support
characterizing architecture-specific constraints.

Supported Simulators
Only the FineSim and FineSim Embedded simulators are supported for
SiliconSmart memory characterization.

Memory Characterization Data Flow

A full functional description of the memory requires the analysis of an
enormous number of potential states. To avoid this problem of significant data
expansion, the SiliconSmart tool uses a template-based flow to describe the
functionality of memory. The template-based flow imports a template.tcl file as
the input file which contains the functional behavior of the memory (a memory
datasheet is required to create the template.tcl file).

238 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Memory Characterization Data Flow

Note: See the Template File Examples section for more detailed
information on what is contained in a template file.

The below figure shows the SiliconSmart memory characterization data flow:

Figure 22 Basic Memory Characterization Data Flow

SiliconSmart ACE User Guide 239

L-2016.03
Chapter 6: Memory Characterization
Memory Characterization Data Flow

Recommended Memory Characterization Flows

The following sections describe recommended memory characterization flows:
■
Basic Memory Characterization Flow — This template-based flow will
create a new Liberty model and should be used for memories where there
is no existing Liberty model.
■
Memory Recharacterization Flow — This template-based flow requires an
existing Liberty model, and should be used whenever possible. This flow
ensures that the basic information related to memories (such as input data
and address bus widths) will already be present in the output Liberty model.
■
Incremental CCSN Memory Characterization Flow — This flow requires an
existing Liberty model. It will copy non-CCSN data from the input Liberty and
model CCSN data from the characterized results
■
Memory Characterization through Back-Annotation — This flow uses back-
annotation for memory characterization.

Basic Memory Characterization Flow

The basic memory characterization flow is a template-based flow which
imports a template.tcl file and creates a new Liberty model. This flow should be
used when an existing Liberty model is not available as an input.

Using this Flow

The following steps will guide you through a complete memory setup and
characterization:
1. Before importing, you must have:
• template.tcl — the template file containing functional information of the
memory. See Creating the Template File if you do not have a template
file.
• netlist — you will need to specify either the location of a fully extracted
netlist with parasitics, or both the location of a hierarchical prelayout
netlist and a .spef file for the entire memory.
• process model — set the SPICE model path (usually in configure.tcl).
• simulation setup — set simulator type and simulator options (see
Selecting a Simulator for more information).

240 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Memory Characterization Data Flow

2. Importing — Run the import command, specifying:

• The template file.
• The netlist location.
• The netlist extension.
• The cells to be characterized.
• For example:
import -template template_file -netlist_dir netlist_dir
-extension extension [-overwrite]

3. The following will be created:

• A flattened netlist.
• An instance file containing a state table created from the template file.
• A configure file with pin-type definitions created from the template file.
4. Configuring — Edit the configure.tcl file as necessary (refer to the
configure.tcl Checklist).
5. Defining the Interface — Edit the memory interface descriptions in the
instance file as necessary.
6. Finding Internal Nodes for Constraints — Follow the steps in this section for
information on setting up the template file and the commands used to find
the internal nodes.
7. Validating — Run basic input capacitance and delay arcs to confirm basic
memory functionality.
8. Making state table adjustments — The state table can now be further
adjusted, after confirming basic memory functionality and that the setup is
sanitized and clean.
9. Characterizing and Modeling — Use the following commands to run
characterization on the cells and create the data for the Liberty model.

Using Commands in this Flow

This flow uses the following commands as shown below:
■
import — specify the following:
• The template file.
• The netlist.

SiliconSmart ACE User Guide 241

L-2016.03
Chapter 6: Memory Characterization
Memory Characterization Data Flow

• The cells to be characterized.

■
configure — specify the data to be modeled.
■
characterize — characterize the specified data in the Liberty model.
■
model — specify the data to be modeled for the memory.
An example of this is shown below:
import -template template_file -netlist_dir netlist_dir
-extension extension [-overwrite]
configure -data_to_be_characterized cells
characterize cells
model -data_to_be_modeled cells

Memory Recharacterization Flow

This template-based flow is the recommended memory characterization flow if
you already have an existing Liberty file containing basic memory information.

Using this Flow

This flow follows the Basic Memory Characterization Flow above, with the
following adjustments:
■
Importing — In addition to the required files, you will also need to reference
an existing Liberty model. An example of this is shown below:
import -template template_file -netlist_dir netlist_dir
-extension extension -liberty liberty_file [-overwrite]
■
Configuring and Modeling — When using the configure and model
commands, specify only the data to be added or replaced in the output
Liberty model.

Incremental CCSN Memory Characterization Flow

This flow will incrementally characterize memories and add CCS-noise data to
an existing Liberty model (which contains NLDM, at a minimum). The following
sections describe the setup and usage of this CCS-noise add-on flow:
■
Using this Flow
■ Using Commands in this Flow
■
Excluding Generation of CCSN Models

242 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Memory Characterization Data Flow

■
Generating Single CCBs
■
Example Run Script for CCS-Noise Add-On Flow

Using this Flow

The following sections describe requirements for the CCS-noise add-on flow:
■
Required Inputs
■
Required Settings
■
Identifying a Cell as a Memory
■
Using Standalone Mode for Debugging

Required Inputs
This flow requires the following inputs:
■
SPICE netlist and corresponding process models
■
Reference Liberty model (to which CCS noise data is to be added)

Required Settings
The following can be set in either configure.tcl or in the flow file run.tcl:
■
Specify device model names — while configuring for CCSN, the
SiliconSmart tool partitions the cell netlist to generate CCBs, which requires
N-type and P-type transistor model names used in the cell spice netlist to be
specified using the nmos_model_names and pmos_model_names.
Additionally, the following parameters support resistor, capacitor and diode
SPICE sub-circuit wrappers (X-instance calls) in the SPICE netlist:
res_model_names, cap_model_names, dio_model_names.
Please see Example Run Script for CCS-Noise Add-On Flow for example
definitions of the above.
■
Specify simulator and simulator options — define the simulator-related
parameter settings (simulator, simulator_options,
simulator_cmd). Note that only FineSim or FineSim-Embedded are
supported for memory instances.
Note: The MACMOD=1 option for simulator options is needed if the
SPICE process models have sub-circuit definitions for the
NMOS or PMOS transistor models.

SiliconSmart ACE User Guide 243

L-2016.03
Chapter 6: Memory Characterization
Memory Characterization Data Flow

Identifying a Cell as a Memory

A memory Liberty model typically contains several memory related attributes/
constructs, as shown below. These groups identify the cell as a memory.
At cell-level:
memory() {
type : …
}

At bus-level:
memory_read() {
…
}

memory_write() {
…
}

If the imported .lib does not have any of the above statements, you should set
the parameter sis_cell_type_memory to 1 before the import command in
the run script to identify the cell as a memory.

Using Standalone Mode for Debugging

One of the most important steps in this flow is configure, as that step
identifies CCBs and performs cell partitioning for CCSN characterization.
While creating the flow and running the memory for the first time, it is
recommended to run both import and configure in standalone mode locally
on your machine. This can be done by setting job_scheduler=standalone
and run_list_maxsize=1. With this, the SiliconSmart tool will print out all
warnings/errors encountered in the siliconsmart.log file, which allows for easy
parsing and debugging.
These warnings may also provide information if any of the device model names
have been missed from the *_model_name parameter settings. It is important
to then define them in your flow/setup.

244 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Memory Characterization Data Flow

Using Commands in this Flow

Using the CCS-noise add-on flow with an existing library is similar to the
Recharacterization Flow, with the following distinctions for memory:
■
import — it is recommended to use a template file with the –template
switch. The cell functional description is not needed for CCSN, but the
template file helps to identify and create pintypes.
It is also recommended to use the –use_default_whens switch with
import to skip the arc-based processing as memory cells will have no arc-
based CCBs (for faster import of the reference Liberty).
■
configure — invoke this command with -ccs_noise only. it is not
necessary to configure for –timing as a memory is a complex multi-stage
circuit with only pin-based CCBs.
■
characterize — this step does not need to specify any –match regular
expressions, as only –ccs_noise is configured and only CCSN arcs will be
characterized automatically.
■
model — invoke this command with -ccs_noise only. All other constructs
(NLDM, NLPM, CCST) will be copied as is from the reference Liberty into
the new one and the CCSN constructs will be added as per the current
characterization.

Excluding Generation of CCSN Models

You can exclude generation of CCSN models for certain pins of the memory
cell (if necessary) by using the parameter ccsn_exclude_pin as below:
set_config_opt –cell $cell ccsn_exclude_pin {LEGACY CONST
IRRELEVANT}

Generating Single CCBs

You can generate a single CCB for each input and output pin by using the
parameter ccb_single_fanout, detailed in Generating Single CCBs for
Input and Output Pins.

SiliconSmart ACE User Guide 245

L-2016.03
Chapter 6: Memory Characterization
Memory Characterization Data Flow

Example Run Script for CCS-Noise Add-On Flow

The following shows a complete run.tcl flow file for CCS-noise add-on flow:
set cell {memory_cell_name}

#Create a char directory and perform set_location on it.

set charpt chp

create $charpt
set_log_file $charpt/sis.log
file copy configure.tcl $charpt/config/configure.tcl
set_location $charpt

#Add any custom settings for this run. These can be directly added
#to the configure.tcl as well.

set_config_opt simulator finesim_embedded

set_config_opt simulator_options {
“common, finesim: finesim_mode=spicexd, MACMOD=1”
}
set_config_opt job_scheduler grid
set_config_opt run_list_maxsize 50
set_config_opt normal_queue {-P bnormal}

#CCSN CCB partitioning process requires the device models used

#in the netlists to be defined.

set_config_opt nmos_model_names {NMOS NFET NCH}

set_config_opt pmos_model_names {PMOS PFET PCH}
set_config_opt dio_model_names {ndio}
set_config_opt cap_model_names {pcap}
set_config_opt res_model_names {resstar}

#Add any custom CCSN parameters if values need to be changed from

#the default settings.

#In case the Imported Lib does not have any memory based constructs,
#identify that it is in-fact importing a memory cell.

set_parameter sis_cell_type_memory 1

#Import, configure, char, and model as described in flow

import -liberty mem_nldm.lib –template mem_template.tcl

-netlist_dir netlists/ -extension .dspf –use_default_whens $cell
configure -ccs_noise $cell
characterize $cell
model -ccs_noise -output with_CCSN $cell

246 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Memory Characterization Data Flow

Enabling Donut-Style Memory Netlists for CCS-Noise

Set the parameter memory_ccsn_partial_netlist to 1 to enable support
of memory cells with donut style netlists for CCS-noise characterization.

SiliconSmart ACE User Guide 247

L-2016.03
Chapter 6: Memory Characterization
Importing

Importing
Use the import command to import the template file, netlist directory,
extension of the netlist, and (optionally) a Liberty file. The state table will always
be generated automatically during the import step.
The following figure shows the files necessary for the import step and the files
that will be created as a result.

To import files for memory characterization:

Example 165 Without Referencing the Liberty File
import -template template_file -netlist_dir netlist_dir
-extension extension [-overwrite]

Example 166 Referencing the Liberty File (Recharacterization)

import -template template_file -netlist_dir netlist_dir
-extension extension -liberty liberty_file [-overwrite]

248 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Importing

where:
■
template_file — the template file to be imported.
■
netlist_dir — the netlist directory which contains the netlist to be
imported.
■
extension — the netlist file extension.
■
liberty_file — the liberty file to be imported.
■
[-overwrite] — is an optional switch that, when specified, will overwrite
the existing instance file during the import step.
See Also
■
Creating the Template File
■
configure.tcl File Methodology
■
Instance File Methodology

Creating the Template File

For memory characterization, SiliconSmart needs to know details about the
address bus, data bus, and different control pins associated with the memory in
order to find out the function associated with the memory. This function of the
memory is described in a template file.
The template file contains a sequence of Tcl commands which provide
information about all of the pins/buses that define the function associated with
the memory. The state-table can be generated automatically using a template
file during import.

Template File Commands

Refer to the Memory Commands section for a list of all available memory
commands, which includes the following types:
■
Tcl Memory Commands
■
Functional Mode Commands
■
Test Mode Commands
■
General Memory Commands
■
Scan Chain Commands

SiliconSmart ACE User Guide 249

L-2016.03
Chapter 6: Memory Characterization
Importing

Template File Examples

The following examples describe various template file types:
■
Example Template for Single Port Ram
■
Example Template for Dual-Port Ram
■
Example Template for Single Port Ram with Test, Pipeline, Write Through,
and Extra Margin Adjustment

Example Template for Single Port Ram

This is an example of an synchronous single port SRAM in which independent
read write operation can be performed on the same port.

Figure 23 Example of Single Port RAM Format

In the above figure:

■
CLK is used as the clock for the single port ram.
■
A is the address bus.
■
D is the data bus.
■
Q is the output of the single port ram.
■
CEN is the chip enable.
When CEN is L, then only read or write operation can be performed on the
memory. WEN is used as both read and write enable signals for this memory.
When the value of WEN is H, memory read operation takes place on the
memory. When the value of WEN is L, memory write operation takes place on
the memory.

250 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Importing

Take the following example:

Figure 24 Example Single Port RAM Memory

The template file for the above would be:

Example 167
set_memory_type single_port_ram
set_memory_name RF128x2x4
create_readwrite_port A
set_clock CLK -active r -port A
set_address_bus A -width 9 -port A
set_data_bus D -width 15 -port A
set_read_enable WEN -active H -port A
set_chip_enable CEN -active L -port A
set_data_output Q -width 15 -port A

SiliconSmart ACE User Guide 251

L-2016.03
Chapter 6: Memory Characterization
Importing

The above template file will automatically generate the following state table
during the import step:

CLK CE WE A D : me mem iq : me mem iq

N N m 2 m 2

R L L L L/H : - - - : L/H n -

R L L H L/H : - - - : n L/H -

R L H L - : L/H - - : n n L/H

R L H H - : - L/H - : n n L/H

R H - - - : - - - : n n n

- - - - - : - - - : n n n

Example Template for Dual-Port Ram

This is an example of a dual port ram with read operation taking place at one
port and write operation at the other port. Here, read operation takes place in
port A and write operation takes place in port B.

Figure 25 Example of Dual Port RAM Format

252 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Importing

In the above figure:

■
CLKA is active at the rising edge. CENA has to remain at state L for read
operation to take place on this port.
■
CLKB is active at the rising edge. CENB has to remain at state L for write
operation to take place on this port.
Take the following example:

Figure 26 Example Dual Port RAM

SiliconSmart ACE User Guide 253

L-2016.03
Chapter 6: Memory Characterization
Importing

The template file for the above would be:

Example 168
set_memory_type multi_port_ram
set_memory_name DPSRAM128x2x4
set_bypass_mode OFF
set_pipeline_mode OFF
set_writethrough_mode ON
set_bist_mode OFF
set_extramargin_adjustment_mode OFF
create_readwrite_port A
set_clock CLKA -active r -port A
set_address_bus AA -width 7 -port A
set_data_bus DA -width 2 -port A
set_read_enable WENA -active H -port A
set_write_enable WENA -active L -port A
set_chip_enable CENA -active L -port A
set_data_output QA -width 2 -port A
create_readwrite_port B
set_clock CLKB -active r -port B
set_address_bus AB -width 7 -port B
set_data_bus DB -width 2 -port B
set_read_enable WENB -active H -port B
set_write_enable WENB -active L -port B
set_chip_enable CENB -active L -port B
set_data_output QB -width 2 -port B

254 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Importing

The above template file will automatically generate the following state table
during the import step:

CLK CE A CLK CE DB AB : me me iq : me me iq
A NA A B NB m m2 m m2

- - - r L L/H L : - - - : L/H n -

- - - r L L/H H : - - - : n L/H -

R L L - - - - : L/H - - : n n L/H

R L H - - - - : - L/H - : n n L/H

- - - r H - - : - - - : n n n

R H - - - - - : - - - : n n n

- - - - - - - : - - - : n n n

Example Template for Single Port Ram with Test, Pipeline, Write Through,
and Extra Margin Adjustment
This is an example of a single port ram with independent read write operation.
This memory also supports pipeline mode operation, write through mode
operation, test mode operation and extra margin adjustment mode.
To make all the above mentioned modes operational, the
set_pipeline_mode, set_writethrough_mode, set_bist_mode, and
set_extramargin_adjustment_mode commands have been used.
This memory is capable of operating in both functional mode and test mode.
Functional Mode Signals
The following signals are associated with the port while it operates in functional
mode:
■
CLK is the clock associated with the port.
■
ADR is the address bus and D is the data bus.
■
WE has been used as both read enable and write enable signal.
When the value of WE is L, read operation takes place on the port. When the
value of WE is H, write operation takes place on the port. ME is the memory
enable signal associated with the port. Any read or write operation can take
place through the port only when the value of ME is H.

SiliconSmart ACE User Guide 255

L-2016.03
Chapter 6: Memory Characterization
Importing

The value of BISTE decides whether the memory will operate in functional
mode or in test mode. When the value of BISTE is H, the memory will operate
in test mode. When the value of BISTE is L, the memory will operate in
functional mode. When the value of PIPEME is H the memory operates in
pipeline mode during read operation.
RME is the extra margin adjustment enable pin and RM is the extra margin
adjustment bus. RME and RM do not take part in state table but they are present
in when conditions.
WEM is the maskable write enable associated with the port. When it is in active
high state, part of memory word is written into depending on which bit of WEM
has H value. TCLKE is the test clock enable signal which when high selects the
test mode clock and which when low selects the functional mode clock.
Q is the data output and QP is the pipeline output associated with the port.
Test Mode Signals
The following signals are associated with the port while it operates in test
mode:
■
TCLK is the clock associated with the port.
■
TADR is the address bus and TD is the data bus.
■
TWE has been used as both read enable and write enable signal.
When the value of TWE is L read operation takes place on the port. When the
value of TWE is H write operation takes place on the port. TME is the memory
enable signal associated with the port. Any read or write operation can take
place through the port only when the value of TME is H. When the value of
TPIPEME is H, the memory operates in pipeline mode during write operation.
TWEM is the maskable write enable associated with the port. When it is in active
high state, part of memory word is written into depending on which bit of TWEM
has H value.
Some input pins have also been added through the add_input_pin
command and few of these input pins have been tied to low through the
set_input_pins_tiedto_low command.
These input pins do not affect the function of the memory either in the
functional mode or the test mode but they need to be defined to generate a
complete instance file.

256 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Configuring

The template file for the above would be:

Example 169
set_memory_type single_port_ram
set_memory_name sadslskkb1p512x47m4b2w1c1p1d0r1
set_pipeline_mode ON
set_writethrough_mode ON
set_bist_mode ON
set_extramargin_adjustment_mode ON
create_readwrite_port A
set_clock CLK -active r -port A
set_address_bus ADR -width 9 -port A
set_data_bus D -width 47 -port A
set_read_enable WE -active L -port A
set_write_enable WE -active H -port A
set_memory_enable ME -active H -port A
set_bist_enable BISTE -active H -port A
set_pipelinemode_enable PIPEME -active H -port A
set_extramargin_adjustment_enable RME -active H -port A
set_extramargin_adjustment RM -width 4 -port A
set_maskablewrite_enable WEM -width 47 -active H -port A
set_testclk_enable TCLKE -active H -port A
set_data_output Q -width 47 -port A
set_pipeline_output QP -width 47 -port A

If TestMode is present, the following inputs (in green) must be added:

set_testmode_clock TCLK -active r -port A
set_testmode_address_bus TADR -width 9 -port A
set_testmode_data_bus TD -width 47 -port A
set_testmode_read_enable TWE -active L -port A
set_testmode_write_enable TWE -active H -port A
set_testmode_memory_enable TME -active H -port A
set_testmode_pipelinemode_enable TPIPEME -active H -port A
set_testmode_maskablewrite_enable TWEM -width 47 -active H -port A
set_testmode_data_output Q -width 47 -port A
set_testmode_pipeline_output QP -width 47 -port A

Configuring
The following sections describe the configure.tcl file used for memories:
■
configure.tcl Checklist
■
configure.tcl File Methodology

SiliconSmart ACE User Guide 257

L-2016.03
Chapter 6: Memory Characterization
Configuring

configure.tcl Checklist
You should use the following checklist as a guide to finalize the configure.tcl file:
■
Check that all NMOS and PMOS model names are defined correctly.
■
Check that the SPICE module file path and PVT are defined correctly.
■
Check that all simulator options are defined as required.
■
Check that all supply and ground nodes are defined correctly.
■
Check that all parameter settings in configure.tcl are correct.

configure.tcl File Methodology

While standard cells have single pin input/output ports, memories usually use
bus structures on the input/output interface. Consider an example single port
RAM memory with a 16-bit input bus D, a 16-bit output bus Q, a 10-bit address
signal, A, a 2-bit write-enable bus WEN, a 1-bit enable pin CEN, and a 1-bit clock
signal CLK.

Figure 27 Example Single Port RAM Memory

Figure 28 Pins for Example Single Port RAM Memory

In this example, CLK and CEN are standard single pin input signals and are
therefore defined using the default pin type. Conversely, D, Q, A, and WEN are

258 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Configuring

memory-specific bus signals and therefore they must be defined with

appropriate bus-specific pintypes defined in the configure.tcl file.
Example 170
add_pin D bus_16 –input
add_pin Q bus_16 -output
add_pin A bus_10 –input
add_pin CEN default –input
add_pin WEN bus_2 –input
add_pin CLK default input

The above is the result of the import command taking the template.tcl file as
an input and defining all bus-specific pintype to the configure.tcl file
automatically.
The SiliconSmart tool supports three bus-specific pin type parameters:
■
bus_width — This required attribute specifies the number of bits in the
bus. The default value is 1 for pins and must be greater than 1 for busses.
■
target_bits — This optional attribute specifies a subset of the pins to be
used in delay/power measurements. This attribute recognizes the fact that
for a wide bus of say 64 bits, it is not necessary to probe for measurements
on all the bits; it is sufficient to examine only a select few of those 64 bits to
obtain accurate results. Each target_bit is specified such that it is a non-
negative integer between 0 and (bus_width - 1). If target_bits is not
explicitly specified then, by default, all the bits in the range [0,
(bus_width - 1)] will be considered for characterization. This parameter
is used in conjunction with the bus_width parameter.
■
default_bus_value_i — This optional attribute specifies the set of
default values that should be used for the busses. Here i is a non-negative
integer. The default_bus_value_0 defines the state of each bit in the bus
when the bus is in low (L) state. Therefore the value of
default_bus_value_0 as 0b00000011 means that a value of 0 or L on
the 8-bit bus actually means that the first 6 bits are at 0 and the last 2 bits
are at 1. Similarly, the default_bus_value_1 defines the state of each
bit in the bus when the bus is in high (H) state. Therefore the value of
default_bus_value_1 as 0b11111111 means that a value of 1 or H on
the 8-bit bus actually means that all the 8 bits of the 8-bit bus are at a logical
value 1. By default, the default_bus_value_0 sets all the bits to 0 and
default_bus_value_1 sets all the bits of the bus to 1.
This parameter can be used with the target_bits parameter to perform
specific measurements on a single bit. This parameter is used in conjunction
with the bus_width parameter.

SiliconSmart ACE User Guide 259

L-2016.03
Chapter 6: Memory Characterization
Defining the Interface

These bus definitions are usually defined in the configure.tcl file. For instance,
the following pin type bus definitions must be defined for the previous example
SRAM in configure.tcl:
Example 171
pintype bus_10->default {
set bus_width 8
set target_bits { 0 7 }
set default_bus_value_0 0b00000011
set default_bus_value_1 0b11111111
}

pintype bus_16->default {
set bus_width 16
set target_bits { 0 }
}

pintype bus_2->default {
set bus_width 2
}

As the names indicate, bus_8 refers to 8-bit bus and bus_16 refers to 16-bit
bus. As target_bits is a pin type parameter, it also can be set on a per-arc
basis by using the set_config_opt command.
For example, the following command added to the memory’s instance file sets
the target_bits pin type parameter specifically for the output bus Q, as
follows:
Example 172
set_config_opt –from CLK -to Q –pin Q target_bits {1}

The set_config_opt here defines that for all arcs from CLK to Q, the
measurements will be done on only the target bit 1 of the 16-bit Q bus.
The remaining configuration setup is similar to the standard cell configuration
setup (Refer to Configuring Cells).

Defining the Interface

The following sections describe instance files used for memories:
■
Instance File Methodology
■
Example Instance Files

260 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Defining the Interface

Instance File Methodology

The instance file is generated during the import step and defines the interface
descriptions of the memory. For memory characterization, the interface
description of the cell type must be set as memory and describe the interface
pins with appropriate pin types in the instance file.

Figure 29 Example Single Port RAM Memory

Figure 30 Pins for Example Single Port RAM Memory

The below interface description applies for the above SRAM (this is the same
SRAM mentioned in Figure 27 and Figure 28):
Example 173
set_cell_type memory

#pin descriptions
add_pin D bus_16 –input
add_pin Q bus_16 -output
add_pin A bus_10 –input
add_pin CEN default –input
add_pin WEN bus_2 –input
add_pin CLK default input

In the previous example, CLK and CEN are standard single pin input signals and
are therefore defined using the default pin type. Conversely, D, Q, A and WEN

SiliconSmart ACE User Guide 261

L-2016.03
Chapter 6: Memory Characterization
Defining the Interface

are memory-specific bus signals and therefore they must be defined with
appropriate bus specific pintypes defined in configure.tcl.
The functional description has to be specified in the form of a state table (using
add_table command) and using the add_function command. The state
table essentially contains information of the states of the pins that enable the
memory read, write and disable operations. This is similar to the truth tables to
describe logical function of cells. This is constructed from the functionality
information contained in the memory user guide or the data sheet.
The state-table format is:
Example 174
add_table {
list of input_pins: output_pin (present state) : output_pins
(next state)
input pin values: output pin values (present) : output pin values
(next)
}

The following table describes the single port SRAM with address (A), data (D),
chip enable (CEN) and write enable (WEN) with write through feature enabled.

Figure 31 Example SRAM with Write-Through

Figure 32 Pins for Example SRAM with Write-Through

The functionality of this memory can be described in terms of the following

state-table:

262 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Defining the Interface

Example 175
add table (

CLK WE CE A D : me mem iq : me mem iq

N N m 2 m 2

#write operation

R L L L L/H : - - - : L/H N L/H

R L L H L/H : - - - : N L/H L/H

#read operation

R H L L - : L/H - - : N N L/H

R H L H - : - L/H - : N N L/H

#no-operation

R - H - - : - - - : N N N

~r - L - - : - - - : N N N

}
add_function Q iq
add_pin mem_int default –internal –spice_node
{dummy_internal_node}
add_function mem_int mem

The first two rows of the state-table describe the write operation. The first row
states that when CLK is rising, CEN (chip enable) is low, WEN (write enable) is
low, the data present at address L is written into a memory register mem.
Similarly, the second row states that the data present at address H is written
into a memory register mem2. The two registers mem and mem2 are logical
names given to the memory word locations specified by addresses L (all
address bits are 0) and H (all address bits are ones) respectively.
The next two rows describe the read operation. The third row states that when
CLK is rising, CEN is low, WEN is high, address (A) is L, the contents of the
register mem appear at the output register iq. Similarly, the fourth row states

SiliconSmart ACE User Guide 263

L-2016.03
Chapter 6: Memory Characterization
Defining the Interface

that when the address A is H, the contents of the register mem2 appear at the
output register iq.
The last two rows describe the no-operation or the disabled state of the
memory. The fifth row suggests that when CEN is high, no change takes place
in the memory or at the output. The previous state of the memory is retained.
Similarly, the last two states that if the clock is not rising, no change in the state
of the memory occurs.
The memory register mem is a name given to the memory word when the
address is L (that is, when all address bits are 0). The bit cell of this word
mem_int is associated with an internal SPICE node using the add_pin and
add_function command as follows:
Example 176
add_pin mem_int default –internal –spice_node
{dummy_internal_spice_node} add_function mem_int mem

As Figure 33, shows, the pin mem_int is a logical name given to the bit-cell of
the word mem. This bit-cell of the word mem is actually associated with an
internal SPICE node in the netlist.

Figure 33 mem_int Bit Cell

This internal SPICE node is the storage node of the bit cell that stores the data
written into it.
SiliconSmart performs the constraints measurement either on the internal node
mem_int or at the outputs for different control pins. You must find this internal

264 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Defining the Interface

SPICE node and then substitute this dummy SPICE node name in the instance
file with the actual SPICE node in the following command:
Example 177
add_pin mem_int default –internal –spice_node
{dummy_internal_spice_node}

SiliconSmart can find the internal SPICE node automatically. The method of
finding the internal SPICE node is described in the Finding Internal Nodes for
Constraints section.
The state table can also be generated using template-based flow. For more
information, please refer to the Basic Memory Characterization Flow section.

Example Instance Files

The following examples describe various instance file types:
■
Synchronous 2-port Register File
■
Synchronous 2-port SRAM with Independent Read and Write Operation
■
Synchronous ROM

Synchronous 2-port Register File

Register file access is synchronous and is triggered by the rising edge of a
clock CLKA or CLKB. Input address, input data, and chip enable are latched by
the rising edge of the clock, respecting individual setup and hold times. Each
port of the register file is fully independent. However, read and write at the
same address cannot occur at the same time.
Port A is read-only and port B is write only. The CENA/CENB must be low for a
read operation or write operation to occur at the respective ports.

SiliconSmart ACE User Guide 265

L-2016.03
Chapter 6: Memory Characterization
Defining the Interface

Figure 34 Port A Read-Only; Port B Write Only

The following is the interface and functional description of this memory:

Example 178
set_netlist_file [get_location]/netlists/sram.cdl
set_cell_type memory

Pin definitions:
add_pin CENA default –input
add_pin CENB default -input
add_pin AA bus7 -input
add_pin AB bus7 -input
add_pin DB bus2 -input
add_pin CLKA default -input
add_pin CLKB default -input
add_pin QA bus2 -output

set_subckt_ports { QA_1 QA_0 CLKA CENA AA_6 AA_5 AA_4 AA_3 AA_2
AA_1 AA_0 CLKB CENB AB_6 AB_5 AB_4 AB_3 AB_2 AB_1 AB_0 DB_1 DB_0
VDD VSS }

Cell function definitions:

add_table {

CLK CE AA CLK CE DB AB : me me iq : me me iq
A NA B NB m m2 m m2

- - - r L L/H L : - - - : L/H N -

- - - r L L/H H : - - - : n L/H -

R L L - - - - : L/H - - : n N L/H

R L H - - - - : - L/H - : n N L/H

266 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Defining the Interface

- - - r H - - : - - - : n N n

R H - - - - - : - - - : n N n

- - - - - - - : - - - : n N n

}
add_function QA iq
add_pin mem_int default -internal -spice_node
{xi0_0.xi0_0.xi3_1.xi0_0.nt}
add_function mem_int mem

User-specified characterization and modeling options go below:

...
...

Synchronous 2-port SRAM with Independent Read and Write

Operation
This is an example of a synchronous two-port SRAM with independent read
and write operation on each of the two ports. The pins CA and CB are chip
enable for the respective ports that must be low (L) for the read and write
operation to take place on these ports. The pins WA and WB are the write enable
ports for port A and port B respectively. When WA is low (L), write operation
takes place on that port. When WB is high (H), read operation takes place on
that port. QA and QB are the output buses at each of the port. AA, AB, DA and
DB are address and data buses.
The following describes the interface and the functional description of this
SRAM:
Example 179
set_netlist_file [get_location]/netlists/2PortSRAM.cdl
set_cell_type memory

SiliconSmart ACE User Guide 267

L-2016.03
Chapter 6: Memory Characterization
Defining the Interface

Pin definitions:
add_pin CA default -input
add_pin WA default -input
add_pin CB default -input
add_pin WB default -input
add_pin AA bus7 -input
add_pin AB bus7 -input
add_pin DA bus2 -input
add_pin DB bus2 -input
add_pin CKA default -input
add_pin CKB default -input
add_pin QA bus2 -output
add_pin QB bus2 -output

set_subckt_ports { QA_1 QA_0 QB_1 QB_0 CKA CA WA AA_6 AA_5 AA_4

AA_3 AA_2 AA_1 AA_0 DA_1 DA_0 CKB CB WB AB_6 AB_5 AB_4 AB_3 AB_2
AB_1 AB_0 DB_1 DB_0 VDD VSS

Cell function definitions:

add_table {

C W A D CK C W A D CK : me mem iq iq : me mem iq iqb

A A A A A B B B B B m 2 a b m 2 a

# write on port A

L L L L/ r - - - - - : - - - - : L/H N N N
H

L L H L/ r - - - - - : - - - - : L/H N N N
H

#read on port A

L H L - r - - - - - : L/H - - - : N N L/ N
H

L H H - r - - - - - : - L/H - - : N N L/ N
H

# write on port B

- - - - - L L L L/ r : - - - - : L/H N N N
H

268 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Defining the Interface

- - - - - L L H L/ r : - - - - : N L/H N N
H

#read on port B

- - - - - L H L - r : L/H - - - : N N N L/
H

- - - - - L H H - r : - L/H - - : N N N L/
H

# no-operation

H - - - r - - - - - : - - - - : N N N N

- - - - - H - - - r : - - - - : N N N N

add_pin mem_int default -internal -spice_node {xi10/xi00/xi04/

xi00/xi7_0/bb}
add_function QA iqa
add_function QB iqb
add_function mem_int mem

Synchronous ROM
ROM access is synchronous and is triggered by the rising edge of the clock,
CLK. The address input and chip enable are latched by the rising edge of the
clock, respecting individual setup and hold times. The value of chip enable
must be low (CEN=0) (for a ROM with active low enable signal) for a read
operation to occur. During a read cycle, data on the data output bus Q[n-1:0]
is read from the memory location specified on the address bus A[m-1:0].
The following is the interface and functional description of this cell:
Example 180
set_netlist_file [get_location]/netlists/ROM128x2x8.cdl
set_cell_type memory

SiliconSmart ACE User Guide 269

L-2016.03
Chapter 6: Memory Characterization
Defining the Interface

Pin definitions:
add_pin CEN default -input
add_pin A bus7 -input
add_pin CLK default -clock
add_pin Q bus2 -output
set_subckt_ports { Q_1 Q_0 CLK CEN A_6 A_5 A_4 A_3 A_2 A_1 A_0
VDD VSS }

Cell function definitions:

add_table {

CLK CEN A : iq : iq

R L L : - : L

R L H : - : H

- H - : - : n

- L - : - : n

add_function Q iq

User-specified characterization and modeling options go below:

...
...

270 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Finding Internal Nodes for Constraints

Finding Internal Nodes for Constraints

In memory characterization, the constraints are measured either at the output
or at the internal bit cell of the memory. The following figure shows the steps
involved in finding internal nodes for constraints:

To find internal nodes of memory for constraint measurement:

1. In the template.tcl file, set mem_internal_node to dummy:
set_mem_internal_node dummy

2. Run the import command to get the instance file:

import

The internal node mem_int should be defined in the instance file as follows:
add_pin mem_int default –internal –spice_node dummy

SiliconSmart ACE User Guide 271

L-2016.03
Chapter 6: Memory Characterization
Memory Characterization Optimizations

3. Ensure that all delay arc characterizations are passing with the existing
instance file. If the delay arcs are characterized successfully, then the
functional description in the instance file is correct.
If any of the delay arcs failed, then re-check the functionality of the memory
described in the instance file.
4. When the functionality of the memory described in the instance file passes,
the internal node mem_int should be defined in the instance file as:
add_pin mem_int default –internal –spice_node
{actual_internal_spice_node}

5. Once the setup is done, use find_internal_nodes_for_constraint

to locate the internal SPICE node:
find_internal_nodes_for_constraint -match expression
-mem_int_node dummy_node [-get_word_line_node]

Use the optional -match expression switch while finding the internal
node to reduce the overhead of running for all constraints. For example,
-match setup & hold uses the same nodes. See
find_internal_nodes_for_constraint for more information.
There is another flow where you can first find out the potential candidates for
the internal node and then select a few nodes among them and then test each
of these nodes to find out the correct internal node. This flow is useful if you
either already have some knowledge on the potential candidates for the internal
node or if there are too many internal nodes to test.
See Also
■
Command: find_potential_internal_nodes
■
Command: test_internal_nodes_for_constraint

Memory Characterization Optimizations

In comparison to standard cells, memories are large, complex structures that
may contain millions of transistors and RC nets. Characterizing such a large
memory at transistor level may be very inefficient using the common SPICE
simulators. SiliconSmart memory characterization is tightly integrated with
FineSim Pro, a very fast SPICE simulator. This tight integration of SiliconSmart
with FineSim Pro enables user to run memory characterizations with some
optimizations that can be used to speed up memory characterization to a great

272 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Memory Characterization Optimizations

extent. Please note that these optimizations can only be used with FineSim Pro
or Embedded FineSim Pro and require special ACE memory licenses. The
following are the available memory characterization optimizations that is
supported by SiliconSmart.
The following topics are described in this section:
■
Active Node Based Netlist Pruning
■
Initialization
■
Using Constraint Seeds
■
FineSim Pro Options
■
Memory Characterization through Back-Annotation
■
Limitations with Optimization

Active Node Based Netlist Pruning

The simulation-based netlist pruning seeks to reduce memory characterization
time by pruning the memory netlist via simulation-based node identification.
Simulation-based netlist pruning is based on simulating the full memory in a
low-accuracy setting to identify the switching (active) nodes and then reducing
the netlist size for the high-accuracy simulations.

Note: Pruning is not supported for multi-voltage memory cells.

Memory pruning optimization can be enabled by setting the following:

Example 181
set_parameter enable_memory_pruning 1

When pruning is enabled, SiliconSmart first performs a very fast SPICE run for
each arc to find out the inactive nodes and then based on the switching activity
of the nodes, prunes the original SPICE netlist for that arc. The actual
simulation and the measurements are then performed on the pruned netlist.
The active node based pruning flow can be made to work with either a flat RC
extracted netlist or a hierarchical prelayout netlist that is to be back annotated
with RC parasitics contained in a DSPF file.
This active node based pruning flow will give best results for a memory
characterization flow that uses the schematic level pre-layout netlist to be back-
annotated with the extracted interconnect RC parasitics contained in a DPF/
DSPF file. The flow uses the schematic level netlist (without RC) for pruning

SiliconSmart ACE User Guide 273

L-2016.03
Chapter 6: Memory Characterization
Memory Characterization Optimizations

and then uses the pruned netlist to be back-annotated with the extracted
interconnect RC parasitics contained in a DSPF/SPF file for the actual
simulation for runtime improvement. A runtime improvement of more than 5x
can be obtained with the pruning flow over running the full-flat DSPF netlist.
See Also
■
Command: report_pruning
■
Parameter: internal_power_supply_spice_nets
■
Parameter: internal_ground_supply_spice_nets
■ Parameter: detect_internal_power_nodes_for_pruning
■
Parameter: sis_pruning_with_flat_netlist
■
Parameter: node_activity_tolerance
■
Parameter: node_stability_pruning_threshold

Initialization
For sequential memory cells, it is essential to initialize memory into a known
state before the actual measurements can be taken. SiliconSmart runs
initialization stimuli in separate simulations from the actual transitions under
test. This is implemented using either the .IC SPICE directives to save and
restore the post-stimulus values of circuit nodes, and it is aimed at reducing the
overhead involved in acquiring multiple measurements with the same
initialization stimulus. By sharing the stimulus, these measurements are now
much shorter, and the initialization stimulus is only simulated once, with the
resulting savings in simulation time for the actual measurement done for
several slew/load points. The separate initialization mode is controlled using
the parameters separate_cell_initialization. The parameter
separate_cell_initialization can have values of off, on, and ic (the
default value). A value of off disables separate initialization, and ic enables it
using the selected directive.

Using Constraint Seeds

Characterizing constraints in memory can be very time-consuming as the
SiliconSmart tool uses pass-fail criteria based on bisection method to locate
constraint values. If you have a reference Liberty file which has close enough
constraint values for setup and hold measurements but wants to recharacterize

274 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Memory Characterization Optimizations

those values for more accuracy, you can import the Liberty file with the switch
-use_constraint_seeds. For more details, please refer to the explanation
of the import command.
SiliconSmart can use the imported setup and hold tables as seeds to the setup
and hold measurements for faster characterization and more accurate data.
The constraint_seed_values specifies the default values used for
independent setup and hold constraint acquisitions. The defaults help reduce
the amount of simulation time by providing a good initial guess. This parameter
can be set to a scalar value based on the input transition times of the data and
clock pins. For more details, please see the Constraints section.
When an input .lib is not available, or if the constraint values in the input .lib
cannot be used as seed values (because they are at a different PVT condition),
then constraint_simulated_seed can be used. This parameter uses a
2x2 constraint simulation to determine the initial search range for the full
constraint.

Note: This feature must be used only if you are certain that the
constraint values that are used as seeds are fairly close to the
actual constraint values. This can be useful for cases where a
memory has been characterized for one corner. In such a
scenario, the constraint values for this corner can be used as
seeds for characterizing the constraint arcs for another corner.

FineSim Pro Options

Apart from these optimization features, a significant speedup can also be
achieved by using these FineSim Pro options:
Example 182
finesim_mode=promd
finesim_spred=3

Note: Note that although finesim_spred=3 will provide a speedup,

it is also less accurate.

SiliconSmart ACE User Guide 275

L-2016.03
Chapter 6: Memory Characterization
Memory Characterization Optimizations

Memory Characterization through Back-Annotation

The back-annotation flow using FineSim for memory char is more efficient in
following grounds:
■
Pruning runtime and memory usage.
■
Finding the internal node.
■
General memory usage and runtime in the actual char.
■
Improving accuracy of pruning Vs non-pruning flow.
When used with the import command, the following option uses back-
annotation flow for memory characterization:
Example 183
-dspf_netlist_for_backannotation DSPF_netlist_path

This option can used by itself or with a combination of other options of the
import command.

Note: Back-annotation flow is only supported with the template.tcl file.

The following sections describe the different usage of this characterization:

■
Usage 1
■
Usage 2

Usage 1
import -template template_file –dspf_netlist_for_backannotation
DSPF_netlist_path

In the above case, SiliconSmart will automatically remove the RCs from the
DSPF file and generate a new DPF file.
■ This new DPF file will be used for pruning and finding internal nodes.
■
For actual characterization, the original DSPF file will be back-annotated to
the generated DPF file.
■
If there is a hierarchical netlist, it will be flattened automatically.
■
The FineSim options will be set automatically for the back-annotation flow
for characterization. If the user specifies some specific FineSim options to
use, they will be retained.

276 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Liberty Output

Usage 2
import -template template_file –netlist_dir netlist_dir
-extension ext –dspf_netlist_for_backannotation
DSPF_netlist_path

This command can be used if the user has a hierarchical CDL netlist and an
extracted DSPF netlist that can be back-annotated.
■
The CDL netlist will be specified using the options -netlist_dir and
-extension, similar to any other netlist file.
■
The hierarchical netlist will be flattened automatically.
■
The FineSim options will be set automatically for the back-annotation flow
for characterization. If the user specifies some specific FineSim options to
use, they will be retained.

Limitations with Optimization

Pruning can be used with initialization for flat RC extracted netlist. However,
Pruning cannot be used with initialization directly in a flow that uses the
schematic level pre-layout netlist to be back-annotated with the extracted
interconnect RC parasitics contained in a DPF/DSPF file due to an integration
issue between FineSim and SiliconSmart.
In order to use Pruning with initialization in a flow that uses the hierarchical
netlist with RC-extracted back-annotation, the following needs to be done
before the characterization:
Example 184
set_parameter hierarchy_separator “/”

The SiliconSmart tool will automatically add "*|DIVIDER ^" in the RC-
extracted netlist netlist_name_edited.

Liberty Output
In contrast to standard cells that have independent output ports, memories
consist of buses containing multiple output bits with simulation results that must
be compressed into a single value or a single table. Regardless of the width of
the busses in the memory, the final results in the Liberty model contain only a

SiliconSmart ACE User Guide 277

L-2016.03
Chapter 6: Memory Characterization
Liberty Output

single value or look-up table. Thus, there is a need to convert multiple result
values into a single consolidated result.
This consolidation step for each type of measurement is described below:
■
Delay
■
Power
■
Input Capacitance
■
Setup/Hold
■
CCS Timing
■
Individual Bit Modeling Support
■
Extra-Margin Adjustment Pins in Memories

Delay
Delay measurements are controlled by the library_type switch to the model
command, which is specified as maximum, minimum, or average. For each
PVT/load/slew combination, the multiple look-up tables associated with
target_bit is considered and compressed using a MAX, MIN or AVG
operation. In other words, the appropriate delay value across all the bits is
extracted and stored in a single lookup table.

Power
Power measurements consist of the following two components:
■
CapEnergy — corresponds to the energy expended in charging up the
output capacitances.
■
Energy— corresponds to the energy expended due to the current flowing in
the Vdd supply.
The energy component is identical across all output bits because the Vdd
network is common to all the transistors. Thus it is sufficient to extract Energy
for any one of the target_bits. On the other hand, the CapEnergy
component can be different across output bits because the outputs can be
connected to different output loads. In this case, SiliconSmart performs a SUM
operation and extracts the aggregate CapEnergy across the bits. The
TotalEnergy is then given by the difference of Energy_single_bit -
(SUM) CapEnergy.

278 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Liberty Output

Note: It is more accurate to take the SUM across all output bits instead
of just the target_bits because all outputs contribute to
CapEnergy. However, SiliconSmart currently does not consider
the effect and models only the target_bits.

Input Capacitance
Input capacitance Cin is controlled by the model_pin_cap_calc parameter,
which is specified as max, min, or ave. Correspondingly, SiliconSmart performs
a max, min or ave operation to extract the appropriate Cin value across the
target_bits.

Setup/Hold
For setup/hold, SiliconSmart performs a MAX operation to extract the maximal,
worst-case value across the target_bits.

CCS Timing
SiliconSmart first produces CCS waveform information for all the
target_bits. The worst-case CCS waveform is the one that corresponds to
the output bit with the worst-case delay value for all the target_bits and
then selects the CCS waveform corresponding to the output bit with the worst-
case delay value. Also, be aware of the following underlying assumptions:
■
All drivers of the output bits have the same drive strength.
■
The differences between the parasitics influencing the bits are negligible.
■ There is no single outlier output bit with a delay that is substantially different
from the other bits.

SiliconSmart ACE User Guide 279

L-2016.03
Chapter 6: Memory Characterization
Liberty Output

Individual Bit Modeling Support

The timing and power data for memories is also often modeled at either bus
level or at individual bit level within the bus group. Consider the following
snippet of an example Liberty file:
Example 185
bus(Q) {

bus_type : Q_bus_16_to_0 ;
max_capacitance : 1;

pin(Q[0]) {

timing() {
…
…
}
}
pin(Q[1]} {
timing() {
…
…
}
}
…
…
pin(Q[15]) {

direction: output;
timing() {
…
…
}
}
}

bus(A) {
bus_type : bus_4_to_0;
direction: input ;

timing() {
related_pin : “CLK” ;
when : “!CEB”
timing_type: setup_rising ;

rise_constraint(constraint_template) {

280 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Liberty Output

values(“….”);
}
fall_constraint(constraint_template) {
values(“ ….”);
}
}
}

The previous example shows a Liberty file having bus descriptions of bus Q and
bus A. The bus Q is a 16-bit bus and bus A is a 5-bit bus.
Bus Q has timing information for each bit in a separate pin block. The bus A
however has no pin blocks. In this case, the same timing and power information
applies to the whole bus (that is, to each of the bits of the bus). That means
that the data characterized for the bits of a bus can be modeled at a bus level or
for single/multiple bits in each pin block.
SiliconSmart supports the creation and modeling of characterized data at
individual bit level within the bus group depending on the value of the
liberty_bus_as_pins parameter.
The parameter liberty_bus_as_pins is used by modeler for the creation of
pin groups within the bus groups as specified in the value of this parameter.
The parameter is used as follows:
set_config_opt -pin bus liberty_bus_as_pins
{list_of_bit_or_range}

Example 186
set_config_opt –pin D liberty_bus_as_pins {0:7 8 9 10 11:15}

This means that individual pin groups within the bus group D will be created as
specified (that is, the following pin groups D[0:7], D[8], D[9], D[10],
D[11:15]) will be created within the bus group and data will be modeled
within each of these groups. If characterization is available for pins in the
specified range, the models for the pin range will be generated for the pin-
specific characterization.
The import command automatically creates these set_config_opt
commands for individual bit modeling for buses if the reference Liberty file has
such model format.
Please note that the parameter liberty_bus_as_pins is different from the
existing pin type parameter target_bits. The parameter
liberty_bus_as_pins is intended to be for Liberty modeling only and the
parameter target_bits is meant to be for characterization only. The concept

SiliconSmart ACE User Guide 281

L-2016.03
Chapter 6: Memory Characterization
Liberty Output

is that the model produced does not have to strongly depend on what is
characterized. For instance, a delay may be computed (characterized) for all
bits of a bus, but a model may have only a single number for the bus or for a
couple of sub-busses of the bus (0:7 8:15) for instance.
Example 187
set_config_opt –pin Q target_bits {}
set_config_opt –pin Q liberty_bus_as_pins {0:7 8:15}

Another example would be to measure only a single bit to allow maximal

pruning, but replicate that measurement for all pins individually, because that’s
the kind of model you want.
Example 188
set_config_opt –pin Q target_bits {0}
set_config_opt –pin Q liberty_bus_as_pins {0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15}

In cases, where the list of pins/pin-range specified in target_bits does not

match with the pins/pin-range specified in the liberty_bus_as_pins
parameter (that is, the bits specified for modeling does not match with the data
what we have characterized) the data is modeled for each such bit/bit-range
taking the worst measurement related data for that pin/pin range. So, if you
want to model the timing data for a pin group Q[0:7], we pick up the worst
delay from the characterized data for the bit range 0-7 and that data is modeled
for this pin group. If the characterized data for any bit is not available in this
range, we model the worst delay from all the bits of the entire bus across this
pin range.

Extra-Margin Adjustment Pins in Memories

Sometimes the memory has read-write margin input bus or extra-margin
adjustment pins. These buses program the sense amp differential setting by
adding delays into internal timing pulses. This results in different delays from
CLK to Q as these extra-margin adjustment bus is incremented from say 000 to
111 for a 3-bit extra-margin adjustment bus.
For example, the 3-bit bus say RWMA programs the sense amp is such a
manner that the delay from clock to output increases as the state of this bus
changes from 000 to 111. Thus, 000 is the fastest setting and 111 is slowest
setting. The memory therefore must be characterized for delays from clock to
output for all the possible 8 states of the RWMA bus.

282 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Liberty Output

Currently, SiliconSmart cannot characterize delay arcs from clock to output for
these individual states of the RWMA bus directly due to the limitation of
SiliconSmart being not able to expand the buses into individual bits for different
states during configuration. In order to characterize such arcs, you need to do
some manual intervention after the instance file is created from the import
command.
You need to expand such buses to individual pins using the add_pin
commands in the instance file after the import command. Since the bus in
expanded to individual pin-level in the instance file, it is important to know that
from a SiliconSmart perspective, the original bus is no longer visible.
SiliconSmart now only understands these pins which are essentially the parts
of the same bus. Any references to the original bus in the instance file in
set_config_opt command needs to be replaced with any of these expanded
pin name in the instance file.
Considering the previous example of the 3-bit RWMA bus, the following manual
intervention needs to be done in the instance file.
Replace the following line in the instance file add_pin RWMA bus_3 –input
with the following add_pin commands, as follows:
Example 189
add_pin RWMA_0 default -input
add_pin RWMA_1 default -input
add_pin RWMA_2 default –input

This essentially expands the bus RWMA into individual pins RWMA[0], RWMA[1]
and RWMA[2]. Since the original bus is no longer visible, any references to the
original bus in the instance file in any set_config_opt command where
explicit slews and loads are defined for that pin needs to be replaced with any
of these expanded pin name in the instance file.
For example, the following command:
Example 190
set_config_opt –from RWMA –ref CLK state_partitions one

if present, should be replaced by the following line in the instance file:

Example 191
set_config_opt –from RWMA_0 –ref CLK state_partitions one

Because the bus is expanded explicitly to individual pins in the instance file, the
measurements are also done on these pins separately (like setup and hold

SiliconSmart ACE User Guide 283

L-2016.03
Chapter 6: Memory Characterization
Path Based Constraint Support for Memories

measurements between this pin and clock). However, the characterization

results done on these pins are usually modeled at the bus-level.
To make sure that the measurements done on these pins separately are
modeled at bus-level, the following command needs to be mentioned in the
instance file:
Example 192
set_pins_to_bus_map -pins { RWMA_0 RWMA_1 RWMA_2} -bus RWMA

The command set_pins_to_bus_map is used to tell the modeler that all the
individual pins specified by the -pins switch are the part of the same bus
specified by the -bus switch. For example, in the previous command, it means
that the individual pins RWMA_0 , RWMA_1, and RWMA_2 are all part of the same
bus RWMA and any measurement done with respect to these pins should be
modeled at bus-level RWMA.

Path Based Constraint Support for Memories

SiliconSmart supports the measurement of path based setup/hold constraints
for memories. There are two types: user-defined nodes and auto-generated
nodes.
The following topics are described in this section:
■
User-Defined Node
■
Auto-Generated Node

User-Defined Node
Path-based constraints are the measurements of path based setup/hold
constraints for memories. The nodes to be used for path delay measurement
will be provided by the user. There will be one data node and one clock node
specified for setup measurement. Similarly, one data node and one clock node
will be specified for hold measurement. The functionality of these nodes in
terms of input nodes will be specified by the user.

284 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Path Based Constraint Support for Memories

Use the path_constraint_enable and path_constraint_setup

parameters:
■ setup = delay from data input to path_constraint_feedback – delay
from clock input to path_constraint_enable.
■
hold = delay from clock input to path_constraint_enable
- delay from data input to path_constraint_feedback.
Different feedback nodes/enable nodes for setup/hold can be specified using
the –type option with the set_config_opt command.

Example 193
add_pin FB_SETUP default –internal –spice_node N_1 –no_model
add_function FB_SETUP D
set_config_opt-type setup path_constraint_feedback FB_SETUP

add_pin FB_HOLD default –internal –spice_node N_2 –no_model

add_function FB_HOLD D
set_config_opt –type hold path_constraint_feedback FB_HOLD

add_pin ENABLE_SETUP default –internal –spice_node N_3 –no_model

add_function ENABLE_SETUP CLK
set_config_opt –type setup path_constraint_enable ENABLE_SETUP

add_pin ENABLE_HOLD default –internal –spice_node N_4 –no_model

add_function ENABLE_HOLD !CLK
set_config_opt –type hold path_constraint_enable ENABLE_SETUP

The external data/clock will be measured at switching threshold (which is 50%

by default). The internal nodes are measured at either low slew threshold or

SiliconSmart ACE User Guide 285

L-2016.03
Chapter 6: Memory Characterization
Path Based Constraint Support for Memories

high slew threshold. The selection is done such that the constraint value is
maximum (pessimistic). Consider the following figure:

Figure 35 Setup path_constraint_feedback/enable Pins

The path_constraint_feedback pin for setup is DB. The

path_constraint_enable pin for setup is nclk.
Tsetup = Tdatady – Tclkdy

Here, DB is measured at low slew threshold and nclk is measured at high

slew threshold, such that Tsetup is maximum.
And for hold:

Figure 36 Hold path_constraint_feedback/enable Pins

286 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Path Based Constraint Support for Memories

The path_constraint_feedback pin for hold is P1. The

path_constraint_enable pin for hold is bclk.
Thold = Tclkdy – Tdatady

Note that bclk is measured at high slew threshold and P1 is measured at low
slew threshold such that Thold is maximum.

Defining New Pintypes

If the user wants to use different thresholds for measuring delay to these
nodes, it can achieved by defining new pintypes:
Example 194
pintype pintype_path_based -> default {
set logic_high_threshold 0.9
set logic_low_threshold 0.1
set prop_delay_level 0.5
}

The new pin type can be used instead of default for these pins.
Since data input in memory will be a bus, it’ll be assumed that the internal
nodes specified correspond to the least significant bit of the bus.
It’ll be possible to specify different feedback/enable nodes for different
constraint measurements. For example, to specify a different pin for a
constraint between address pin (A) and clock (CLK):
Example 195
set_config_opt -type { setup } -from A -reference CLK \
-- path_constraint_feedback FB_A_SETUP

SiliconSmart now supports 2 modes for path-based constraints: verify and

polish. One more value will be supported: nochange, which means that
SiliconSmart will not verify the constraint numbers generated by path-based
measurement. Those numbers will be modeled as they are.

Auto-Generated Node
The parameter delay_based_constraint_mode must be set to on during
the import step in the template-based flow. If this parameter is set to on,
SiliconSmart will perform a structural analysis on the memory netlist to
determine the signal and clock nodes of data, address, and other signal pins.

SiliconSmart ACE User Guide 287

L-2016.03
Chapter 6: Memory Characterization
Path Based Constraint Support for Memories

By default, if nothing is provided as input by the user (provided the parameter

delay_based_constraint_mode is on), SiliconSmart will identify the
internal clock and signal nodes for data, address and WEN (write enable). For
the buses, it will identify only the clock and signal nodes for the 0th bit of the
data bus and the first and the last bit for the address bus.
If the user wants to use different combinations of bits for the data and address
bus, the command set_path_based_constraint can be specified in the
template file to tell SiliconSmart to determine the internal clock and signal
nodes for the specified targets bits of the data and address bus.
Example 196
set_path_based_constraint –bus D –target_bits {0 4 7 15}

In the above case, SiliconSmart will determine the clock and data nodes
corresponding to the 0th, 4th, 7th and 15th bits of the data bus and then
calculate the worst of the all the setup and hold values for each of these bits.
Example 197
set_path_based_constraint –bus A –target_bits {0 1 2 3 4 5 6 7}

In the above case, if the bus A is of 8 bits, SiliconSmart will determine the clock
and signal node for all the bits of the address bus.
The user can use this command to instruct SiliconSmart to determine the
internal nodes for any bus or pin. For a pin, the user needs to specify the
following command:
Example 198
set_path_based_constraint –pin CEN

288 SiliconSmart ACE User Guide

L-2016.03
 Chapter 6: Memory Characterization
Path Based Constraint Support for Memories

Once the import step is complete, SiliconSmart will generate the instance file
that will contain clock and the data node information for each of the bits
specified in the template file. For example:
Example 199
set_config_opt -type {setup hold} -from D -reference CLK {\
delay_based_constraint_mode on
path_based_signal_nodes { {0 dw xi1_0/xi0_0/xi0_1/xi0_0/di
xi1_0/xi0_0/xi0_1/xi0_0/dnn dw_}\
{1 stubdw_1 xi7_0/xi0_0/xi0_1/xi0_0/di xi7_0/xi0_0/
xi0_1/xi0_0/dnn stubdw__1} }

path_based_clock_nodes \
{ {0 xi1_0/xi0_0/xi0_3/xi0_0/xi0_0/
cs0 xi1_0/xi0_0/xi0_1/xi0_0/gtpnd gtp_2 xi1_0/xi0_0/xi0_3/xi0_0/
xi0_0/cs0 xi1_0/xi0_0/xi0_3/xi0_0/xi0_0/cs1 xi1_0/xi0_0/xi0_3/
xi1_0/xi0_0/xi0_0/cs0 xi1_0/xi0_0/xi0_3/xi1_0/xi0_0/xi0_0/cs1
xi1_0/xi0_0/xi0_3/xi2_0/xi0_0/xi0_0/cs0 xi1_0/xi0_0/xi0_3/
xi2_0/xi0_0/xi0_0/cs1 xi1_0/xi0_0/xi0_3/xi3_0/xi0_0/xi0_0/cs0
xi1_0/xi0_0/xi0_3/xi3_0/xi0_0/xi0_0/cs1}\
{1 gtp_2 xi7_0/xi0_0/xi0_1/xi0_0/gtpnd xi7_0/xi0_0/xi0_3/xi0_0/
xi0_0/xi0_0/cs0 xi7_0/xi0_0/xi0_3/xi0_0/xi0_0/xi0_0/cs1 xi7_0/
xi0_0/xi0_3/xi1_0/xi0_0/xi0_0/cs0 xi7_0/xi0_0/xi0_3/xi1_0/
xi0_0/xi0_0/cs1 xi7_0/xi0_0/xi0_3/xi2_0/xi0_0/xi0_0/cs0 xi7_0/
xi0_0/xi0_3/xi2_0/xi0_0/xi0_0/cs1 xi7_0/xi0_0/xi0_3/xi3_0/
xi0_0/cs0 xi7_0/xi0_0/xi0_3/xi3_0/xi0_0/cs1}\
}
}

In the above example, the parameter path_based_signal_nodes specifies

the data nodes for bit 0 and bit 1 of the data bus D. Similarly, the parameter
path_based_clock_nodes specifies the clock nodes in the clock path for bit
0 and bit 1 for the data bus.
SiliconSmart will calculate delays from external data and clock to each of these
nodes and find out the max and min clock and data delay values and find out
the worst setup and hold time values.

SiliconSmart ACE User Guide 289

L-2016.03
Chapter 6: Memory Characterization
Path Based Constraint Support for Memories

290 SiliconSmart ACE User Guide

L-2016.03
 7
7 Statistical Characterization

This chapter describes statistical characterization and its methodology.

The SiliconSmart tool can characterize the variation of delay, transition, and
constraint with respect to process model variations.
Multiple formats are supported for modeling the impact of process variation.
The following sections describe statistical characterization in SiliconSmart:
■
Statistical Format Generation Flow
■
Statistical Hold Support
■ AOCV/POCV Characterization
■
LVF Characterization
■
AOCV/POCV (Side File Format) Model Generation from LVF Data

Statistical Format Generation Flow

The statistical formats generation flow in SiliconSmart can be divided into the
following stages:
■
Configuring Cells
■
Netlist Pruning
■
Screening
■ Characterization
■
Modeling Statistical Formats

SiliconSmart ACE User Guide 291

L-2016.03
Chapter 7: Statistical Characterization
Statistical Format Generation Flow

Configuring Cells
When using the sensitivity-based approach, the configuration of a cell for intra-
cell parameters requires the SiliconSmart tool to change the intra-cell
parameter value on a per transistor basis as this variation varies for each
transistor in a cell.
To do this, the cell netlist must first be prepared for intra-cell variations, with the
following steps:
1. Define the intra-cell parameters in configure.tcl with the
add_opc_statistical_parameter command.
2. Use analyze_netlists -statistical to wrap each transistor as a
subcircuit, creating a subcircuit instance for each transistor and, within that
subcircuit instance, a unique transistor model instance.
3. The above steps will modify the netlist so that each transistor instance has
unique random variables associated with it for each of the parameters
specified by the add_opc_statistical_parameter command.
The analyzed netlists are stored in: char_point/netlists/op_cond/cell,
extension
The following provides a detailed explanation of the above process.
Before using analyze_netlists, you must define the intra-cell parameters
in the configure.tcl file with the add_opc_statistical_parameter
command, as shown in the following example:
Example 200
add_opc_statistical_parameter op_cond –intracell –model xnch vthn
add_opc_statistical_parameter op_cond –intracell –model xpch vthp

Running the analyze_netlist –statistical command modifies the

netlist so that each transistor instance has unique random variables associated
with it for each of the parameters specified by the
add_opc_statistical_parameter command.
Given the previous example’s commands, the modified netlist would appear as
shown in the following example:
Example 201
.subckt INVD0 A Y
XMN Y A VSS VSS xnch L=0.06u W=0.39u vthn=vthn_XMN
XMP Y A VDD VDD xpch L=0.06u W=0.52u vthp=vthp_XMP
.ends INVD0

292 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
Statistical Format Generation Flow

So, there is one random variable associated with XMN, vthn_XMN, and one
random variable associated with XMP, vthp_XMP.
The following example shows how this is achieved, by wrapping a transistor
model inside a SPICE subcircuit (.subckt card) and then replacing transistor
instances inside a cell netlist with instances of these subcircuits.
Example 202
Original cell netlist:
.subckt INVD0 A Y
MN Y A VSS VSS nch L=0.06u W=0.39u
MP Y A VDD VDD pch L=0.06u W=0.52u
.ends INVD0
Original process technology SPICE model:
.model nch NMOS (
+ VTH0 = 0.28 + ‘vthn’
…
+)
.model pch PMOS (
+ VTH0 = -0.33 + ‘vthp’
…
+)

The original SPICE model (.model card) is wrapped inside a subcircuit and the
transistor model is instantiated within the subcircuit.

SiliconSmart ACE User Guide 293

L-2016.03
Chapter 7: Statistical Characterization
Statistical Format Generation Flow

The following additional example shows how the transistor name nch is
wrapped in a subcircuit named xnch. It also shows how the parameter vthn is
defined as one of the arguments to this xnch subcircuit.
Example 203
.subckt xnch D G S B W=0 L=0 vthn=0
* vthn is an argument for this subckt
MN D G S B nch W=’W’ L=’L’
* this is the actual transistor instance which
* was previously defined in the cell netlist
.model nch NMOS
* this is the original transistor model
* fully enclosed within this subckt.
+ VTH0 = 0.28 + ‘vthn’
…
+)
.ends xnch
* end of the subcircuit
.subckt xpch D G S B W=0 L=0 vthp=0
MP D G S B pch W=’W’ L=’L’
.model pch PMOS (
+ VTH0 = 0.28 + ‘vthp’
…
+)
.ends xpch
Each cell netlist must be modified as well:
.subckt INVD0 A Y
XMN Y A VSS VSS xnch L=0.06u W=0.39u
XMP Y A VDD VDD xpch L=0.06u W=0.52u
.ends INVD0

Notice that the transistors are no longer instances within the cell netlist. Now
the cell netlist has a subcircuit instance for each transistor. Within each
subcircuit instance, there is a unique transistor model instance. Now that each
transistor is uniquely defined, the parameter(s) of each transistor instance can
be modified individually. (As shown in the previous example, you can specify a
unique value for the threshold voltage (vthn or vthp) for each transistor
instance for the cell.)
See Also
■
Command: add_opc_statistical_parameter
■
Command: analyze_netlists

294 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
Statistical Format Generation Flow

Netlist Pruning
The SiliconSmart tool has a netlist pruning feature to make statistical
characterization faster. Netlist pruning can help in the following ways:
■
It reduces the netlist size so that simulations run faster.
■
It provides enough information about a cell netlist so you can avoid
sweeping parameters that correspond to transistors which don’t affect delay
or slew variation.
Pruning is timing arc specific. For every timing arc, a pruned netlist is created
for the cell. By default, pruning is disabled. You can enable netlist pruning with
the enable_netlist_pruning parameter. By default, nominal slew/delay
tables are still characterized using the original netlist.
Specify the N and P MOS names by using the nmos_model_names and
pmos_model_names parameters. These are required to be set when using
netlist pruning with statistical characterization.
You can use pruned netlists for nominal characterization by enabling the
statistical_use_pruned_netlist_for_nominal parameter.
See Also
■
Parameter: enable_netlist_pruning
■
Parameter: statistical_use_pruned_netlist_for_nominal

Screening
To improve performance, SiliconSmart applies a screening process to reduce
the total number of simulations without significantly compromising accuracy.
The idea behind screening is that for a given slew-load point, not all sensitivities
are significant enough to be considered for modeling. The set of significant
sensitivities varies from one slew-load point to another. To find out which
sensitivities are to be modeled, SiliconSmart selects a few slew/load points as
screening points. SiliconSmart finds all sensitivities at these screening points
and filters out the non-significant ones. For the remaining slew-load points, not
all sensitivities are characterized. For any slew-load point, the closest
screening point is discovered. Sensitivities that are significant at that screening
point are assumed to be significant for that slew-load point. This reduces the
number of simulations needed.

SiliconSmart ACE User Guide 295

L-2016.03
Chapter 7: Statistical Characterization
Statistical Format Generation Flow

By default, the SiliconSmart tool chooses the following screening points:

■
Three corners for the slew-load table except first slew index, first load index
■
First slew index, middle load index
■
Middle slew index, first load index
■
Middle slew index, middle load index
It has been observed that the variation in sensitivity values is higher at low
slew/low load values, so the SiliconSmart tool selects more screening points
towards low slew/load values.
You can control screening tolerance for LVF delay/slew characterization with
the lvf_param_abs_threshold, lvf_param_rel_threshold, and
statistical_screening_tolerance parameters. The parameters
lvf_param_abs_threshold (default: 3e-14) and
lvf_param_rel_threshold (default 5e-4) can be used to discard small
sensitivities before screening. The statistical_screening_tolerance
parameter specifies the tolerance in percentage used to screen sweeping
parameters for LVF delay/slew characterization.
The screening tolerance for LVF constraint characterization is controlled with
parameter statistical_constraint_screening_tolerance.
Once SiliconSmart gets all significant parameters per slew/load value,
configuration process generates characterization sweeps only for those
significant parameters per slew/load value.
See Also
■
Parameter: lvf_param_abs_threshold
■ Parameter: lvf_param_rel_threshold
■
Parameter: statistical_constraint_screening_tolerance
■
Parameter: statistical_screening_tolerance
■
Parameter: statistical_two_sided_screening

296 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
Statistical Format Generation Flow

Characterization
For intra-cell characterization, the defined intra-cell parameters vary locally.
During characterization for each timing arc, two, three, or four acquisitions
(simulations) are run based on parameter settings. These are the acquisitions:
■
Netlist pruning simulation (if enabled using enable_netlist_pruning)
■
Nominal delay simulation (if netlist pruning is enabled and
use_pruned_netlist_for_nominal is disabled)
■
Screening simulation
(if statistical_avoid_screening_acquisition is 0)
■
Main statistical simulation
The netlist pruning acquisition name starts with find_inactive_nodes. The
nominal delay acquisition name starts with delay. The screening acquisition
name starts with simple_param_screening and the main acquisition starts
with statistical_delay.
For example, if there is a timing arc from A rising to Y falling, the corresponding
acquisition names would be as follows:
Example 204
find_inactive_nodes_simple_param_screening__statistical_delay__
A__lh_Y__hl__ACQ_1
delay__A__lh__Y__hl__ACQ_1
simple_param_screening__statistical_delay__A__lh__Y__hl__ACQ_1
statistical_delay__A__lh__Y__hl__ACQ_1

The acquisition statistical_delay__A__lh__Y__hl__ACQ_1 is

dependant on
simple_param_screening__statistical_delay__A__lh__Y__hl__A
CQ_1, which in turn depends on
find_inactive_nodes_simple_param_screening__statistical_de
lay__A__lh_Y__hl__ACQ_1

SiliconSmart ACE User Guide 297

L-2016.03
Chapter 7: Statistical Characterization
Statistical Format Generation Flow

Modeling Statistical Formats

Because different statistical formats have different kind of data/tables,
SiliconSmart models them differently as per format specifications:
■
AOCV (side file) — models derate at 3 sigma
■
POCV (side file) — models the cell delay variation at 1 - sigma of the delay
distribution normalized by the nominal delay
■
LVF — models absolute delay, slew, constraint variation at 1 - sigma.

Sensitivity and Sigma Calculation

In general, to understand statistical format modeling, it is important to
understand how the SiliconSmart tool calculates sensitivities and sigma values.
Consider the following example:
■
Assume that the cell is an inverter with one NMOS and one PMOS.
■
There are five process parameters per transistor: np1, np2, ..., np5 for
NMOS and pp1, pp2, ..., pp5 for PMOS, for a total of ten individual
parameters.
The delay equation for any process parameter combination is expressed as:

Equation 1 Delay for process parameters

D = D 0 + s1  np1 + s2  np2 +  + s6  pp1 + 

where:
■
D 0 is the nominal delay
■
s1 , s2 , ..., s6 are sensitivity values
■ np1 , np2 , ..., pp1 are changes in parameters
The SiliconSmart tool will find s1 , s2 , etc., through simulations by varying one
process parameter at a time, per transistor.

298 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
Statistical Hold Support

Assuming that the distribution of delay D is Gaussian, the SiliconSmart tool will
find the standard deviation of D with the following equation:

Equation 2 Standard deviation of D

2 2 2 2 2 2
 = s1  1 + s2  2 +  + s10  10

where:
■
1 , 2 , ..., are the standard deviations of np1 , np2 , ...
This is how the SiliconSmart tool calculates sensitivity and sigma values for
statistical process parameters.

Statistical Hold Support

The SiliconSmart tool supports finding the standard deviation of hold numbers
due to random process parameter variations (intra-cell and inter-cell) and
adding 3*(standard deviation) as a margin to all hold numbers. To enable this
capability, use –stat_hold with the configure command and model
command.
Example 205 Example Flow
analyze_netlist -statistical
configure –stat_hold
characterize
model –stat_hold

You need to specify the process parameters using the

add_opc_statistical_parameter command.
SiliconSmart finds sensitivity by finding hold values at nominal, min, and max
values for a process parameter.
The following stat_hold characterization approaches are detailed below:
■
stat_hold Characterization Using the Monte Carlo Approach
■
stat_hold Characterization Using the Simulator Bisection Approach

SiliconSmart ACE User Guide 299

L-2016.03
Chapter 7: Statistical Characterization
Statistical Hold Support

stat_hold Characterization Using the Monte Carlo

Approach
In the Monte Carlo approach, the SiliconSmart tool will perform simulator native
Monte Carlo simulation to determine hold sigma. The parameters
simulator_bisection and statistical_model_sigma_montecarlo
are used to enable the Monte Carlo approach. The parameter
statistical_montecarlo_sample_size can be used to control sample
size.
Example flow:
set_config_opt statistical_model_sigma_montecarlo 1
set_config_opt statistical_montecarlo_sample_size <sample size>
set_config_opt simulator_bisection 1
import
configure -stat_hold
characterize
model -fast -stat_hold

Note: Only the standalone FineSim and HSPICE simulators are

supported for this methodology.

stat_hold Characterization Using the Simulator

Bisection Approach
By default, the SiliconSmart tool uses the SiliconSmart native bisection
approach for stat_hold characterization. To use the simulator native
bisection approach, the parameter simulator_bisection should be
enabled.
Simulators supported for this approach are HSPICE, FineSim standalone, and
embedded FineSim.
The configuration file options should be set to enable stat_hold
characterization using simulator bisection and sensitivity based approach, as
shown below:
set_config_opt simulator_bisection 1
import
configure -stat_hold
characterize
model -fast -stat_hold

300 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
AOCV/POCV Characterization

Note: When using the simulator bisection method, if the parameter

statistical_simulator_bisection (default 1) is set to 0
and the parameter simulator_bisection is set to 1,
stat_hold characterization will use internal bisection while
nominal hold characterization will use simulator bisection.

AOCV/POCV Characterization
The SiliconSmart tool supports AOCV (path depth-based only) and POCV
table generation. All AOCV/POCV characterization is performed natively in the
SiliconSmart tool, inheriting all runtime environmental features from regular
characterization (LSF support, cache mechanism, etc.).
The following sections describe AOCV/POCV characterization methodology
and support in the SiliconSmart tool:
■
AOCV Characterization
■
POCV Characterization

AOCV Characterization
The SiliconSmart tool uses AOCV characterization to find the accurate derate
factor, which depends on the depth of the delay path. The SiliconSmart tool will
simulate two arcs for each cell: one for output rising and one for output falling.
The following sections describe using AOCV characterization in SiliconSmart:
■
Running AOCV Characterization
■
Monte Carlo Simulation-Based Methodology
■ Sensitivity-Based Methodology
■
AOCV Parameters

Running AOCV Characterization

There are two methodologies available for AOCV characterization:
■
Monte Carlo Simulation-Based Methodology.
■ Sensitivity-Based Methodology

SiliconSmart ACE User Guide 301

L-2016.03
Chapter 7: Statistical Characterization
AOCV/POCV Characterization

The parameter aocv_sensitivity_based is used to switch between these

two methodologies. By default, the parameter is set to 0, which selects the
Monte Carlo simulation approach. Setting it to 1 will select the sensitivity-based
methodology.
The following topics are described in this section:
■
General AOCV Characterization Guidelines
■
Fast AOCV Characterization
■
Generating the Models

General AOCV Characterization Guidelines

The following guidelines apply to both the Monte Carlo and sensitivity-based
methodologies:
■
Input transition time and net loading — the transistor mismatch effect is
dependent on the input transition time and net loading for the simulation.
These should be specified according to design rule constraints.
■
Number of logic depth levels — select a number of stages as deep as the
longest design paths. If the number of stages is less than the actual path
logic depth, a small minimal difference can occur. If the number of stages is
greater than the specified path logic depth, the AOCV run will conservatively
use the last entry in the table.
■
Fanout loading — select the appropriate fanout loading that is allowed in the
design.

Fast AOCV Characterization

Assuming that process parameter variations between cells in a chain are
independent, AOCV characterization can be optimized by simulating a reduced
chain instead of a full chain. The derate factor for this reduced chain is found
through simulation. For bigger chains, the derate factors are derived
analytically. Reduced chain or fast char mode is the recommended approach
for AOCV characterization.
The parameter aocv_fast_char is used to switch between the full and
reduced chain approaches. By default, the parameter is set to 1, which selects
the reduced chain methodology. Setting this parameter to 0 will simulate the full
chain.

302 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
AOCV/POCV Characterization

Generating the Models

The sequence of commands used to generate AOCV models is similar to other
model format generations:
Example 206
configure -aocv
characterize
model –aocv

The AOCV models will be generated in the location: charpoint/models/aocv

Four tables are generated for each cell:
■
Early rise
■
Late rise
■
Early fall
■
Late fall
where:
■
Rise/fall refers to the transition of the output of the cell.
nominaldelay + 3
■ Late derate factor = -------------------------------------------------
nominaldelay
nominaldelay – 3
■
Early derate factor = ------------------------------------------------
nominaldelay

SiliconSmart ACE User Guide 303

L-2016.03
Chapter 7: Statistical Characterization
AOCV/POCV Characterization

Below is an example of a generated model:

Example 207 Generated AOCV model
version: 1.0
object_type: lib_cell
delay_type: cell
rf_type: rise
derate_type: early
object_spec: */BUFF
depth: 1 2 3 4 5
distance: 0
table: 0.8691 0.8805 0.8822 0.8889 0.8801
object_type: lib_cell
delay_type: cell
rf_type: fall
derate_type: early
object_spec: */BUFF
depth: 1 2 3 4 5
distance: 0
table: 0.8680 0.8817 0.8747 0.8664 0.8803
object_type: lib_cell
delay_type: cell
rf_type: rise
derate_type: late
object_spec: */BUF
depth: 1 2 3 4 5
distance: 0
table: 1.20191100781 1.1621 1.1630 1.1497 1.1683
object_type: lib_cell
delay_type: cell
rf_type: fall
derate_type: late
object_spec: */BUF
depth: 1 2 3 4 5
distance: 0
table: 1.20988082204 1.1632 1.1779 1.1526 1.1286

Monte Carlo Simulation-Based Methodology

For this methodology, the SiliconSmart tool will perform Monte Carlo to find the
derate factor. For the Monte Carlo methodology, a statistical SPICE model
should be used. The SiliconSmart tool will perform a Monte Carlo simulation.
Separate early/late sigma for each stage is then calculated from delay
distribution.

Note: Only the standalone FineSim and HSPICE simulators are

supported for this methodology.

304 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
AOCV/POCV Characterization

The following topics are described in this section:

■
Characterization Guidelines
■
Example of Characterization Setup

Characterization Guidelines
Follow these guidelines when preparing for AOCV characterization with this
methodology:
■
Monte Carlo iterations — use sufficient points so that you will get a good
sampling when near the extremes. This will help populate the delay
distribution near the minimum and maximum and will improve the sigma
calculation.

Example of Characterization Setup

Below is an example of characterization setup using the Monte Carlo
methodology:
Example 208
set_location chp
set_config_opt aocv_fast_char 1
set_config_opt aocv_num_stages 5
set_config_opt aocv_sample_size 1000
set_config_opt aocv_interconnect_model pi
set_config_opt aocv_fanout_load {1e-14 100 2e-14}
configure -aocv
characterize
model –aocv

Sensitivity-Based Methodology
For a complete library with thousands of cells, the Monte Carlo simulation
approach can become prohibitive. In the sensitivity-based approach, the
SiliconSmart tool finds the sensitivity of delay to each process parameter
variation by sweeping the process parameters during simulation. The derate
values are then analytically derived from the sensitivity values.
When using sensitivity based approach, local variation parameters need to be
defined using the add_opc_statistical_parameter and
set_opc_parameter_distribution commands in configure.tcl.

SiliconSmart ACE User Guide 305

L-2016.03
Chapter 7: Statistical Characterization
AOCV/POCV Characterization

The following topics are described in this section:

■
Process Model Requirements
■
Characterization Guidelines
■
Example of Characterization Setup

Process Model Requirements

The statistical SPICE model is required. For the sensitivity-based methodology,
the SiliconSmart tool sweeps the process parameters explicitly. The
analyze_netlists -statistical command is used to prepare the
netlists so process parameters can be assigned to each transistor
independently.

Characterization Guidelines
Follow these guidelines when preparing for AOCV characterization with this
methodology:
■
Specify the simulator to be used. Standalone FineSim, embedded FineSim,
and HSPICE simulators are supported for this methodology.
■
Prepare the netlist for intra-cell variations by adding the following command
before the configure command, as shown below.

Example 209
analyze_netlists -statistical
configure

This will modify the netlist so that transistor specific parameters can be swept
during characterization.

306 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
AOCV/POCV Characterization

Example of Characterization Setup

Below is an example of characterization setup using the statistical-based
methodology:
Example 210
set_location chp
set_config_opt aocv_sensitivity_based 1
set_config_opt aocv_num_stages 5
set_config_opt aocv_interconnect_model pi
set_config_opt aocv_fanout_load {1e-14 100 2e-14}
analyze_netlists -statistical
configure -aocv
characterize
model –aocv

AOCV Parameters
The following parameters control AOCV settings:
■
aocv_num_stages — specifies how many stages need to be
characterized.
■
aocv_input_slew — defines slew value between thresholds.
■
aocv_num_fanouts — specifies how many cells should be connected at
the output of each stage as load. Default value is 0. It can be a single integer
or a list of integers. If it is a single integer, it specifies same number of cells
to be connected at the output of each stage. If a list of integers, the size of
list should be equal to aocv_num_stages. The entries in the list will specify
fanout at each stage.
■
aocv_fanout_cells — cells to be used as load. It can be a single cell or
a list of cells.
■ aocv_passive_load — the value of the load to be connected to the
output of the load cell.
■ aocv_interconnect_model — in addition to using cells at each stage, a
pi/lumped load can also be used at the output of each stage as load. The
value of this parameter can be pi/lumped/none.
■
aocv_fanout_load — a list which has either one value (lumped - C) or 3
values (pi- C1,R,C2).
■
aocv_sample_size — sample size for MC simulation-based
methodology. Default value is 200.

SiliconSmart ACE User Guide 307

L-2016.03
Chapter 7: Statistical Characterization
AOCV/POCV Characterization

■
aocv_input_pin — specifies which input will be used for the AOCV
simulation. If not specified, SiliconSmart will select one at random.
■ aocv_output_pin — specifies which output pin will be used for AOCV
simulation. For multi-output cells, if this is not specified, SiliconSmart will
select one at random.

POCV Characterization
The SiliconSmart tool supports single slew/load-based native POCV
characterization. The POCV coefficient is the cell delay variation at 1 sigma of
the delay distribution normalized by the nominal delay. For example, if the
POCV coefficient is 0.04, then the standard deviation of delay for that arc is 4%.
  delayvariation 
POCV Coefficient: ------------------------------------------------
  nominaldelay 
The SiliconSmart tool will find the  for only one slew-load combination,
simulating one arc for output rise and one arc for output fall.
■ The input and output pin of the arcs can be configured with the
aocv_input_pin and aocv_output_pin parameters.
■
Input slew and output load can be controlled with the pocv_input_slew
and default_load parameters.
■
You can control the Monte Carlo sampling count using
aocv_sample_size.
There are two methodologies available for POCV characterization: Monte Carlo
simulation-based, and sensitivity-based. The parameter
pocv_sensitivity_based is used to switch between these two
methodologies. By default, the parameter is set to 0, which selects the Monte
Carlo simulation approach. Setting it to 1 will select the sensitivity-based
methodology.
Separate Early/Late POCV coefficients modeling is supported for both Monte
Carlo Based approach and Sensitivity based approach.
The following sections describe these methodologies:
■ Monte Carlo Simulation-Based Methodology
■
Sensitivity-Based Methodology

308 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
AOCV/POCV Characterization

Monte Carlo Simulation-Based Methodology

For this methodology, the SiliconSmart tool will perform Monte Carlo
simulation, then find the POCV coefficient. For the Monte Carlo methodology,
the statistical model should be used.

Note: Only the standalone FineSim and HSPICE simulators are

supported for this methodology.

Generating the Models

The sequence of commands used for generating POCV models in the Monte
Carlo methodology is:
Example 211
configure -pocv
characterize
model -pocv

Sensitivity-Based Methodology
For this methodology, local variation parameters need to be defined using the
add_opc_statistical_parameter and
set_opc_parameter_distribution commands in configure.tcl. This is
similar to usage for other SiliconSmart supported SSTA methodologies.

Example of Characterization Setup

Below is an example of POCV characterization setup:
Example 212
set charpt chp
source ./celllist
create charpt
set_log_file charpt/siliconsmart.log
exec cp configure.tcl charpt/config/configure.tcl
set_location charpt
import
analyze_netlists –statistical
set_config_opt pocv_input_slew 0.8e-09
set_config_opt default_load 0.02e-12
set_config_opt -cell INV aocv_input_pin a
set_config_opt -cell INV aocv_output_pin z
configure -pocv cells
characterize cells
model -pocv -output out_pocv

SiliconSmart ACE User Guide 309

L-2016.03
Chapter 7: Statistical Characterization
AOCV/POCV Characterization

Process Model Requirements

The statistical SPICE model is required. The SiliconSmart tool sweeps the
process parameters explicitly. The analyze_netlists -statistical
command is used to prepare the netlists so process parameters can be
assigned to each transistor independently.

Generating the Models

The sequence of commands used to generate POCV models is similar to other
model format generations:
Example 213
analyze_netlists – statistical
configure –pocv
characterize
model –pocv

The POCV models will be generated in the location: charpoint/models/pocv

310 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

Below is an example of a generated model:

Example 214 Generated POCV model
version: 4.0

ocvm_type : pocvm
object_type: lib_cell
delay_type : cell
derate_type: early
rf_type : rise
object_spec: ff_0p88_0c/INVcoefficient: 0.0427
coefficient: 0.0427

ocvm_type : pocvm
object_type: lib_cell
delay_type : cell
derate_type: late
rf_type : rise
object_spec: ff_0p88_0c/INVcoefficient: 0.0427
coefficient: 0.0427

ocvm_type : pocvm
object_type: lib_cell
delay_type : cell
derate_type: early
rf_type : fall
object_spec: ff_0p88_0c/INVcoefficient: 0.0577
coefficient: 0.0577

ocvm_type : pocvm
object_type: lib_cell
delay_type : cell
derate_type: late
rf_type : fall
object_spec: ff_0p88_0c/INV
coefficient: 0.0577

LVF Characterization
POCV cell variation information can be represented by either a single cell-
based variation coefficient (side file) or the Liberty Variation Format (LVF). The
LVF models slew-load dependent delay and transition variation and slew-slew
dependent constraint variation for each timing arc. It improves the accuracy of
POCV analysis by taking into consideration multiple slew/load points for each

SiliconSmart ACE User Guide 311

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

cell. LVF is recommended to be used for the advanced nodes 16nm and below
for better accuracy.
The following sections describe LVF support:
■
POCV Characterization Concepts
■
Supported Characterization Methods
■
Process Model Requirements and Simulator Support
■
Setup
■
Sensitivity-Based LVF Characterization:
■
Monte Carlo-Based LVF Characterization
■
Separate Early/Late Support
■
LVF Add-On Flow
■
LVF Table Checks

POCV Characterization Concepts

The POCV coefficient is the cell delay variation at 1-sigma of the delay
distribution normalized by the nominal delay. POCV LVF is the variation in cell
delay per timing arc at 1-sigma of the delay distribution. The unit of variation in
LVF library is the time unit from the library.
  delayvariation 
POCV Coefficient = ------------------------------------------------
  nominaldelay 

LVF =   delayvariation 

Examples are shown below:

Example 215 Single slew/load based POCV coefficient table
version : 4.0
ocvm_type : pocvm
object_type: lib_cell
rf_type : rise fall
delay_type : cell
derate_type: early
object_spec: lib20nm/inv*
coefficient: 0.05

312 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

Example 216 LVF Format in the library

cell(<name>) {

pin (<name>) {
direction : input;
timing(){

rise_constraint(<const_lu_templ_name>) {
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}

ocv_sigma_rise_constraint(<const_lu_templ_name>) {
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}

fall_constraint(<const_lu_templ_name>) {
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}

ocv_sigma_fall_constraint(<const_lu_templ_name>) {
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}
} /* end of timing */
} /* end of pin */

...

pin (<name>) {
direction : output;
...
timing() {

cell_rise(tmg_tin_oload_3_3) {
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}
cell_fall(tmg_tin_oload_3_3) {
index_1(0,1,2);
index_2(0,1,2);

SiliconSmart ACE User Guide 313

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

values(0,1,2,3,4,5,6,7,8);
}

...
...

ocv_sigma_cell_fall(tmg_tin_oload_3_3) {
sigma_type : "early" ;
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}

ocv_sigma_cell_fall(tmg_tin_oload_3_3) {
sigma_type : "late" ;
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}

ocv_sigma_cell_rise(tmg_tin_oload_3_3) {
sigma_type : "early" ;
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}

ocv_sigma_cell_rise(tmg_tin_oload_3_3) {
sigma_type : "late" ;
index_1(0,1,2);
index_2(0,1,2);
values(0,1,2,3,4,5,6,7,8);
}
} /* end of timing */
} /* end of pin */
} /* end of cell */

Separate Early/Late Sigma

Separate early/late sigma models non-ideal/asymmetric ‘Normal’ delay
distributions more accurately.

314 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

Supported Characterization Methods

The SiliconSmart tool supports two methodologies for LVF model generation:
■
Sensitivity-based approach
■
Simulator native Monte Carlo simulation-based approach
In the sensitivity-based approach, sensitivity is computed by perturbing
variation parameters. The SiliconSmart tool then derives sigma using
sensitivity values. The number of sweeps in the sensitivity-based approach will
be significantly lower compared to Monte Carlo simulation-based approach.
In the Monte Carlo approach, the SiliconSmart tool will perform Monte Carlo
simulation and then derive sigma from delay distribution. The
statistical_model_sigma_montecarlo parameter can be used to
enable the Monte Carlo approach. The parameter
statistical_montecarlo_sample_size can be used to control sample
size.
See Also
■
Parameter: statistical_model_sigma_montecarlo
■
Parameter: statistical_montecarlo_sample_size

Process Model Requirements and Simulator Support

LVF characterization requires a statistical SPICE model. In the sensitivity
based-approach, the SiliconSmart tool sweeps the process parameter values
explicitly. Because of this, the model should have the transistor models in
subcircuit format so that the SiliconSmart tool can sweep the process
parameters in the SPICE deck.

Note: FineSim standalone, FineSim Embedded, and HSPICE

simulators are supported for sensitivity-based LVF
characterization. However, Monte Carlo-based LVF
characterization supports only FineSim standalone and HSPICE
simulators.

SiliconSmart ACE User Guide 315

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

Setup
The inputs for LVF characterization are:
■
Statistical SPICE model
■
Extracted netlists
■
Input seed library/cell instance file

Sensitivity-Based LVF Characterization:

Below is the flow for LVF model generation using the sensitivity-based
approach:
set_config_opt statistical_enable_constraint_sensitivity 1
set_config_opt lvf_model_slew 1
set_config_opt lvf_constraint_models {setup hold}
analyze_netlists -statistical
configure -lvf
characterize
model -lvf

In the above, the analyze_netlists -statistical command is to modify

the netlist so that transistor specific parameters can be swept during
characterization.
Setting the parameter lvf_model_slew to 1 enables modeling of slew sigma
tables.
The parameter lvf_constraint_models specifies LVF constraint types to
model. The default is to characterize and model LVF data for only setup and
hold arcs. Supported types include setup, hold, recovery, removal,
asynch_recovery, and asynch_removal.
For example, to model LVF constraint data for hold and removal arcs:
set_config_opt lvf_constraint_models {hold removal}

In addition, -type lvf is supported by the set_config_opt command. It

enables the user to selectively enable LVF characterization on per cell basis.

316 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

When using instance-based flow/scratch flow, you need to configure,

characterize, and model timing along with LVF to model sigma tables in
generated model. For example:
set_config_opt statistical_enable_constraint_sensitivity 1
set_config_opt lvf_model_slew 1
analyze_netlists -statistical
configure –timing –power –ccs –ccs_noise -lvf
characterize
model –timing –power –ccs –ccs_noise -lvf

Note: The statistical_enable_constraint_sensitivity

parameter must be enabled to trigger variation characterization
for constraint timing arcs.

By default, the SiliconSmart tool uses the SiliconSmart native bisection

approach for LVF constraint characterization. To use the simulator native
bisection approach, enable the parameter simulator_bisection.
Below is the flow for LVF model generation using the simulator bisection
approach for LVF constraint characterization:
set_config_opt statistical_enable_constraint_sensitivity 1
set_config_opt lvf_model_slew 1
set_config_opt simulator_bisection 1
analyze_netlists -statistical
configure -lvf
characterize
model -lvf

Note: When using simulator bisection method, if the parameter

statistical_simulator_bisection (default 1) is set to 0
and the parameter simulator_bisection is set to 1, LVF
constraint characterization will use internal bisection while
nominal constraint characterization will use simulator bisection.

configure.tcl Settings
The user must specify the following in configure.tcl:
1. Statistical SPICE model:
set_opc_process FF {
{.lib 'stat_model_path' SSTA}
}

2. MOSFET names:

SiliconSmart ACE User Guide 317

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

set pmos_model_names { pch_mac }

set nmos_model_names { nch_mac }

3. Statistical parameter definitions:

Random variation parameters are defined by AGAUSS in Statistical LIB in
the statistical SPICE model. Define local variation parameters using the
add_opc_statistical_parameter and
set_opc_parameter_distribusion commands. See
add_opc_statistical_parameter and set_opc_parameter_distribution for
examples and usage for each.
4. Driver mode:
Supported driver modes in LVF characterization are ramp, snps predriver,
active waveform and custom driver. Use of active driver is disabled as active
driver is affected by parameter variations.

add_opc_statistical_parameter
Syntax
add_opc_statistical_parameter opc_name (-intracell) param1 \
[param2] (-model) transistor

where:
■
opc_name — name of the operating condition as created with the
set_operating_condition command.
■
-intracell — should always be -intracell for LVF characterization.
Local variation parameters names comes from the Statistical SPICE model.
■ -model — specifies the transistor model name (e.g., nch_mac, pch_mac).
■
param1, param2 — names of one or more process parameters to add.

Example 217
add_opc_statistical_parameter FF -intracell par1 -model { nch_mac
pch_mac }

set_opc_parameter_distribution
Syntax
set_opc_parameter_distribution <active_pvt> -points \
{point_for_sensitivity} -nominal_value XX \
-variation_range {-1.0 1.0}
-distribution_type gaussian -sigma XX parameter

318 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

where:
■
If local variation parameters are Gaussian (Normal) distributions with mean
0 and variance 1, that defines -nominal_value, -distribution_type
and -sigma.
■
The -points option enables you to configure at which point the tool should
perform sensitivity based analysis.
■
The -variation_range option is not used for intracell statistical
characterization but the SiliconSmart tool issues a warning if not defined.
The following example will configure sensitivity based analysis at 3-sigma
point:
If par1=AGAUSS(0,1,1):
nominal_val = 0
abs_variation = 1
std deviation = 1

add_opc_statistical_parameter <op cond> -intracell par1 -model

{<device model names>}

set_opc_parameter_distribution <op cond> -points { -3.0 3.0 }

-nominal_value 0.0 -variation_range {-1.0 1.0} -distribution_type
gaussian -sigma 1.0 par1

The following example will configure sensitivity-based analysis at 1-sigma

point:
If par1=AGAUSS(0,1,3):
nominal_val = 0
abs_variation = 1
std_variation = 1/3 = 0.33333

add_opc_statistical_parameter <op cond> -intracell par1 -model

{<device model names>}

set_opc_parameter_distribution <op cond> -points { -0.33333

0.33333 } -nominal_value 0.0 -variation_range {-1.0 1.0}
-distribution_type gaussian -sigma 0.33333 par1

Additional Control Parameters

The following sections describe additional parameters:
■
Netlist Pruning and Screening
■ statistical_reduction_factor
■
statistical_simulation_points

SiliconSmart ACE User Guide 319

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

■
netlist_max_sweeps
■
enable_parallel_sweeps

Netlist Pruning and Screening

Netlist pruning and screening parameters provide performance improvements
without significantly compromising accuracy.
Netlist pruning is enabled with the enable_netlist_pruning parameter (a
default block parameter). When netlist pruning is enabled, the SiliconSmart tool
performs simulation for each arc to find out the inactive nodes and then, based
on the switching activity of the nodes, prunes the original netlist for that arc. It
reduces the netlist size so that simulations run faster. Pruning is timing arc
specific. For every timing arc, a pruned netlist is created for the cell. By default,
pruning is disabled.
Screening detects and ignores insignificant device parameters, thus reducing
the total number of simulations without significantly compromising accuracy.
Screening is enabled by default.
Parameters that control screening acquisition are:
■
statistical_avoid_screening_acquisition — This parameter
can be set to avoid screening acquisitions. Default value is 0. Set this
parameter to 1 to avoid screening but this will increase runtime. This is a
default block parameter.
■
statistical_screening_tolerance — This parameter specifies the
tolerance in percentage used to screen sweeping parameters for LVF delay/
slew characterization. Default value is 0.01, i.e., 1%.
■
statistical_screening_points — This parameter is for the user to
specify screening points. For an MxN slew-load table, default screening
points are [N/2, N-1, (M/2)*N, (M*N)/2, (M-1)*N, M*N-1]
■ statistical_constraint_screening_tolerance — This
parameter specifies the tolerance used to consider/ignore a particular
sensitivity value in statistical constraint screening characterization. Unit is
absolute. Default value is 0, in which case constraint_resolution will
be taken as the value. For each combination of statistical parameter and

320 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

transistor, if the calculated sensitivity value is less than

statistical_constraint_screening_tolerance, that pair is
ignored for the other slew-slew points.
■
statistical_constraint_screening_points — This parameter
specifies slew-slew points to be used for statistical constraint screening. If
not specified, the SiliconSmart tool selects the middle slew-slew point as
default.
For example, the below setting will select right top and left bottom grid points
for statistical constraint screening for a 3x3 slew-slew tables with grid points
numbered as below:
0 1 2
3 4 5
6 7 8

So to select right top and left bottom values, set:

statistical_constraint_screening_points {2 6}

The below example shows configure.tcl file settings without optimization

parameters enabled in LVF characterization:
Example 218
set enable_netlist_pruning 0 ( tool default)
set statistical_avoid_screening_acquisition 1

statistical_reduction_factor
This parameter can be used to further optimize performance by characterizing
reduced slew/load points in the table and interpolating data for rest of the table.
For example, if this parameter is set to 0.5, only 50% of the sensitivity values
are found out by simulation and rest 50% is interpolated and put in the model.
Default value is 1.0

statistical_simulation_points
This parameter specifies slew-load points (indices) to be used for LVF
characterization. The LVF table will be interpolated based on these points. If
not specified, SiliconSmart selects points based on
statistical_reduction_factor.

SiliconSmart ACE User Guide 321

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

For example, with the below settings, the SiliconSmart tool will characterize 4
corner slew/load points of a 3x3 table (with grid points numbered as below) and
will interpolate data for rest of the table:
0 1 2
3 4 5
6 7 8

Example 219
set_config_opt statistical_simulation_points {0 2 6 8}

netlist_max_sweeps
This parameter controls the maximum number of sweeps allowed in a single
deck (default 8000). You can specify this parameter on a per-cell basis with the
set_config_opt command.

enable_parallel_sweeps
This parameter enables parallel jobs submission of split decks. With this setting
enabled, jobs are distributed in parallel for one acquisition. Otherwise, the split
netlists will be simulated on one worker sequentially. You can specify this
parameter on a per-cell basis with the set_config_opt command.

Note: Split netlists and parallel jobs submission flow

(enable_parallel_sweeps and netlist_max_sweeps
parameters) for LVF constraint characterization are supported
only when the simulator_bisection approach is used.
When using the SiliconSmart native bisection approach for LVF
constraint characterization, jobs are run sequentially.

Monte Carlo-Based LVF Characterization

Below is the flow for LVF model generation using the Monte Carlo-based
approach:
configure –lvf
characterize
model –lvf

322 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

configure.tcl Settings
The user must specify the following in configure.tcl:
set statistical_model_sigma_montecarlo 1
set statistical_montecarlo_sample_size value

To compile the library with LVF into the Synopsys .db format, use Library
Compiler version I-2013.12 or later.
Below is the flow for LVF model generation using the Monte Carlo approach for
all delay/slew and constraint variation characterization:
set_config_opt statistical_enable_constraint_sensitivity 1
set_config_opt simulator_bisection 1
set_config_opt statistical_model_sigma_montecarlo 1
set_config_opt statistical_montecarlo_sample_size value
set_config_opt lvf_model_slew 1
configure –lvf
characterize
model –lvf

Separate Early/Late Support

Separate early/late modeling is supported for both sensitivity and simulator
native Monte Carlo simulation-based methods.
In the Monte Carlo approach, separate early/late sigma is derived from delay
distribution.
In the sensitivity-based approach, while calculating sensitivities, we separate
the table so that we have one set of values which are more than nominal delay
(used for late sigma calculation) and another set of values which are less than
nominal delay (used for early sigma calculation).
To enable separate early/late sigma in sensitivity based approach, you need to
set -points with 2 values:
set_opc_parameter_distribution FF -points {-3 3} -nominal_value
0.0 -variation_range {-1.0 1.0} -distribution_type gaussian
-sigma 1 par1

If a single value is specified with the -points option, both early and late table
values are same:
set_opc_parameter_distribution FF -points {3} -nominal_value 0.0
-variation_range {-1.0 1.0} -distribution_type gaussian -sigma 1
par1

SiliconSmart ACE User Guide 323

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

Note: See Sensitivity and Sigma Calculation for details on sigma

calculation for the sensitivity-based approach.

LVF Add-On Flow

The LVF add-on flow is enabled by using the -lvf switch for the configure
and model commands. When LVF add-on flow is enabled, only LVF data
(sigma tables) is added to the input (timing + power + CCS-noise) library, and
the rest of the data is taken from the input library. A warning is issued if there is
large discrepancy found between the measured delay and nominal delay in the
imported library. The parameters statistical_timing_rel_tolerance and
statistical_timing_abs_tolerance can be used to control the timing tolerance
between measured delay and nominal delay in the input library.
By default, the SiliconSmart tool will scale LVF delay/slew sigma by the ratio of
nominal delay/slew in input library and measured nominal delay/slew during
LVF characterization. You can disable this scaling by setting the parameter
lvf_sigma_scaling parameter to 0.
For example:
import
configure –lvf
characterize
model –lvf

Note: When using the sensitivity-based approach for LVF add-on flow,
use analyze_netlists -statistical before the
configure command.

The LVF add-on flow also supports the reuse of sensitization vectors from input
library. It enables usage of the same stimulus for statistical delay
characterization as used in timing characterization. This feature is enabled by
adding the -sensitization switch to the import command, as shown
below:
import -sensitization -liberty ./ref.lib -netlist_dir ./netlists
-ext .sp $cells
configure -fast -lvf
characterize
model -fast -lvf -output out_lvfaddon

324 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

LVF Table Checks

The SiliconSmart tool automatically performs LVF tables sanity checks when
the -lvf switch is used with the model command. Set the parameter
lvf_enable_sanity_check to 0 to disable LVF table sanity checks in
modeling.
LVF check errors/warnings are issued if any of the LVF check doesn’t pass. A
summary report of any LVF_WARNING and LVF_ERROR found during LVF
sanity checking is published in the SiliconSmart log. A detailed report is saved
in the LVF_sanity_checks.csv file under the charpoint/reports/ directory.
To perform LVF sanity checks on generated models, use the
qualify_libray command:
qualify_library path_to_model -cells list_of_cells -check {lvf}

SiliconSmart ACE User Guide 325

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

The following table describes the list of checks performed by the tool:

Check ID Description

000 Unexpected OCV table (missing nominal table)

001 Missing OCV table

002 OCV table has different dimension than the nominal table

003 Index not found in the nominal table

004 Sigma > 25% of nominal (only applies to LVF delay/slew tables)

005 Early and late sigma tables have different sizes

006 Ratio of sigma values between early and late is greater than certain
percentage (only applies to LVF delay/slew tables)

007 Sigma is not monotonic

008 Sigma is not within min/max range

009 Duplicate tables

010 Negative sigma

011 Sigma outlier (both absolute and relative tolerance are not met) (only
applies to LVF delay/slew tables)

By default, check IDs 000, 001, 002, 003, 005, 009, 010 are reported as
LVF_ERROR. Other checks are reported as LVF_WARNING. You can direct the
tool to classify a list of LVF checks as errors by specifying the parameter
lvf_check_errors.

Detailed LVF Table Check Descriptions

Detailed descriptions of the above checks are given below:
■
LVF_ERROR 000 — checks for unexpected sigma tables. This error is
issued if sigma tables are modeled but NLDM timing table is missing in the
same timing arc.
■
LVF_ERROR 001 — this error is issued when a sigma table is missing while
the NLDM timing table is defined in the same timing arc.

326 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
LVF Characterization

■
LVF_ERROR 002 — this error is issued when the sigma table size is
different than the NLDM table in the same timing arc.
■ LVF_ERROR 003 — this error is issued when there is a mismatch in tables
indices between NLDM table and sigma tables in the same timing arc.
■
LVF_WARNING 004 — this check will compare the sigma value with
corresponding nominal value. This warning is reported if the ratio of sigma
to nominal values is more than the specified tolerance (default 25%).
The parameter lvf_tol_sigma_to_nom can be used to control tolerance
of sigma value/nominal value ratio. Since ratio of sigma to nominal can vary
with slew/load, you can specify slew/load dependent ratios rather than using
fixed number for all slew/load points in a timing table.
The parameter lvf_check_sigma_pct can be specified to direct LVF
sanity check to use the specified table to check sigma/nominal ratio instead
of a fixed number. For example, if the delay table size is (3x3), set
lvf_check_sigma_pct as below to set slew/load dependent ratios:
Set lvf_check_sigma_pct {0.05 0.05 0.10 0.10 0.25 0.25 0.25
0.3 0.3}

The parameter lvf_check_slew_sigma_pct can be set to specify slew/

load dependent tolerances to check slew sigma to nominal ratio, otherwise
it will fall back to using lvf_check_sigma_pct.
When using parameters lvf_check_sigma_pct or
lvf_check_slew_sigma_pct, if the number of points specified with the
parameter don’t match the number of table points in a timing table, the
SiliconSmart tool will issue the following warning during the LVF table
checks run:
Warning: Percentage table size does not match nominal table
size, arc: AN4,Y,combinational,A,positive_unate, only the
first matching ones will be used.

The above warning means that, for matching grid points, the SiliconSmart
tool will use user-defined sigma/nominal ratios, whereas fixed ratio (as
specified by parameter lvf_tol_sigma_to_nom) is used for the rest of
the points.
■
LVF_ERROR 005 — this errors is issued when table sizes for early and late
sigma tables in the same timing arc are different.
■
LVF_WARNING 006 — the SiliconSmart tool will compare and report
warnings if ratio of early sigma to late sigma (or vice versa) is greater than
the specified tolerance (default 3).

SiliconSmart ACE User Guide 327

L-2016.03
Chapter 7: Statistical Characterization
LVF Characterization

The tolerance of sigma ratio between early table and late table can be
controlled with the parameter lvf_tol_early_to_late.
■ LVF_WARNING 007 — this warning is reported if non-monotonic values are
found in sigma tables.
■
LVF_WARNING 008 — this check compares the sigma value with minimum
sigma and maximum sigma values range specified. The parameters
lvf_sigma_min and lvf_sigma_max specify the lower and upper
bounds of sigma values for table checking, respectively.
■
LVF_ERROR 009 — this error will be issued if duplicate sigma tables are
found for a NLDM table in the same timing arc.
■
LVF_ERROR 010 — this error will be issued if any of the value in a sigma
table is negative.
■
LVF_WARNING 011 — this warning will be reported if both absolute
(LVF_WARNING 008) and relative tolerances (LVF_WARNING 006) are not
met for values in sigma tables.

Parameters to Control Reporting

You can control reporting with the following parameters:
■
lvf_sigma_max — upper bound of LVF sigma values for table checking
(default 1ns)
■
lvf_sigma_min — lower bound of LVF sigma values for table checking
(default 1e-06 ns)
■
lvf_tol_early_to_late — tolerance of LVF sigma ratio between early
table and late table (default 3)
■
lvf_tol_sigma_to_nom — tolerance of LVF sigma value to its nominal
value (default 0.25)
■
lvf_check_errors — specifies a list of LVF checks to be classified as
errors (default: checks 0, 1, 2, 3, 5, 9, 10 reported as LVF_ERROR)
■
lvf_check_suppress — specifies a list of LVF checks to be suppressed
during checking
■
lvf_check_sigma_pct — if specified, LVF sanity checks will use the
table to check sigma/nominal ratio instead of a fixed number
■
lvf_check_slew_sigma_pct — if specified, LVF sanity checks will use
the table to check slew sigma/nominal ratio, otherwise it will fall back to using
lvf_check_sigma_pct

328 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
AOCV/POCV (Side File Format) Model Generation from LVF Data

AOCV/POCV (Side File Format) Model Generation from

LVF Data
LVF data can be reused to generate AOCV /POCV (side file format) models.
This feature enables modeling of multiple slew/load/arc based AOCV/POCV
side file formats.
You have an option to select a specific timing arc (input pin/output pin), slew/
load grid point for AOCV derates/POCV coefficient modeling. The tool default is
to use the worst AOCV derate/POCV coefficient among all timing arcs in a cell
for AOCV/ POCV side files modeling.
The following two flows are supported:
■
Flow 1: Using the CCI Command
■
Flow 2: Generate AOCV/POCV Side Files with LVF in a Single Run
■
Additional Control Parameters

Flow 1: Using the CCI Command

This flow reads the input library and generates AOCV or POCV files to the
given output directory. The -aocv and -pocv switches are optional.
If -aocv is specified, it generates AOCV side files; if -pocv is specified, it
generates POCV side files.

Example 220 Flow 1 usage

print_ocv_side_files -input_lib x.lib -output_path yyy
(-aocv) (-pocv)

Flow 2: Generate AOCV/POCV Side Files with LVF in a

Single Run
This flow creates AOCV/POCV side files along with LVF during LVF
characterization flow. This flow requires the -aocv and -pocv switches to be
set in the model command.

SiliconSmart ACE User Guide 329

L-2016.03
Chapter 7: Statistical Characterization
AOCV/POCV (Side File Format) Model Generation from LVF Data

Example 221 Flow 2 usage

configure –lvf
characterize
model –lvf –aocv -pocv

The above commands will generate both AOCV and POCV side files. The
POCV files will be merged as in existing POCV flow. To generate only POCV
side files, set only the -pocv switch in the model command. Similarly, to
generate only AOCV derate tables, set only the -aocv switch in the model
command.
Location of generated models:
■
<charpt>/models/aocv
■
<charpt>/models/pocv

Additional Control Parameters

The following parameters can be used to control modeling of AOCV derates/
POCV coefficients:
■
lvf_to_ocv_input_pins — this parameter specifies a list of input pins
with which the OCV values are computed from LVF table when generating
OCV side tables
■
lvf_to_ocv_output_pins — this parameter specifies a list of output
pins with which the OCV values are computed from LVF table when
generating OCV side tables
■
lvf_to_ocv_method —this parameter specifies the method to select the
value from LVF table for AOCV/POCV computation (default is max)
■ lvf_to_ocv_slew_indices — this parameter specifies the list of slew
indices (starting with 0) with which the OCV values are computed from LVF
table when generating OCV side tables
■
lvf_to_ocv_load_indices — this parameter specifies the list of load
indices (starting with 0) with which the OCV values are computed from LVF
table when generating OCV side tables
■
aocv_num_stages — this parameter controls path depth in generated
AOCV models

330 SiliconSmart ACE User Guide

L-2016.03
 Chapter 7: Statistical Characterization
AOCV/POCV (Side File Format) Model Generation from LVF Data

The following example will have OCV values computed as minimum of LVF
data at 3rd slew and 3rd load grid point among A->X timing arcs.
Example 222
set lvf_lib ./lvf.lib
set_config_opt -cell $cell lvf_to_ocv_input_pins {A}
set_config_opt -cell $cell lvf_to_ocv_output_pins {X}
set_config_opt -cell $cell lvf_to_ocv_method min
set_config_opt -cell $cell lvf_to_ocv_slew_indices {2}
set_config_opt -cell $cell lvf_to_ocv_load_indices {2}
print_ocv_side_files -input_lib $lvf_lib -output_path ./models
-aocv -pocv

Generated models will be located in:

■
<output_path>/aocv
■
<output_path>/pocv
The following example will have OCV values computed as average of LVF data
at 1st slew/1st load, 1st slew/3rd load, 3rd slew/1st load, and 3rd slew/3rd load
grid points among A->X timing arcs.
Example 223
set charpt chp
Set cells {INV}
create $charpt
set_log_file $charpt/siliconsmart.log
exec cp configure.tcl $charpt/config/configure.tcl
set_location $charpt
set_config_opt -cell $cell lvf_to_ocv_input_pins { A }
set_config_opt -cell $cell lvf_to_ocv_output_pins { X }
set_config_opt -cell $cell lvf_to_ocv_method mean
set_config_opt -cell $cell lvf_to_ocv_slew_indices {0 2}
set_config_opt -cell $cell lvf_to_ocv_load_indices {0 2}
import -liberty ref.lib -netlist_dir ./netlists -ext .sp $cells
analyze_netlists –statistical
configure -fast -lvf $cells
characterize $cells
model -fast -lvf -aocv -pocv -output out_test

Generated models will be located in:

■
<output_path>/aocv
■
<output_path>/pocv

SiliconSmart ACE User Guide 331

L-2016.03
Chapter 7: Statistical Characterization
AOCV/POCV (Side File Format) Model Generation from LVF Data

332 SiliconSmart ACE User Guide

L-2016.03
 8
8

IBIS Characterization

This chapter describes IBIS support and characterization methodology.

SiliconSmart supports a subset of I/O Buffer Information Specification (IBIS)

5.0 modeling format. SiliconSmart provides enough coverage to be able to fully
support single-ended cells and differential-ended cells such as LVDS, and
USB. It also supports cells with programmable driver strengths and on-die
termination (ODT).
IBIS format describes the electrical behavior of the pad pin(s) of an I/O cell to
enable board-level signal integrity analysis without revealing the
implementation details of the cell itself. SiliconSmart can now capture the
additional characterization data needed for this modeling format and generate
the models.
The IBIS format requires more information about the cell and the intended
package than is required for other formats, such as Liberty. Accordingly, you
need to set additional modeling parameters to provide this information to
SiliconSmart. These parameters are prefixed ibis_ and are only needed
when generating IBIS models.
The following sections describe IBIS support in SiliconSmart:
■
Introduction to IBIS
■
Using IBIS in SiliconSmart
■
IBIS Appendix

SiliconSmart ACE User Guide 333

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

Introduction to IBIS
The following sections describe IBIS support and methodology:
■
IBIS Characterization Methodology
■
On-Die Termination (ODT) Support
■
Programmable Driver Strength Support
■
Example of ODT and Programmable Driver Cell Setup

IBIS Characterization Methodology

To generate IBIS models, SiliconSmart measures the following electrical
characteristics of a cell:
■
Dynamic Curve Measurement
■
Static Curve Measurements

Dynamic Curve Measurement

The dynamic (VT) curves are measured by attaching a load harness (fixture
in IBIS terminology) to the output being measured, applying the necessary
stimulus to cause the output to switch, and recording the voltage waveform
through the output pin. This methodology is illustrated in the following figures
for a single ended and a differential cell.

Figure 37 Generating VT curves for a single-ended (non-differential) cell

334 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

Figure 38 Generating VT curves for a differential cell

The resistive load ( R fixture in the circuit setup for generating VT curves) is set
with the pin type parameter ibis_default_r_fixture and has a default
value of 50 ohms. The curves are captured for both rising and falling waveforms
with the voltage source ( V fixture in the circuit setup for generating VT curves). If
left empty, it defaults to the rail voltages as specified by pintype parameters
logic_high_name and logic_low_name. The V fixture can be specified by
the user and it differs for non-differential and differential cells.
Example 224
# non-differential cells (i.e., single ended cells)
set ibis_vt_v_fixture_rising_non_differential_output {DVSS}
set ibis_vt_v_fixture_falling_non_differential_output {DVDD}

# differential cells – in case of LVDS

set ibis_vt_v_fixture_differential_output {VREF}

The reason why we have only one parameter for differential instead of two as in
the case of non-differential (single ended) output can be inferred by inspecting
the circuit setup for generating VT curves for a differential cell. Note that both
the inverting (PADN) and non-inverting (PADP) pins are connected to same
V fixture . Hence if input is falling (rising) then PADN is rising (falling) and PADP is
falling (rising). Thus for any given transition one of the outputs is falling and the

SiliconSmart ACE User Guide 335

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

other is rising. Hence there is no way to distinguish the transitions and thus we
have only one parameter for differential output.

Static Curve Measurements

This section discusses measurement of the following static curve types:
■
IV Curve Measurement
■
Clamping Measurement
■
User Parameters to Control Static Curve Generation
■
Differential Delay Measurement
■
Capacitance Measurement

IV Curve Measurement
The IV curve measurement also places a voltage source on the output pin,
shown in the following circuit setup for a single-ended (non-differential) cell, but
holds the input at a steady-state high or low voltage. Instead, the voltage at the
output PAD is swept over a voltage range and the current through the output pin
is recorded.

Figure 39 Generating IV curves for a single-ended (non-differential) cell

336 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

In the case of a differential cell, the complementary pin is set to a controlled

voltage source as shown in the following circuit setup for a differential cell.

Figure 40 Generating IV curves for a differential cell

In differential cells, sum of the voltages at the complementary pins is a constant

c , where c = V  PADP  + V  PADN  . Thus if one is sweeping the voltage at
V  PADP  = x , then voltage at V  PADN  = c – x is set using a voltage
controlled voltage source  VCVS  . SiliconSmart provides a parameter
ibis_iv_diff_pin_v_sum to set the constant c . For example, in the case
of USB1.1, this parameter is set as:
Example 225
# c = DVDD
set ibis_iv_diff_pin_v_sum DVDD

Clamping Measurement
The IBIS power clamp and ground clamp curves measure the current through
an input pin when held at a range of voltages while the cell is disabled. A

SiliconSmart ACE User Guide 337

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

voltage source is attached to the input pin as shown in the circuit setup below
and is swept over the same voltage range as the IV curves.

Figure 41 Circuit setup for generating Clamping curves for a single-ended (non-
differential) cell

Figure 42 Circuit setup for generating Clamping curves for a differential cell

338 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

At each voltage value the current through the input pin is recorded. In case of
differential cells, there is a slight modification to the methodology. If the voltage
is swept at PADN then the voltage at PADP is set to the same value using a
VCVS. This is done to prevent the current flow between PADN and PADP, a
situation which occurs in LVDS.
There is a special parameter ibis_input_pin_open which is useful in the
context of LVDS. During the LVDS characterization, input pin VREF needs to be
open only during the clamping characterization. This can be achieved in by
using the following statement in the control/*.inst file. Note that this is used in
the control/*.inst file not in the config/*.tcl file:
Example 226
set_config_opt -pin {VREF} -type ibis_clamping
ibis_input_pin_open one

Two pin type parameters, ibis_power_clamp_supply and

ibis_ground_clamp_supply, can be used to override the voltage range
independent of the parameters logic_high_name and logic_low_name,
respectively. These parameters can be set to the name of alternate supplies
defined with the add_opc_supplies command. If unset they default to the
same supplies as logic_high_name and logic_low_name. These
parameters typically only need to be set when characterizing cells tolerant of
greater input voltage swings than are driven.

User Parameters to Control Static Curve Generation

This section discusses various parameters used to control the IV and clamping
curve generation. One can control the voltage range over which the simulation
for IV and clamping curves is performed; also one can control the number
points that needs to be sampled in the voltage range that has selected.
Voltage Range
To determine the voltage range for the IV and clamping curves, SiliconSmart
finds the maximum voltage range (max_range), which is the largest difference
between logic_high_name and logic_low_name for each of the operating
conditions (say typ,worst,best) being characterized. The voltage range to
V max to V min is computed as follows:
max_range = max{typ,worst,best}(logic_high_name - logic_low_name)
Vmax = logic_high_name + ibis_above_rail_multiplier * max_range
Vmin = logic_low_name - ibis_below_rail_multiplier * max_range

In these equations, logic_low_name and logic_high_name are both

replaced by the actual voltages of the supplies for each operating condition.

SiliconSmart ACE User Guide 339

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

The pin type parameters ibis_above_rail_multiplier and

ibis_below_rail_multiplier control the voltage range. Both default to
1.0.
However, some circuits will fail to converge in the circuit simulator at the
extremes of these ranges, in which case the multipliers should be reduced. The
modeling code extrapolates as needed to fill in the missing regions as specified
in the IBIS format. The extrapolation is controlled by the pin type parameter
ibis_rail_extrapolate_linear. If the parameter is set to 1, the currents
are linearly extrapolated otherwise the currents are saturated.
Number of Points in Voltage Range
The number of points in the voltage range swept is determined by the
parameter ibis_clamping_iv_num_points. Note that this parameter is
used only if the ibis_clamping_iv_analysis_mode_dc (default: false)
parameter is set to true.
When ibis_clamping_iv_analysis_mode_dc is set to true, SiliconSmart
uses dc sweep to generate IV and clamping curves for the cell. The default
behavior for SiliconSmart is to use transient analysis to generate IV and
clamping curves. When transient analysis is used then
ibis_clamping_iv_num_points is ignored and only 25 points in the
voltage range are used to generate IV and clamping curves.
A special case arises when ibis_clamping_iv_num_points is set to a
number greater than 100 and dc sweep is on
(ibis_clamping_iv_analysis_mode_dc is set to true). Then
SiliconSmart uses Douglas-Peucker algorithm to reduce the number of points
to 90 so that it satisfies the IBIS requirement that not more than 100 points are
in the IV tables.

Differential Delay Measurement

The differential launch delay measurement is performed on all differential
output pairs. It measures the time delay between the two signals crossing the
50% point of their total voltage swing. Since the voltage swing depends on the
load harness and the operating voltage, the final voltage swing is determined
dynamically.

Capacitance Measurement
In IBIS, the parameter C_comp is used to represent the input or output die
capacitance. It is an all inclusive capacitance seen through the pad such as
transistor's parasitic capacitance. It does not include the package capacitance
which is accounted explicitly using the keyword C_pkg in the IBIS file.

340 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

The methodology to measure capacitance is the same as the one used in

Standard Cells. At the pad of interest, have a transitioning signal and find the
average current ( I avg ) over the time interval ( t ). Also note the voltage
difference ( V ) during the time interval. The capacitance is given by:

t
C = I avg  -------
V

Although the capacitance is nonlinear, IBIS approximates it using a single best

number for a given corner. The end-user has to manually determine the best
value of C_comp based on the system setup at hand. The value provided by
SiliconSmart gives a good starting point.

On-Die Termination (ODT) Support

SiliconSmart supports an on-die termination (ODT) implementation in IBIS
using the [Submodel] keyword.
The following sections describe this support:
■
Characterization
■
Post-Processing
■ Regression Method
■
Notes on Parameter Usage
■
Adding a Submodel Construct

SiliconSmart ACE User Guide 341

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

Characterization
The following setup illustrates the SiliconSmart ODT characterization
procedure using a simple circuit. In this circuit, the ODT is modeled as a simple
linear resistor from ‘pad’ to ground. This is referred to as ‘pulldown’ ODT.

Figure 43 Abstract IBIS Model with Pulldown ODT

Note: Pulldown ODT is modeled as a resistor.

Since the resistor ( R PD ) can be switched on or off, SiliconSmart does the

following:
■ Find clamping currents I with ODT switched off. Applying KCL at node x
off
p
in the circuit setup shown above:
I off = I x (1)
p

■
Find clamping currents I on with ODT switched on. Applying KCL at node x
p
in the circuit setup shown above:
I on = I x + I R (2)
p

■
Subtract the currents from I on by I off to get the ODT currents ( I R ):
p p

IR = I on –I off (3)
p p

342 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

Post-Processing
■ Either Pullup or Pulldown — When you have either pulldown or pullup ODT
as in PGPIO cells, the post processing is straightforward. The ODT currents
(IR) go under either the [GND Clamp] (for pulldown ODT) or [POWER
Clamp] (for pullup ODT). Note that these [GND Clamp] and [POWER
Clamp] go under the [Submodel] keyword.
■
Both Pullup and Pulldown — Consider the following IBIS model with both
pullup and pulldown ODT.

Figure 44 Abstract IBIS model with both pullup and pulldown ODT

Note: ODT is modeled as a resistor.

We state the major limitation of our postprocessing. If the switches S PD and

S PU are the same, that is S PD = S PU = S O then we require linear ODT for the
results to be exact in the regression method. Regression results are limited by
the severity of the nonlinearity.
The key elements in the circuit setup for characterizing cells with both pulldown
and pullup ODT, are the switches S PD and S PU . If they are controlled by
different signals, currents through the ODT can be calculated using the method
described in the Characterization subsection. Compared to the method
described previously, one needs to do one more characterization. The extra

SiliconSmart ACE User Guide 343

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

characterization involves finding clamping currents with only pullup ODT

switched on (note that pulldown ODT should be switched off).
But when the switches S PD and S PU are the same, that is S PD = S PU = S O , we
need approximate techniques to split the current between pullup and pulldown
resistor. This approximation is necessary because of the following. In the
presence of both pullup and pulldown ODTs, equation (3) becomes as follows:
I R = IR PD + IR PU = I on –I off = y (4)
p p

Note that y (the sum of currents through pullup and pulldown resistors) is
obtained over various sweeps of the voltage at ‘pad’ V PAD . Mathematically,
there are two unknowns but many equations. To obtain the best fit, the method
generally used is the linear regression. The result obtained will be exact if the
ODTs are linear. The method is limited by the severity of the non-linearity.

Regression Method
First one must find the current through ODT using simple circuit analysis in the
circuit setup for characterization with both pulldown and pullup ODT:

V PAD  V PAD – V DD 
IR PD + IR PU = ------------- + -----------------------------------
R PD R PU

This can be rewritten as:

– V DD
y = -------------- +  ---------- + ---------- V PAD
1 1
R PU  R PU R PD
(5)
This can be viewed as a first order linear regression equation:
y =  0 +  1 x (6)

where x can be interpreted as the voltage swept at PAD . Recall y represents

the current measured at PAD . On doing the linear regression you can obtain
the parameters  0 and  1 . Once  0 and  1 are obtained, the values of the
resistances R PD and R PU can be estimated. This is straightforward and it can
be obtained by inspection of Equations (5) and (6). In SiliconSmart only R PD is
estimated. Matching Equations (5) and (6), you get the following:
– V DD
 o = --------------
R PU

344 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

– V DD
 R PU = --------------
0
Similarly, consider the following equation:
 1 =  ---------- + ----------
1 1
 R PU R PD

which results in the following estimate for R PD :

1
R PD = ----------------------------
  – --------- 1 -
 1 R PU

By applying Ohm’s law one can find out the currents through the resistor R PD .
Note that linearity is assumed here. The current through R PU can be obtained
by subtracting the current through R PD from the total current measured at
PAD  y  . The current through R PU goes under [POWER Clamp] and current
through R PD goes under [GND Clamp] under the [Submodel] construct.

SiliconSmart ACE User Guide 345

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

Now that the SiliconSmart implementation has been shown, consider the
parameters that are used. The following code example goes into the control/
files that use these parameters:
Example 227
# Control file
set_config_opt -type ibis -to {PAD} state_partitions one
set_config_opt -type ibis -from {PAD} state_partitions one

# odt mode
set_config_opt -from PAD ibis_odt_mode {
TERM0&!TERM1 "150 ohm equivalent termination"
!TERM0&TERM1 "75 ohm equivalent termination"
TERM0&TERM1 "50 ohm equivalent termination"
!TERM0&!TERM1 "ODT disabled"
}

# one of the ibis_odt_mode’s should not be a part of

# either pullup or pulldown
# i.e. we need exactly one unterminated condition
set_config_opt ibis_odt_pullup_modes \
{TERM0&!TERM1 !TERM0&TERM1 TERM0&TERM1}
set_config_opt ibis_odt_pulldown_modes \
{TERM0&!TERM1 !TERM0&TERM1 TERM0&TERM1}

# default for ODT submodel is All, aka the table is going

# to be added for both receiver and driver
set_config_opt ibis_odt_receiver_only \
{TERM0&!TERM1 !TERM0&TERM1 TERM0&TERM1}

# set ibis_odt_linear_regression_min_scale 0.0

# set ibis_odt_linear_regression_max_scale 1.0
...

Notes on Parameter Usage

■
The signal combinations which lead to different ODT conditions is specified
using the keyword ibis_odt_mode.
■
The signal combinations that lead to pullup ODTs is specified using
ibis_odt_pullup_modes.
■
The signal combinations that lead to pulldown ODTs is specified using
ibis_odt_pulldown_modes.
• If you have an ODT that has both pullup and pulldown resistors, the
signal combination must be specified in both
ibis_odt_pullup_modes and ibis_odt_pulldown_modes.

346 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

■
The signal combinations that make the ODT work only in the receiving mode
is specified using ibis_odt_receiver_only.
■ The signal combinations that make the ODT work only in the driving mode
is specified using ibis_odt_driver_only.
• If the signal combination is not specified in either
ibis_odt_driver_only or ibis_odt_receiver_only,
SiliconSmart defaults to ODT being on for both driving and receiving
modes.
■
In the case of ODT that has both pullup and pulldown modes (as in the
previous example with the when conditions TERM0&!TERM1,
!TERM0&TERM1, TERM0&TERM1), there are two more parameters to control
the post-processing of data. Because the post-processing involves linear
regression for the case of having both pullup and pulldown modes,
SiliconSmart provides the following parameters so you can specify the
range over which the regression should be done.
• ibis_odt_linear_regression_min_scale (default = 0.0)
• ibis_odt_linear_regression_max_scale (default = 1.0)
The previous parameters scale the pullup reference and provide the range for
linear regression. Suppose the pullup reference is V DD ; the default data range
for linear regression would be as follows:
[0.0 × V DD , 1.0 × V DD = [0, V DD ]

Adding a Submodel Construct

While modeling ODT, the SiliconSmart tool generates the [Add Submodel]
keyword to model the clamping current differences (  ) between non-ODT
termination and the ODT termination. If you don’t need the [Add Submodel]
keyword and do not want to model the  currents, you can set
ibis_add_submodel to false.

SiliconSmart ACE User Guide 347

L-2016.03
Chapter 8: IBIS Characterization
Introduction to IBIS

Programmable Driver Strength Support

SiliconSmart can generate IBIS files for a cell with various drive strengths. The
following two parameters must be specified in the control file to generate IBIS
files for programmable driver cells:
■
ibis_prog_driver_mode
■
ibis_prog_driver_mode_name

Design of Experiments
Consider for example, a cell having p ODTs and q programmable driver
strengths; then SiliconSmart ends up doing p + q static (clamping and IV)
curve simulations. This is due to the fact that ODT simulations are not affected
by the active part of the circuitry and the programmable driver simulations are
done by using a single ODT setting (the setting which switches off the ODT, i.e.
no ODT condition). Hence if each simulation costs   f  time (where f is a
polynomial) then the time complexity is    p + q f  .
Thus by careful planning of experiments, SiliconSmart avoids the more costly
pq number of simulations and thus a more expensive    p + q f  runtime.

348 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Introduction to IBIS

The usage of these parameters is illustrated using the following example (which
must be entered in the control/*.inst file):
Example 228
#----------------------------------------------------------
# Control file
#----------------------------------------------------------...
set_config_opt -type ibis -to {PAD} state_partitions one
set_config_opt -type ibis -from {PAD} state_partitions one
#----------------------------------------------------------
# programmable driver strengths
# syntax: when_condition comment
#--------------------------------------------------------------
---------
set_config_opt -type ibis -to PAD ibis_prog_driver_mode {
!DRIVE2&!DRIVE1&DRIVE0 "14.9mA driver"
!DRIVE2&DRIVE1&!DRIVE0 "14.6mA driver"
!DRIVE2&DRIVE1&DRIVE0 "14.4mA driver"
DRIVE2&!DRIVE1&DRIVE0 "9.8mA driver"
DRIVE2&DRIVE1&!DRIVE0 "9.3mA driver"
(!(!DRIVE2+!DRIVE1+!DRIVE0)) "6.9mA driver"

# NOTE:
# You would write the Boolean
# (!(!DRIVE2+!DRIVE1+!DRIVE0)) as
# DRIVE2&DRIVE1&!DRIVE0
# But it was done that way to show the robustness of
# Siliconsmart when recognizing the Boolean expressions
}

#----------------------------------------------------------
# The name for driver strength to appear in the models.
# syntax: when_condition name
#----------------------------------------------------------
set_config_opt ibis_prog_driver_mode_name {
!DRIVE2&!DRIVE1&DRIVE0 "14_9"
!DRIVE2&DRIVE1&!DRIVE0 "14_6"
!DRIVE2&DRIVE1&DRIVE0 "14_4"
DRIVE2&!DRIVE1&DRIVE0 "9_8"
DRIVE2&DRIVE1&!DRIVE0 "9_3"
DRIVE2&DRIVE1&DRIVE0 "6_9"
}
#----------------------------------------------------------

Please note that when there are multiple clamping conditions (when
ibis_odt_mode has more than two when conditions) and IV acquisitions
(when ibis_prog_driver_mode has more than two when conditions), we
need a deterministic ordering of these acquisitions.

SiliconSmart ACE User Guide 349

L-2016.03
Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

The order will be determined by the comment in the ibis_odt_mode (for

clamping) and ibis_prog_driver_mode (for IV). SiliconSmart will sort the
when conditions based on the comment appearing next to the when condition.
Because of this, it is important that each comment be unique.

Example of ODT and Programmable Driver Cell Setup

Here is a simple example of a cell having both programmable driver strength
and ODT. The parameters ibis_prog_driver_mode_name and
ibis_odt_mode_name specify the conditions for programmable driver
strengths and ODT. In case of the ODT, one needs exactly one condition which
is neither pullup nor pulldown.
Example 229
set_config_opt ibis_prog_driver_mode_name {
!DRIVE "hi"
DRIVE "lo"
}

set_config_opt ibis_odt_mode_name {
TERM "50"
!TERM "ut"
}

set_config_opt ibis_odt_pullup_modes {TERM}

Using IBIS in SiliconSmart

The following sections describe using IBIS:
■
Configuration, Characterization, and Modeling
■
Using the active_pvts Parameter
■
C_comp Measurement
■
Setting Up SiliconSmart for IBIS
■
IBIS 5.0 Support

350 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

Configuration, Characterization, and Modeling

To generate the additional IBIS measurements, the cell must be configured with
the –ibis switch. This switch enables the IBIS measurements, in addition to
the standard timing and power measurements.
Once characterization is complete, the IBIS models can be generated with the
model command. The –ibis switch selects the IBIS format and writes the
models to the directory char_dir/models/ibis.
The following commands configure and characterize cells in a characterization
directory and then generate an IBIS model containing all of the cells:
Example 230
configure –ibis
characterize
model -ibis

Using the active_pvts Parameter

The IBIS format allows a model to contain information on a cell for one or three
operating conditions. This can be specified in SiliconSmart via the
active_pvts parameter. Additionally, the IBIS model is specific about
whether the order of the operating conditions must be typical, minimum, and
maximum when three are specified. Thus, the order of the operating condition
names in the active_pvts parameter must be in this same order. If only one
operating condition is specified then it is assumed to be a typical corner.
An example for the case of three operating conditions:
Example 231
# the order is (typ,min,max)
set active_pvts {TT SS FF}

In case of a single operating condition:

Example 232
set active_pvts {TT}

C_comp Measurement
This section describes generating IBIS files which automatically characterize
the input capacitance at the PAD using SiliconSmart. This input capacitance is

SiliconSmart ACE User Guide 351

L-2016.03
Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

called C_comp in IBIS parlance. In order for the C_comp to be computed

automatically, you might need to make a change in the add_table function of
the control/*.inst file.
Consider the following example:
■
PAD is an input.
No change in any of the files. When you use the new SiliconSmart you
should be able to see C_comp being characterized automatically.
■
PAD is an output.
Consider a LVDS cell which has the following control/*.inst file:

Example 233
# Pin definitions
add_pin A default -input
add_pin PWRDN default -input
add_pin OE default -input
add_pin PADP pad -output
add_pin PADN pad -output
add_pin VREF default -input

# truth table
add_table {
A OE : PADP PADN
0/1 1 : 0/1 1/0
1/0 1 : 1/0 0/1
- 0 : Z Z
}

The PADP/PADN has to appear on the input side of the truth table for the
C_comp characterization to occur. We need to rewrite the control/*.inst file
as follows:

Example 234
add_table {
A OE PADP PADN : PADP PADN
0/1 1 Z Z : 0/1 1/0
1/0 1 Z Z : 1/0 0/1
- 0 1/0/Z - : 1/0/Z -
- 0 - 1/0/Z : - 1/0/Z
}

352 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

■
PAD is an inout.
This is similar to the "PAD is an output'' case. Also pay attention to the pins
that are declared as output. For example, consider the following snippet in
the control/*.inst file:

Example 235
add_pin PAD pad -inout
add_pin Y default -output
add_pin PO default -output

It is important that Y and PO are defined. For example, they can be set to 0:
Example 236
add_function Y 0
add_function PO 0

Setting Up SiliconSmart for IBIS

This section describes how to setup SiliconSmart for IBIS. But first, we
summarize the different I/O architectures that are supported by SiliconSmart
IBIS.
The following sections describe this architecture and setup:
■
Cells Supported
■
Cell Examples
■
Final SiliconSmart IBIS Flow

Cells Supported
SiliconSmart IBIS supports the following I/O cells:
■ Single ended I/O cells
■
Differential I/O cells
• Validate IBIS models of differential I/O cells by generating eye diagrams.
■
I/O cells with On-Die Termination (ODT)
■
I/O cells with programmable drivers
■
I/O cells with both ODT and programmable drivers
■
I/O cells with open-sink and open-source configurations

SiliconSmart ACE User Guide 353

L-2016.03
Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

To turn on DC sweep for characterizing IV and clamping curves you need to set
the following in the config/configure.tcl:
Example 237
set ibis_clamping_iv_analysis_mode_dc true

Next, we list a complete control/*.inst files for different I/O cell architectures
supported by SiliconSmart. This will serve as a template for setting up cells for
IBIS characterization.

Cell Examples
The following cell examples are described below:
■
Open-Sink and Open-Source Cell
■
Differential Cell
■
Cell with Both ODT and Programmable Driver

354 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

Open-Sink and Open-Source Cell

Example 238
# file: charpt/control/OPEN_SRC_SINK.inst

# This is a version of the driver is an open source driver (PADP)

# and open sink (PADN) with the appropriate pullup/down resistors.
set_netlist_file [get_location]/netlists/OPEN_SRC_SINK.inc

add_pin A default -input

add_pin EN default -input
add_pin PD50 default -input
add_pin PU50 default -input

add_pin PADP ptype -output

add_pin PADN ptype -inout

# Notice that PADN is an inout and PADP is an output.

# To be correct, PADN must appear as both an input and
# an output in this table.
add_table {
A EN PADN : PADP PADN
0 1 Z : 0 1
- 0 Z : Z Z
- 0 0/1 : Z 0/1
}
set_config_opt -pin {PU50 PD50} dontcare_bias 0

# We need PADP/PADN pins to be in the IBIS model

set_config_opt state_partitions none
# PADP - open sink
set_config_opt -type ibis -to {PADP} -to_direction {ZL L}
state_partitions one
# PADN - open source
set_config_opt -type ibis -to {PADN} -to_direction {ZH H}
state_partitions one
set_config_opt -type ibis -from {PADP} state_partitions one
set_config_opt -type ibis -from {PADN} state_partitions one

# IBIS package values

define_parameters OPEN_SRC_SINK {
set ibis_package_r 18
set ibis_package_l 1e-9
set ibis_package_c 15e-15
}

SiliconSmart ACE User Guide 355

L-2016.03
Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

Differential Cell

Example 239
# file: /control/DIFF.inst
set_netlist_file [get_location]/netlists/DIFF.cir

# Pin definitions
add_pin A default -input
add_pin PWRDN default -input
add_pin OE default -input
add_pin PADP pad -output
add_pin PADN pad -output

# You need PADP and PADN on both sides to characterize

# c_comp automatically

add_table {
A OE PADP PADN : PADP PADN
0/1 1 Z Z : 0/1 1/0
1/0 1 Z Z : 1/0 0/1
- 0 1/0/Z - : 1/0/Z -
- 0 - 1/0/Z : - 1/0/Z
}

# instruct siliconsmart to use differential characterization

set_output_differential PADP PADN
set_config_opt ibis_iv_diff_pin_v_sum VSUM
set_config_opt -pin PWRDN dontcare_bias 1

set_config_opt state_partitions none

set_config_opt -type {ibis} -to {PADP} state_partitions one
set_config_opt -type {ibis} -to {PADN} state_partitions one
set_config_opt -type {ibis} -from {PADP} state_partitions one
set_config_opt -type {ibis} -from {PADN} state_partitions one

# alias pad names

set_config_opt -pin PADP ibis_pin_alias PADQ
set_config_opt -pin PADN ibis_pin_alias PADQC

Cell with Both ODT and Programmable Driver

This example can be adapted to cells with either ODT or programmble driver by
removing the parts which are not relevant. For example, if you are writing an

356 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

instance file for a cell with ODT only remove the parts which reference
programmable driver in the following instance file.
Example 240
# file: /control/ODT_PD.inst
set_netlist_file [get_location]/netlists/ODT_PD.net

add_pin PAD pad -inout

add_pin A default -input
add_pin READ default -input
add_pin DRIVE default -input
add_pin TERM0 default -input
add_pin TERM1 default -input

add_table {
A READ TERM DRIVE PAD : PAD
0/1 0 - - Z : 0/1
- 1 - - 0/1/Z : 0/1/Z
}

set_config_opt state_partitions none

set_config_opt -type {ibis} -to {PAD} state_partitions one
set_config_opt -type {ibis} -from {PAD} state_partitions one

# programmable driver parameters

set_config_opt -type ibis -to PAD ibis_prog_driver_mode {
!DRIVE "2mA driver"
DRIVE "1mA driver"
}

set_config_opt -type ibis -to PAD ibis_prog_driver_mode_name {

!DRIVE "2m"
DRIVE "1m"
}

# ODT parameters
set_config_opt -type ibis -from PAD ibis_odt_mode {
!TERM1&TERM0 "150 ohm equivalent termination"
TERM1&!TERM0 "75 ohm equivalent termination"
TERM1&TERM0 "50 ohm equivalent termination"
!TERM1&!TERM0 "ODT disabled"
}

set_config_opt -type ibis -from PAD ibis_odt_mode_name {

!TERM1&TERM0 "150"
TERM1&!TERM0 "75"
TERM1&TERM0 "50"
!TERM1&!TERM0 "unterm"

SiliconSmart ACE User Guide 357

L-2016.03
Chapter 8: IBIS Characterization
Using IBIS in SiliconSmart

# one of the ibis_odt_mode's should not be a part of either pullup

or pulldown
# aka we need exactly one unterminated condition
set_config_opt ibis_odt_pullup_modes {
!TERM1&TERM0
TERM1&!TERM0
}

set_config_opt ibis_odt_pulldown_modes {
TERM1&TERM0
}

# default for ODT submodel is All, aka the table is going

# to be added for both receiver and driver
# This one specifies submodel is for receiver only
# Using the equivalent ibis_odt_driver_only one can specify for
driver.
set_config_opt ibis_odt_receiver_only {
!TERM1&TERM0
TERM1&!TERM0
TERM1&TERM0
}

Final SiliconSmart IBIS Flow

Once control/*.inst file is setup, the IBIS models can be generated by executing
the following script in the SiliconSmart environment.
Save the following script as driver.tcl:
Example 241
# file: driver.tcl
# Let charpt = pvt
set_location pvt
configure –ibis
characterize
model -ibis

Then by issuing the following command, one generates IBIS models:

Example 242
% ls
driver.tcl pvt
% siliconsmart driver.tcl

The generated IBIS models can be found in charpt/models/ibis/ directory.

358 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

IBIS 5.0 Support

The SiliconSmart tool supports IBIS 5.0. To enable this feature, set the
following parameters in the configure.tcl file or use set_config_opt from the
run script or the SiliconSmart shell command line:
set ibis_version 5.0
set ibis_isso 1
set ibis_composite_current 1

where:
■
ibis_version — this parameter controls the IBIS version number written
to the IBIS files. The default version is 4.1.
■
ibis_isso — this boolean parameter controls the [ISSO_PU] and
[ISSO_PD] section in IBIS models. Note [ISSO_PU/PD] is supported in
IBIS from version 5.0 and above. The default setting is 0.
■
ibis_composite_current — this boolean parameter controls the
[Composite Current] section in IBIS models. Note that [Composite
Current] is supported in IBIS from version 5.0 and above. The default
setting is 0.

IBIS Appendix
The following sections describe additional IBIS options and information:
■
Model Name Syntax
■
IBIS Parameter Summary
■
IBIS Merging Utility
■
IBIS-AMI Model Support
■
Checking the Generated IBIS File
■
Frequently Asked Questions

SiliconSmart ACE User Guide 359

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

Model Name Syntax

The syntax for constructing the model name is as follows:
Mcounter_pin_name_prog_driver_when_cond_name_odt_when_cond_name
cell_name

Since IBIS restricts the model name to at most 40 characters in length,

SiliconSmart truncates the model name after 40 characters (for versions older
than 5.0, model name will be restricted/truncated to 20 characters). Consider
the following an example to illustrate model name generation. Assume you
have two pins PADP and PADN and the cell name is XYZ. Also, assume the
following are defined in the control file:
Example 243
set_config_opt ibis_prog_driver_mode_name {
!DRIVE "hi"
DRIVE "lo"
}

set_config_opt ibis_odt_mode_name {
TERM "50"
!TERM "ut"
}

There are two driving strengths and two ODTs, thus leading 2 x 2 = 4 IBIS
models for each of the two pins. The names are as follows:
Example 244
M0_PADP_hi_ut_XYZ
M1_PADP_lo_ut_XYZ
M2_PADP_hi_50_XYZ
M3_PADP_lo_50_XYZ
M0_PADN_hi_ut_XYZ
M1_PADN_lo_ut_XYZ
M2_PADN_hi_50_XYZ
M3_PADN_lo_50_XYZ

Note: The numbers in this example model might be switched. For

example, instead of M0_PADP_hi_ut_XYZ, you might end up
with M2_PADP_hi_ut_XYZ.

360 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

Pin Alias
The parameter ibis_pin_alias can be used to model the alias name of a
given pin. For example in the control/*.inst file to rename PADP as PADQ and
PADN as PADQC we need the following statements:
Example 245
set_config_opt -pin PADP ibis_pin_alias PADQ
set_config_opt -pin PADN ibis_pin_alias PADQC

Note: There is no dash before ibis_pin_alias as it is a full-fledged

parameter not a flag. This declaration will result in IBIS model
names starting with MPADQC instead of MPADN which was the
case in the SiliconSmart releases before 2009.xx.

IBIS Parameter Summary

The following sections describe the IBIS parameter types and usage:
■
IBIS Pin Type Parameters
■
IBIS Pin-Level Parameters
■
IBIS Cell-Level Parameters
■
Eye-Diagram Generation Parameters for IBIS Validation
■
Parameter Usage

IBIS Pin Type Parameters

IBIS characterization and modeling is controlled by a set of pin type parameters
and global parameters in the ibis_model parameter block. Most of these
parameters are optional or have reasonable default values that often do not
need to be adjusted. The pin type parameters, shown in Table 7, control the
characterization of the cell as described in the IBIS characterization
methodology section. The pin type parameters ibis_power_clamp_supply
and ibis_ground_clamp_supply must be set to the name of a voltage
supply defined in each operating condition with the add_opc_supplies

SiliconSmart ACE User Guide 361

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

command. The default values are the appropriate supply rails as specified by
the pin type parameters logic_high_name and logic_low_name.
Table 7 IBIS Pin Type Parameters

Parameter Description
(default value)

ibis_default_r_fixture Specifies the resistive load used when capturing

the IBIS VT curves.

(50 Ohms)

ibis_ground_clamp_suppl Specifies an alternate supply name to be used as

y the reference voltage during ground clamp
measurements.
(value of logic_low_name)

ibis_above_rail_multipl A multiplier used to determine the top of the power

ier clamp and IV curve voltage range in the equation,
VSS+ibis_above_rail_multiplier*(VDD-
(1.0) VSS). The default of 1.0 corresponds to a voltage
of 2*VDD (assuming VSS is ground). This
parameter takes a value in the range [0.0, 1.0].

ibis_below_rail_multipl A multiplier used to determine the bottom of the

ier ground clamp voltage range in the equation,
vss-ibis_below_rail_multiplier*(VSS-
(1.0) VDD). The default value of 1.0 corresponds to a
voltage of -VDD (assuming VSS is ground). This
parameter takes a value in the range [0.0, 1.0].

ibis_diff_pin_single_mo Setting this parameter to 1 will cause both of the

del differential pins to have a single model.

(0)

ibis_iv_diff_pin_v_sum This applies to cells whose outputs are differential.

When the outputs are differential and we are
(value of logic_high_name) characterizing at a pin PADN then its
complementary pin PADP is set to (c-V(PADN)).
This parameter specifies that constant.

362 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

Table 7 IBIS Pin Type Parameters (Continued)

Parameter Description
(default value)

ibis_power_clamp_supply Specifies an alternate supply name to be used as

the reference voltage during power clamp
(value of logic_high_name) measurements.

ibis_rail_extrapolate_l If either ibis_above_rail_multiplier or

inear ibis_below_rail_multiplier is not at its
default value of 1.0, this parameter comes into
(0.0) play as the simulation voltage range will be a
subset of the required IBIS voltage ranges. When
this parameter is set to 0, the current will be
saturated as SiliconSmart extrapolates the
voltages. When the parameter is set to 1, currents
will be linearly extrapolated.

ibis_vt_v_fixture_diffe The value of Vfixture whose outputs are

rential_output differential.

(values of logic_high_name
and logic_low_name)

ibis_vt_v_fixture_falli The value of Vfixture when the output is falling.

ng_non_differential_out This applies to cells whose output is non-
put differential (single-ended).

(values of logic_high_name
and logic_low_name)

ibis_vt_v_fixture_risin The value of Vfixture when the output is rising.

g_non_differential_outp This applies to cells whose output is non-
ut differential (single-ended).

(values of logic_high_name
and logic_low_name)

IBIS Pin-Level Parameters

The parameters shown in Table 8 control the IBIS model generation. With the
exception of ibis_c_comp_typ, all of the parameters are either optional or
default to reasonable values. None of the values are used by SiliconSmart for

SiliconSmart ACE User Guide 363

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

characterization. They are only passed through to the model. The IBIS format
allows each of these values to be specified on a per-model basis (again, a
model is associated with a pin in IBIS), so these parameters must be defined in
the parameter block ibis_model nested within a pin type.
Table 8 IBIS Pin-Level Parameters

Parameter (default value) Description

ibis_enable Set to Active-High or Active-Low to specify

whether an output pin is active-high or
(Active-High) active-low.

ibis_polarity Set to Non-inverting or Inverting to

specify whether a pin is an inverting or non-
(Non-inverting) inverting output.

ibis_c_comp_typ, The die capacitance of the pin not including

ibis_c_comp_min, package capacitances. These parameters
ibis_c_comp_max default to the value of the pintype parameter
ibis_c_comp. They can be overridden here.
(value of pintype parameter
ibis_c_comp)

ibis_c_series_typ, Specifies [C Series] value for the particular

ibis_c_series_min, corner. Also look at the description for
ibis_c_series_max ibis_r_series_typ.

ibis_cref, Specifies the capacitance, resistance, and

ibis_rref, voltage used in the test loads.
ibis_vref

(unset)

ibis_l_series_typ, Specifies [L Series] value for the particular

ibis_l_series_min, corner. Also look at the description for
ibis_l_series_max ibis_r_series_typ.

ibis_model_type Specifies one of the defined IBIS model types to

be written to the model. This parameter is set by
(Input, Output, or the tool automatically based on the pin direction,
Input_Output based on pin but may be overridden.
direction)

364 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

Table 8 IBIS Pin-Level Parameters (Continued)

Parameter (default value) Description

ibis_r_series_typ, Specifies [R Series] value for the particular

ibis_r_series_min, corner. Note that if both ibis_r_series_typ and
ibis_r_series_max ibis_c_series_typ is specified then SiliconSmart
will be using keywords [Rc Series] and [C series]
in the output IBIS file. Please refer to IBIS
Cookbook V4.0 (pages 80 – 84) for more details.
IBIS allows combinations of RC, RL and LC. RLC
is not supported and it defaults to RC.

ibis_vdd Specifies the supply voltage for the pin. This is

set automatically from logic_high_name for
(logic_high_name voltage for each pin and should normally not be set.
the pin)

ibis_vdiff Minimum voltage differential for differential pins.

(unset)

ibis_vinh, The minimum voltage for a high signal and the

ibis_vinl maximum voltage for a low signal.

(0.8, 2.0)

ibis_vmeas Voltage measurement reference used for

propagation delay measurements.
(unset)

IBIS Cell-Level Parameters

The parameters shown in Table 9 define the electrical aspects of the packaging
connected to the cell. SiliconSmart allows these to be defined at the cell level,
even though the IBIS format only allows them to be set once per file. If multiple

SiliconSmart ACE User Guide 365

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

cells are modeled to a single IBIS file, SiliconSmart uses the R/L/C values for
the last cell for which they are defined.
Table 9 IBIS Cell-Level Parameters

Parameter (default value) Description

ibis_package_c Specifies the capacitance of the package.

(unset)

ibis_package_l Specifies the inductance of the package.

(unset)

ibis_package_r Specifies the resistance of package.

(unset)

ibis_clamping_curve_make This is a Boolean parameter which applies to all

_monotonic the pins in the cell. If true the clamping curves of
the IBIS model are forced to be monotonic. This
(true) is because the IBIS syntax checker issues a
warning when non-monotonic values are
detected. The default value is true.

ibis_clamping_iv_analysi When set to true, SiliconSmart uses DC Sweep

s_mode_dc to generate IV and Clamping curves else uses
transient analysis to generate IV and Clamping
(false) curves.

ibis_clamping_iv_num_poi The number of voltage steps to use when

nts capturing the IBIS IV and clamping curve data.
This parameter is used only when the parameter
(90) ibis_clamping_iv_analysis_mode_dc is
set to true.

ibis_odt_driver_only For IBIS clamping, specifies if a particular ODT

mode (keyed by condition) is only for driver.
Similar to ibis_odt_receiver_only.

366 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

Table 9 IBIS Cell-Level Parameters (Continued)

Parameter (default value) Description

ibis_odt_linear_regression_max This parameter can be set to a floating point

_scale value between [-1.0,2.0]. If it is set to 0.5,
the regression uses data until
(1.0) 0.5*logic_high_name. The starting point of
the data range is determined using
ibis_odt_linear_regression_min_scal
e.

ibis_odt_linear_regression_min_ Used in ODT cells which have both pullup as well

scale as pulldown terminations. This parameter can be
set to a floating point value between
(0.0) [-1.0,2.0]. If it is set to -0.5, the regression
uses data from -0.5*logic_high_name. The
end point of the data range is determined using
ibis_odt_linear_regression_max_scal
e.

ibis_odt_mode Specifies the name for each mode. All ODT

modes must be defined here. It is used in
configuration to determine the state partitioning.

ibis_odt_pulldown_modes Specifies if a particular ODT mode (keyed by

condition) has a pulldown termination.

ibis_odt_pullup_modes Specifies if a particular ODT mode (keyed by

condition) has a pullup termination.

ibis_odt_receiver_only Specifies if a particular mode (keyed by

condition) has a pulldown termination.

ibis_use_exact_mode_name Specifies whether

ibis_prog_driver_mode_name and/or
(false) ibis_odt_mode_name is used directly to
construct model names. If not set, a mixture of
cell and pin information is used to construct
model names. The default value is false.

SiliconSmart ACE User Guide 367

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

Table 9 IBIS Cell-Level Parameters (Continued)

Parameter (default value) Description

ibis_single_pvt_corner_name If you have all the three corners (typ/min/max)

specified and you want to generate a single
(typ) corner file with min values, this keyword must be
set to min. This keyword is ignored when
generating IBIS data for all the three corners in a
single file.

Eye-Diagram Generation Parameters for IBIS Validation

SiliconSmart can generate an eye-diagram for the IBIS models of the
differential cells with the parameters shown in Table 10. Currently, this feature
is available for driver cells only. Once these parameters are set (in config/
configure.tcl), SiliconSmart generates IBIS models and runs eye-diagram
validation decks on the IBIS models automatically.
Example 246
# validation parameters
set ibis_validate_prbs_size 20
set ibis_validate_bit_time 1.35e-9
set ibis_validate_bit_slew 1e-10
set ibis_validate_input_pin_name "A"
set ibis_validate_terminating_resistor 100

Table 10 IBIS Eye-Diagram Generation Parameters

Parameter (default value) Description

ibis_validate_bit_slew Sets the slew input PRBS vector in validation

deck.
(0.1ns)

ibis_validate_bit_time Sets the bit time of input PRBS vector in

validation deck.
(1ns)

ibis_validate_prbs_size Sets the size of input Pseudo Random Bit

Sequence (PRBS) vector in validation deck.
(50)

368 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

Table 10 IBIS Eye-Diagram Generation Parameters (Continued)

Parameter (default value) Description

ibis_validate_input_pin_ Sets the input pin name in the IBIS validation

name deck.

ibis_validate_terminatin Sets the value of terminating resistor between

g_resistor differential plans in the IBIS validation deck.

Default: No resistance between

the differential pins)

Parameter Usage
For example, a typical pin type for an I/O pad to be used with IBIS would look
like this:
Example 247
pintype PAD->default {
set logic_high_name VDD3

# restrict the voltage range for the clamping measurements to

# avoid simulation errors.
set ibis_above_rail_multiplier 0.6
set ibis_below_rail_multiplier 0.5

# define the pass-through parameters

define_parameters ibis_model {
set ibis_vdiff 0.350
set ibis_enable Active-High
}
}

The cell-level parameters are set in a parameter block with the same name as
the cell. For example:
Example 248
define_parameters MYIOPAD {
set ibis_package_r 20
set ibis_package_l 1e-4
set ibis_package_c 1e-14
}

SiliconSmart ACE User Guide 369

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

The nested parameter values can be read using a scoping operator, similar to
Tcl namespaces, with the pin type name followed by the parameter block name.
For example:
Example 249
get_parameter PAD::ibis_model ibis_vdiff

IBIS Merging Utility

This section discusses an utility which is used when different corners have
different when conditions. For example: Say the odt_pullup_mode has
different when conditions:
Example 250
typ : !cond1&!cond0
min : cond1&!cond0
max : !cond1&cond0

The user needs to create three different characterization directories

corresponding to typ, min and max corners. Each directory is distinguished by
their differing when conditions (Here for example, the odt_pullup_mode).
Also one needs to set special parameters to let SiliconSmart know that files
generated at each corner will be used to merge into a bigger IBIS file
containing all the corners.
Finally one needs to create a new characterization directory merge to finally
merge the data into a single IBIS file. This is mainly done using the command
ibis_merge.

Using ibis_merge
Step by step instructions are given below.
SiliconSmart needs the following new parameters for ibis_merge in the
config/configure.tcl file:
■
Block parameter:
ibis_plan_for_corner_merge — Set to true or false. This switch
indicates whether the generated data will be merged with other corners into
one IBIS model. When set to true, SiliconSmart uses a unified voltage range
for all three corners.
■ Pin parameters:
• ibis_typ_pullup_ref

370 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

• ibis_min_pullup_ref
• ibis_max_pullup_ref
• ibis_typ_pulldown_ref
• ibis_min_pulldown_ref
• ibis_max_pulldown_ref
• ibis_typ_power_clamp_ref
• ibis_min_power_clamp_ref
• ibis_max_power_clamp_ref
• ibis_typ_gnd_clamp_ref
• ibis_min_gnd_clamp_ref
• ibis_max_gnd_clamp_ref
Consider the following rationale in regard to these pin parameters. Suppose
you are characterizing for a typ corner and you need information about min/
max corners so that you have a unified voltage range across all the corners.
The previously listed pin parameters help in capturing this information.
■
Normally, only the parameters ibis_typ_pullup_ref,
ibis_min_pullup_ref, and ibis_max_pullup_ref need to be
specified.
■
The parameters ibis_*_pulldown_ref, ibis_*_gnd_clamp_ref
default to gnd (0.0).
■
The parameter ibis_*_power_clamp_ref defaults to
ibis_*_pullup_ref.
■
With ibis_merge –typ typ_char_pt -min min_char_pt -
max max_char_pt cell_name:
• typ — identifies the typ corner.
• *char_pt — characterization point of the typ/min/max corner.
• cell_name — cell names that will be merged and appear in the final
IBIS model. SiliconSmart discards any cell that is not present in all three
corners with a warning or error.

SiliconSmart ACE User Guide 371

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

Consider the following usage example. Given the following characterization

points under the pvt directory, there are three characterization points for each
corner: max, min, and typ.
Example 251
[pvt] % ls
max min typ

[pvt] % cat typ/config/configure.tcl

# Only the interesting parts are listed here.

# Rest are removed

# … deleted …
define_parameters default {
# … deleted …
set active_pvts {TT}
set ibis_plan_for_corner_merge true
# … deleted …

pintype pad -> default {

# … deleted …
set ibis_typ_pullup_ref 1.8
set ibis_min_pullup_ref 1.7
set ibis_max_pullup_ref 1.9
# … deleted …
}

# … deleted …

create_operating_condition TT
set_opc_process TT [subst {
{.lib '[get_location]/process_models/xyz’ TT}
}]
add_opc_supplies TT VSS 0.0 VDD 1.00 DVSS 0.0 DVDD 1.80 VREF 1.2
vdiff_high 1.38 vdiff_low 1.04 VDD_REF 1.00 VSS_REF 0 DVDD_REF
1.80 DVSS_REF 0 BIAS 0.99 VSUM 2.4
set_opc_temperature TT 25

# … deleted …

372 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

The other characterization points min/max are similar to the typ

characterization point except for the fact that the active_pvts are different.
■ For the min characterization point, you define set active_pvts {SS}.
Also, assume that the SS is defined with operating conditions in the config/
configure.tcl file.
■
For the max characterization point, you define set active_pvts {FF}.
Also, assume that the FF is defined with operating conditions in the config/
configure.tcl file.
Next is the big step of merging these three files. First, create a new directory,
merge, in which you will merge and produce an IBIS file that contains all the
three corners:
Example 252
[pvt] % cp –r typ merge

[pvt] % ls
max merge min typ

SiliconSmart ACE User Guide 373

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

Now, you must edit the config/configure.tcl file. The edited file should appear as
follows:
Example 253
[pvt] % cat merge/config/configure.tcl
# Only the interesting parts are listed here.
# Rest are removed

# … deleted …
define_parameters default {
# … deleted …
set active_pvts {TT SS FF}
set ibis_plan_for_corner_merge false
# … deleted …

# first set active pvt to the following

set active_pvts {TT SS FF}

# … deleted …

create_operating_condition TT
set_opc_process TT [subst {
{.lib '[get_location]/process_models/xyz’ TT}
}]
add_opc_supplies TT VSS 0.0 VDD 1.00 DVSS 0.0 DVDD 1.80 VREF 1.2
vdiff_high 1.38 vdiff_low 1.04 VDD_REF 1.00 VSS_REF 0 DVDD_REF
1.80 DVSS_REF 0 BIAS 0.99 VSUM 2.4
set_opc_temperature TT 25

create_operating_condition SS
set_opc_process SS [subst {
{.lib '[get_location]/process_models/xyz’ SS}
}]
add_opc_supplies SS VSS 0.0 VDD 0.9 DVSS 0.0 DVDD 1.7 VREF 1.18
vdiff_high 1.38 vdiff_low 1.04 VDD_REF 0.9 VSS_REF 0 DVDD_REF 1.7
DVSS_REF 0 BIAS 0.92 VSUM 2.36
set_opc_temperature SS 125

create_operating_condition FF
set_opc_process FF [subst {
{.lib '[get_location]/process_models/xyz’ FF}
}]
add_opc_supplies FF VSS 0.0 VDD 1.1 DVSS 0.0 DVDD 1.9 VREF 1.21
vdiff_high 1.38 vdiff_low 1.04 VDD_REF 1.1 VSS_REF 0 DVDD_REF 1.9
DVSS_REF 0 BIAS 1.08 VSUM 2.42
set_opc_temperature FF -40

374 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

# … deleted …

The final step is setting the ibis_plan_for_corner_merge to false:

Example 254
set ibis_plan_for_corner_merge false

You are nearly ready to produce the merged IBIS file. All you must do now is
run the ibis_merge command and then issue the modeling command, as
follows:
Example 255
[pvt] % ls
max merge min typ
[pvt] % cd merge/
[merge] % ls
config control driver.tcl etc models netlists process_models
reports runtime siliconsmart.log

Consider the driver.tcl file:

Example 256
[merge] % cat driver.tcl
set_location .
ibis_merge -typ "../typ/"\
-min "../min/"\
-max "../max/"\
cell_name
model -ibis cellname -out driver.ibs

You have completed the steps necessary and can now call SiliconSmart:
Example 257
[merge] % siliconsmart driver.tcl

If you completed all the steps successfully, you will find driver.ibs in the models/
ibis/ directory.

SiliconSmart ACE User Guide 375

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

IBIS-AMI Model Support

The SiliconSmart tool supports the generation of IBIS-AMI models. To invoke
AMI, the following parameters need to be set in the configure.tcl file:
Example 258
# New AMI parameters (required)
# Instruct SiS to use an AMI flow
set ibis_ami 1

# define `n' tap FIR filter

# Syntax: set ibis_ami_taps {list of taps}
# Ex: A `5' tap filter
set ibis_ami_taps {-1 0 1 2 3}

# define weights for the taps

# It should have same length as taps.
# Syntax: set ibis_ami_weights {list of weights}
# Ex: The weights for a `5' tap FIR filter
set ibis_ami_weights {0.01 0.02 0.2 0.1 0.02}

# define sample_interval to use in AMI_Init() function

# recommended value is "bit_time/64", default value is 10e-12
set ibis_ami_sample_interval 2e-12

The above mentioned IBIS-AMI related parameters are supported only at cell-
level. You can not use the set_config_opt command to specify the
parameters at pin and pin-type level.
The below parameters and settings should be set carefully to reflect Rx/Tx
behavior:
■
nsamples — This parameter will affect impulse response accuracy. It is
recommended to set it to a value of power of 2, such as 128 or 256.
■
smallest_slew/default_slew/largest_slew/
explicit_points_slew — It is recommended to set the value to a
number smaller than actual signal rise time. A typical value would be
bit_time/5.
■
initial_delay — This parameter should be set to a reasonable value,
such as 10e-12.

376 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

■
trailing_delay — Since the LTI system impulse response has a long
settling time, set this to a value larger enough to allow the system to settle
down. Note that trailing_delay - initial_delay/
ibis_ami_sample_interval should equal nsamples. If not, an
extension of sampling points will be conducted.
■
stable_time — Together with trailing_delay, this allows the
SiliconSmart tool to gather enough data points for system transition. A
typical value is bit_time*10.

Checking the Generated IBIS File

Set the ibischk_cmd parameter in the configure.tcl or run.tcl file to set the
IBISCHK parser to check the generated IBIS file.
Specify the absolute path to the IBISCHK binary in the configure.tcl or run.tcl
file as shown below:
Example 259 Setting IBISCHK in the configure.tcl file
set ibischk_cmd ibischk_binary_path

Example 260 Setting IBISCHK in the run.tcl file

set_config_opt ibischk_cmd ibischk_binary_path

For example:
set_config_opt ibischk_cmd /u/username/bin/ibischk5

The above example could be used in the sis_cci>> prompt and run.tcl file.

Frequently Asked Questions

The following is a list of frequently asked questions by IBIS users:
■
How can I control the number of points in the VT waveform table in an IBIS
model?
■
Which parameter (nsamples or voltage_resolution) has the higher priority?
■
Why does SiliconSmart output [GND Clamp] tables in the entire range [-
VDD, 2VDD]?
■
How can I generate rising waveforms in IBIS for open_sink cells

SiliconSmart ACE User Guide 377

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

How can I control the number of points in the VT waveform table

in an IBIS model?
You can use the nsamples and voltage_resolution parameters to control
the error tolerance and the maximum number of points in a VT waveform An
example of its usage in the config/configure.tcl file:
Example 261
define_parameters default {
# ...
set nsamples 1000
# ...
}

pintype pad -> default {

# ...
set voltage_resolution 1e-9
# ...
}

Which parameter (nsamples or voltage_resolution) has the

higher priority?
What voltage_resolution does is that when SPICE dumps a waveform
with millions of points it reduces that to a manageable number. Let us say you
have a million points and the voltage_resolution is set to 1e-3. (i.e. you
need accuracy up to a milli-volt.) Suppose this resolution requires only 100
points in the waveform; SiliconSmart outputs only 100 points. If nsamples is
set to 30, SiliconSmart further reduces these 100 points to 30. In some cases,
SPICE may put fewer points in the tr0 than the number of nsamples. In this
case, there may be fewer data points in the model than requested by
nsamples.

Why does SiliconSmart output [GND Clamp] tables in the entire

range [-VDD, 2VDD]?
This is to make current values explicit to the circuit simulator and to avoid
double counting in the corner cases. It comes at an expense of consuming
more file space but it results in clarity. In case of [GND Clamp], the current
values will be zero in the range  V DD 2V DD  and for [POWER Clamp], the
current values will be zero in the range  0 2V DD  . Note that the [POWER
Clamp] voltage values are with respect to V DD .

378 SiliconSmart ACE User Guide

L-2016.03
 Chapter 8: IBIS Characterization
IBIS Appendix

How can I generate rising waveforms in IBIS for open_sink cells

You can do this by using add_user_stimulus. Suppose that the following is
the truth table found in the *.inst file for a open_sink cell:
Example 262
# Cell function definition.
add_table {
DO OE : PAD
0 1 : 0
- 0 : Z
}

The above will generate only falling (ZL) waveforms. To generate the rising
waveform for characterization, use add_user_stimulus as shown below.
Example 263
add_table {
DO OE : PAD
0 1 : 0
- 0 : Z
}

# generate ibis models

set_config_opt state_partitions none

# generate ZH (rising) waveforms in ibis simulation

add_user_stimulus {
{in {DO 1 OE 0 } out {PAD Z}}
{in {OE 1} out {PAD 1} meas {type delay from OE to PAD}}
}

# ibis_clamping
set_config_opt -type { ibis } -from PAD state_partitions one
# iv/vt table – filter using to_direction
set_config_opt -type { ibis } -to PAD -to_direction {ZH ZL L}
state_partitions one

# Also add the following to the config/configure.tcl

# under the appropriate pintype

set ibis_vt_v_fixture_rising_non_differential_output VDD

SiliconSmart ACE User Guide 379

L-2016.03
Chapter 8: IBIS Characterization
IBIS Appendix

380 SiliconSmart ACE User Guide

L-2016.03
 9
9

Generating Data Sheets

This chapter describes how to generate and customize data sheets.

A characterization data sheet summarizes the digital performance

characteristics of a library cell. Some of these characteristics include intrinsic
delay, output transition time, capacitance, constraints (setup, hold, removal,
and recovery times), dynamic energy, and leakage power.
You can generate data sheets for any characterized cells in the current
characterization directory.

Note: All data sheets are generated from the acquired characterization
data only. You cannot generate data sheets from existing Liberty
models.

The following sections describe the process of generating data sheets:

■ Using the generate_datasheet Command
■
Data Sheet Content
■
Customizing the Provided Data Sheet
■
Customizing Data Sheet Format and Content
■
Variable Substitution

SiliconSmart ACE User Guide 381

L-2016.03
Chapter 9: Generating Data Sheets
Using the generate_datasheet Command

Using the generate_datasheet Command

The generate_datasheet command generates data sheets for one or more
cells with the following syntax:
Example 264
generate_datasheet -output output_dir -parameter_blocks
param_block_list -operating_condition opc_list [-fast]-merge
[-file filename] cells

Most of the above switches can be used for further customization. In its
simplest form, the general usage of generate_datasheet is:
set_location charpoint
generate_datasheet

Note: Before using this command, it is necessary to first establish a

characterization location by using the set_location
command. This characterization directory must also contain
active cells. If a valid characterization directory location is
specified or does not contain active cells, using
generate_datasheet will return an error.

By default, output from generate_datasheet will be directed to:

/char_dir/reports/datasheets

Each data sheet is written to a file with the name cell_opc.html, where cell is
the name of the cell and opc is the name of the operating point (for example,
TBUFIX20_worst.html). A warning message is issued if any operating condition
(OPC) does not contain a specified cell.
One data sheet will be generated for every OPC of every cell. For example, for
two OPCs with three cells each, six data sheets will be generated. A master
index HTML will be generated per OPC, indexDataSheet_$OPCNAME.html,
which will link the individual data sheets of the cells from within.

382 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Using the generate_datasheet Command

See Also
■
Command: generate_datasheet

Usage Examples
To restrict or select cells for data sheet generation, specify the cells individually:
Example 265
generate_datasheet SDFFSXL TBUFIX20

To restrict or select OPCs for data sheet generation, use the

-operating_condition option:
Example 266
generate_datasheet -operating_condition {typ worst}

The above generates a data sheet for all cells for operating conditions typ and
worst.

Example 267
generate_datasheet -operating_condition {typ worst} SDFFSXL
TBUFIX20

The above generates a data sheet for the cells SDFFSXL and TBUFIX20 for
operating conditions typ and worst.

Example 268
generate_datasheet -output my_dir/ds_gen -operating_condition
{typ worst}

The above generates a data sheet for all cells for operating conditions typ and
worst. Using the -output option directs the output to my_dir/ds_gen instead
of the default location (this location is created, if necessary).

Example 269
generate_datasheet -output my_dir/ds_gen -parameter_blocks
{userparms *} TBUFIX20

The above generates a data sheet for the TBUFIX20 cell for all available
operating conditions. Output is stored in the my_dir/ds_gen subdirectory, which
is created if necessary. Parameters are obtained from the userparms block
and the default (ioreport) parameter block (default implied with *). If

SiliconSmart ACE User Guide 383

L-2016.03
Chapter 9: Generating Data Sheets
Data Sheet Content

parameters by the same name exist in both blocks, those in the userparms
block will override those in the ioreport block.

Cell Schematics
Cell schematics are generated in the data sheet when the following command
is included in your configure.tcl file:
Example 270
set graphviz_location [get_install_path]/etc/graphviz-2.26.3

Data Sheet Content

The exact content of the data sheet produced for any given cell depends upon
the cell type and the available characterization data.
The content of each data sheet table is described in the following sections:
■
Example Data Sheet Reports
■
Banner
■
Header and Subheader
■
Function
■
Attributes
■
Input Pin Capacitance
■
Delay and Output Transition Time
■ Constraint Results
■
Dynamic Energy
■ Leakage Power
■
Setup and Conditions

384 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Data Sheet Content

Example Data Sheet Reports

Below are examples of generated data sheets:
■
Simple Combinational Cell Data Sheet
■
Sequential Cell Data Sheet

SiliconSmart ACE User Guide 385

L-2016.03
Chapter 9: Generating Data Sheets
Data Sheet Content

Simple Combinational Cell Data Sheet

An example of a datasheet for a simple combinational cell is shown below:

386 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Data Sheet Content

Sequential Cell Data Sheet

A truncated example of a data sheet for a sequential cell is shown below:

SiliconSmart ACE User Guide 387

L-2016.03
Chapter 9: Generating Data Sheets
Data Sheet Content

Banner
The banner is the topmost block of the data sheet containing the main data
sheet title, subtitle, and graphics.

Header and Subheader

The header shows the cell name, cell description and company name. The
subheader shows the date and time on which the data sheet was generated
and the version of SiliconSmart which from which it was generated.

388 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Data Sheet Content

Function
A function description (such as Z = A&B) will be shown for cell outputs that
have such information present. Others can have a truth table shown.

Attributes
The attributes table shows the area attribute for the cell. Sequential cells will
also have a Flop Group table containing information from the ff() group.

SiliconSmart ACE User Guide 389

L-2016.03
Chapter 9: Generating Data Sheets
Data Sheet Content

Input Pin Capacitance

The input pin capacitance table shows the average capacitance for each input
pin. The Type column will indicate either input or inout.

Delay and Output Transition Time

This table shows the intrinsic delay and output transition time for every
input-to-output arc of the cell. Each specific arc is identified by a unique
combination of input-pin/input-signal-direction and output-pin/output-
signal-direction. The results for each are indicated for a specific input transition
time and output capacitive load. You can select the transition time and load.
It is possible that some cells are characterized with a constant load and/or
constant input transition time. In these instances it is possible that the columns
corresponding to the constant parameter (pin name and load) is missing.
Furthermore, a secondary load might be shown for a related output. If
nonconstant, two columns will be present for the given output (pin name
and load).

390 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Data Sheet Content

Constraint Results
This table is available only for sequential cells. The constraints table may
indicate any or all of the following: setup time, hold time, recovery time, removal
time, and minimum pulse width.

Dynamic Energy
This table shows the energy dissipated (or absorbed) by the device due to a
given signal event. The event reference can be an input pin or output pin.
Energy will be positive for absorbed power and negative for dissipated power.
Both cases are summarized in the table.
Input pin events shown in the table cause no change in any cell output (input
transition which does not cause an output transition), resulting in a change of
internal power only. These cases can be recognized by a missing cell output
pin and load in the table. Output events represent those events that cause a
change in a given target output. The result for this type of event represents
switching energy and can be recognized by the presence of an explicit output
pin (the event reference) and associated load. Other outputs might change, but
are not the designated target, but can be shown in another row. Again, you can

SiliconSmart ACE User Guide 391

L-2016.03
Chapter 9: Generating Data Sheets
Data Sheet Content

select the transition time and load conditions. An additional load can also be
shown on a related output.

Leakage Power
This summarizes the static power used by the cell with no signal activity for all
conditions. It will be reported for multiple when conditions when such are
available in the characterization data and Liberty model.

392 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Customizing the Provided Data Sheet

Setup and Conditions

This is a summary of the process, voltage, and temperature (PVT) under which
the cell was characterized. It also shows the locations of the characterization
point, data sheets, and data sheet configuration file.

Customizing the Provided Data Sheet

You can customize the data sheet provided with SiliconSmart. This involves
changing the supplied data sheet configuration file.
The following topics are described in this section:
■ Customization Options
■
Setting the Data Sheet Customization File
■
Modifying, Adding, and Overriding Parameters
■ Setting Transition Time and Load Pin Parameters
■
Reporting a List of Load/Slew Values

SiliconSmart ACE User Guide 393

L-2016.03
Chapter 9: Generating Data Sheets
Customizing the Provided Data Sheet

Customization Options
You have the following customization options:
■
Selection of input transition time(s) and output load(s) — if you do not
choose the input transition and output load values explicitly for reporting in
the data sheet, the SiliconSmart tool picks the values corresponding to the
default indices.
The default is the middle index for both. For example, if capacitance indices
are {0.0pf, 0.1pf, 0.2pf, 0.3pf, 0.4pf}, 0.2pf will be selected.
■
Units — you can select the desired units for time, capacitance, resistance,
power, energy, voltage, and current for the data sheet. These can be
different than the ones used for the Liberty model.
■
Titles and headings — you can change banner titles, cell description,
company name, and table captions.
■
Formatting — you can change the font face, font size, and any other text
attributes for any item in the data sheet.
■
Annotation — additional annotation can be added anywhere within the
report.
■
Table format — table borders, text attributes, base cell attributes, and
internal dividers can be customized.
The following sections detail how to customize the above options.

Setting the Data Sheet Customization File

Each customization option is controlled by setting applicable parameters in the
data sheet configuration file.
Whenever a new characterization directory is created, the SiliconSmart tool
automatically copies over a sample data sheet configuration file called
gends_config.tcl into the $charpoint/reports/ directory. If already present, this
file is not overwritten. This configuration file is consistent in structure and
function to other SiliconSmart configuration files.
If you want to use a custom gend_config.tcl, the location of the file can be
overridden by setting the gends_config_file parameter. This parameter

394 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Customizing the Provided Data Sheet

can be set through the flow file (run.tcl) or through the global configuration
settings file (configure.tcl).
Example 271
set_parameter gends_config_file current_directory/
gends_config.tcl

The file name specified using gends_config_file should be specified as an

absolute path. Otherwise, it will be relative to the reports subdirectory.
See Also
■
Parameter: gends_config_file

Modifying, Adding, and Overriding Parameters

You can modify or override existing parameters. These two actions are
distinguished in this section. You can also add new parameters for additional
data sheet customization.

Modifying and Adding Existing Parameters

The easiest way to modify existing parameters (or to add new ones) is to edit
the $charpoint/gends_config.tcl configuration file.
Just as configure.tcl contains a few basic parameter blocks such as default,
pintype, validation, liberty_model, etc., the gends_config.tcl has a
basic parameter block called ioreport. In its default form, the ioreport
block contains default values for numerous parameters which affect the data
sheet generation and customization process.
A sample ioreport block is shown as below:
Example 272
define_parameters -append ioreport {
set user_time_unit ns
set user_capacitance_unit pf
set user_resistance_unit ohm
set user_voltage_unit V
set user_current_unit A
set user_power_unit nW
set user_energy_unit pJ
#
set num_digits_after_decimal 4
}

SiliconSmart ACE User Guide 395

L-2016.03
Chapter 9: Generating Data Sheets
Customizing the Provided Data Sheet

If you want to add or modify some parameters, the -append option can be
used to avoid clearing the ioreport block each time new parameters are
changed or added. Parameters in the ioreport define_parameters block
can also be grouped to affect different aspects of the data sheet.

Overriding Existing Parameters

To redefine or update the parameter value in the same ioreport
define_parameters block, or define a new ioreport block with
-append and a different parameter value:

Example 273
#Customization 1
define_parameters -append ioreport {
set oload_typ 0.04219
set tin_typ 0.51
}

#Customization 2
define_parameters -append ioreport {
set oload_typ 0.2
}

Setting Transition Time and Load Pin Parameters

The default gends_config.tcl created by the SiliconSmart tool does not specify
any values for the input slew and output load indices used for reporting
measurement results in the data sheets.
When one of these parameters is omitted, the SiliconSmart tool selects a
default value from the list of characterization indices. It does this by selecting
the value corresponding to the middle index. Specifically, if there are N indices
for a given parameter, then the value at N/2th position is used (starting at
position 0).
For example, if load indices for an output are {0.01, 0.1, 0.35, 0.8,
1.2}, then the value 0.35 is used.
Use the parameters tin_typ and oload_typ for selecting slew and load
indexes. The SiliconSmart tool does not select an exact slew load point for
reporting (it will not interpolate between existing load/slew indices); it will select

396 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Customizing the Provided Data Sheet

a point that is nearest to the index point specified by the parameters described
in the existing table.
There are additional parameters available (mentioned in Table 11) to control
the input transition time for related and constrained pins for constraints.
The value to be specified for these parameters should be in Library units.
For example:
Example 274
index_1 = {1ps 10ps 17ps 22ps 28ps}
index_2 = {1fF 3fF 9fF 14fF 16fF}

In the above example, if tin_typ = 20ps and oload_typ = 10fF, then the
SiliconSmart tool selects 22ps from index_1 and 9fF from index_2.
Table 11 Parameter Type Descriptions

Parameter Type Description

oload_typ Load value for the target output of a measurement.

rload_typ Load value for a related output of a measurement.

tin_typ Input transition time value for the primary or target

input.

rtin_typ Input transition time value for a related pin of a

measurement.

ctin_typ Input transition time value for a constrained pin of a

constraint measurement.

Reporting a List of Load/Slew Values

It is possible to select a list of load/slew values to report in the data sheet,
rather than a single value. This will result in a table of delay/slew values in the
data sheet as opposed to a single value. This capability is currently valid only
for delay and slew values.

SiliconSmart ACE User Guide 397

L-2016.03
Chapter 9: Generating Data Sheets
Customizing the Provided Data Sheet

For example:
define_parameters -append ioreport {
set oload_typ_delay {0.00079 0.002054 0.00474}
set tin_typ_delay {0.014 0.022 0.038}
}

The result is shown below.

As previously mentioned, if the exact slew value/load value is not found, the
SiliconSmart tool will try to find the closest slew/load value from the existing
indices.

398 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Customizing Data Sheet Format and Content

Customizing Data Sheet Format and Content

While reviewing this section, refer to the default gends_config.tcl file in the
reports subdirectory of the characterization directory for examples and specific
settings of important parameters. When defining parameters, be careful if you
change the order of definitions. In cases, where a reference (e.g., var) is
made, the definition for the referenced variable must have been made prior to
the new one.
The following topics are described in this section:
■
General Report Settings
■
Table Settings

General Report Settings

There are parameters which determine some default format characteristics of
the report as described in Table 12. Unless otherwise specified, each
parameter specifies a valid HTML string which can have one or more
embedded parameters.
Table 12 Overall Report-Related Parameters

Parameter Name Description

banner This HTML text block describes the report banner

which currently displays the top graphics, main report
title, subtitle and the company name. This must be
defined after any parameters referenced within.

banner_title Specify the text for the report banner title, subtitle and
banner_sub_title company name as displayed in the report banner. By
company_name default, this is generic text (no HTML formatting). You
can decorate each with HTML tags such as font or
color overrides. Alternatively, the decoration can also
be done to the banner parameter.These parameters
are embedded directly into the definition of the
banner parameter.

SiliconSmart ACE User Guide 399

L-2016.03
Chapter 9: Generating Data Sheets
Customizing Data Sheet Format and Content

Table 12 Overall Report-Related Parameters (Continued)

Parameter Name Description

cell_description This is embedded in the header parameter and is

default_cell_descript meant to be a description following the cell name.
ion Each cell can have a different title. A cell’s description
can be specified by defining a parameter with the
name cell__description, where cell is the cell’s
name. If no parameter by that name is found, then a
default description is used, as identified by the
default_cell_description parameter. If
neither parameter is found, then the cell description
will be left blank.

cell_name This is embedded in the header parameter. The

name of the cell is automatically substituted by the
software so you won’t find definition for it in the
configuration file.

company_name This is a static parameter embedded with the header.

epilog This HTML string defines the closing HTML tags for
the data sheet. It should end with the appropriate
tags for ending the HTML body, but you can embed
additional footer text and parameters.

header This HTML text block defines the functional header

for the data sheet. It identifies the cell name, cell
description, company name, date/time when the
report was generated and SiliconSmart software
version. The company name is intended to be the
name of the company that produces the cell. In any
case, it can be changed to any value.

Each of these items is an embedded parameter. All

are embedded as late variables (for example,
@@cell_name@@). The only static embedded
parameter is company_name. The other late
variables are substituted during data sheet
generation. Refer to each parameter for details.

400 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Customizing Data Sheet Format and Content

Table 12 Overall Report-Related Parameters (Continued)

Parameter Name Description

image_dir This sets the path to the directory containing all

graphic images used in the report. The default setting
is reports/datasheets/images under the
characterization directory. A default stock images
directory is created during the create step.

image_title_bg These image files collectively set the landscape for

image_title_left the banner text and sets the report logo. Each of
image_logo these files resides in the images subdirectory defined
by the image_dir parameter.

prolog This HTML text block is used to provide the proper

HTML opening tag sequence for setting up the data
sheet. It contains the default settings for the report
font face and size.

software_version This is embedded in the header and is set by the

software during data sheet generation.

timestamp This is embedded in the header and is set by the

software as the time/date of data sheet generation.

If an area, such as the header or banner, is substantially redesigned, it is

advisable to replace or override the definition of the defining parameter. In
doing so, you might not need the embedded references. For example, if the
banner is redesigned you might not need the banner_title parameter. In
this case, you can delete the unused parameters.

Table Settings
There are parameters which determine some default format characteristics of
all tables generated by the software. Some of these are overall settings for
tables while others affect various types of cells or various types of tables.
Unless otherwise specified, each parameter specifies a valid HTML string

SiliconSmart ACE User Guide 401

L-2016.03
Chapter 9: Generating Data Sheets
Customizing Data Sheet Format and Content

which can have one or more embedded parameters. The following table
describes the parameters that set overall defaults for all tables.
Table 13 Overall Table Parameters

Parameter Name Description

row_gridline Specifies the default format for the internal grid lines
col_gridline between rows and columns, respectively. These are
overridden for cells around the table perimeter and for
cells adjacent to a row or column separator.

row_separator Specifies the format of a border that you can use to

col_separator distinguish between independent cells and
dependent cells and also inserted to divide captions
from data.

table_borders This is a Tcl list that sets the format for all four table
borders. The order of the border elements is {top-
border, bottom-border, left-border, right-border}.
Specifying * for any border element causes that
element to retain its current setting. Specifying none
causes no border to display.

table_font Determines the default setting for the font face and
table_font_size type for all tables.

Each table in the data sheet has a caption. You can set the content of these
captions with the parameters described in the following table.
Table 14 Specific Table Captions

Parameter Name Description

cap_table_title Caption for the input capacitance table.

constraints_table_tit Caption for the constraints table.

le

delay_table_title Caption for the delay and output transition table.

energy_table_title Caption for the dynamic energy table.

function_table_title Caption for the function or truth-table.

402 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Customizing Data Sheet Format and Content

Table 14 Specific Table Captions (Continued)

Parameter Name Description

leakage_table_title Caption for the leakage power table.

You can set most of the column headers for each table. There are different
column headers for each type of table. These are shown in the following table.
Normally, the headers are formatted with the col_header_fmt parameter.
Table 15 Table Column Headers

Parameter Name Description

delay_headers This specifies the column headers for all columns of

the delay and transition time table. The report will
display only those used.

energy_headers This specifies the column headers all columns of the

dynamic energy table. The report will display only
those used.

You can specify the format for cells within a table with cell prolog and cell
prototype HTML strings. The cell prolog is the HTML string that is written for a
cell as part of the HTML <td> tag opening sequence. This tag identifies the
start of a new cell in a HTML table. The cell prototype is the HTML string which
is populated with the actual table data. The prototype serves the purpose of
both formatting the data and determining how the field value(s) in the cell are
ordered and organized. There are different cell prototypes and prologs for each
different type of cell. These are described in the following table.
Table 16 Cell Prolog and Prototype Parameters

Parameter Name Description

col_header_fmt Specifies the default format for all column headers.

normal_cell_fmt Identifies the default or normal format for cells which

have no explicit setting and contain a single value,
generally non-numeric data.

numeric_cell_fmt Specifies the default format for all numeric cells

containing a single value.

SiliconSmart ACE User Guide 403

L-2016.03
Chapter 9: Generating Data Sheets
Variable Substitution

Table 16 Cell Prolog and Prototype Parameters

Parameter Name Description

pin_dir_cell_fmt Specifies the format of any cell that is used to show a

cell pin name and signal direction such as A(LH).

The prolog and prototype are grouped as a single parameter. The prolog is first
in the list followed by the prototype. The prolog is generally used to identify the
overall style of the cell (such as alignment, background, and so on). It can have
embedded parameters. For data values to be properly populated, the prototype
must contain one or more embedded field names. The software will search for
data in the table matching the field names. You should not modify the existing
field names in any way, but you can move them around or redecorate around
them. Field names have the form @@field@@.

Generating User-Supplied Truth Tables

You can use the datasheet_truth_table parameter to generate use-
supplied truth tables in the datasheet.
Example 275
set_config_opt -cell LATCH datasheet_truth_table { {D CK E Q(n)
Q(n+1)} {X X 0 Q QN} {0 R 1 0 1} {1 R 1 1 0} {X 0 X Q QN} {X 1 X Q QN} }

The above example will produce a truth table for a typical latch.

Variable Substitution
The stock data sheet makes ample use of variable substitution. Variable
substitution is primarily used to populate the data sheet with text or values that
is intrinsically variable (table values, timestamp, name of each cell, and so on).
You will see embedded variables in almost every data sheet HTML parameter.
Variable substitution occurs at three basic levels.
The following topics are described in this section:
■
Tcl-Level Substitution
■ Substitution by define_parameters Command
■
Late Substitution

404 SiliconSmart ACE User Guide

L-2016.03
 Chapter 9: Generating Data Sheets
Variable Substitution

Tcl-Level Substitution
The first level occurs directly from the substitution of variables by Tcl; in other
words, the use of $ variables in Tcl code. This method of substitution is not
commonly used within the data sheet configuration file.

Substitution by define_parameters Command

The second type of variable substitution, and most common, occurs within
each define_parameters command, which evaluates the various set
subcommands within the context of the parameter block being defined. A
reference made to a $ variable causes define_parameters to first search
for the parameter within the parameter block being defined or modified. If not
found, it searches the enclosing Tcl namespace for the variable.
Consider this example:
Example 276
set tin_typ 2.0
define_parameters –append ioreport {
set ctin_typ $tin
set tin_typ 1.0
set rtin_typ $tin
}

This assigns 2.0 to ctin_typ, 1.0 to tin_typ (in ioreport) and 1.0 to
rtin_typ. This works across definitions of the same block (when using –
append). This type of substitution does not apply to the set_parameter
statement because standard Tcl substitution rules will prevail.

Late Substitution
The last type of variable substitution is referred to as late substitution or late
evaluation. A variable that is evaluated late can be referred to as a late variable.
A variable can be tagged for late evaluation by placing the variable name
between two pairs of @@. For example, variable @@foo@@ will be evaluated late
during data sheet generation. Late evaluation is only useful when creating
custom data sheets.

SiliconSmart ACE User Guide 405

L-2016.03
Chapter 9: Generating Data Sheets
Variable Substitution

406 SiliconSmart ACE User Guide

L-2016.03
 10
10

Validating the Output Liberty File

This chapter describes using SiliconSmart validation tools.

The following validation tools are described in this chapter:

■ Qualifying the Liberty File with qualify_library
■
Comparing Liberty Files with compare_library
■
Running HDL Validation

Qualifying the Liberty File with qualify_library

The qualify_library feature is detailed in the following sections:
■
Introduction
■ Validation
■
Tolerance Adjustment
■
Addressing Failures
■
qualify_library Options
■
Example run.tcl Script
■
Viewing Results

Introduction
For successful IC design, it is necessary to check the libraries generated by the
characterization tool for consistency, accuracy, and completeness. The

SiliconSmart ACE User Guide 407

L-2016.03
Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

qualify_library feature enables validation of libraries generated by the

SiliconSmart tool to ensure their correctness when consumed by downstream
tools.
The qualify_library feature is built on top of the capabilities in the Library
Compiler tool from Synopsys. It supports validation of library files and provides
the following key features:
■
Faster cell-level distributed processing, allowing jobs to be run on compute
farms.
■
A comprehensive HTML-based interface for presenting and analyzing
results, including graphs and histograms.

Setup
Since the qualify_library feature is built on top of the features in Library
Compiler, it is necessary to specify the location of this executable. If it is
present in the your executable path (as indicated by a valid return value for the
which lc_shell command), it will be automatically picked up by the
SiliconSmart tool.
Alternately, you can explicitly specify the executable using the SiliconSmart
configuration parameter qualification_lc_shell, as shown in the
example below:
set_config_opt qualification_lc_shell /global/apps/lc_2014.09-
SP5/bin/lc_shell

Using qualify_library
The qualify_library check can be invoked on an existing SiliconSmart
characterization database by simply setting the location and invoking the
command in the tool shell.
The simplest invocation of the command is to invoke qualify_library with
a pointer to the library to be qualified, as shown below:
qualify_library test.lib

The full set of options supported by the command can be displayed using the
-help switch, as shown below:
qualify_library -help

See qualify_library Options for more information on qualify_library

options.

408 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

Results
The results of the qualification run are written out in HTML form, in a directory
titled qualification/html, in the characterization database, and can be viewed
using a browser to navigate to the index.html file. This will display a top-level
summary of results, and is designed to allow navigation to cell-level results
entirely within the browser.
See Viewing Results for more information on qualify_library results.

Validation
The qualify_library feature validates the library for the following aspects:
■
Library Compilation
■
Consistency Between CCST and NLDM Timing Models
■
Consistency Between CCSN and NLDM Timing Models
■
Voltage Range Check
In addition, the following optional checks are also provided:
■
Cell Sensitivity Check
■
Minimum Load Index
■
Data Ranges
These checks are invoked using the command-line switch below:
-check list_of_strings

where list_of_strings is a list of additional checks to run, selected from

the keywords sensitivity, and data_range as appropriate. Additional
checks may be added to the list as they are introduced.

Library Compilation
To ensure that the library is syntactically and structurally correct,
qualify_library compiles the library using Library Compiler, and reports
warning and errors.
The SiliconSmart tool allows users to suppress known compiler warnings using
the configuration option qualification_lc_suppress, which takes as

SiliconSmart ACE User Guide 409

L-2016.03
Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

argument, a list of valid Library Compiler warning ids, as shown in the example
below:
set_config_opt qualification_lc_suppress { warning_id_list }

Consistency Between CCST and NLDM Timing Models

This check verifies that the delays and slews obtained using the CCS-timing
models are consistent with NLDM values which represent measured data from
SPICE simulations and can hence be used as a reference to establish
accuracy to circuit simulation. Validation is performed at each index point of the
table, i.e., for every input transition and output load combination.

Consistency Between CCSN and NLDM Timing Models

This check verifies that the delays and slews obtained using the CCS-noise
models are consistent with NLDM values which represent measured data from
SPICE simulations and can hence be used as a reference to establish
accuracy to circuit simulation. Validation is performed at each index point of the
table, i.e., for every input transition and output load combination.
Consistency failures are shown in table form as shown below, and shows at
which slew/load point the models differ, and by what numerical criteria.

Figure 45 CCSN vs. NLDM failure table

410 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

Voltage Range Check

This check evaluates the ability of a library cell’s CCS-noise model to fully
transition between the rails. This enables detection of any models that do not
have a full swing for any reason. A fixed percentage tolerance of 5% is used
(i.e., 95% of full swing). The figure below shows this behavior for both rising
and falling:

Figure 46 Voltage range check behavior

Cell Sensitivity Check

The CCS-noise models of some cells can be sensitive in delay and slew to their
input driving waveform. Small distortions of the input driving waveform tail can
lead to significant changes in cell timing values. Such sensitivity is typically
seen at small slews and large loads.
In the check, the cell is driven by two inputs: a normal input that transitions fully
between the rails, and a clamped input that saturates at 95% of the rail, as

SiliconSmart ACE User Guide 411

L-2016.03
Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

shown below. If the difference between these two exceeds the threshold
specified by the user, an error is recorded.

Figure 47 Cell sensitivity check

A cell sensitivity failure is displayed in table format, as shown below:

Figure 48 Cell sensitivity failure table

Data Ranges
This feature performs a sanity check on the values in the library, ensuring that
they lie between specified minimum and maximum values. This check is
designed to detect any gross outliers or faulty values resulting from simulation
runaway conditions that may not be detected during characterization.

412 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

The ranges are specified using the SiliconSmart configuration parameter

qualification_data_range, which takes a list of model keywords and
values ranges, as shown below:
set_config_opt qualification_data_range { delay 0 0.1 transition
0 1.5 }

Currently the supported keywords are delay, transition, constraint,

energy, current, capacitance, dc_current, ccsn, and pg_current.

Minimum Load Index

This check is intended to flag the occurrence of a minimum load index for a
timing table, which is less than the smallest pin capacitance in the library. Such
a condition, if present, can degrade the accuracy of timing results from
downstream tools, that may have to perform extrapolation to get desired values.

Tolerance Adjustment
The validation checks in qualify_library use relative and absolute
tolerances which can be specified using the SiliconSmart configuration
parameter qualification_tol, as shown below:
set_config_opt qualification_tol {type rel_tol abs_tol}

where type can be one of the following:

■
delay — controls the tolerance of differences between CCS timing delays
and NLDM delays.
■ slew — controls the tolerance of the differences between CCS timing slews
and NLDM slews.
■
delay_ccsn — controls the tolerance of differences between CCS-noise-
based delays and NLDM delays.
■
slew_ccsn — controls the tolerance of the differences between CCS-
noise-based slews and NLDM slews.
■
delay_sensitivity — controls the tolerance of differences between the
compared delays from using an input waveform to full VDD and from using
an input waveform going to 95% of VDD.
■
slew_sensitivity — controls the tolerance of the compared slews from
using an input waveform to full VDD and from using an input waveform going
to 95% of VDD.

SiliconSmart ACE User Guide 413

L-2016.03
Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

■
voltage — controls the tolerance of input waveform to reach certain
threshold of the supply voltage. By default, the tolerance is set as 0.05 (5%
of vdd).
■
delay_interpolation
■
slew_interpolation
For example, to specify a tolerance value of 1% and an absolute tolerance of
0.02 library units for delay and a 3% relative tolerance and 0.04 library units for
slew, the specification would be:
set_config_opt qualification_tol {delay 0.01 0.02 slew 0.03 0.04}

If tolerance values are not specified for a type, the default values are used.
These default values are set in compliance with PrimeTime and the Library
Quality Assurance System, and can be obtained with the
report_check_library_options command in Library Compiler:
Relative tolerance for delay : 0.02
Absolute tolerance for delay : 0.005ns
Relative tolerance for slew : 0.03
Absolute tolerance for slew : 0.0075ns
Relative tolerance for ccsn delay : 0.03
Absolute tolerance for ccsn delay : 0.003ns
Relative tolerance for ccsn slew : 0.05
Absolute tolerance for ccsn slew : 0.005ns
Relative tolerance for sensitivity delay : 0.1
Absolute tolerance for sensitivity delay : 0.01ns
Relative tolerance for sensitivity slew : 0.15
Absolute tolerance for sensitivity slew : 0.015ns

Addressing Failures
The following list discusses possible cell failures and potential causes for them:
■
Consistency failure — This type of failure points to a need to examine
relevant characterization options, and possibly re-characterize the library
with new settings.
■
Voltage range failure — This type of failure also points to issues in the cell
circuit design and/or layout, and could be caused by internal leakage or
capacitive effects.
■
Sensitivity failure — This type of failure points to issues in the cell circuit
design and/or layout, and should be addressed there.

414 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

■
Data range failure — This type of failure may require an investigation into
the characterization flow to determine if the runaway value was caused by a
simulator failure or a modeling error.
■
Load index failure — This type of failure requires that the library be
recharacterized with a smaller minimum load index for the timing tables.

qualify_library Options
The simplest invocation of the command is to invoke qualify_library with
a pointer to the library to be qualified, as shown below:
qualify_library test.lib [-aggressor string]
[-sim_options string] [-cells list_of_strings]
[-check list_of_strings] [-slews list_of_strings]
[-loads list_of_strings] [-power_rails list_of_strings]
[-report_only] [-finesim] [-no_zip] [-first_load] string

The full set of options supported by the command is shown below:

[-aggressor string]
Aggressor cell name for glitch analysis.
[-sim_options string]
User-specified simulator options line.
[-cells list_of_strings]
List of cells to qualify.
[-check list_of_strings]
List of additional checks to run (index).
[-slews list_of_strings]
Slew points to use for correlation (mid, max, all, <fractions>).
[-loads list_of_strings]
Load points to use for correlation (mid, max, all, <fractions>).
[-power_rails list_of_strings]
Voltage supply names and pairs for non-pg libraries.
[-report_only]
Only compile results from existing data.

SiliconSmart ACE User Guide 415

L-2016.03
Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

[-finesim]
Use FineSim (default is HSPICE).
[-no_zip]
Do not gzip cell libraries.
[-first_load]
Include first load (not included by default).
string
Input library name.

Example run.tcl Script

Below is an example run script for using qualify_library:
set chp [pwd] set_location $chp
set_config_opt job_scheduler grid
set_config_opt normal_queue {-P bnormal -V -l qsc=i}
set_config_opt run_list_maxsize 50
set qualification_lc_shell /global/apps5/syn_2013.12-SP2/bin/
lc_shell
qualify_library [get_location] /models/liberty/example.lib

416 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

Viewing Results
In addition to the standard SiliconSmart directory structure, there is a new
directory called qualification being created in the char_point. This contains
all the qualification related data and also html files:

Figure 49 Qualification directory structure

To view the html report, launch the following command:

firefox char_point/qualification/html/index.html

which will show the html report as below:

Figure 50 HTML report

SiliconSmart ACE User Guide 417

L-2016.03
Chapter 10: Validating the Output Liberty File
Qualifying the Liberty File with qualify_library

The html report gives an overall picture of the tool version that is being used,
with an overall summary telling the number of failures, passes, and a brief
description on the per cell summary.
The user can click errors to debug more on which cell, which arc and which
slew load point has the failure occurred. Furthermore, it gives a broad
perspective for the user to analyze the data on the basis of histogram, which
tells how many points have correlated and how many points are out of
tolerance as specified by the user.

Figure 51 Cell histogram

418 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

Figure 52 Table map showing the errors

Comparing Liberty Files with compare_library

An important aspect of library qualification is comparing the library to a
reference. This library comparison is necessary for the following reasons:
■
The data volume is too large.
■ Version changes can cause slight numerical differences.
■ Logical expressions may be formatted differently.
■
Constructs may be reordered in a distributed flow.
The compare_library feature considers all of the above and presents
results in a hierarchical, user-friendly format.
This feature is described in the following sections:
■ Using compare_library
■
Comparison Tolerances
■
compare_library Options

SiliconSmart ACE User Guide 419

L-2016.03
Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

■
Output Files
■
Graphical User Interface

Using compare_library
The following sections describe using compare_library:
■
Basic Library Comparison
■
Numerical Comparison
■
Selective Comparison
■
Adding User-Defined Attributes for Comparison

Basic Library Comparison

A basic library comparison with compare_library will perform structural
comparison of two Liberty files.
For example:
compare_library -reference ref.lib -test test.lib

where the two Liberty files to be compared are specified with -reference and
-test.
This basic comparison checks for missing groups and attributes and considers
logical attribute values when matching groups, whens, etc. Non-numerical
attribute differences are also reported (group names, etc.).
This basic comparison does not check numerical value differences.

Numerical Comparison
To perform a numerical comparison of attributes and group values, you must
specify the -value switch, as shown below:
compare_library -reference ref.lib -test test.lib -value

The tolerances used in this comparison can be viewed with the -tolerances
switch. You can set these tolerances with set_config_opt. See Comparison
Tolerances for more information on tolerances in compare_library.
In addition, this comparison will compare 2-D tables whose x and y-variables
are swapped and perform value interpolation for 1-D and 2-D tables whose
index values differ.

420 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

Points compared are all printed in the appropriate .csv files and organized by
value type. See Numerical Data Files (*.csv) for more information.

Selective Comparison
By default, all cells in the libraries are compared. You can use the following
options with compare_library to select cells to compare and skip, or groups
to ignore during the comparison:
■
To compare only select cells:
compare_library -cells { cell1 cell2 ... }
■
To skip select cells:
compare_library -skip { cell1 cell2 ... }
■
To ignore select groups:
compare_library -ignore { group1 group2 ... }

Adding User-Defined Attributes for Comparison

By default, user-defined attributes in the libraries are not compared. To include
user-defined attributes in the comparison, you must specify the
-user_defined option as shown below:
compare_library -reference ref.lib -test test.lib -value
-user_defined

Note: When matching ECSM models, the -user option is required, as

ECSM models are defined as user-defined attributes and are not
part of Liberty syntax.

Comparison Tolerances
The following sections describe tolerances used for compare_library:
■
Viewing Tolerances
■
Specifying Tolerances
■
Tolerance Settings

SiliconSmart ACE User Guide 421

L-2016.03
Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

Viewing Tolerances
Use the -tolerance switch with compare_library to view current
tolerance settings, as shown below:
compare_library -tolerances

Which will show:

Info: capacitance : abs 0.0010 rel 0.0100
Info: cell_leakage : abs 5.0000 rel 0.0400
Info: ccs_noise : abs 0.0400 rel 0.0150
Info: ccsn_current : abs 0.0100 rel 0.0400
Info: ccsn_output_voltage : abs 0.0050 rel 0.0500
Info: current : abs 0.0400 rel 0.0100
Info: dc_current : abs 0.0100 rel 0.0400
Info: delay : abs 0.0050 rel 0.0200
Info: energy : abs 5.0000 rel 0.0400
Info: hold : abs 0.0150 rel 0.0400
Info: leakage : abs 5.0000 rel 0.0400
Info: max_capacitance : abs 0.0010 rel 0.0100
Info: max_transition : abs 0.0075 rel 0.0300
Info: miller_capacitance : abs 0.0010 rel 0.0100
Info: mpw : abs 0.0150 rel 0.0500
Info: nochange : abs 0.0150 rel 0.0400
Info: receiver_capacitance: abs 0.0010 rel 0.0100
Info: recovery : abs 0.0150 rel 0.0400
Info: removal : abs 0.0150 rel 0.0400
Info: setup : abs 0.0150 rel 0.0400
Info: sigma : abs 0.0500 rel 0.0500
Info: slew : abs 0.0075 rel 0.0300
Info: other : abs 0.0050 rel 0.0500

Specifying Tolerances
Tolerances can be specified for each type in library units, as shown below:
set_config_opt value_type_absolute_tolerance tolerance_value
set_config_opt value_type_relative_tolerance tolerance_value

For example:
set_config_opt delay_absolute_tolerance 0.0001
set_config_opt delay_relative_tolerance 0.002

A failure is flagged when a test value differs from the reference value by the
absolute and relative tolerances.

422 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

Tolerance Settings
Please note that some values share tolerance settings.
For example:
■
max_capacitance, receiver_capacitance, miller_capacitance
settings all come from capacitance.
■
cell_leakage settings come from leakage.
■
max_transition settings come from slew.
Additionally, a maximum relative difference (-max_rel_diff) option is
provided to capture gross outliers. These outliers are not included in the
statistics, and will be reported in the file outliers.csv.

compare_library Options
The compare_library command has the following syntax and options:
compare_library -reference ref.lib -test test.lib
[-output_dir dir] [-tolerances] [-value] [-user_defined]
[-verbose] [-gui] [-all_points] [-compare_ccst_voltage]
[-sigma_error_1] [-max_rel_diff double] [-cells cells]
[-skip_cells cells] [-ignore_groups liberty_groups]
[-compare_values liberty_groups]

[-reference ref.lib]
Reference library path.
[-test test.lib]
Test library path.
[-output_dir dir]
Specifies the output directory location.
[-tolerances]
Prints current tolerance settings and exit.
[-value]
Compare numerical data values.
[-verbose]
Specifies verbose mode.

SiliconSmart ACE User Guide 423

L-2016.03
Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

[-gui]
Displays a GUI to examine results after the comparison.
[-all_points]
Writes all points to .csv file. Expect a runtime increase.
[-compare_ccst_voltage]
Compare CCS-timing voltage from CCS output_current models.
[-sigma_error_1]
Use normalized 3-sigma difference formula to compute relative error of
sigma values.
[-max_rel_diff double]
Maximum absolute relative difference that is not an outlier (-1 to deactivate).
[-cells cells]
List of cells to compare.
[-skip_cells cells]
List of cells to skip.
[-ignore_groups groups]
List of Liberty groups to ignore. The special keywords
ccs|ccst|ccsn|ccsp|lvf are supported.
[-compare_values groups]
List of Liberty groups whose values are compared. The special keywords
ccs|ccst|ccsn|ccsp|lvf are supported.)
[-user_defined]
Includes user-defined attributes from the libraries in the comparison.

424 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

Output Files
By default, results are written to a /compare_library directory located within
your current working directory. This location can be overridden by specifying a
different location with the -output_dir switch.
The following sections describe the files located in this directory:
■
Summary File (summary.log)
■
Difference Files (*.diff)
■
Numerical Data Files (*.csv)

Summary File (summary.log)

This directory contains a top-level summary.log file with a summary of all library
differences, as well as listing all library constructs that were not compared. The
information is provided in a 2-level hierarchy: library and cell. Auxiliary files
(*.txt) are intended to help with bookkeeping.

SiliconSmart ACE User Guide 425

L-2016.03
Chapter 10: Validating the Output Liberty File
Comparing Liberty Files with compare_library

An example summary.log file is shown below:

Reference: ref.lib
Test : test.lib
Cells : 1
----------
Tolerances: abs rel
----------------------------
capacitance : 0.0001 0.0200
ccs_noise : 0.0400 0.0150

FJSCGDSDFFQXC5: 1 ccsn_current value, 2 delay value, 1 energy

value, 6 hold value, 28 output_current_fall, 33
output_current_rise, 3 setup value, 2 slew value

Warning: skipping user-defined receiver_capacitance:char_when

comparison

Summary:
--------
0 library mismatches
1 cell mismatch

Group Mismatch Summary:

-----------------------
output_current_fall (28)
output_current_rise (33)

Value Mismatch Summary:

-----------------------
ccsn_current (273)
delay (94)

Each report also includes a table of value statistics.

Difference Files (*.diff)

A different file lists every group/attribute difference, one per line, and contains
the full context of the difference at library/cell level. Each line is intended to be
self-standing. Line numbers are included in libraries where the data is found.

426 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Running HDL Validation

An example .diff file is shown below:

adds attr pin_name_map [line 2729360 vs 2669646]

pin clkout timing ( related_pin:clk timing_sense:positive_unate

timing_type:combinational ) missing attr sensitization_master
[line 2729450 vs 2669735]

pin Q timing output_current_rise vector 1 ( related_pin:CLK

timing_type:rising_edge ) table has 15 values vs. 17 [line 2579472
vs 2592604]

Numerical Data Files (*.csv)

Numerical comparison data output is contained in *.csv files and contain all
relevant information for each value type comparison These files are organized
by value type, e.g., delay, slew, etc., and best viewed in associated programs
like Excel, OpenOffice, etc.
For performance reasons, only failing points are written to the .csv file. You can
specify the -all_points option to save all points at the cost of some run-time
and disk usage

Graphical User Interface

Specifying the -gui option will invoke a GUI after the library comparison. This
allows a more user-friendly examination of results.
This enables the graphing of numerical data, if compared. Scatter-plots and
error histograms are also supported. Library fragments for will be displayed for
each difference (when clicked).
Please note that loading a full library into the browser is prohibitively expensive
for large libraries and that a slight performance lag may occur when dealing
with large libraries.

Running HDL Validation

HDL validation (command validate_hdl) is used to cross-check the HDL
(Verilog) models with the corresponding Liberty models. This type of validation
is primarily useful in ensuring consistencies in the timing constructs produced
in the HDL model.

SiliconSmart ACE User Guide 427

L-2016.03
Chapter 10: Validating the Output Liberty File
Running HDL Validation

Verilog modeling must be completed before HDL validation is invoked. For

instance, model –verilog –output out from SiliconSmart ACE will
produce the Liberty file models/liberty/out_op_cond.lib and the Verilog files
out.v, out_udp.v and out_test.v in the models/verilog/ directory. SiliconSmart
will then verify the congruity of these sets of files.

Note: The SiliconSmart tool’s HDL validation utility uses multiple tools.
You must have access to and a license for all required tools
(VCS, PrimeTime) before running this utility.

The following phases comprise HDL validation:

■
SDF Generation
■
HDL Simulation
■
Timing and Function Verification
■
Reports

SDF Generation
The SDF file is generated from the Liberty model using an STA tool. Typically,
the Liberty model corresponds to the one generated by SiliconSmart ACE in
conjunction with the Verilog files during the modeling phase. However, for some
recharacterization flows, if an SDF (corresponding to the reference library) file
already exists, it is possible to bypass this step.
The SDF file is generated using two parameters:
■
sdf_source_tool_cmd — should point to the executable of the STA tool.
■
generate_sdf_cmd_file — should point to the file containing the
appropriate file tags (to substitute the locations of the Liberty/Verilog
models) and list of commands to the STA tool.
SiliconSmart uses pt_shell for the default value for
sdf_source_tool_cmd and also provides a generate_sdf.tcl in the

428 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Running HDL Validation

install_path/etc/validation/validate_hdl directory for the default value for

generate_sdf_cmd_file. The contents of this file are as follows:
Example 277
"set l /testlib"
"set rule_lib \$l"
"set m /work/top/top"
"import lib -lib \$l -case worst liberty_file"
"import netlist verilog_file"
"run bind logical -verbose -report_unbound \$m \$l"
"export sdf \$m -no_interconnect -version 3.0 sdf_file"

Clearly, the contents of this file must match the commands and switches
supported by the source STA tool. Furthermore, the options must be specified
to match the format produced during Verilog modeling. For instance, using
verilog_removal_as_hold=false during Verilog modeling combined with
–version 2.1 in the SDF generation command may produce errors because
SDF version 2.1 does not support removal constructs and must instead
interpret them as hold constructs.

HDL Simulation
HDL Simulation is used for timing and function verification of the Verilog
models. The simulators supported by SiliconSmart are Modelsim, NC, and
verilogXL. The parameters hdl_target_simulator and
hdl_target_simulator_path must be specified appropriately (see also
hdl_target_simulator_options).
This phase is comprised of the following checks:
1. Verilog compilation — Compiles the individual modules in the three HDL
model files. SiliconSmart creates modules for functional definitions, test
vector interfaces and UDP tables for flops/latches.
2. Verilog simulation — Runs a simulation of the test vectors provided in the
test bench against the functional definition in the UDP file. The test bench
file contains a simple error checking mechanism to compare the Boolean
simulator output with the values expected from the behavioral model. The
simulator also writes a Value Change Dump (VCD) file as it executes the test
bench vectors.

SiliconSmart ACE User Guide 429

L-2016.03
Chapter 10: Validating the Output Liberty File
Running HDL Validation

Timing and Function Verification

HDL simulators typically report back-annotation errors if there is an arc in SDF
that does not map to the Verilog data. However, it does not report a problem if
there is an arc in the Verilog data that does not have a corresponding SDF arc.
To address this mismatch, SiliconSmart provides a more robust check where
the VCD data is mapped to the values in the SDF file.
Each arc from the VCD file is captured and correlated with the corresponding
SDF arc while considering the overall state of the input pins. This type of
mapping checks for two possible scenarios:
1. If there is an arc present in the Verilog model that does not have a
corresponding entry in the SDF file.
2. If the delay in the VCD file matches the corresponding delay in the SDF file.
This check confirms that the simulator correctly interprets the back-
annotated data.
The results of this mapping operation are recorded appropriately for further
examination:
Example 278
# Run Liberty/Verilog modeling, verilog files from SiliconSmart
# model –verilog –create_new_model –output out

set_location char_dir

# Parameters for validate_hdl

set_parameter hdl_target_simulator VCS
set_parameter hdl_target_simulator_path
path_to_bin_that_contains_VCS

set_parameter sdf_source_tool_cmd "path [get_parameter validation

generate_sdf_cmd_file]"

validate_hdl -verilog -lib char_dir/models/liberty/

out_op_cond.lib -ver_file char_dir/models/verilog/out.v cells

Running this command will produce the char_dir/validation/validate_hdl

directory. The SDF data will be located in the char_dir/validate/validate_hdl/sdf
directory. For the sake of simplicity, SiliconSmart will split the large .sdf files into
individual cell SDF files in the cell_sdf_files directory. Errors during the SDF
generation process are reported in the sdf_source_tool.log file.

430 SiliconSmart ACE User Guide

L-2016.03
 Chapter 10: Validating the Output Liberty File
Running HDL Validation

The HDL simulation results are located in the char_dir/validate/validate_hdl/

verilog directory. Errors during compilation or simulation can be seen in the
VCS/verilog_compile.log or VCS/verilog_sim.log files, respectively.
The cell-specific simulation logs are found in the vsim_cell_test*.log files and
the cell VCD files are located in the VCS/vcd_dir directory. The VCD to SDF
mapping reports are located in the VCS/reports directory. The verilog/reports/
*summary.report file contains an overall summary across all the cells in the
Liberty model.

Reports
The VCD-SDF mapping compares the delay numbers from the VCD file
(generated from the HDL netlists and located in Modelsim/vcd_dir/cell.vcd) to
the delay numbers from the SDF file (generated from the Liberty and located in
sdf/cell_sdf_files/cell.sdf). Each cell’s detailed report is located in the
Modelsim/reports/cell.vcd_sdf_report file. An example of such a report is
shown below:
Example 279
timestamp A B Y Arc r/f VCD VCD SDF SDF
SDF Result

edge/cond delay(ps)edge/cond delay(ps) chosen

---------------------------------------------------------------
---------
20000 1* 1* 0*
20000 1 1 1 A->Y r (posedge A,A&&B) 0
0,0 Cond/Edge PASS
40000 1 0* 1
40000 0* 0 1
60000 1* 0 1
60000 1 0 0* A->Y f (posedge A,A&&!B) 0 0,0
Cond/Edge PASS

Where:
■
Timestamp — the time instant in the VCD file.
■
Ports — input and output port states. A * specifies that the pin changed state
from the previous timestamp.
■
Arc — the current transition in the VCD file that is considered for delay
annotation.

SiliconSmart ACE User Guide 431

L-2016.03
Chapter 10: Validating the Output Liberty File
Running HDL Validation

■
r/f — the rise/fall transition that occurs on the output pin.
■
VCD edge/cond — the current input pin state for the given transition.
■
VCD delay — the input to output delay in the VCD file at the given instant of
time.
■
SDF edge/cond — for the current edge/condition, the equivalent edge/
condition found in the SDF file, whose delays are suitable to consider in
matching the delay-annotation.
■
SDF delay — the delay chosen from the SDF that should be mapped to the
delay in the VCD file at the same state.
■
Result — the result of VCD and SDF delay correlation. N1 and N2 are delay
numbers found in SDF.
In addition, the verilog/reports/verilog_*_summary.report file contains an overall
summary across all of the cells in the Liberty model. An example of this file is
shown below:
Example 280
---------------------------------------------------------------
Cell Status
---------------------------------------------------------------
MUX4X1 Pass
NAND2X1 Fail
OR2X1 Incomplete -- Unmapped arcs to SDF
DFFX1 Pass

A status of Pass/Fail indicates a success or failure in the VCD-SDF mapping

process. A status of Incomplete indicates that the VCD-SDF mapping was
not attempted since either the VCD or SDF files were missing. This problem
can occur when Modelsim cannot perform a correct simulation due to errors in
the functional Verilog model.

432 SiliconSmart ACE User Guide

L-2016.03
 11
11

Timing Models

This chapter describes characterization and modeling methodologies for timing

measurements, signal integrity, and IBIS models in SiliconSmart.

SiliconSmart uses a number of techniques to capture the timing and power

characteristics of a cell-based on the selected options.
The following sections describe timing methodology in SiliconSmart:
■ Timing Measurements
■
Tri-State Enable and Disable Transition
■
Constraints
■ Constraint Styles

Timing Measurements
Timing characterization involves measuring the propagation delay through a
cell, as well as transition times, tri-state enable and disable times, and timing
constraints between two input signals.
The following sections describe these timing measurements:
■ Propagation Delays and Transition Time
■
Current Source Models
■
CCS Receiver Models
■ Maximum Capacitance Measurement for TIEH/TIEL Cells
■
Output-to-Output Timing Arc Support

SiliconSmart ACE User Guide 433

L-2016.03
Chapter 11: Timing Models
Timing Measurements

Propagation Delays and Transition Time

The most basic timing measurements measure the propagation delay through
a cell from an input to an output and the output signal transition time. For basic
combinational cells, this means applying a range of input transitions to the cells
over a range of output loads and measuring the delay and output transition
times. The results are two-dimensional tables of delays and transition times
indexed by input transition time and output load.
Propagation delays are measured from the time when the input transition
crosses the logic delay threshold to when the output transition crosses the
same threshold. The threshold is specified as a fraction of the voltage swing of
the pin by setting the pin type parameter prop_delay_level and defaults to
50%.
Similarly the output transition time is measured from the time when the output
signal crosses the low (high) threshold to when the signal crosses the high
(low) threshold for rising (falling) transitions. The thresholds are specified by
setting the pin type parameters logic_low_threshold and
logic_high_threshold. These parameters default to 20% and 80%,
respectively.
Some cells have multiple output pins that all switch in response to a single input
event. This case presents two options: sweep independent loads on each of the
output pins or sweep a load on only one output and apply a default load to the
others. SiliconSmart offers both options.
Sweeping an independent load on each of the switching output pins typically
results in the most accurate model. However, this results in significantly more
characterization time and a larger resulting model. Because the Liberty format
supports a maximum of three table dimensions, SiliconSmart only supports
sweeping the load on two independent outputs.
Sweeping the load on a single output and applying a default load to any other
output pins is a more typical characterization method. For I/O cells, it is
common for the two switching output pins to be the output pad and a chip-side
output. In this case, the load on the pad of primary concern and the chip-side
loads have relatively little effect. For details of how to select which mode to use,
see the Table Dimensions and Sweep Order section.

Differential Pins
Differential pins are a pair of pins that encode a logic value not by the absolute
voltage on either pin but instead the relative voltage between them. Because of

434 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Timing Measurements

this, propagation delay can not be measured to an absolute voltage, but must
instead be measured by looking at both signals.
To measure the delay from an input pin to a differential driver, SiliconSmart
samples both output pins and uses the crossover point as the delay threshold.
This makes the measurement insensitive to the absolute voltages being driven
by the output pins. When measuring delays from a differential receiver,
SiliconSmart uses the 50% point of the input transition. This is guaranteed to
be the same as the crossover point because the input transition times are
matched.

Current Source Models

Current source models are recent extensions to the Liberty format that
describe transitions as a waveform instead of as a single transition time.
SiliconSmart supports two formats: Effective Current Source Models (ECSM)
supported by Cadence in SignalStorm, and Composite Current Source models
(CCS) supported by Synopsys. The ECSM specification extends the Liberty
format by providing voltage waveforms for each point in the Liberty transition
tables and, optionally, input pin capacitance tables for each input pin. The
voltage waveforms are converted to current waveforms by the consuming tool.
The CCS format is similar, but stores current waveforms for each point in the
transition tables.
The ECSM waveforms record the voltage waveform produced by an output pin
for each slew and load point in the Liberty transition tables (see
rise_transition and fall_transition). The waveform data specifies a
set of voltage levels (normalized to 0.0 to 1.0) and the crossing times for the
signal. Each ecsm_waveform group in the Liberty file corresponds to one
point in the rise_transition or fall_transition table.
The input pin capacitance tables are indexed by input transition time and record
the capacitance seen by a driver in the transition from its initial state to the
switching threshold of the cell. This table is in addition to the Liberty
pin_capacitance attribute.
CCS waveforms record the current through the load capacitor at a set of time
points during the transition. The data is stored in the standard Liberty units.

SiliconSmart ACE User Guide 435

L-2016.03
Chapter 11: Timing Models
Timing Measurements

CCS also records a two-part receiver model for each arc that records the input
pin capacitance as seen by the driver, which is split into two parts:
■ CCS Timing Waveform Reduction

CCS Timing Waveform Reduction

SiliconSmart dynamically decides how many points are needed for each
current waveform based on their linearity. The balance between the vector size/
.lib size and waveform accuracy is controlled by the pin parameter
ccs_max_voltage_error. The default/recommended value is 0.005. When
CCS timing is enabled, each default-arc corresponds to a physical arc that can
be simulated.

CCS Receiver Models

Timing arc-level receiver models are modeled inside a timing() group and can
be modeled for all input pins from where a timing arc originates. Consider the
following example:
Example 281
A->Z in INV, CK->Q in DFF

In these cells because you have timing from A/CK, a receiver model can be
modeled inside the timing() group under the output pin Z/Q. There will be two
indices for receiver models, similar to the timing LUT table. The load index will
be the same as the timing LUT table’s load index but the slew index will be
measured or calculated as slew at input A/CK inside the deck for the timing arc.
The slew calculation is as per the SNPS specification, that is, the measuring
slew for a C1/C2 interval and then convert them into 100% and then convert
them into Liberty slew thresholds (as in 10-90%).
You can find different measurements into the deck.cir such as ccs_cin1,
ccs_cin2 as related to C1/C2 receiver cap value, ccs_tin1/2 related to
slew index value.
Pin-level receiver models are modeled inside a pin() group and typically
modeled for all those input pins from where no direct timing arc originates.
Consider the following example:
Example 282
D, SI, SE pins in scan-flop.

436 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Timing Measurements

Because there is no timing arc for these pins, a separate Cin_ arc is generated
by SiliconSmart for measuring pin capacitance. In this case, because there is
output like delay arcs, the receiver model is measured only for different input
slew indices by keeping the default load at the output pin. That’s why there is
only one index (slew) in receiver model at pin level.
Input slew index is an actual measured value, so there is a possibility that slew
index range may not be the same as slew index range in timing LUT tables.
(This is not the case for pwl driver but may happen with other drivers). If you
want to cover a whole slew range as in delay LUT tables in receiver models,
you can set the slew_matching_cin parameter.

CCS Receiver Capacitance Methodology

Timing modeling with CCS is composed of a driver model and a receiver
model. The CCS timing receiver model uses two capacitance values to model
the variation of cell input capacitance during the input signal transition. For
primetime delay calculation, the C1 value is used before the delay trip point has
been reached in the transition and the C2 value is used after the delay trip point
has been reached. This is true for both rise and fall transitions.

The C1 capacitance value is recommended to be chosen such that the current

produces a voltage that matches the value at the input delay trip point of the
cell. Similarly, the C2 capacitance value is recommended to be chosen such
that the current produces a voltage that matches the second slew trip point of
the cell.

SiliconSmart ACE User Guide 437

L-2016.03
Chapter 11: Timing Models
Timing Measurements

Following the above guideline within the SiliconSmart tool, C1 is computed by

simply integrating the current on the input starting the instant the input begins
to transition (or if using an active driver, the instant the transition on the active
driver begins) until the propagation delay threshold, where C1 = integ(I) is
divided by deltaV. There is no other post-processing or calculations done on the
C1 value.
For example, say vdd = 0.945 (50%VDD = 0.4725V):
.meas tran ccs_cin1__a__lh_t1 when v(a)=0.4725
.meas tran ccs_cin1__a__lh_v0 find v(a) at=t0
.meas tran ccs_cin1__a__lh_v1 find v(a) at='ccs_cin1__a__lh_t1'
.meas tran ccs_cin1__a__lh_q integ i(va_meter) from=t0
to='ccs_cin1__a__lh_t1'
.meas tran ccs_cin1__a__lh abs(ccs_cin1__a__lh_q/
(ccs_cin1__a__lh_v1-ccs_cin1__a__lh_v0))

The C2 value is computed in a similar manner, except the integration period is

from the prop delay threshold till the upper/lower slew threshold for the rising/
falling transition respectively.
For example, say that:
■
vdd = 0.945 (50%VDD = 0.4725V)
■
logic_high_threshold = 0.65*vdd
■
logic_low_threshold = 0.35*vdd
Then:
.meas tran ccs_cin2__a__lh_trig when v(a)=0.4725 td=t0
.meas tran ccs_cin2__a__lh_targ when v(a)=0.61425 td=t0
.meas tran ccs_cin2__a__lh_v0 find v(a) at='ccs_cin2__a__lh_trig'
.meas tran ccs_cin2__a__lh_v1 find v(a) at='ccs_cin2__a__lh_targ'
.meas tran ccs_cin2__a__lh_q integ i(va_meter)
from='ccs_cin2__a__lh_trig'
to='ccs_cin2__a__lh_targ'
.meas tran ccs_cin2__a__lh abs(ccs_cin2__a__lh_q/
(ccs_cin2__a__lh_v1-ccs_cin2__a__lh_v0))

Note that the NLDM input capacitance measurement uses a different

methodology and the values for CCS and NLDM caps are not expected to
match.

438 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Timing Measurements

Maximum Capacitance Measurement for TIEH/TIEL

Cells
SiliconSmart can measure the maximum capacitance a pin can drive to
produce the maximum slew/transition given as input for pins that have a non-
transitioning (fixed) output. With this feature, you can calculate maximum
capacitance for cells such as pull-ups and pull-downs where the output pin is
fixed at either logic high or logic low. This maximum capacitance is then
exported to the Liberty model.
To use this feature, issue the following command in the cell .inst file:
Example 283
set_cell_type tie -pin output_pin -state H|L

where:
■
-pin specifies the output pin that is being pulled logic high or logic low, and
■
-state specifies the logic state of the cell, that is H for logic high and L for
logic low.
This measurement is invoked when the configure command includes the
-timing switch. When this is enabled, it generates a new measurement
named maxcap during characterization.

Output-to-Output Timing Arc Support

SiliconSmart supports timing paths from one output to another output pin. This
is not, however, the default behavior. The default behavior for timing arcs is
from an input pin to an output pin. You can enable output-to-output replacement
arcs by setting the configure_delay_from_outputs pin type parameter in
the configure.tcl file or with the set_config_opt command. This
replacement arc is preferred for the case when an output is derived directly (or
through a very weak buffer) from another output and replaced respective to an
output pin arc.
For example, say in a flop there are two output pins Q, SO and clock (CK). SO is
connected to Q through a weak buffer or directly and in this case, the timing to

SiliconSmart ACE User Guide 439

L-2016.03
Chapter 11: Timing Models
Tri-State Enable and Disable Transition

the SO pin will have a loading effect on Q. So you would model Q->SO timing
arcs. This can be achieved as follows:
■ Through the set-config_opt command:

Example 284
set_config_opt usual_flags -pin SO
configure_delay_from_outputs {Q}
■
From the pin type block in configure.tcl:

Example 285
set_pintype_parameter configure_delay_from_outputs {Q}

Slew index values for such an arc will be slew measured at pin Q and load
indices will be load applied at SO pin while input slew at clock pin (in sequential
cell) will be controlled by default_slew pin type parameter. Because you are
modeling Q->SO arc, CK->SO arc will not be modeled.
SiliconSmart supports output to output arcs for NLDM and CCS Timing formats
only.

Tri-State Enable and Disable Transition

Tri-state enable and disable transitions are those that go from a high-
impedance disabled state to a driven voltage or from a driven voltage to a
disabled state, respectively. Both of these measurements require modifications
to the basic propagation measurements because the start or end of the
transition is not a defined voltage level.
Three-state disable describes the cell's behavior when it is relinquishing control
of a bus. These two modes have a significant impact on characterization. They
require additional measurements, some of which are unique to three-state
devices.
They also require the following considerations:
■
The three-state enable event can cause a new state to appear on the bus.
A state change occurs when the three-state driver attempts to apply a state
opposite to that left on the bus by a previous driver. No state change occurs
when the previous driver leaves the bus in the same state the current driver

440 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Tri-State Enable and Disable Transition

requires. Most model formats require propagation delay and output slew
information for this event and ignore the possibility that the state might not
have changed.
■
The three-state disable event never causes a new state to appear on the
bus. This is because the act of releasing control means the driver has no
influence over what state appears on the bus. Because no new state is
propagated, most model formats either do not require or do not model timing
information for the disabling event.
■
When an output pin is disabled, its pin capacitance must be reported to
accurately estimate the total load capacitance. Pin capacitance is measured
for three-state pins as it is for input pins. However, most model formats do
not deal with this capacitance completely and require adjustments to other
measurements. This will be described later in this document.
■
Contention occurs when one driver releases control of a bus at the same
time another driver is taking control of the bus. Functionally, this can result
in an ambiguous voltage on the bus that can cause signal integrity violations
elsewhere in the design. It is desirable to know how soon after a disable
event an enabling cell can take control of the bus. This is the primary
purpose of the three-state disable measurement: to avoid signal contention.
■
If contention is unavoidable, it is necessary to model its effect on dissipated
power.
Contention represents a brief low-resistance short circuit. The current flow
through this short circuit is considerably higher than that seen through CMOS
switching, which is a moderate-resistance short circuit of very brief duration.
However, most model formats do not support contention power modeling. For
this reason, SiliconSmart does not automatically measure contention currents.
The following sections describe the characterization methodologies applied to
three-state drivers.
■ Timing Measurements
■
Pin Capacitance

SiliconSmart ACE User Guide 441

L-2016.03
Chapter 11: Timing Models
Tri-State Enable and Disable Transition

Timing Measurements
This section describes the timing measurements that are unique to three-state
devices:
■
Three-State Enable
■
Three-State Disable

Three-State Enable
A cell captures control of a bus when it transitions from the high-impedance (Z)
state to either the low (L) or high (H) state. The load for the cell-under-test
(CUT) is configured as shown in Figure 53, and Figure 54.

Figure 53 ZH Transition Schematic

Figure 54 ZL Transition Schematic

442 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Tri-State Enable and Disable Transition

The measurement proceeds as follows:

1. A voltage-controlled resistance (shown in Figure 53 and Figure 54 as
element Rs) is attached to the output of the cell-under-test and is controlled
by the ideal stimulus applied to the enable pin. The purpose of the switch is
to hold the output state until the circuit is ready to take control of the output
node.
2. The switch is connected to a voltage source representing either logic_low
or logic_high as defined in the pin attribute block (PAB) for the output pin
under test. Which source it is connected to depends on whether the ZL or
the ZH timing arc is being measured. For most complementary metal-oxide
semiconductor (CMOS) circuits, the resistor is connected to either Vdd or
Vss.
3. The circuit is initialized with the switch closed. By default, the closed
resistance is 100.
4. As the simulation progresses, the switch transitions from closed to open,
permitting the CUT to take control of the output node. The default open
resistance is 1G.
5. The measurement is performed as the enable pin and output pin-under-test
change state.

Three-State Disable
A cell releases control of a bus when it transitions from either the L or H state to
the Z state. SiliconSmart ACE implements the three-state disable
measurement using output current rather than output voltage. This is done
because the act of releasing control does not generate an output transition that
is controlled by the CUT. The use of current therefore provides measurements
that are characteristic of the CUT and provides accurate timing to avoid
contention.
The load for the CUT is configured as shown in Figure 55and Figure 56.

SiliconSmart ACE User Guide 443

L-2016.03
Chapter 11: Timing Models
Tri-State Enable and Disable Transition

Figure 55 HZ Current-Based Network

Figure 56 LZ Current-Based Network

The measurement proceeds as follows:

1. An ideal voltage source (Vtri) is attached to the CUT’s output pin. Its value
is set to bisect the normal voltage swing on the pin. Therefore, the following
equation holds true:

Example 286
Vtri = (logic_high - logic_low) / 2

444 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Tri-State Enable and Disable Transition

2. As the simulation progresses, current flows through Vtri. During the HZ

simulation, current flows from Vdd through the Vtri as shown in Figure 55.
During the LZ simulation, current flows through Vtri to Vss as shown in
Figure 56.
3. Input slew is measured for the voltage transition that occurs on the enable
pin.
4. Propagation delay is measured from the voltage transition on the enable pin
to an appropriate current flowing through the ideal source on the output pin.
The default measurement trigger is 10 percent of the peak current flow.
Measurement trip points for the voltage transition on the enable pin reference
the same parameters for a traditional propagation delay measurement:
prop_delay_level and logic_*_threshold. The delay measurement
trigger for current is controlled using the prop_delay_current parameter No
output slew measurement is made during the three-state disable test. Such a
measurement has no meaning because no change of state is propagated. All
model formats that support a representation of three-state disable output slew
ignore any provided values.
The prop_delay_current parameter identifies a point along a current
transition just as the prop_delay_level parameter identifies a point along a
voltage transition. However, unlike the voltage measurement where both
beginning and ending voltages are known, SiliconSmart does not know the
maximum current (the enabled current). The minimum current is always
assumed to be zero (the disabled current).
SiliconSmart measures the maximum current during the simulation. The target
current used during delay measurement is then calculated as follows:
Example 287
I(max) * prop_delay_current

This equation differs from that used to calculate the target voltage because
I(min) is always assumed to be zero.
Figure 57, shows typical voltage and current waveforms for the HZ
measurement. The maximum current flow is measured while the CUT is active.
As the active high three-state control pin, en, is switched high to bring the
device into high impedance, the CUT stops sourcing current and current flow
begins to drop.
When the current reaches the specified current threshold point, the three-state
intrinsic delay measurement is performed from the propagation delay threshold
of the en pin to this current threshold point.

SiliconSmart ACE User Guide 445

L-2016.03
Chapter 11: Timing Models
Tri-State Enable and Disable Transition

Figure 57 Three-State Disable (HZ) Measurement

Pin Capacitance
Pin capacitance is acquired for all output-type three-state pins. It is identical to
the automatic acquisition of input pin capacitance.

Modeling Three-State Pin Capacitance

No model formats correctly account for three-state pin capacitance, and so
adjustments must be made to the model's construction.
The problem occurs when analysis engines attempt to use something other
than the three-state delay and output transition time tables (using Figure 53
through Figure 56 as examples, the A->Y delay arcs). Standard delay
measurements automatically and intrinsically account for the pin's capacitance.

446 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Tri-State Enable and Disable Transition

However, most analysis engines add pin capacitance to the total net load when
it is explicitly defined, as it must be for three-state pins. This means the pin
capacitance is counted twice when information other than three-state delay
information is used.
To compensate for this behavior, SiliconSmart adjusts the load-index for tables
other than three-state delay tables by adding the pin capacitance to every point
in the index. The result is a proper representation of delay and output transition
time under all conditions.
Occasionally I/O cell pad pins will exhibit significant leakage currents even
when disabled. In this case, the tri-state disable measurements can fail
because the output current never drops below the necessary threshold.
SiliconSmart can compensate for this by subtracting the steady-state leakage
current before finding the disabling threshold. To use this feature, set the pin
type parameter subtract_leakage to 1. This feature is not enabled by
default as it extends the simulation time to find the steady-state current and is
not frequently necessary.

Output Pin Capacitance on Bi-directional and Tri-state Pins

Liberty-format-based timers compute the pin capacitance of a net by summing
the capacitance attribute of every pin attached to that net, whether the pin is
driving the net or not.
When the tool looks up timing from an input pin to a bi-directional or tri-state
output pin arc, the effective output load includes the value of the capacitance
attribute on the non-driving output along with the interconnect capacitance and
the input capacitances of the fanout.
To correctly interpolate this into the cell's timing and power tables, the load
indices of the timing tables must be offset by the value of the capacitance
attribute. Once offset this way, the load lookup in the table will be correct.
The SiliconSmart tool automatically generates models with the load indices
correctly offset. The parameter subtract_pin_capacitance (default is 1)
controls this behavior; it can be changed it so loads are not offset, if you choose
to do so. If you have imported a .lib file that did not have the load indices
correctly offset, a warning will be issued related to this. When you generate a
recharacterized model you will notice that the load indices have been adjusted.

SiliconSmart ACE User Guide 447

L-2016.03
Chapter 11: Timing Models
Constraints

For example, the imported Liberty has the following load/slope information for a
timing/power table.
pin(Y) {
direction : output;
capacitance : 0.003473;
function : "A";
three_state : "!OE";
internal_power() {
related_pin : "A";
rise_power(energy_template_7x7) {
index_1 ("0.028, 0.044, 0.076, 0.138, 0.264, 0.516,
1.02");
index_2 ("0.0050534, 0.0075814, 0.0129534,
0.0236974, 0.0451854, 0.0878454, 0.174113");
values (" ....." );
}
....
}

After importing this Liberty, the load information in the instance file is:
set_config_opt -type { timing noise } -- explicit_points_load\
{ 1.5804e-15 4.1084e-15 9.4804e-15 2.0224e-14 4.1712e-14
8.4372e-14 1.7064e-13 }

Notice that each load point from the imported liberty has the pin capacitance on
pin Y subtracted from it. This adjusted load set is used for characterization.
While writing the model back out again, the SiliconSmart tool will offset the
loadset appropriately with the capacitance value on pin Y.

Constraints
Timing constraints examine the relative timing between two input transitions.
The transitions may occur on two different pins, such as in setup and hold
measurements, or on a single input as in minimum pulse width measurements.
In all cases the measurement seeks to find the minimum spacing that can
occur between the two edges before the cell fails to operate as expected.
The following sections describe timing constraints:
■
Setup/Hold Measurements
■ Path-Based Constraint Analysis

448 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

■
Methodology
■
Constraint Modes

Setup/Hold Measurements
SiliconSmart supports four methods of acquiring constraints: independent,
dependent, dependent-setup, and dependent-hold. Independent acquires the
constraint by running separate simulations for each constraint. In the case of a
setup measurement, the signal is held stable after the setup edge, equating to
an infinite hold value. Similarly, when acquiring the hold value, the setup time is
effectively infinite. This is the default for setup and hold measurements and
always used for recovery and removal measurements.
The three dependent modes capture the setup and hold constraints as two
measurements on a single pulse on the data pin in one simulation. These
modes exclude the possibility of a negative meta-stable region.
The measurement method for each of these modes is described in the
following sections.
■
Enabling the Measurement
■
Dependent Measurement Operation

Enabling the Measurement

The dependent and independent constraint mode is controlled via the
parameter constraint_mode. So, to enable dependent setup and hold
measurement, set the variable constraint_mode to dependent in the default
parameter block of the configure.tcl file. The variable's default value is
independent.

Dependent Measurement Operation

For each pair of setup and hold constraints, a combined_setup_hold
measurement is generated. This measurement combines the two
measurements into three cascaded optimizations:
■
First Optimization
■
PWL Inputs with Incomplete Edges
■
Operation with Active Drivers

SiliconSmart ACE User Guide 449

L-2016.03
Chapter 11: Timing Models
Constraints

First Optimization
First, a pulse width optimization is set up centered on the reference pin’s
prop_delay_level transition threshold. The optimization begins at a tiny
width (fixed at 1e-14) and expands until the output pin transitions correctly or
until the input pin's dependent_max_width is reached. See A of Figure 58.

Figure 58 Dependent Setup/Hold Diagram

Next, using the pulse found in the previous step, the setup edge is moved in
until the cell fails. See B of Figure 58. Finally, using the last non-failing setup
edge position, the hold edge is brought in until the cell fails again.
Optimizing the setup and hold edge after the initial pulse is important because
it allows the algorithm to account for cells in which the center of the pulse is
significantly offset from the clock edge. For example, this occurs in scan flops in
which the logic on the front the flop causes the minimum input pulse to occur
significantly before the clock edge. See C of Figure 58.
The results of the measurement are setup and hold tables indexed by the
transition time on the input pin and reference pin (clock). The transition times
used in the tables are the actual measured transition times, which may be
slightly different than the specified values when using active drivers.
The dependent-setup and dependent-hold modes work the same way as
dependent mode. The difference is in the initial conditions of the search. In

450 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

dependent-setup mode, the initial pulse is ahead of the clock edge. This
ensures that the valid pulse found in A of Figure 58, will be one with the hold
minimized. Phase B then finds the minimum setup given the hold value found in
phase A. In dependent-hold mode, the initial pulse is behind the clock edge.
This ensures that the valid pulse found in phase A will be one with the setup
minimized. Phase B does nothing, and phase C finds the minimum hold given
the setup value found in phase A.

PWL Inputs with Incomplete Edges

It is occasionally desirable to construct PWL stimuli in which an input edge
does not completely reach the target rail before the next edge begins. This
could happen if the edge slew is longer than allowed for by the PWL (certain
odd combinations of parameter settings can cause this), or if a constraint or
MPW search could pass with an incomplete (cratered) pulse.
It is possible to handle PWL inputs with incomplete edges. This is done by
detecting the potential for the condition and introducing a scaling parameter to
reduce the edge duration and voltage swing sufficiently so that the end of the
edge precedes the beginning of the next edge. This parameter is
constraint_pulse_cratering.
■
If constraint_pulse_cratering, is set to true, then the search range
for combined setup/hold and MPW are modified to allow cratered pulses. In
that case, the slew used is the requested, rather than the measured slew,
and the pulse is allowed to crater past the point where slew could be
measured down to the delay threshold. This will result in less pessimistic
setup+hold and MPW values for large slews.
■
If constraint_pulse_cratering=0 (the default), then no change
should be noticed in most cases.
Small differences in results may be seen where the end-to-start interval
between two edges is less than 0.5% of the first edge’s rail-to-rail time, or if
active waveform is being used and the measured waveform has a relatively
long tail. In addition, when using with constraint_mode=dependent-
setup/hold, smc_degrade should be set larger for the dependent
measurement, or constraint_dependent_margin should be used,
otherwise the independent edge will be pushed as far as possible and may
leave little room for improving the dependent edge with a cratering data pulse.

Note: This will result in a minor .sif change which may cause a cache
miss for constraints or max cap load search.

SiliconSmart ACE User Guide 451

L-2016.03
Chapter 11: Timing Models
Constraints

Operation with Active Drivers

When using active drivers, a load is attached to the driver output to achieve the
desired input slew to the circuit-under-test. Because the waveform for the data
pin in dependent mode must have a pulse, the driver load chosen will be a
compromise between the load required for the rising slew and the load required
for the falling slew. The choice is made by taking the union of the rise-derived
loads and the fall-derived loads and selecting the correct number of loads from
that list. The minimum and maximum loads are always selected. The other
loads are selected arbitrarily from the remaining loads. This produces an actual
input data slew index that is different from the desired setup and hold data
indices, but that covers the whole range of either. In the case in which the
desired setup and hold indices already accommodate the requirements of
dependent constraints with active drivers, the indices do not change.
One way around this issue is to use pwl or active-waveform driver modes. This
avoids the problem with differing pulse edge slews, but minimum pulse is
constrained to be a pulse for which the leading and trailing edge transitions
complete the rail-to-rail transition. This can result in pessimistic setup and hold
values for slow data slews.

Path-Based Constraint Analysis

SiliconSmart measures timing constraints, such as setup and hold, by
performing a search to find the position of the data edge relative to the clock
edge that forms the boundary between correct and incorrect cell operation. The
search begins with an initial guess (usually 0), expands the search interval until
the pass/fail boundary is bracketed, and then successively halves the search
interval until the interval is reduced to the specified resolution. For reasonable
resolutions (1-10ps) this will typically take 8-12 simulations. That number can
be considerably reduced with a very good initial guess. Path-based constraints
provide that good guess for setup and hold by measuring the delay from the
data and clock inputs to a critical internal node and then using the difference as
the initial guess.
Path-based constraint analysis speeds the acquisition of setup and hold by
analyzing the structure of the netlist and attempting to directly measure the
constraint values. The directly measured values are close approximations of
the transitional setup/hold values found with the bisection search described
above. Instead of using these values directly, SiliconSmart uses them as seeds
to the bisection search, significantly reducing the number of iterations required
to converge on the answer.

452 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

To perform path-based constraint analysis, SiliconSmart requires knowledge of

three nodes inside the latch structure (the master latch in the case of a flip-
flop). These nodes are:
■
Positive feedback node — This is the node in the feedback loop that is the
un-inverted function of the data expression.
■
Positive clock node — This is a node in the clock tree that is a positive
function of the input clock signal after all clock buffering. This is typically a
node close to one of the pass gates in the feedback loop.
■
Negative clock node — Similar to the positive clock node, this is a node is
that is the inverse of the clock input. Again, it is typically a node close to one
of the pass gates in the feedback loop.
Figure 59 illustrates these nodes in a simple latch circuit.

Figure 59 Latch Circuit

In Figure 59, node N1 is the positive feedback node. Notice that it is an un-
inverted function of the data input, D. This node should also not be gated by
pass-gates.
The positive and negative clock nodes are typically measured at the inputs to
the pass gates controlling the feedback loop. In this example, the nodes are
labeled EN and !EN.
The setup and hold times for this circuit can be calculated by measuring the
delay from D to N1 and the clock input to EN and !EN.

SiliconSmart ACE User Guide 453

L-2016.03
Chapter 11: Timing Models
Constraints

Enabling Path-Base Constraint Analysis

To enable path-based constraint analysis, each of the nodes described above
must be identified in the netlist and specified to SiliconSmart.
1. Add the internal nodes with the add_pin command.
2. Define the function of each internal node.
3. Specify the nodes to be used for each constraint measurement using
set_config_opt.
Adding the internal nodes is accomplished using the add_pin command to
define the name and specify the name of the node in the SPICE netlist. For
example:
Example 288
add_pin FB default -internal -spice_node N18:7 -no_model

This command creates internal node FB and specifies that the name of the
node in the SPICE netlist is N18:7. The -no_model switch is used to indicate
that this node should not appear in any of the resulting models. The pin type
default is used for this node. The positive and negative clock nodes must be
added similarly.
The function of each of the nodes must also be defined. Typically this is done
via the add_function command, for example:
Example 289
add_function FB D

This command merely indicates the node FB is a direct function of D. In

general, the function of the feedback node will be the same as the data
expression of the latch or flip-flop.
The last step is to specify which nodes are to be used for a given constraint by
using the set_config_opt command. There are three parameters that must
be set:
■ path_constraint_feedback — set to the name of the feedback node
(FB in the examples above).
■
path_constraint_enable_positive — set to the name of the positive
enable node.
■
path_constraint_enable_negative — set to the name of the
negative enable node.

454 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

In most cells, there is only a single latch structure (not counting any slave
latches in flip-flops) and the command looks something like this:
Example 290
set_config_opt path_constraint_feedback FB

Once the nodes have been defined, path-based constraint analysis must be
enabled via the global parameter path_constraint_mode. This parameter
is set in the default parameter block of the configure.tcl file. Setting this
parameter to the word polish tells SiliconSmart to use the path-based setup or
hold value as a seed to the standard search algorithm which polishes the
result, increasing or decreasing the value until the failure point is found. This
mode results in setup and hold values that are the same as not using path-
based constraints within one constraint tolerance (see the
constraint_resolution pin type parameter).
path_constraint_mode can also be set to verify. In this mode, SiliconSmart
uses the path-based setup or hold value and verifies that the cell functions at
this setting. If it does, no further refinement is performed-the value is not
decreased. If the cell fails the value is increased until the cell functions as
expected. This mode requires fewer iterations and is faster but produces more
conservative results.
The default value for path_constraint_mode is off, disabling path-based
constraint analysis and resulting in the use of the standard methods. See the
Measuring Path-Based Setup and Hold section for details on the methodology
used.

Example of Functional Description

Figure 60 shows a gate-level circuit describing a simple scan flop function. The
functional description of the cell would appear like this in the instance file:
Example 291
add_flop IQ IQN CK {D&SE | SD&!SE}

That is, the scan enable pin, SE, controls whether the data comes from the
standard data input D or the scan data input SD.

SiliconSmart ACE User Guide 455

L-2016.03
Chapter 11: Timing Models
Constraints

Figure 60 Simple Scan Flop Circuit

To set this cell up, the feedback node and the positive and negative enable
nodes must be identified and specified to SiliconSmart. In this case, N1:6 is
the positive feedback node because it is the feedback node of the master latch.
CK:14 and CK:7 are potential positive enable nodes. Either can be selected as
they are part of the same wire. Similarly, CKB:4 or CKB:6 can be selected for
the negative enable node.
The below example shows the Tcl code that creates the three internal nodes,
defines their function, and specifies the nodes to use via set_config_opt.
This code was automatically generated by the analyze_netlists
command. In most cases this description will be automatically generated, but it
may be necessary to create it manually for some cells.
Example 292
add_pin SISMART_FB default -internal -spice_node N1:6 -no_model
add_function SISMART_FB {D&SE | SD&!SE}
set_config_opt path_constraint_feedback SISMART_FB

add_pin SISMART_ENN default -internal -spice_node CKB:4 -no_model

add_function SISMART_ENN !CK
set_config_opt path_constraint_enable_negative SISMART_ENN

add_pin SISMART_ENP default -internal -spice_node CK:7 -no_model

add_function SISMART_ENP CK
set_config_opt path_constraint_enable_positive SISMART_ENP

The analyze_netlists command generates the add_pin commands using

the pin type specified by the parameter path_constraint_pintype. This
parameter is set in the default parameter block of the configure.tcl file. The
default value is default, meaning the internal pins will use the pin type
default.

456 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

Measuring Path-Based Setup and Hold

Path-based setup and hold comprise a race between the signals from the
switching data input to the feedback node, and from the clock input to the
enable_positive or enable_negative node. The constraint value is the
difference between these two delays. The eight possible measurements
({setup, hold} x {data rise, data fall} x {clock rise,
clock fall}) differ in which enable node is used and to which threshold the
delay is measured.
The feedback node is always measured at the switching threshold. The enable
nodes are measured at the low or high slew thresholds.
To understand path constraint setup and hold it is necessary to be clear about
the meaning of the enable_positive and enable_negative nodes. When
the latch is enabled (transparent) enable_positive/enable_negative
should be 1/0. When the latch is disabled (latched) enable_positive/
enable_negative should be 0/1. This is independent of particular clock pin
states, which may vary from cell to cell. The relation between the clock pin(s)
and the enable_positive/enable_negative nodes is determined by the
function specified for those nodes. This means that enable_positive=1
connects a data value 1 at the latch, enable_negative=0 connects a data
value 0 at the latch, enable_positive=0 connects the feedback 0 value and
enable_negative=1 connects the feedback 1 value. These relations
determine which delays and threshold are relevant for each constraint
measurement.
For a latch, the relevant clock edge is the disable edge–that is,
enable_positive/enable_negative transitioning from 1/0 to 0/1.
For setup to pass, SiliconSmart assumes the data input must cause the
feedback node to reach its switching threshold before the transistor connecting
that initial feedback value begins to turn on. So, if the feedback node is rising, it
must reach the switching threshold before the enable_negative node rises
to its lower slew threshold. If the feedback node is falling then it must reach the
switching threshold before the enable_positive node falls to its upper slew
threshold. This is a conservative estimate of the conditions necessary to
prevent the feedback node from falling back into its initial state instead of
completing its transition to the final state.
For hold to pass, SiliconSmart assumes the transistor connecting the initial
value of the feedback node has completed turning on before the feedback node
reaches its switching threshold. So, if the feedback node is rising, the
enable_negative node must rise to its upper slew threshold before the
feedback node reaches its switching threshold. If the feedback node is falling,

SiliconSmart ACE User Guide 457

L-2016.03
Chapter 11: Timing Models
Constraints

the enable_positive node must fall to its lower slew threshold before the
feedback node reaches its switching threshold.
Comparing the setup and hold measurements, the assumption is that for a
given data transition, if the feedback node reaches the switching threshold
before the enable node connecting the initial feedback value reaches its
beginning slew threshold, then the final value will be latched; if the feedback
node reaches the switching threshold after the enable node reaches its ending
slew threshold then the value will not be latched, and if it arrives between the
two thresholds, the result is indeterminate (neither setup or hold are satisfied).
It is possible to adjust the thresholds to achieve more optimistic or pessimistic
values from the path constraint measurements. The most convenient way to do
this is to define an alternate pin type block for use with path constraint nodes.
The thresholds associated with that pin type can be adjusted and will only
affect the path constraint measurements. The threshold parameters used are
the standard slew and switching threshold parameters. Threshold adjustment is
not generally necessary but might be desirable if the standard thresholds are
being adjusted in a way which would make the path constraints less accurate. If
a custom path constraint pin type is used, the parameter
path_constraint_pintype should be set to the pin type name before
running analyze_netlists.
Experiments have determined slew thresholds of 0.3 and 0.7 work well for
producing accurate path constraint measurements. This will vary with process
and library design. Notice that the exact threshold values used are not critical;
they will have some effect on performance, and for
path_constraint_mode=verify can produce more conservative results.
The final constraint step will guarantee that invalid setup and hold values are
never produced, and for path_constraint_mode=polish will guarantee
values as accurate as those produced without using path constraints.

458 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

For example, define the following in the configure.tcl file if the thresholds for
your default pintypes are other than 30% and 70%.
Example 293
pintype pintype_3070 -> default {
set logic_high_threshold 0.7
set logic_low_threshold 0.3
set prop_delay_level 0.5
}

define_parameters default {
set path_constraint_pintype pintype_3070
.
.
.
}

Be sure to run analyze_netlists after making these changes in the

configure.tcl file.

Methodology
This section describes the SiliconSmart constraint measurement
methodologies. The current trend with ASIC designs is to exploit the existing
technologies by reducing design margins and using innovative techniques.
Given this trend, characterization methodologies have increasingly gained
importance. SiliconSmart offers a wide variety of methodologies to measure
constraint values that can be selected depending on the specific design
requirements or flow. This section addresses all the major modes, styles, and
options that constitute or tune a constraint measurement methodology.
SiliconSmart includes four constraint modes that you can enable using the
constraint_mode parameter. These modes are as follows:
■ Independent Mode
■
Dependent Mode
■
Dependent-Setup Mode
■
Dependent-Hold Mode

SiliconSmart ACE User Guide 459

L-2016.03
Chapter 11: Timing Models
Constraints

SiliconSmart includes constraint styles that you can enable using the
smc_constraint_style parameter. These styles are as follows:
■ Pass-Fail
■
Relative-Degradation
■
Slew-Degradation
■
Delay-Reduction
SiliconSmart includes the following important parameters you can use
specifically for controlling constraint measurements:
■
smc_degrade (default is 0.1)
■
smc_degrade_absolute (10ps for relative-degradation and 0ps for slew-
degradation)
■
constraint_glitch_check (1, i.e., on.)
■
constraint_resolution (10ps)
■
set_config_opt -type constraint state_partitions (all/one)
■
path_constraint_mode (off)
■
constraint_dependent_margin (equal to constraint resolution)
■
model_neg_constraint_sum (1, i.e., on)
The previous parameters are specific to constraint measurements.
SiliconSmart also includes some additional more general parameters that can
be helpful. While the following parameters are useful for all kinds of
measurements, they can be particularly important for constraint
measurements:
■
default_load — capacitive load used for all constraint measurements.
■ largest_slew — largest input transition applied (impacts measurement
windows).
■ max_tout — largest output transition expected (impacts measurement
windows).
■
driver (default is pwl)
■
separate_cell_initialization (on)
■
glitch_high_threshold (default equal to logic_high_threshold)
■
glitch_low_threshold (default equal to logic_low_threshold.)

460 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

Constraint Modes
Constraint modes define the methodology used for the measurement of
constraint values. There are various methods to define and measure the
constraints between data and clock transitions.
The following sections describe constraint modes:
■
Independent Mode
■
Dependent Mode
■
Dependent-Setup Mode
■
Dependent-Hold Mode
■
Debugging Dependent Modes
■
Correction for Dependent-Setup & Dependent-Hold Constraint Modes

Independent Mode
SiliconSmart performs separate simulations for setup and hold measurements.
For setup measurement, the data is kept stable before the active edge of the
clock. For hold measurements, the data is kept stable after the active edge of
the clock.
Transition-based measurements are made for both setup and hold as far as
possible. That is, the output is initialized to an opposite state and a constraint is
considered to be met when the output makes a successful transition.
Setup and hold when conditions are kept the same if possible to ensure the
following formula holds true:
Example 294
setup+hold > 0

For more details, see the Negative Setup + Hold section.

Flow
Iterations begin with a zero constraint (setup/hold) value. SiliconSmart
compensates for data and clock slew values so that the initial (zero) constraint
is the same for all data-clock slew combinations measured between the
prop_delay_level of the signals.
When the initial simulation is successful, the constraint value is decreased in
successive iterations by exponentially larger values until a failure is detected.

SiliconSmart ACE User Guide 461

L-2016.03
Chapter 11: Timing Models
Constraints

When the initial simulation is unsuccessful, the constraint value is increased in

successive iterations by exponentially larger values until the simulation is
successful. Then a binary search algorithm is applied until the result is
accurate within the specified constraint resolution
(constraint_resolution).

Figure 61 Setup Measurement

Output (Q) makes a transition when the constraint is met for setup, hold, and
recovery measurements while it remains stable for removal measurements (for
edge-sensitive cells).

Figure 62 Hold Measurement

Recovery measurements are done in the same manner as setup

measurements. See Figure 63, which assumes that the asynchronous pin RST
is low active.

462 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

Figure 63 Recovery Measurement

Removal measurements are done in the same manner as hold measurements

except that the output is non-transitioning. See Figure 64, which assumes that
the asynchronous pin RST is low active.

Figure 64 Removal Measurement

Minimum Pulse width measurements are done by applying a minimum

(triangular wave) clock pulse in the first iteration. If the simulation is a success,
no further iterations are done. If not, a wide pulse (determined by max_cmpw) is
applied and a binary search algorithm is used to find the result within
constraint_resolution.

SiliconSmart ACE User Guide 463

L-2016.03
Chapter 11: Timing Models
Constraints

Figure 65 Minimum Pulse Width Measurement

Failure Detection
Simulation is judged as pass or fail based on criteria controlled by the
smc_constraint_style parameter. For more details, see the Constraint
Styles section.

Debugging
For debugging purposes, SiliconSmart creates a
setup__D__lh__CK__lh__ACQ_1.tar.gz file in the standard location inside the
runtime/spice directory. This is a setup simulation for a D pin moving from low-
to-high, a CK pin moving from low-to-high, and acquisition number 1. Multiple
acquisitions are present for multiple when conditions. It is a tar gzip database
that includes the following files and directories:
■
setup__D__lh__CK__lh__ACQ_1.sof.gz — simulation Output File (sof),
readable by SiliconSmart. It can be converted to a user-readable format with
the report_sim_results command.
■
setup__D__lh__CK__lh__ACQ_1.sif_number/ — a simulation directory for
iteration number; This directory contains SPICE decks and simulator output
files. deck.tr0 contains waveforms for important signals. A single SPICE
deck file deck.cir is created for all data-clock slew combinations. Iterations
begin from *.sif_0 and continue until a result is obtained for all the data-clock
slew combinations.

Dependent Mode
In dependent mode, a combined setup and hold measurement is made at the
same time. Because both constraints are applied at the same time, the
measured values are different and more pessimistic as compared to
independent mode, in which one constraint is kept at an almost infinite value.
When an active driver is used with dependent mode, rise and fall slew indices
are recalculated and the final slew index values can differ from specifications.

464 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

This is because the rise and fall data transitions occur within the same
simulation for dependent mode and it is not possible to achieve both exact rise
and exact fall slews from driver output. For more details, see the Setup/Hold
Measurements section.

Flow
The iterations begin with a very narrow pulse (approximately equal to a
triangular wave with small margin) centered around prop_delay_level of
reference pin, as shown in Figure 66 for Dependent Mode.

Figure 66 First Iteration with Approximately Zero Pulse Width for Dependent Mode

If the simulation is successful, no further iterations are done because data

pulse is an almost triangular wave shape and it is not possible to reduce it
further.
If first simulation is unsuccessful, a very large pulse width (governed by
dependent_max_width) centered around prop_delay_level of reference
pin (clock) is applied as shown in Figure 67.

SiliconSmart ACE User Guide 465

L-2016.03
Chapter 11: Timing Models
Constraints

Figure 67 Seed Pulse to Begin Pulse-Optimization in Dependent Mode

Data pulse is slowly reduced (binary search) from both edges until a solution
within constraint_resolution is reached.
Once a valid data pulse is obtained, a second optimization is performed. Pulse
is reduced by moving the setup edge while keeping the hold edge constant at
the valid pulse value.

Figure 68 Setup Optimization for Dependent Mode

Finally a third optimization is performed on the hold edge which is moved-in

until simulation is successful.

466 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

Figure 69 Hold Optimization for Dependent Mode

Setup and hold numbers are calculated from the resulting data pulse. For
example, the resulting pulse is shown in Figure 70.

Figure 70 Final Result with Dependent Mode

Recovery, removal and minimum pulse width measurements are done in the
same manner as for independent mode.

SiliconSmart ACE User Guide 467

L-2016.03
Chapter 11: Timing Models
Constraints

Below is a graphical representation of dependent mode:

Figure 71

Failure Detection
Simulation judgment for failure/success is done based on constraint style. For
more details, see the Constraint Styles section.
Glitch threshold values for dependent mode are fixed at the logic_low/
high_threshold values. (The glitch_low_threshold and
glitch_high_threshold parameters are not used for glitch detection when
specified) .

Dependent-Setup Mode
Dependent-setup mode is similar to dependent mode except that the initial data
pulse is placed ahead of reference pin transition, i.e., the trailing data pulse
edge is aligned with reference pin edge. This method ensures that minimum
hold values are obtained.

468 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

Flow
It begins with a very narrow pulse ahead of the related pin transition as shown
in Figure 72. This initial negative hold value is governed by largest_slew
parameter.

Figure 72 First Iteration with Zero Pulse Width in Dependent-Setup Mode

When the initial iteration is successful, no further iterations are done because
data pulse is almost a triangular wave shape and it is not possible to reduce it
further.
If first simulation is un-successful, a very large pulse width governed by
dependent_max_width is applied (ahead of reference pin edge) as shown in
Figure 73.

SiliconSmart ACE User Guide 469

L-2016.03
Chapter 11: Timing Models
Constraints

Figure 73 Seed Pulse to Begin Pulse Optimization in Dependent-Setup Mode

Similar to dependent mode, pulse is slowly reduced from both edges until a
valid pulse is obtained within constraint-resolution.
A second optimization is performed by moving-in the setup edge while keeping
the hold edge constant.

Figure 74 Setup Optimization in Dependent-Setup Mode

No third optimization is required in dependent-setup mode. Setup and hold

numbers are calculated from the resulting data pulse. For example, the
resulting pulse is shown in Figure 75.

470 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

Figure 75 Final Result with Dependent-Setup Mode

Recovery, removal and minimum pulse width measurements are done in the
same manner as for independent mode.
Below is a graphical representation of dependent-setup mode:

Figure 76

SiliconSmart ACE User Guide 471

L-2016.03
Chapter 11: Timing Models
Constraints

Failure Detection
Failure detection is common to all dependent modes. Simulation judgment for
failure or success is determined based on constraint style. For more details,
see the Constraint Styles section.
Glitch threshold values for dependent mode are fixed at the logic_low/
high_threshold values. (The glitch_low_threshold and
glitch_high_threshold parameters are not used for glitch detection when
specified).

Dependent-Hold Mode
Dependent-hold mode is also similar to dependent mode except that the initial
data pulse is placed after the reference pin transition i.e., leading edge of data
pulse is aligned with reference pin edge. This method ensures that minimum
setup values are obtained.

Flow
The flow begins with a very narrow pulse after the related pin transition, as
shown in Figure 77. This initial negative setup value is governed by
largest_slew parameter.

Figure 77 First Iteration with Zero Pulse Width in Dependent-Hold Mode

If the initial iteration is successful, no further iterations are done because data
pulse is almost a triangular wave shape and it is not possible to reduce it
further.

472 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

If the first simulation is unsuccessful, a very large pulse width governed by

dependent_max_width is applied (after the reference pin edge) as shown in
Figure 78.

Figure 78 Seed Pulse to Begin Pulse-Optimization in Dependent-Hold Mode

Similar to dependent/dependent-setup mode, pulse is slowly reduced from both

edges until a valid pulse is obtained within constraint-resolution.
Second optimization is performed by moving in the hold edge while keeping the
setup edge constant.

Figure 79 Setup Optimization in Dependent-Hold Mode

No third optimization is required in dependent-hold mode. Setup and hold

numbers are calculated from the resulting data pulse. For example, the
resulting pulse shown in Figure 80.

SiliconSmart ACE User Guide 473

L-2016.03
Chapter 11: Timing Models
Constraints

Figure 80 Final Result with Dependent-Hold Mode

Recovery, removal and minimum pulse width measurements are done in the
same manner as for independent mode.
Below is a graphical representation of dependent-hold mode:

Figure 81

474 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraints

Failure Detection
This methodology is common for all dependent modes. Simulation judgment for
failure/success is done based on constraint style. For more details, see the
Constraint Styles section.
Glitch threshold values for dependent mode are fixed at the logic_low/
high_threshold values. (The glitch_low_threshold and
glitch_high_threshold parameters are not used for glitch detection when
specified.)

Debugging Dependent Modes

There is one debugging methodology used for all dependent modes. For
debugging purposes, SiliconSmart creates the
combined_setup_hold__D__lh__CK__lh__ACQ_1.tar.gz file in the standard
location inside the runtime directory. This is a combined setup and hold for D
rising from low-to-high and CLK low-to-high for acquisition number 1. Multiple
acquisitions are present for multiple when conditions. It is a tar gzip database
that contains following files and directories:
■
*sof.gz and *sif_0 — similar to those for Independent mode.
■
*sif_0 — contains first iteration (minimum pulse width) for all data-clock slew
combinations.
■
*sif_1 — contains second iteration for those data-clock slew combinations
that fail the first iteration. It applies a very wide data pulse width, and
consecutive iterations continue according to the flow.

Correction for Dependent-Setup & Dependent-Hold Constraint

Modes
It was observed that the relaxed edge (setup edge for dependent-setup and
hold edge for dependent-hold) is extremely sensitive to the position of
restrained edge w.r.t. clock. If the restrained edge (hold edge for dependent-
setup & setup edge for dependent-hold) is relaxed by only a few pico-seconds,
it allows the relaxed edge to fold-in by tens of pico-seconds during optimization
step. This sensitivity occasionally lead to non-monotonocity in the constraint
numbers w.r.t. data & clock slew values.

SiliconSmart ACE User Guide 475

L-2016.03
Chapter 11: Timing Models
Constraint Styles

To overcome this problem, SiliconSmart employs a correction technique

whereby a fixed margin is added to the restrained edge after the first (pulse)
optimization step. This margin can be controlled by the following parameter:
Example 295
constraint_dependent_margin value { default:
constraint_resolution }

The default value of the parameter is one constraint resolution.

For example, in dependent-setup, after the pulse optimization, hold edge is
closest to the clock edge. It is moved towards the right to add a margin.

Once the margin is added to the hold edge, the setup edge optimization is
performed. The hold margin allows the setup edge to move closer to the clock
edge.

Constraint Styles
Constraint Styles define criteria for the judgment of simulations, performed for
each iteration during constraint measurement. SiliconSmart decides regarding
the next iteration on the basis of whether previous iteration was a success/
failure. Final constraint results vary significantly with the choice of constraint
style.
The following sections describe constraint styles:
■
Simulator Bisection Support
■
Monitoring Internal Nodes for Constraints
■
Pass-Fail

476 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

■
Relative-Degradation
■
Slew-Degradation
■
Delay-Reduction
■
Relative-Slew-Degradation
■
Pushout-Degradation
■
Advanced Parameters for Constraint Measurements
■
Negative Setup + Hold
■
Path-Based Constraints
■
Summary of Various Constraint Modes and Styles

Simulator Bisection Support

Using the simulator bisection method for timing constraint acquisition provides
a substantial runtime and accuracy improvement over other constraint
acquisition methods.
The support is enabled with the simulator_bisection parameter. When
set to 1, the SiliconSmart tool will use the simulator bisection offered by the
target simulator for its constraint acquisition method. Set the parameter to 0
(default) to disable this method and use the SiliconSmart algorithm.
Example 296 Enabling simulator bisection support
set_config_opt simulator_bisection 1

With simulator bisection switched on, you’ll notice that the SiliconSmart tool
now produces a single spice deck for every constraint arc (as opposed one per
iteration, in default method).
These spice decks are formatted to use simulator bisection and you can easily
recognize some of the typical directives within it:
■
Specifying model optimization in HSPICE:
.model optmod opt METHOD = PASSFAIL
■
Optimization instruction for parameter setup:
.param setup = opt1('init_hbm','min_setup','max_setup')
■
Measurement for CK->Q delay degradation 5%:

SiliconSmart ACE User Guide 477

L-2016.03
Chapter 11: Timing Models
Constraint Styles

.meas tran sis_result_hbm_1 PARAM = ‘CK_Q_delay' PUSHOUT =

5e-12,1e-08 PUSHOUT_PER = 0.05
■ Performing transient analysis with bisection:
.tran 1e-12 1e-9 sweep OPTIMIZE = opt1 RESULT =
sis_result_hbm_1,… MODEL = optmod

The following table shows the acquisition modes supported for this method:

constraint_style Pass-Fail Relative-deg Slew-deg Relative

Slew-deg

transitioning check toggling toggling toggling toggling

fallback check toggling toggling toggling toggling

glitch check non-toggling non-toggling non-toggling non-toggling

relative check N/A toggling N/A toggling

slew check N/A N/A toggling toggling

The following sections describe this support:

■
Simulator Bisection Checks
■
Limitations

Simulator Bisection Checks

The following checks apply for simulator bisection:
■
Transitioning Check
■ Fallback Check
■
Glitch Check
■
Relative Check
■ Slew Check

478 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Transitioning Check
This check is considered a fail if any of the transitioning output nodes fail to
make an expected transition from logic_low_threshold to
logic_high_threshold, or vice versa.

Figure 82 Transitioning check

Fallback Check
Fallback is detected on transitioning node if a node makes a transition in the
opposite direction at logic_low_thresholds or
logic_high_thresholds. You can also provide a list of thresholds using the
parameter fallback_threshold_pcts. If values are specified, the fallback
check is done only at thresholds specified through the parameter:
set_config_opt -type setup fallback_threshold_pcts {0.2 0.25 0.75
0.8}

SiliconSmart ACE User Guide 479

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Fallback check measurements are enabled only if the

constraint_glitch_check parameter is enabled.

Figure 83 Fallback check

When nothing is specified for fallback_threshold_pcts, the fallback check is

performed at logic_low_threshold and logic_high_threshold, by
default. If values are specified, the fallback check is performed only at
thresholds specified through this parameter.
For example:
set_parameter fallback_threshold_pcts (p1 p2 p3)

The above example performs has the fallback check executed only at these
points, not at logic_low_threshold and logic_high_threshold. This
is shown below:

Figure 84

480 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Glitch Check
Glitch is detected on non-transitioning output nodes or internal node (if defined)
if a node crosses glitch_low_threshold or glitch_high_threshold.

Figure 85 Glitch check

Relative Check
Relative check is detected if delay increases beyond the nominal delay
measured in the first iteration by more than the relative tolerance (specified by
smc_degrade) and absolute tolerance (specified by
smc_degrade_absolute):
delay.sweepValue() <= nominal_delay + max(smc_degrade_absolute,
smc_degrade*nominal_delay)

SiliconSmart ACE User Guide 481

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Figure 86 Relative check

For example:
Nominal delay= 100ps
Smc_degrade= 10% of nominal slew
Smc_degrade_absolute= 5ps
Then
Slew.sweerValue()<=100ps + max( 5ps, 10% * 100)
<= 100ps + max(1ps, 10ps)
<= 100ps + 10ps
<= 110ps

Slew Check
Slew check is detected if node slew increases beyond the nominal slew
measured in the first iteration by more than the relative tolerance (specified by
smc_degrade) and absolute tolerance (specified by
smc_degrade_absolute):
slew.sweepValue() <= nominal_slew + max(smc_degrade_absolute,
smc_degrade*nominal_slew)

482 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Figure 87 Slew check

For example:
Nominal slew= 100ps
Smc_degrade= 10% of nominal slew
Smc_degrade_absolute= 15ps
Then
Slew.sweerValue()<=100ps + max( 15ps, 10% * 100)
<= 100ps + max(15ps, 10ps)
<= 100ps + 15ps
<= 115ps

See Also
■
Parameter: constraint_glitch_check
■ Parameter: fallback_threshold_pcts
■ Parameter: glitch_high_threshold
■
Parameter: glitch_low_threshold
■ Parameter: logic_high_threshold
■
Parameter: logic_low_threshold
■ Parameter: simulator_bisection
■ Parameter: smc_constraint_style
■
Parameter: smc_degrade
■
Parameter: smc_degrade_absolute

SiliconSmart ACE User Guide 483

L-2016.03
Chapter 11: Timing Models
Constraint Styles

■
Parameter: smc_slew_degrade
■
Parameter: smc_slew_degrade_absolute

Limitations
Simulator bisection has the following limitations currently:
■
Supported only for independent smc_constraint_mode.
■
Supported only for the following constraint styles:
• Pass-fail
• Relative-degradation
• Slew-degradation
• Relative-slew-degradation
■
Supported for precharacterization only when driver_mode is pwl.
■
Not supported for constraint_monotonic_check 1.
■
Supported only for HSPICE and FineSim simulators:
• HSPICE: After version hspice_2013.03
• FineSim: Starting with version 2014.09
■
separate_cell_initialization=0 is not supported.
■
Supported only for the following driver_mode:
• pwl
• emulated (ccs-predriver)
• active
• active-waveform
• custom
■
min_period acquisition is not supported.

Monitoring Internal Nodes for Constraints

Sometimes it is convenient to measure internal pin state other than primary
outputs or in addition to them in order to detect constraint failures.

484 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

The internal node check for constraint measurement is done in a similar

manner as primary output check; however it is only supported when simulator
bisection method is enabled.
When using simulator_bisection 1, constraint criteria can be directly
defined for internal nodes, since a simulator can perform measurements at
these nodes without requiring a function previously defined for them.
In order to use the feature above, internal nodes have to be setup through the
command monitor_internal_nodes {nodename {pintype}}.
For example:
Example 297
set_config_opt -type {setup} -from D -reference CP
monitor_internal_nodes {m15:src {pintype_int_1}}

The command optionally accepts a pintype designation, which is used for the
constraint criteria description: in cases where you have to monitor for multiple
nodes and they do not share the same criteria, parameters can be defined in
pintype and later associated to internal nodes via the
monitor_internal_nodes instruction.
For the example above, you can redefine constraint criteria for the internal node
by doing the following:
1. Create an empty pintype block in configure.tcl to define the internal node.
2. Redefine the constraint criteria in driver.tcl
For example, in configure.tcl:
Example 298
pintype int_1->default {
}

And in driver.tcl:
Example 299
set_config_opt -pintype int_1 { smc_constraint_style relative-
degradation }
set_config_opt -pintype int_1 { smc_degrade 0.2 }
set_config_opt -pintype int_1 { glitch_high_threshold 0.90 }
set_config_opt -pintype int_1 { glitch_low_threshold 0.10 }

The above is also true when handling primary outputs and internal nodes
altogether with diverse constraint style or different parameters.

SiliconSmart ACE User Guide 485

L-2016.03
Chapter 11: Timing Models
Constraint Styles

You can define multiple internal nodes in the same way by defining all internal
nodes in configure.tcl and driver.tcl.
For example, in configure.tcl:
pintype int_1->default {
}

pintype int_2->default {
}

And in driver.tcl:
#int_1 definition
set_config_opt -pintype
set_config_opt -pintype
set_config_opt -pintype
slew-degradation }
set_config_opt -pintype
set_config_opt -pintype
set_config_opt -pintype
set_config_opt -pintype
0.5 0.6 0.7 0.8}}
set_config_opt -pintype
int_1 {glitch_high_threshold 0.8 }
int_1 {glitch_low_threshold 0.2 }
int_1 {smc_constraint_style relative-
int_1 {smc_degrade 0.05 }
int_1 {smc_slew_degrade .5 }
int_1 {smc_degrade_absolute 15e-12 }
int_1 {fallback_threshold_pcts {0.2 0.4
int_1 {smc_degrade_check negative-side }

#int_2 definition
set_config_opt -pintype int_2 {glitch_high_threshold 0.9 }
set_config_opt -pintype int_2 {glitch_low_threshold 0.1 }
set_config_opt -pintype int_2 {smc_constraint_style slew-
degradation }
set_config_opt -pintype int_2 {smc_degrade 0.025 }
set_config_opt -pintype int_2 {smc_degrade_absolute 1.5e-12 }
set_config_opt -pintype int_2 {fallback_threshold_pcts {0.25 0.55
0.75}}
set_config_opt -pintype int_2 {smc_degrade_check positive-side }

When measuring constraint at internal nodes, the SiliconSmart tool has to

acquire some behavior of the monitored points in order to detect a usable
method applied and eventually switch on different check.
Assuming delay degradation is defined but the node is not toggling, the tool
should apply glitch check by default but this requires a strict expectation set
from simulation behavior.
In order to identify internal node behavior, a functional recognition (FR)
simulation is conducted with relaxed timing; once the functionality of internal
node is known the tool can do checks for them equal to primary outputs.

486 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Added FR simulations appear in the database with the prefix

"monitor_internal_node_".
For example, if the primary acquisition name is:
setup_hbm__D__lh__CP__lh__ACQ_1

then the acquisition name to find FR at the internal node is:

monitor_internal_node_setup_hbm__D__lh__CP__lh__ACQ_1

Generally, the event which actuates the internal node changes in a constraint
arc is the clock edge, so the clock signal is assumed as the triggering event for
the internal nodes by default.
For those cases which might require precise trigger identification, users can
use the parameter constraint_trigger_node {<int_node>
<trigger_node>} to assign which pin triggers the internal node change. the
parameter:
Example 300
set_config_opt -type {setup} -from D -reference CP
constraint_trigger_node {m15:src CP }

By default monitor of internal nodes is done together with primary outputs.

However, if the parameter skip_constraint_outputs is set to true,
constraint measurements will be skipped for primary outputs to be done for
internal nodes exclusively:
set_config_opt skip_constraint_outputs 1

By default, the SiliconSmart tool checks fallback at logic_low_threshold

and logic_high_threshold for transitioning node. The parameter
fallback_threshold_pcts supports fallback checks at multiple thresholds
for these nodes. The parameter equally applies to internal nodes used for
constraints:
set_parameter fallback_threshold_pcts {0.2 0.5 0.8}

See Also
■
Parameter: monitor_internal_nodes
■
Parameter: constraint_trigger_node
■
Parameter: fallback_threshold_pcts
■
Parameter: skip_constraint_outputs

SiliconSmart ACE User Guide 487

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Pass-Fail
When smc_constraint_style is set to pass-fail, the simulation is
considered a pass if all of the following checks pass:
■
Transitioning Check
■
Fallback Check
■
Glitch Check

Relative-Degradation
When smc_constraint_style is set to relative-degradation, the first
iteration (*.sif_0) is a reference delay measurement done at a relaxed
constraint value. This constraint value is common for all data-clock slew
combinations and is internally calculated as follows:
1.2* (largest_slew)/(logic_high_threshold-logic_low_threshold)
The simulation is considered a pass if all of the following checks pass:
■
Transitioning Check
■
Fallback Check
■
Glitch Check
■
Relative-Degradation

Slew-Degradation
When smc_constraint_style is set to slew-degradation, the process
is similar to relative-degradation, except that the degradation is observed for
output slew instead of for output delay. The simulation is considered a pass if all
of the following checks pass:
■
Transitioning Check
■
Fallback Check
■
Glitch Check
■
Relative-Degradation

488 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Delay-Reduction
Delay-reduction works similarly to delay-degradation, except that the relative
checks equation is:
delay.sweepValue() >= nominal_delay - max(smc_degrade_absolute,
smc_degrade*nominal_delay)

Note: The delay-reduction method is available only for the SiliconSmart

native bisection method. If you are using the simulator bisection
method, you can achieve the same functionality by using
smc_constraint_style relative_degradation with
smc_degrade_check negative-side.

Relative-Slew-Degradation
When smc_constraint_style is set to relative-slew-degradation,
both relative-degradation and slew-degradation will be checked. This
smc_constraint_style is only supported when the
simulator_bisection parameter is set to 1.

Pushout-Degradation
For standard sequential cells, it is observed that clock-to-output delay
increases as the constraint (setup/hold) value shrinks. Hence the curve for
function (constraint + delay) follows a U-shape. Pushout-degradation style
detects the constraint value for which the (constraint + delay) curve displays
minimum value (as depicted by TS2 point in Figure 88.

Note: Pushout-degradation is only supported for independent

constraint_mode.

SiliconSmart ACE User Guide 489

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Figure 88 Pushout Degradation Algorithm

The criteria for simulation failure is the same as for pass-fail style. Additionally,
it applies another algorithm to detect the TS2 point.

Note: All degradation-based constraint styles (relative, slew, pushout)

can be used only when an output transition is possible. They
cannot be used in measurements that have non-transitioning
outputs. In such cases, SiliconSmart automatically switches to
pass-fail constraint style.

For example, for independent mode, flip-flops can use slew or delay
degradation only for setup, hold, and recovery but only use pass-fail (along with
glitch detection) for removal. Latches can use degradation only with setup and
recovery and can only use pass-fail (along with glitch detection) for hold and
removal.

Advanced Parameters for Constraint Measurements

You can use the following parameters for tuning advanced settings for
constraint measurements. The default values for the parameters listed in
Table 17 are obtained from their global counterparts (for example, the default

490 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

value for constraint_default_slew is the same value as for

default_slew).
Table 17 Advanced Constraint Measurement Parameters

Parameter Block Default

constraint_autorange_load pintype autorange_load

constraint_default_load pintype default_load

constraint_default_slew pintype default_slew

constraint_explicit_points_load pintype explicit_points_load

constraint_explicit_points_slew pintype explicit_points_slew

constraint_largest_load pintype largest_load

constraint_largest_slew pintype largest_slew

constraint_numsteps_load pintype numsteps_load

constraint_numsteps_slew pintype numsteps_slew

constraint_smallest_load pintype smallest_load

constraint_smallest_slew pintype smallest_slew

The parameters listed in Table 18 can be modified to match the size of the
search window, However it is recommended that you use the
total_slew_multiplier parameter instead of modifying these parameters
directly. The total_slew_multiplier parameter stretches the window
consistently for all the constraint measurements.
■
Internal parameter max_constraint_multiplier is fixed at 1.2.
■
Internal parameter total_slew is calculated as:

SiliconSmart ACE User Guide 491

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Example 301
(largest_slew / (logic_high_threshold -logic_low_threshold)) *
total_slew_multiplier

Table 18 Parameters to Modify with Constraint Windows Parameter

Parameter Block Default

max_asynch_recovery pintype max_constraint

max_asynch_removal pintype max_constraint

max_cmpw pintype clock_active_period

max_constraint pintype max_constraint_multip

lier * total_slew

max_hold pintype max_constraint

max_ncmpw pintype clock_inactive_period

max_recovery pintype max_constraint

max_removal pintype max_constraint

max_setup pintype max_constraint

min_asynch_recovery pintype min_constraint

min_asynch_removal pintype min_constraint

min_cmpw pintype 1e-12

min_constraint pintype min_constraint_multip

lier * total_slew

min_hold pintype min_constraint

min_ncmpw pintype 1e-12

min_recovery pintype min_constraint

min_removal pintype min_constraint

min_setup pintype min_constraint

492 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Table 19, lists additional parameters that control different options related to
constraint measurements, such as path-based measurements and
precharacterization method. For more details about path-based
measurements, see the Path-Based Constraints section.
Table 19 Additional Advanced Parameters

Parameter Block Default

dependent_max_width pintype -2 *max_constraint

constraint_glitch_time_delta default 1e-15

constraint_outputs default empty_list()

constraint_seed_values default empty_list()

model_negative_constraints default 1

model_neg_constraint_sum default 1

model_neg_constraint_sum_thresh default 4*time_res_high

old

path_constraint_enable_negative default ""

path_constraint_enable_positive default ""

path_constraint_feedback default ""

path_constraint_pintype default default_pintype

prechar_binning_constraints default "none"

statistical_enable_constraint_sensit default 0
ivity

smc_degrade_maximum default 0

Negative Setup + Hold

The sum of setup + hold numbers should not be less than or equal to zero for
the same reference clock edge. However there are two ways to calculate setup

SiliconSmart ACE User Guide 493

L-2016.03
Chapter 11: Timing Models
Constraint Styles

+ hold, each having a different meaning and each being individually handled by
SiliconSmart:
■ Same Data Edge
■
Opposite Data Edge (Data Pulse Width)
■
Negative Constraint Sum Modeling

Same Data Edge

The summation of setup + hold for the same data edge corresponds to the
following equation (and vice versa):
Example 302
rise_constraint Setup + rise_constraint Hold

If negative, it implies that same data event occurring at a particular time

instance would lead to different outputs. For example, consider a simple D flip-
flop as shown in Figure 89.

Figure 89 Negative Setup + Hold for Same Data Edge

In Figure 89, the event on data pin D depicted by a dotted line corresponds to a
hold constraint value and would produce a stable low output Q, while the data
event on D depicted by a solid line corresponds to setup constraint value and
would produce a rising output. Hence any data event occurring in between
these two transitions would meet both setup and hold requirements and
produce opposite values at output Q at the same time.
It is not acceptable to STA and Back-annotation tools. One of the major reasons
for negative setup+hold is the use of different when conditions for setup and
hold measurements. when conditions correspond to other pin conditions e.g.,
for a scan flip-flop, scan-enable to clock constraint measurement can have two
when conditions: scan-input=1, data=0 and scan-input=0, data=1.

494 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Because typically the circuit design is different for scan-input and data, different
when conditions produce significantly different results.
SiliconSmart makes sure that same other pin conditions (when condition) are
used for both setup and hold measurements in order to avoid negative
summation values for this reason.

Opposite Data Edge (Data Pulse Width)

The summation of setup+hold for opposite data edge corresponds to the
following equation (and vice versa):
Example 303
rise_constraint Setup + fall_constraint Hold

If negative, it implies that data fall transition can occur before rise transition,
while still producing output corresponding to rise edge, which is physically
impossible.

Figure 90 Negative Setup+Hold for Opposite Data Edge

It is not checked by STA or back-annotation tools. Negative setup+hold values

for opposite edge are common for “independent” constraint mode, where setup
measurement is made assuming an infinite hold time and hold measurement is
made keeping infinite setup time. SiliconSmart offers "dependent modes"
which can be used to avoid these negative setup+hold values for opposite
edges. For dependent modes, setup + hold measurement are made
simultaneously in a single simulation and hence it is impossible to get negative
setup+hold for opposite edges for dependent constraint modes.

SiliconSmart ACE User Guide 495

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Negative Constraint Sum Modeling

Negative constraint modeling can be checked and corrected during the
modeling step, with the following behavior:
■
By default, negative constraint sum modeling is allowed.
This means that even if setup+hold (recovery+removal) is negative, the
constraint values will be modeled as is and you should expect negative
constraint sum values in the final model.
■
By default, the negative constraint sum will be evaluated both for same
edges and opposite edges.
This includes ([setup_rise + hold_rise] and [setup_fall+hold_fall]) for same
edges and ([setup_rise+hold_fall] and [setup_fall + hold_rise]) for opposite
edges.
To disable having the sum evaluated for the opposite edges, set the parameter
model_neg_constraint_chk_opposite_edge to 0.
To disable having constraints modeled with this negative constraint sum,
perform the following:
1. Set model_neg_constraint_sum to 0
2. Set an appropriate value to model_neg_constraint_sum_threshold
It is this model_neg_constraint_sum_threshold value which SiliconSmart will
compare the constraint sum against to determine whether to give a warning or
error. If the sum is negative but within the limit set with
model_neg_constraint_sum_threshold, a warning will be generated. If
it is outside of this limit, an error will be generated.
It is important to note that the model_neg_constraint_sum_threshold
parameter does not have a default value. The user must choose and set a
value for this threshold. If model_neg_constraint_sum is set to 0 and no
value is set for model_neg_constraint_sum_threshold, the SiliconSmart
tool will generate an error to set an appropriate value for the threshold.
Additionally, if model_neg_constraint_sum = 0 and if the constraint sum is
greater than model_neg_constraint_sum_threshold (as set by the
user), then the SiliconSmart tool will correct the constraint numbers to make
the sum marginally positive. This marginally positive value can be controlled by
the model_neg_constraint_sum_margin parameter.

496 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

See Also
■
Parameter: model_neg_constraint_chk_opposite_edge
■
Parameter: model_neg_constraint_sum
■
Parameter: model_neg_constraint_sum_margin
■
Parameter: model_neg_constraint_sum_threshold

Path-Based Constraints
The basis of path-based constraint methodology is to speed up the constraint
measurements. All the preceding measurement methodologies measure the
timing constraints by performing an iterative search algorithm i.e., different
constraint values are applied on the circuit, starting from an initial guess, until a
result is found within constraint resolution. For reasonable resolutions (1-10ps)
this will typically take 8-12 simulations. That number can be considerably
reduced with a very good initial guess. Path-based constraints provide that
good guess for setup + hold by measuring the delay from the data and clock
inputs to a critical internal node and then using the difference as the initial
guess.

Figure 91 Latch Circuit depicting important nodes for path-based measurement

In the sample latch circuit shown in Figure 91, delay measurements are made
from Data (D) to Feedback node (N1) because this node decides whether the
data event will be latched. Other important measurements are from Enable pin
(EN) to negative enable (!EN) and positive enable (shown as EN itself, while it
can be a buffered EN in some cases).

SiliconSmart ACE User Guide 497

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Flow
Use the following command to define appropriate internal nodes in the cell
instance file:
Example 304
analyze_netlists -constraint_nodes cells

It will automatically update the control/cell.inst file to include a path file created
in control/path/cell.path which contains something similar to following:
Example 305
add_pin SISMART_FB default -internal -spice_node m__160 -no_model
add_function SISMART_FB !(!IQ6)
set_config_opt path_constraint_feedback SISMART_FB
add_pin SISMART_ENN default -internal -spice_node BCLK__F32 -
no_model
add_function SISMART_ENN CK
set_config_opt path_constraint_enable_negative SISMART_ENN
add_pin SISMART_ENP default -internal -spice_node NCLK__200 -
no_model
add_function SISMART_ENP !CK
set_config_opt path_constraint_enable_positive SISMART_ENP

The previous lines define three nodes: feedback node, negative enable node,
and positive enable node; associate them with the corresponding SPICE node
and declare their functionality.
The meaning of the various nodes are as follows:
■
feedback — This node should be the output of master latch. Typically, it is
an uninverted function of data.
■
enable_positive — This node should be 1 when the latch is enabled/
transparent and 0 when the latch is disabled/latched.
■
enable_negative — This node should be 0 when the latch is enabled/
transparent and 1 when the latch is disabled/latched.
This command must be used with caution. You must verify the node names
produced by the command.
You can enable a path-based methodology using the following parameter:
Example 306
set path_constraint_mode verify/polish

498 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

■
verify — when path_constraint_mode is set to verify, constraint
values are calculated based on path delays and then simulations are made
to verify that output are not failing for these constraints. In case any failure
is detected, constraint value is increased until simulation is successful.
■
polish — when path_constraint_mode is set to polish, constraint
values are calculated based on path delays. These values are used as initial
seed to begin normal constraint simulations. The advantage of seed value
lies in significantly reducing the number of simulations to achieve the result
which is as accurate as normal constraint simulation.
Note: verify is the fastest method but it produces conservative
results while polish is as accurate as the normal constraint
measurement.

Debugging
The following files are generated inside the runtime/spice/cell directory:
■
path_setup0__setup__D__hl__CK__lh__ACQ_1.tar.gz — This file contains
the decks for measurement of path delays related to D (data) falling from
high to low and CK (clock) rising from low to high. Delay measurements are
made for all requested data-clock slew combinations. Examples of delays
which are measured: data-to-feedback-node, clock-to-enable-negative,
clock-to-enable-positive etc. This is the first step of measurement.
Measurement delays are used for both setup + hold.
■
Setup/hold__D__hl__CK__lh__ACQ_1.tar.gz — This file contains the
verification / polishing decks. It contains the deck for setup measurement/
verification for D (data) falling from high to low and CK (clock) rising from low
to high. All data-clock slew combinations are simulated in the single deck.
The constraint value for the first iteration is calculated from delays calculated
in the first step.
Successive iteration are present in corresponding *_sif_number directory,
where number stands for iteration number.

Summary of Various Constraint Modes and Styles

The various constraint modes and styles can be classified on the basis of
degree of pessimism. It is depicted in Table 20, where 1 represents the most

SiliconSmart ACE User Guide 499

L-2016.03
Chapter 11: Timing Models
Constraint Styles

optimistic approach and 3 represents the most pessimistic approach. The

behavior is different for setup + hold measurements.
Table 20 Degrees of Pessimism for Constraint Modes

Constraint Mode Setup Hold

Independent 1 (most optimistic) 1 (most optimistic)

Dependent 2 2

Dependent-Setup 3 (most pessimistic) 1

Dependent-Hold 1 3 (most pessimistic)

Various constraint styles can be similarly classified based on degree of

pessimism, as shown in Table 21.
Table 21 Degrees of Pessimism for Constraint Styles

Constraint Style Degree of optimism

Pass-fail 1 (most optimistic)

Relative-degradation 2

Slew-degradation 2

Pushout-degradation 2

Degradation-based styles can be equal or more pessimistic compared to pass-

fail style. Their behavior heavily depends upon the cell under consideration as
well as the constraint arc being measured.

Note: The degree of pessimism indicated for constraint styles is not on

the same scale as that used for constraint modes. They must not
be compared.

500 SiliconSmart ACE User Guide

L-2016.03
 Chapter 11: Timing Models
Constraint Styles

Sample rankings of various constraint combinations for a D flip-flop, based on

actual simulations, are shown in Table 22. Results may vary from cell to cell. 1
is the most optimistic approach and 10 is the most pessimistic approach.
Table 22 Degrees of Pessimism for Setup for D Flip-Flops

Independent Dependent Dependent- Dependent-

setup hold

Pass-fail 1 2 8 1

Relative-deg 1 2 8 1
10%

Relative-deg 2 3 7** 2
1%

Slew-deg 1% 1 2 8 1

Pushout-deg 3 - - -

Sample rankings of various constraint combinations for hold for a D flip-flop,

based on actual simulations, are shown in Table 23. Results may vary from cell
to cell. 1 is the most optimistic approach and 10 is the most pessimistic
approach.
Table 23 Degrees of Pessimism for Hold for D Flip-Flops

Independent Dependent Dependent- Dependent-

setup hold

Pass-fail 1 3 1 8

Relative-deg 1 3 1 7**
10%

Relative-deg 2 3 2 9
1%

Slew-deg 1% 1 3 1 8

Pushout-deg 2 - - -

SiliconSmart ACE User Guide 501

L-2016.03
Chapter 11: Timing Models
Constraint Styles

Note: It is possible to have lesser hold values for relative/slew

degradation styles as compared to pass-fail style for dependent-
hold mode. This is legitimate behavior because it is
compensated by slightly conservative setup values for this mode.
Similar behavior is true for dependent-setup.

502 SiliconSmart ACE User Guide

L-2016.03
 12
12

Power and Electromigration Models

This chapter describes the methods used to characterize the power and
electromigration behavior of a cell.

In the Liberty format, power is described as internal power and leakage power.
Internal power is the energy consumed by a cell when an input pin switches,
whether the output switches or not (referred to in this document as switching
and hidden power). Leakage power is the steady-state power consumed by a
cell.
The following sections describe power methodology in SiliconSmart:
■ Internal Power
■
Hidden vs. Switching Internal Power
■
Multi-Output Pin Cells Power Methodology
■ Negative Energy Values in internal_power Groups
■
Leakage Power
■ Multi-Rail Power Methodology
■ CCS Power
■
Troubleshooting SiliconSmart Power Models
■
Electromigration (EM) Characterization

Internal Power
Internal power in the Liberty (.lib) format refers to the amount of energy
consumed by a cell during a switching event, minus any energy (C*V*V) used

SiliconSmart ACE User Guide 503

L-2016.03
Chapter 12: Power and Electromigration Models
Internal Power

to charge the output load of the cell. This is the basic equation or calculation for
internal power. In general, the equation is as follows:
Internal Power for switching event =
(Total energy consumed by cell during switching event)
– (Energy used to charge the load on output pin(s) of cell)
– (Leakage energy component)
– (Energy consumed by input pin for non-switching event at
same ‘when’ condition as condition for switching event)
– (Energy component used to charge secondary output pin(s)
at default load)
* (n-1)/n

In the previous equation, n equals the number of output pins switching during a
switching event.
To measure the internal power in a cell, first the current through each supply
rail is measured as a transition is applied to one or more of the input pins. The
energy consumed through each of the supply rails over the simulation period is
the total energy.
The total energy value also includes any leakage current measured during the
measurement period. For standard cells starting at the 90nm process rules and
many I/O cells before that, the leakage currents can be large enough to
constitute a significant percentage of the total energy. To account for this,
SiliconSmart subtracts the average leakage current from the total energy.
Consider the following illustration:

Figure 92 Switching Power Events for a Single Output Cell with a Single Supply

504 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Internal Power

Total charge is measured as the integral of the supply current during the
power_period, as shown in the following equation:

t end

Q total =   I VDD  dt
t start

To find the leakage energy component, the steady-state current during the last
5% of the measurement period is measured and multiplied by Vdd to calculate
the leakage power component:

t end

P leakage = VDD  average   I VDD  dt

t 95%

The previous leakage power component is calculated at each slew/load index

and then SiliconSmart finds the median value of leakage power. The median
value ( P medianleakage ) of leakage power multiplied by power_period is
subtracted for all slew/load indices. This is done to avoid introducing errors
when the leakage measurement is unstable for any reason, for instance, if slow
slews are still oscillating at the end of the simulation. This is occasionally
observed in some simulators for certain options settings.
As a check to ensure that the correct leakage values are being used,
SiliconSmart also measures the steady-state current during an additional
period from 90% to 95% of the simulation time. The internal energy of the cell is
computed twice, once by subtracting the first value of the leakage energy and
again using the second value. If the two values for internal energy differ by
more than the threshold, an error is reported. The threshold is specified in both
relative and absolute terms via the parameters
power_stabilization_threshold (default is 5%) and
power_stabilization_threshold_absolute (default is 1pJ).

Note: This error will also be reported if the current waveform as

computed by the simulator is highly erratic. To get accurate
power numbers, it is very important that the simulator options be
setup such that the current waveforms are smooth and accurate.

SiliconSmart ACE User Guide 505

L-2016.03
Chapter 12: Power and Electromigration Models
Hidden vs. Switching Internal Power

For many SPICE engines, this requires using the option

method=gear and/or reducing the largest simulator time step as
controlled by the parameter time_res_low.

Now if you calculate internal power for the case illustrated in Figure 92, internal
power will be the total energy minus the leakage energy component. If the
switching event is a rising event at an output pin, the energy used to charge the
load on output is also subtracted, as follows:
Erise =  Qtotal  Vdd  –  Pmedianleakage  powerperiod  –  CL  Vf  Vf 
Efall =  Qtotal  Vdd  –  Pmedianleakage  powerperiod 
Notice that SiliconSmart uses  CL  Vf  Vf  and not  CL  Vdd  Vdd  for
computing the energy required to charge the output load capacitance.
The SiliconSmart methodology handles long output transitions without
requiring that the output is completed, as long as the internal transistor states
have settled. SiliconSmart uses  CL  Vf  Vf  (assuming Vstart = 0 ), where
Vf is a measured voltage. For large output loads with long transitions, it is
possible that the power_period selected might not be long enough for the
output to completely reach the rail voltage. In such a case, subtracting
 CL  Vdd  Vdd  would remove more energy than was actually contributed at
the supply over the period of measurement. Using  CL  Vf  Vf  makes it less
critical that power_period be extended, thus reducing simulation time and,
more importantly, reducing the introduction of errors.

Hidden vs. Switching Internal Power

SiliconSmart measures two forms of internal power for a cell: hidden and
switching. Hidden internal power (or more correctly, internal energy) occurs
when an input pin switches but no output pins switch. The results of this
measurement are placed in a Liberty internal_power group on the input
pin. Switching internal energy occurs when one or more output pins switch in
response to an input pin transition. These results are placed in an
internal_power group on the output pin with the related_pin attribute set
to the input pin.
Some power analysis tools simply accept a netlist activity file that records how
many times a given net switches, and do not account for whether a transition on
an input pin causes a transition at the output of the cell or not. Because of this

506 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Hidden vs. Switching Internal Power

the tools will count both the internal energy on an input pin as well as the
internal energy on an output pin if both match the current state of the cell.
Because of this, SiliconSmart automatically generates when conditions for
internal_power groups that are mutually exclusive across the set of hidden
and switching events.
However, this does not work for clock pins on sequential cells. The problem is
when conditions can not contain state registers for the cell and thus the hidden
and switching cases can not be made mutually exclusive. To illustrate this,
consider a standard D-flop as shown in Figure 93 (A) and Figure 93 (B).

D=1 Q=0 D=1 Q=1

ck ck

A B
Figure 93 Example D-flop

In Figure 93 (A), a rising transition on the clock pin causes the output pin to
switch, resulting in an internal_power group on the output pin with a when
clause of D. In Figure 93 (B), the same rising transition on the clock does not
cause the output to switch, so an internal_power group is placed on the
clock pin, also with a when condition of D. Because static power analysis tools
work off an activity file, they will add in the contribution of all internal power
groups on all switching pins matching the current condition. Because both
power groups have the same when condition, both the hidden and switching
power will be counted, overestimating the power consumption of the cell.
The solution to this problem is to subtract the contribution of the hidden power
from the switching power table at the same when conditions. This resolves
the case in which both the input and output pins switch because the sum will
equal the original switching power value. It also correctly handles the hidden
power cases because the power analysis tool only has a switch event for the
input pin.

SiliconSmart ACE User Guide 507

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

Multi-Output Pin Cells Power Methodology

The following topics are described in this section:
■
Output Switching Energy Subtraction
■
Splitting default_load Internal Energy Among Multiple Output Pins
■
3-D Table Support
■
Filling Power Tables that Do Not Occur
■
Pin Capacitance

Output Switching Energy Subtraction

When a cell has multiple outputs, the C  V2 energy component for all
charging output capacitances, i.e., rising outputs, is subtracted from the total
energy measured for the supply. The fall transitioning outputs are discharging
their corresponding output load and thus do not contribute the total charge
measured at the supply.
Consider the following example:

Figure 94 Sample Power Event

For the power event illustrated in Figure 94:

A  rise ,X  rise ,Y  fall ,Z  rise
and the internal energy is as follows:

508 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

E  A  X  =  Qtotal  Vdd  –  Pmedianleakage  powerperiod  –  CL  Vdd  Vfx 

E  A  Y  =  Qtotal  Vdd  –  Pmedianleakage  powerperiod 

E  A  Z  =  Qtotal  Vdd  –  Pmedianleakage  powerperiod  –  CL  Vdd  Vfz 

Only the output switching energy from output X and Z are subtracted from the
total energy.

Splitting default_load Internal Energy Among Multiple

Output Pins
The default SiliconSmart power methodology sweeps the load on a single
output pin while holding the other pins at a constant load (default_load).
Thus, for each switching output, we have an energy table.
The energy tables will intersect at the case where all outputs have
default_load for that output pin. To avoid counting the energy at
default_load n times, (n-1/n) portion of the energy at the default_load
will be subtracted from each energy value in the table for that output. There is
no need to produce tables for other outputs in this case because they are each
handled by the case in which their load is swept. It also is not necessary to
consult the other outputs for what their tables actually contain.
The procedure for doing this is as follows:
1. Calculate the base energy for each output pin: for every switching output pin,
sweep over all the slew/load combinations keeping the load on the other
pins as default_load. Thus, we will have n energy tables where n is the
number of switching outputs.
Measure the following by SPICE:

Example 307
Tx = base energy table for pin X
Ty = base energy table for pin Y
Tz = base energy table for pinZ

2. These n tables will intersect at the case where all outputs have
default_load for that output pin.
Interpolate the energy at default load:

SiliconSmart ACE User Guide 509

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

Example 308
Td-x = energy at default load for X
Td-y = energy at default load for Y
Td-z = energy at default load for Z

3. To avoid counting the energy at the default_load n times, (n-1)/n

portion of the energy at the default_load will be subtracted from each
energy value in the table for that output. There is no need to produce tables
for other outputs in this case as they are each handled by the case when
their load is swept
Model the following energy tables in the Liberty model:
Example 309
Tx-new = Tx – (2/3)*Td-x
Ty-new = Ty – (2/3)*Td-y
Tz-new = Tz – (2/3)*Td-z

510 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

Consider the following example:

Table 24 Measured Internal Energy when the load across pin X is swept and pin Y
and pin Z are kept at “default_load” (Data measured by SPICE)

slew 1e-11 6.494e-11 2.578e-10 6.261e- 1.2e-9

10

load 8e-18 4.163e-15 1.875e-14 4.66e-14 9.0e-14

1.387e-14 1.386e-14 1.383e-14 1.358e-14 1.303e-14

1.392e-14 1.391e-14 1.387e-14 1.364e-14 1.311e-14

1.536e-14 1.536e-14 1.531e-14 1.509e-14 1.450e-14

1.959e-14 1.958e-14 1.956e-14 1.943e-14 1.853e-14

2.64e-14 2.639e-14 2.637e-14 2.633e-14 2.617e-14

Table 25 Measured Internal Energy when the load across pin Y is swept and pin X
and pin Z are kept at default_load (Data measured by SPICE)

slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

load 8e-18 4.163e-15 1.875e-14 4.66e-14 9.0e-14

1.3554e-14 1.351e-14 1.3557e-14 1.36e-14 1.431e-14

1.359e-14 1.356e-14 1.363e-14 1.365e-14 1.436e-14

1.507e-14 1.507e-14 1.517e-14 1.5111e-14 1.576e-14

1.943e-14 1.941e-14 1.945e-14 1.947e-14 1.970e-14

2.63e-14 2.627e-14 2.629e-14 2.632e-14 2.656e-14

Table 26 Measured Internal Energy when the load across pin Z is swept and pin X
and pin Y are kept at default_load (Data measured by SPICE)

Slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

Load 8e-18 4.163e-15 1.875e-14 4.66e-14 9.0e-14

SiliconSmart ACE User Guide 511

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

Table 26 Measured Internal Energy when the load across pin Z is swept and pin X
and pin Y are kept at default_load (Data measured by SPICE)

1.380e-14 1.378e-14 1.384e-14 1.327e-14 1.304e-14

1.387e-14 1.384e-14 1.385e-14 1.332e-14 1.306e-14

1.550e-14 1.538e-14 1.533e-14 1.488e-14 1.447e-14

2.002e-14 1.976e-14 1.960e-14 1.937e-14 1.861e-14

2.72e-14 2.68e-14 2.651e-14 2.623e-14 2.61e-14

Thus, we have three base energy tables as shown above. However, these three
energy tables intersect at the case when all the three output pins have
default_load. Therefore, in order to avoid counting the energy at
default_load 3 times, we find the energy for every input slew at
default_load and subtract 2/3 of the energy at default_load from each
of the above energy tables.
The following is the energy table for each input slew at default_load got by
interpolation from Table 24.
Table 27 Energy values at default_load with X as primary output (values obtained by
interpolation)

Slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

1.364e-14 1.3702e-14 1.514e-14 1.946e-14 2.634e-14

Subtracting 2/3 of the above energy values for each input slew at
default_load from Table 24, the following table gets modeled in the Liberty
file across pins X.
Table 28 Final Modeled Energy Values Across Pin X

Slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

Load 8e-18 4.163e-15 1.875e-14 4.66e-14 9.0e-14

4.781e-15 4.766e-15 4.738e-15 4.488e-15 3.937e-15

4.787e-15 4.774e-15 4.742e-15 4.513e-15 3.979e-15

512 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

Table 28 Final Modeled Energy Values Across Pin X

5.272e-15 5.264e-15 5.218e-15 4.995e-15 4.412e-15

6.621e-15 6.611e-15 6.591e-15 6.456e-15 5.5557e-15

8.838e-15 8.829e-15 8.808e-15 8.773e-15 8.610e-15

The following is the energy table for each input slew at default_load got by
interpolation from Table 25.
Table 29 Energy values at default_load with Y as primary output (values obtained by
interpolation)

Slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

1.360e-14 1.365e-14 1.511e-14 1.946e-14 2.631e-14

Subtracting 2/3 of the previous energy values for each input slew at
default_load from Table 24, the following table gets modeled in the Liberty
file across pins Y.
Table 30 Final modeled energy values across pin Y

slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

load 8e-18 4.163e-15 1.875e-14 4.66e-14 9.0e-14

4.493e-15 4.459e-15 4.497e-15 4.54e-15 5.255e-15

4.495e-15 4.463e-15 4.53e-15 4.556e-15 5.266e-15

4.999e-15 4.999e-15 5.033e-15 5.038e-15 5.689e-15

6.459e-15 6.44e-15 6.47e-15 6.493e-15 6.73e-15

8.759e-15 8.732e-15 8.75e-15 8.777e-15 9.02e-15

SiliconSmart ACE User Guide 513

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

Finally, the following is the energy table for each input slew at default_load
got by interpolation from Table 26
Table 31 Energy values at default_load with Z as primary output (values obtained by
interpolation)

Slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

1.341e-14 1.345e-14 1.499e-14 1.943e-14 2.630e-14

Subtracting 2/3 of the above energy values for each input slew at
default_load from Table 24, the following table gets modeled in the Liberty
file across pins Z.
Table 32 Final modeled energy values across pin Z

Slew 1e-11 6.494e-11 2.578e-10 6.261e-10 1.2e-9

Load 8e-18 4.163e-15 1.875e-14 4.66e-14 9.0e-14

4.867e-15 4.841e-15 4.905e-15 4.335e-15 4.100e-15

4.908e-15 4.871e-15 4.887e-15 4.359e-15 4.100e-15

5.508e-15 5.388e-15 5.337e-15 4.891e-15 4.478e-15

7.069e-15 6.806e-15 6.651e-15 6.423e-15 5.657e-15

9.673e-15 9.266e-15 8.98e-15 8.701e-15 8.565e-15

3-D Table Support

If more accuracy is required for modeling load dependency, 3-D power tables
are supported by SiliconSmart. The 3rd index in a 3-D table is the load on a
secondary output pin. SiliconSmart will sweep the load on two output pins.
Note, however, that 3-D tables do not provide higher accuracy for cells with
more than 2 outputs. Also note that the characterization time increases due to
the additional swept load variable.
It is recommended that CCS Power be used instead of 3-D power tables if
higher accuracy is desired for power modeling.

514 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

Filling Power Tables that Do Not Occur

In some cells/circuits with different functionality, it may happen that for a certain
arc, input/output can only transition in one direction and not both. So we may
be able to only measure/report rise_power or fall_power, but not both.
However, for Liberty format/syntax consistency, we still have to report both, so
the options for a power table that can actually not be measured for the circuit
are either to fill it with zeroes or copy values from the opposite power table.
You can use the parameter liberty_fill_out_power_with to choose
what to put for power tables that do not really occur. To fill the table with zeroes,
set this parameter to zero. To copy values from the opposite power table, set
this parameter to opposite_edge.

Pin Capacitance
The Liberty pin_capacitance attribute reflects the effective capacitive load
of a given input pin as seen by a driver. Because the Liberty format only
support a single capacitance value and the effective value varies by input
transition time and the specifics of the driver model used by each third-party
tool, SiliconSmart provides two methods of acquiring the pin capacitance value.
Electrically, the pin capacitance would typically be measured by integrating the
current into the input pin over the complete transition. In practice this breaks
down due to leakage currents through the input pins and because the drive
models of the third-party tools are primarily concerned with the transition times
between the slew thresholds.
For these reasons, SiliconSmart integrates the input current between two
measurement thresholds controlled by the pin type parameters
cin_low_threshold and cin_high_threshold. By default, these
parameters are set to 0.05 and 0.95, reflecting 5% and 95% of the signal’s
voltage swing. This clips off any ringing in the single and long tails caused by
leakage currents through the input pin.
Some I/O cells exhibit a significant amount of leakage current through input
pins, particularly on I/O pads, causing a significant overestimation of the input
pin capacitance. SiliconSmart can measure the steady-state current through
the input pin and subtract this from the current integration period. To enable this
feature, set the pin type parameter subtract_leakage to 1. When
subtract_leakage is set to 1, this essentially results in the parameters
cin_high_threshold and cin_low_threshold being ignored. Because

SiliconSmart ACE User Guide 515

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Output Pin Cells Power Methodology

this feature is typically not needed and leads to longer run times because of the
need to simulate the cell for a longer time period, this feature is disabled by
default.
SiliconSmart supports a second method of measuring pin capacitance, which
has been shown to yield better correlation results with some timing analysis
tools, such as Cadence SignalStorm. This method estimates the effective pin
capacitance by attaching an active driver cell to each input pin of the cell under
test and applying a transition to the input pin. The active driver
precharacterization data contains a table of capacitance values and the
resulting output transition time. Using this table, the transition time into the input
pin can be matched to an equivalent capacitance value.
To avoid inaccuracies in some simulators at very low capacitive loads, a small
bias capacitor is added to the output of the active driver when performing the
slew matching input capacitance measurement. Once the equivalent
capacitance value is found, the bias capacitance is subtracted out again. The
value is controlled by the pin type parameter cin_bias_capacitance, and
should be set to a small capacitance value. The default is 10ff.
The slew matching Cin measurement is enabled by setting the global
parameter slew_matching_cin to true. The default is false.
SiliconSmart supports another method of measuring pin capacitance: delay
matching. This is similar to the slew matching method. Instead of slew, delay is
used. Also SiliconSmart does not use the driver as it is. Two instances of the
driver are connected in a series to make the driver used for CIN
characterization. Delay across the second instance is measured. The delay
matching CIN measurement is enabled by setting the global parameter
delay_matching_cin to true.
If you want to use separate drivers for active driver and delay matching driver,
that is possible. You can use the delay_matching_cin_driver parameter.
The driver should be imported using the import_driver command. This
parameter defaults to driver.

Setting Asymmetric cin Thresholds

Use the following pin-type parameters to set low/high thresholds for pin
capacitance measurements of the rising/falling waveform:
■
cin_high_threshold_fall
■
cin_low_threhold_fall

516 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Negative Energy Values in internal_power Groups

■
cin_high_threshold_rise
■
cin_low_threshold_rise
For example:
set_config_opt -cell * -pin * cin_low_threshold_rise 0.005
set_config_opt -cell * -pin * cin_high_threshold_rise 0.8
set_config_opt -cell * -pin * cin_high_threshold_fall 0.995
set_config_opt -cell * -pin * cin_low_threshold_fall 0.2

Negative Energy Values in internal_power Groups

There are several reasons why negative values could appear in
internal_power groups. In most cases this behavior can be explained and
produces accurate results in power analysis tools.
The following sections describe these reasons:
■
Leakage Energy Subtraction
■
Leakage Energy Stabilization
■
Input Pin Currents

Leakage Energy Subtraction

Leakage energy is subtracted from the hidden and switching energy tables to
prevent double counting.
It is important to note that leakage energy is highly state-dependent and could
vary by a factor of magnitude between certain steady-states of a cell. There is
no way to directly separate the actual amount of energy due to leakage during
a switching or hidden power event. SiliconSmart estimates the leakage energy
during a hidden or switching power event to be equal to the final state leakage
energy.
Thus, for cases where the final state leakage energy is much greater than the
initial state leakage energy, the estimated leakage energy subtracted may be
larger than the actual leakage energy for the event. This could then result in a
negative energy table if the power event itself consumed little energy. This is
more likely to take place for hidden energy events where the energy consumed
is typically smaller, and could potentially be on the same order of leakage
energy consumption.

SiliconSmart ACE User Guide 517

L-2016.03
Chapter 12: Power and Electromigration Models
Negative Energy Values in internal_power Groups

Note that this phenomenon should only result in very small negative values and
can typically be ignored since other power events will over-shadow the effects
of these small power values.

Leakage Energy Stabilization

Leakage currents are generally very small currents and most simulators
produce an oscillating current waveform where the oscillations are a significant
percentage (over 100%) of the average magnitude of the signal. SiliconSmart
computes the leakage current in a cell by averaging the leakage current over
the last 5% of the simulation. However, when the oscillations are large enough,
the average still fluctuates depending on the exact starting and ending time of
the averaging period.
To further help reduce the fluctuations SiliconSmart takes the median value of
the average leakage current across all input slews and output loads. This yields
a single leakage current that is used for every value of the power table for a
given internal_power table.
Despite this process there is still some variation in the final leakage value.
Given the tiny magnitude of some power measurements, variation in the
leakage value can result in negative power numbers. Again, the negative
values are several orders of magnitude smaller than the current used to charge
the capacitive load and thus do not significantly affect the final results.

Input Pin Currents

Negative internal energy numbers arise sometimes after C*V2 and leakage
power subtraction. These numbers arise because the net gate to source or
gate to drain current is larger than the short circuit current produced during the
switching of the cell, especially at fast input slews. Until recently this current
was negligible, being swamped by short circuit current.
At very small geometries, this methodology can now produce a small negative
internal energy with some types of devices. For this purpose, SiliconSmart
provides the parameter model_negative_energy to zero out these negative
values. It is important to note that these are trivial gate currents which
represent a fraction of a percent of the typical short circuit currents. Also,
because some power analysis tools acquire power over a complete duty cycle,
the power seen over this cycle is guaranteed to be positive.

518 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Leakage Power

This implies that if the rise_power and fall_power groups within an

internal_power group are added together, the result should be positive.
However, if there is significant error due to leakage stabilization, this sum could
still be negative. It’s important to note that these negative numbers should be
small relative to the rest of the power tables and would have an insignificant
impact on the overall power consumption reported by power analysis tools.
An example of this case is as follows:
■
Pin A is low, Pin Y is high
■
C is charged due to the voltage difference between A and Y
■
A fast rising edge on A:
• The edge rate is faster than C’s discharge time
• The voltage on Y increases (as it is already high)
■
V depends on CL:
• Larger CL values suppress the increase
• Small CL => Y could increase above VDD
■
Y > VDD => VDD is a current sink rather than a source & hence, negative
power for this one event

Leakage Power
Leakage power is the power consumed by a cell when it is in a steady-state
condition. SiliconSmart measures the leakage current by running a transient
simulation with the inputs held stable. For combinational cells this is simply a
matter of setting the inputs to the desired state and running the simulation for
the necessary time period. To improve the accuracy of the results, SiliconSmart
averages the current through each of the supplies over a period of time. This
period starts after an initial delay (controlled by the parameter
initial_delay) to ensure the simulation stabilized first. The period is
controlled by the parameter power_period.
Sequential cells often require one or more inputs transition to get the cell into
the appropriate internal state. In this case, SiliconSmart simulates the
appropriate transitions and then waits for a period of time (again controlled by
the parameter initial_delay) after the last transition, before it averages the
current.

SiliconSmart ACE User Guide 519

L-2016.03
Chapter 12: Power and Electromigration Models
Leakage Power

You can specify simulator options specifically for leakage power measurements
directly via the simulator_options parameter in configure.tcl or
set_parameter calls. Leakage specific options can be specified as shown in
the following example:
Example 310
//Example for hspice simulator
set simulator_options {"leakage,hspice: method=gear"}

Example: Suppose use has simulator_options settings as below:

set simulator_options {
"common,finesim: probe=1 finesim_mode=spicehd"
"leakage,finesim: finesim_method=gear"
}

According to this, common category options will be used to all measurement/

simulations except for energy and leakage_power measurements. Complete
options used for energy will be all options under the common and power
categories. Similarly, for leakage_power, complete options will options from
common, power and leakage categories together. Appending all options across
categories are in the same order so that later, one takes a higher priority and
overrides previous options.

Gate Leakage Current

SiliconSmart uses a pre-defined simulation time to calculate the leakage
current through various supplies and also the gate leakage current through the
inputs. This simulation time used by SiliconSmart is sufficient to capture the
correct polarity of leakage currents most of the time.
However, for some cells, this simulation time may not be sufficient enough to
capture the correct polarity of gate leakage especially if it changes very slowly
over time (this could be verified by looking at the nature of the current waveform
using FineWave). In that case, SiliconSmart issues a warning during modeling
that the gate leakage current for a particular input pin for some when condition
(say W) is less than the value which is possible for that state. In such cases, the
parameter gate_leakage_time_scaling_factor should be used to
increase the total simulation time. The default value of this parameter is 1.0
which means the gate leakage will be measured between (1*power_period)
and ((1*power_period)+power_period) under default conditions where
power_period equals 1.32e-8s. You can set the parameter
gate_leakage_time_scaling_factor to an appropriate value, 50.0 for
example, and then reconfigure, recharacterize (after deleting the cache) and

520 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Leakage Power

model the cell. This will measure the gate leakage current between
(50*power_period) and ((50*power_period)+power_period) (if it is set
to 50.0).
If the gate leakage current for some when conditions is still unexpected and/or
of reverse polarity, it means that the time scaling factor 50.0 is not sufficient.
The parameter needs to be set to a larger value may be 75.0 or 100.0 or 150.
You must reconfigure and recharacterize the cell every time (after deleting the
cache) this parameter is set to a new value.

Leakage Power State Compression

When characterizing leakage power for cells with many inputs, the number of
leakage states can be overwhelmingly large. You can manually reduce the
number of states by using explicit when statements via the set_config_opt
command, but this can be somewhat cumbersome and time consuming for
large cells. This feature can independently reduce both the number of states
characterized and the number of states modeled.

Reducing the Number of Characterized Leakage States

Use the expand_side_inputs command to generate a reduced list of when
conditions. The output from this command is then given to the
set_config_opt command to explicitly specify the when conditions just as
you would do manually.

Power Measurement Methodology for Antenna Cells

You must add the following line in the instance file for the antenna cells to be
able to measure leakage power through the ground supply like VSS:
Example 311
set_cell_type antenna

In addition, if you want to measure the leakage power after 100ns, the
parameter initial_delay should be set to 100ns. Increasing the parameter
gate_leakage_time_scaling_factor will have no effect on the
simulation time and the measurement time.

SiliconSmart ACE User Guide 521

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

Multi-Rail Power Methodology

Each supply in the SiliconSmart parameter power_meas_supplies is
monitored and current is integrated individually, and measured data contains
an individual power value for each supply (Liberty model contains an
internal_power group per supply). A modeler post-processes these values
and writes the model.
Setting the parameter liberty_multi_rail_format to v1/v2 (default is
none) will write multi-rail power constructs in the Liberty model. Once
characterized, both single and per-supply models can be generated.
A single power event will result in power being drawn from multiple rails. Power
from each rail is independently modeled in an individual table.

522 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

An example of this follows:

Example 312
Liberty Model Header
input_voltage(core) {
vil : 0.0 ;
vih : 0.9 ;
vimin : 0.0 ;
vimax : 0.9 ;
}

input_voltage(pad) {
vil : 0.0 ;
vih : 3.0 ;
vimin : 0.0 ;
vimax : 3.0 ;
}

power_supply() {
default_power_rail : VDD ;
power_rail(VDD, 0.9);
power_rail(VDDPST, 3.0); }

operating_conditions(worst) {
process : 1.0 ;
temperature : 125 ;
voltage : 3.0 ;
power_rail(VDD, 0.9);
power_rail(VDDPST, 3.0); }

Cell Model

cell(PADNMINLVDS_1) {
cell_leakage_power : 1122. ;
rail_connection(con_VDD, VDD);
rail_connection(con_VDDPST, VDDPST);

pin(dout) {
direction : output ;
output_signal_level : VDD ;
output_voltage : core ;

internal_power() {
power_level : "VDD" ;
related_pin : "inn" ;
when : "!test" ;
fall_power(pwr_tin_oload_5x5) { }
rise_power(pwr_tin_oload_5x5) { }

SiliconSmart ACE User Guide 523

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

internal_power() {
power_level : "VDDPST" ;
related_pin : "inn" ;
when : "!test" ;
fall_power(pwr_tin_oload_5x5) { }
rise_power(pwr_tin_oload_5x5) { }
}
}

Multi-Rail Power Support

All user-specified power rails in the operating conditions in the configure.tcl file
are modeled in the operating_condition and power_supply block of the
generated Liberty file using the power_rail attribute. All cell rails are
connected at the cell level using the rail_connection attribute.
The grounds to be modeled must be listed in the power_meas_grounds
parameter. If a ground rail is omitted from this list, it will incorrectly appear in
the power_supply block of the Liberty model.
There is an additional parameter model_exclude_supplies that can be
used to specify supply rails that should not be modeled in the output Liberty file.
You can use the set_opc_default_voltage command to allow the default
voltage for any operating condition to be specified, which is used as the default
library voltage in the Liberty model. This is used in cases when there are
multiple voltages. When not set, the default is the minimum of all the voltages
for the operating condition.
SiliconSmart measures the power consumed by each supply rail independently
during power characterization. At modeling time you can choose to model the
power in the traditional form (all supplies combined) or using the Liberty multi-
rail constructs.
SiliconSmart supports multi-rail leakage modeling as well as support for the
Liberty pg_pin syntax. You can use the liberty_multi_rail_format
parameter to enable this functionality. Possible values for this parameter are
none, v1, and v2. The default value is none. The value v1 enables a previous
multi-rail power syntax. The value v2 causes SiliconSmart to generate the
multi-rail format, including multi-rail leakage models.
For backwards compatibility, when liberty_multi_rail_format is not set,
SiliconSmart follows the setting of the model_power_per_supply

524 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

parameter. Thus, when model_power_per_supply is set to true,

liberty_multi_rail_format automatically defaults to a value of v1 and
produces consistent models.
You must define pintype as follows in the configure file:
Example 313
pintype h ->default {
set logic_high_name vddi ....
}
pinype k ->default {
set logic_high_name vdd...
}

To support this feature, you must use the most recent Liberty multi-rail power
as described in the application note CCS Power Liberty Syntax, version 2.0.

SiliconSmart ACE User Guide 525

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

The following .lib file demonstrates multi-rail format:

/
***************************************************************
***/
/* Liberty models generated by SiliconSmart 2007.05 (Production)
*/
/* */
/* File generated on Thu Jul 12 17:14:43 CDT 2007. */
/
***************************************************************
****/

library(tt_0p8v_1p2v_25c) {
delay_model : table_lookup ;
time_unit : 1ns ;
voltage_unit : 1V ;
current_unit : 1mA ;
capacitive_load_unit(1, pf);
pulling_resistance_unit : 1kohm ;
leakage_power_unit : 1uW ;
voltage_map(vdd, 1.200);
voltage_map(vddi, 0.800);
voltage_map(vddg, 1.200);
voltage_map(vssg, 0.000);

operating_conditions(tt_0p8v_1p2v_25c) {
process : 1.000 ;
temperature : 25 ;
voltage : 0.8000 ;
}

input_voltage(default) {
vil : 0.000 ;
vih : 1.200 ;
vimin : 0.000 ;
vimax : 1.200 ;
}

input_voltage(footer) {
vil : 0.000 ;
vih : 1.200 ;
vimin : 0.000 ;
vimax : 1.200 ;
}

input_voltage(header) {
vil : 0.000 ;
vih : 1.200 ;

526 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

vimin : 0.000 ;
vimax : 1.200 ;
}

input_voltage(lowvoltage) {
vil : 0.000 ;
vih : 0.8000 ;
vimin : 0.000 ;
vimax : 0.8000 ;
}

output_voltage(default) {
vol : 0.000 ;
voh : 1.200 ;
vomin : 0.000 ;
vomax : 1.200 ;
}

output_voltage(footer) {
vol : 0.000 ;
voh : 1.200 ;
vomin : 0.000 ;
vomax : 1.200 ;
}

output_voltage(header) {
vol : 0.000 ;
voh : 1.200 ;
vomin : 0.000 ;
vomax : 1.200 ;
}

output_voltage(lowvoltage) {
vol : 0.000 ;
voh : 0.8000 ;
vomin : 0.000 ;
vomax : 0.8000 ;
}
cell(foot_8x) {

leakage_power() {
related_pg_pin : "vdd" ;
when : "!sleepn" ;
value : "0.000" ;
}

leakage_power() {
related_pg_pin : "vddg" ;

SiliconSmart ACE User Guide 527

L-2016.03
Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

when : "!sleepn" ;
value : "-0.000" ;
}

leakage_power() {
related_pg_pin : "vddi" ;
when : "!sleepn" ;
value : "-0.000" ;
}

pin(sleepn) {
capacitance : 0.009456 ;
direction : input ;
input_voltage : footer ;

internal_power() {
related_pg_pin : "vdd" ;

fall_power(pwr_tin_2) {
index_1("0.02840, 0.5506");
}

rise_power(pwr_tin_2) {
}
}

internal_power() {
related_pg_pin : "vddg" ;

fall_power(pwr_tin_2) {
}

rise_power(pwr_tin_2) {
}
}

internal_power() {
related_pg_pin : "vddi" ;

fall_power(pwr_tin_2) {
}

rise_power(pwr_tin_2) {
}
}
related_power_pin : vdd ;
related_ground_pin : vssg ;
}

528 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Multi-Rail Power Methodology

pg_pin(vddg) {
voltage_name : vddg ;
pg_type : primary_power ;
}

pg_pin(vddi) {
voltage_name : vddi ;
pg_type : primary_power ;
}

pg_pin(vdd) {
voltage_name : vdd ;
pg_type : primary_power ;
}

pg_pin(vss) {
voltage_name : vss ;
pg_type : primary_ground ;
}
}
}

Modeling Current/Power from Multiple PG Pins into One

PG Pin in Liberty
SiliconSmart supports modeling power/current from multiple PG pins to a
single PG pin. The parameter power_meas_map facilitates this. The
parameters power_meas_supplies and power_meas_grounds should
specify only those PG pins that need to be modeled. Consider the following
example:
Example 314
set_parameter power_meas_supplies {VDD}
set_parameter power_meas_grounds {VSS}
set power_meas_map { VNW VDD VPW VSS }

Here, current/power for pin VNW will be combined along with that of VDD.
Similarly, current/power for pin VPW will be combined along with that of VSS.
Suppose you have the following definition in the configure.tcl file:
set power_meas_supplies {VDD1 VDD2}
set power_meas_map {VNW1 VDD1 }

SiliconSmart ACE User Guide 529

L-2016.03
Chapter 12: Power and Electromigration Models
CCS Power

Here, no mapping has been defined for VDD2, just for VDD1. That means the
current/power number modeled in Liberty related to VDD2 will be current/power
measured for VDD2 only.

CCS Power
To use the CCS-power feature of SiliconSmart, use the following sequence of
commands:
Example 315
set_location charpt
configure –timing –ccs_power cell_list
characterize
model –create_new_model –timing –ccs_power –liberty cell_list

If there are multiple outputs switching for a particular when condition, there will
be different dynamic_current groups—one for each switching output. This is
done to ensure that each dynamic_curent group for an event corresponds to
an internal_power group in which the event comprises of a triplet of
related_input, related_output and a when condition. This modeling
format of dynamic_current will enable to have one-to-one correspondence
between NLDM power tables and CCS-power waveforms.
The below topics are described in the following sections:
■
Optimizing the CCS-Power Waveform
■
CCS Decoupling Capacitance
■
MT-CMOS Switch Cells Support
■ CCS-Power Model Warnings from Synopsys Library Compiler

Optimizing the CCS-Power Waveform

Enable the ccs_power_optimize_waveform parameter to have the
SiliconSmart tool use optimized segmentation to reduce the current waveforms
in CCS-power models:
set_config_opt ccs_power_optimize_waveform 1

By default this option is enabled.

530 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
CCS Power

CCS Decoupling Capacitance

To characterize intrinsic parasitics, a small sinusoidal voltage perturbation is
applied to each PG pin separately. All outputs are connected with tiny loading
capacitance vales (that is, 1fF) such that the measured intrinsic capacitance is
purely PG pin capacitance, and it does not depend on loading. The
recommended voltage magnitude is 0.1V or 10% of power supply.
By measuring the magnitude and phase of the current response, the
capacitance is calculated by the following formula:

I0
---------------------------
V 0 cos   

where:
 is the sinusoidal waveform frequency.
V 0 is the magnitude of the perturbation voltage waveform.

I 0 is the magnitude of the current response.

 is the phase of the current response.

MT-CMOS Switch Cells Support

An MT-CMOS switch cell has at least one virtual output power or ground pin,
one regular input power and ground pin and one input switch pin. MT-CMOS
switch cells characterization uses some of CCS power methodology for
characterization.
The virtual output power/ground pin needs to be identified and added to the
instance file as an output pin using the following command:
Example 316
add_pin virtual_output_pin_name pintype -output

Because the virtual power/ground pin is defined as an output pin, it is also

important to specify the function of this virtual output pin using the
add_function command or add_table command.

SiliconSmart ACE User Guide 531

L-2016.03
Chapter 12: Power and Electromigration Models
CCS Power

Every virtual output pin is associated with a regular power/ground supply pin.
You must also add the following command in the instance file of the MT-CMOS
cell:
Example 317
set_cell_type mtcmos –type coarse_grain|fine_grain \
virtual_supply_name_map {virtual_output_pin pg_pin […] }

The set_cell_type command is needed to specify the information on the

virtual output power/ground pin of the cell.

Note: The –type option is required for specifying the type of the
switch. The value can be either coarse_grain or
fine_grain. The default is coarse_grain.

You must specify this association of the virtual output pin with the primary
power/ground supply pin using the option -virtual_supply_name_map.
The value of this option should be a list containing virtual output pin name
followed by its associated primary power/ground supply pin name.

Note: It is mandatory that the liberty_multi_rail_format

parameter be set to v2 when configuring and modeling an
mtcmos/switch cell. The v1 and v2 format cannot be mixed in the
same Liberty model. When you or model a list of cells that
includes a mtcmos cell and if the parameter is not set to v2, an
error message is generated.

Example 318
set_cell_type mtcmos -type coarse_grain –virtual_supply_name_map
{VVDD VDD }

In the above example, VVDD is a virtual output pin and it is associated with
primary power supply VDD (header cell). Similarly, virtual output pin VVSS is
associated with primary ground supply pin VSS (Footer cell) in the below
example.
Example 319
set_cell_type mtcmos -type coarse_grain –virtual_supply_name_map
{VVSS VSS }

532 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Troubleshooting SiliconSmart Power Models

Once this is done, you can run SiliconSmart and characterize the cell using the
following sequence of commands:
Example 320
set_location charpt
configure –timing –ccs_power switch_cell_name
characterize
model –create_new_model –timing –ccs_power –liberty
switch_cell_name

CCS-Power Model Warnings from Synopsys Library

Compiler
Warning: Line 621454, The 'vector' has identical adjacent 'values'
(0.0162161, 0.0162161). (LBDB-671)

This warning is issued from the Synopsys Library Compiler as two identical
adjacent values in dynamic_current vectors. This can be worked around by
increasing the significant digits for modeling.
Warning: Line 5194739, The 'value' attribute value is less than
the minimum allowed (0.0). Using 0.0 instead. (LBDB-163)

This warning is issued because the resistance value is negative. This occurs for
those intrinsic_resistance groups for three-state when conditions.

Troubleshooting SiliconSmart Power Models

If you suspect the power numbers to be inaccurate, follow the check-list below
to make sure your characterization and modeling environment is setup
correctly.

SiliconSmart Parameters
Check the following parameters in your configure.tcl file.

SiliconSmart ACE User Guide 533

L-2016.03
Chapter 12: Power and Electromigration Models
Troubleshooting SiliconSmart Power Models

■
power_meas_supplies — Be sure to include all your positive power
supplies with this parameter in the form of a Tcl list, for example: “set
power_meas_supplies {VDD VCC VDDIO}”. If any of the supplies are
missing from this list, the current through those supplies will not be
measured and will not be taken into account for the power modeling.
■
largest_slew and max_tout — Although these parameters do not
directly effect power measurements, it is import to note that these
parameters control the size of power measurement windows. Be sure to set
largest_slew to the largest input transition you expect to use during the
characterization of this library. Set max_tout to the largest output slew you
expect to see at the output of any cell in your library given the
largest_slew as an input.
■
power_period—This parameter sets length of the measurement window
for power. SiliconSmart automatically sets the value of this parameter such
that it allows sufficient time to the output voltages to settle. However, in rare
cases where a cell’s output takes unusually long to setting, you may need to
manually override the value of this parameter for a specific cell or set of
cells. If power values look much smaller than expected, try increasing the
value of this parameter. You can query the current value of this parameter
by using the get_parameter command.

Active Driver Netlist Subcircuit Definition

When using an active driver circuit to drive the input signals during
characterization, be sure to include the supply nodes as part of the SPICE
subcircuit so that SiliconSmart can isolate the supplies nodes for the active
driver from the supplies of the cell being characterized. For example, a good
.subckt line for an active driver buffer might be as follows:
Example 321
.subckt BUFX20 A Y VDD VSS

If VDD and VSS are not included above, and VDD and VSS are being used by the
cell netlist as well, it will result in the power being dissipated by the active driver
being incorrectly reported as part of the power of the cell being characterized.
SiliconSmart produces a warning message when this occurs for all standard
Berkeley SPICE format netlists.

534 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

Electromigration (EM) Characterization

Electromigration is the gradual displacement of metal atoms in a
semiconductor. When high-density current passes through a thin metal wire, it
causes drift of metal ions in the direction of the electron flow. Electromigration
can drastically reduce the lifetime of a chip by causing a wire short, or a wire
open.
Current density, and hence, electromigration, strongly depends on the toggle
rate. To meet electromigration requirements of a cell, each output is
constrained to a maximum toggle rate.
In the Liberty model, this is done by annotating cells with electromigration
characterization tables representing the output net’s maximum toggle rates.
Electromigration is represented by the pin-level electromigration group
that contains the em_max_toggle_rate group. The related_pin attribute
identifies the input pin with which the electromigration group is
associated. Liberty syntax allows for an optional current_type attribute to
specify the type of current:
■
average
■
rms
■
peak

SiliconSmart ACE User Guide 535

L-2016.03
Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

The following example shows an electromigration group for an inverter

cell:
pin(X) {
direction : "output" ;
function : "!(A)" ;
……
electromigration() {
related_pin : "A" ;
em_max_toggle_rate(em_ntin_oload_8x7) {
current_type : peak ;
index_1(“…..");
index_2(“…..");
values(“…….");
}
em_max_toggle_rate(em_ntin_oload_8x7) {
current_type : rms ;
index_1(“…..");
index_2(“……");
values(“……");
}
em_max_toggle_rate(em_ntin_oload_8x7) {
current_type : average ;
index_1(“……");
index_2(“……");
values(“……");
}
em_max_toggle_rate(em_ntin_oload_8x7) {
index_1(“……");
index_2(“……");
values(“……");
}
}

The following sections detail electromigration in the SiliconSmart tool:

■
Electromigration Flow
■
Using EM in SiliconSmart
■
Incremental EM Characterization
■
Parameters for EM Characterization
■
EM Characterization Directory

536 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

Electromigration Flow
The figure below represents the EM characterization solution flow chart in the
SiliconSmart tool:

Figure 95 Electromigration flow

SiliconSmart EM characterization flow has two steps:

1. EM Threshold Calculation
2. EM Characterization and Modeling
The first step acquires current thresholds for each cell. The current thresholds
are a pre-requisite to the second step, which performs the EM characterization.
The separation of the current threshold calculation from the EM
characterization provides performance benefits, since the former is done at the
cell level, while the latter is done at the arc level.

EM Threshold Calculation
An essential input to the first step, the current threshold calculations is the RA
Tcl file. The RA Tcl file defines the EM rules in Tcl format suitable for
CustomSim Reliability Analysis (RA).

SiliconSmart ACE User Guide 537

L-2016.03
Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

CustomSim RA is the simulator used by SiliconSmart for the current threshold

calculations. Current thresholds are acquired for each current type (average,
peak, and RMS) for each resistor in the extracted netlist.
The following inputs are required for current threshold calculations:
■
RA Tcl file
■
Post-layout (extracted netlist). The netlist should contain the resistor layer
and geometry information for each resistor in the netlist. An example is given
below:
R1 VBN:1 VBN:10 6.37931e-07 $l=0.037 $w=0.058 $lvl=26
■
Pre-layout netlist. This can be a skeletal file with the .subckt <ports> and
.ends lines only. CustomSim back-annotation flow creates the device only
netlist from the post-layout netlist during the pre-process step.
This step is performed at the cell level and the output is a cell-level .emx file
that contains current threshold values for each current type and for each
resistor in the netlist. The output of this step is a .emx file that is saved in the
<char_dir>/control/emx directory.

EM Characterization and Modeling

While the current threshold calculations are performed at the cell level, the EM
characterization measurements are performed for each propagating arc of the
cell, using Hspice or FineSim as the simulator. The type em_current applies
to EM current measurements. This can be used to apply settings/parameters to
EM current measurements.
For example, the following command will characterize EM currents for a default
state of side inputs for the arc from A to Z for the AOI21 cell:
set_config_opt –type {em_current} –cell AOI21 –from A –to Z
state_partitions one

Average, RMS and peak currents are measured on each resistor in the cell
netlist, for each slew/load index pair specified by the user. The same methods

538 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

available for slew/load index selection for timing measurements are applicable
to EM current measurements.
For example, if the user desires to use the same explicit slew/load indices for
timing and EM tables, it can be done with the following commands:
set_config_opt –type {timing em_current} explicit_points_slew
{slew1 slew2…}
set_config_opt –type {timing em_current} explicit_points_load
{load1 load2…}

The EM tables are modeled in the liberty file at the pin level (for output pins).
Electromigration is represented by the pin-level electromigration group
containing the em_max_toggle_rate group. The tables represent the
maximum toggle rate for each output pin. The related_pin attribute
identifies the input pin associated with the electromigration group.
By default, SiliconSmart models a single EM table in the library for each arc.
This table is created with the maximum toggle rate among the different current
types. By enabling the parameter em_table_with_current_types, a
separate EM table is modeled for each current type: average, rms, and peak.
A library model with EM tables for each current type can give better accuracy
with downstream EM analysis tools.

Using EM in SiliconSmart
As specified in the previous section, the first step that involves calculations of
current thresholds requires an RA Tcl file and a pre-layout netlist. This is in
addition to the extracted netlist that is also used for the main characterization
(timing, EM, others).
The pre-layout netlist for each cell, should reside in a sub-directory named
ideal, under the directory specified by the -netlist_dir option of the
import command.
The netlist extension for the pre-layout netlists should be specified using the
parameter ideal_netlist_ext.
The switch -em to the configure command enables EM analysis. It enables
both the current threshold calculations as well as the EM characterization step.
If pre-calculated current thresholds are already available and specified in the
<char_dir>/control/emx/cell.emx files, the SiliconSmart tool can detect the
existence of these files and skip the current threshold calculations.

SiliconSmart ACE User Guide 539

L-2016.03
Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

The -emx switch to the configure command can be used to run pre-
processing alone, and generate the cell.emx files.
The switch -em to the model command enables modeling of electromigration
tables in the Liberty file.
An example run.tcl script is shown below:
set_location char_dir
import -liberty seed.lib –netlist_dir netlists –ext .spx $cells
configure –timing –em $cells
characterize $cells
model –timing –em $cells

Incremental EM Characterization
The SiliconSmart tool supports incremental characterization of EM models.
This allows a user to add EM models to an existing Liberty model. An example
for Incremental EM characterization is given below. This will copy non-EM data
from the input Liberty and model EM data from the characterized results.
The EM related parameters have to be specified in the configure.tcl:
import -liberty seed.lib –netlist_dir netlists –ext .spx $cells
configure –em $cells
characterize $cells
model –em $cells

Parameters for EM Characterization

The following parameters should be specified for EM characterization:
■ em_threshold_simulator — This parameter specifies the simulator to be
used for EM current threshold calculations. The default is xa. Currently, this
is the only supported simulator for EM current threshold calculations.
■
em_threshold_simulator_cmd — This parameter sets the command to be
used by the SiliconSmart tool to invoke the simulator for EM current
threshold calculations. The command format is similar to the one used for a
command-line execution of the simulator, with the input file replaced by
[input_deck] and output file replaced by [listing_file].
The default is:
xa [input_deck] –o [listing_file].

540 SiliconSmart ACE User Guide

L-2016.03
 Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

■
simulator_options — This is an existing parameter that has been enhanced
with a new tag xa to specify options for reliability analysis with XA including
the RA Tcl file. For example:
set simulator_options {
tran,xa: xa_cmd="set_ra_option -ratcl <RA.tcl file>"
}
■
em_table_with_current_types — This parameter, when enabled, generates
separate EM toggle rate tables in the liberty model for each current type
(average, RMS, peak). The default value is 0, which generates a single
em_max_toggle_rate table for each electromigration table per timing arc.
■
ideal_netlist_ext — This parameter specifies the filename extension
(including the ‘.’) for the pre-layout cell netlists for EM current threshold
calculations (EM pre-process step).

EM Characterization Directory
The figure below illustrates the location of the EM characterization related files
in the SiliconSmart characterization directory:

SiliconSmart ACE User Guide 541

L-2016.03
Chapter 12: Power and Electromigration Models
Electromigration (EM) Characterization

542 SiliconSmart ACE User Guide

L-2016.03
 13
13

CCS-Noise Characterization

This chapter describes noise characterization methodology in SiliconSmart.

The SiliconSmart tool can generate a boundary-based noise model referred to

as CCS-noise (CCSN). The boundary-based modeling requires transistor
netlist analysis of a cell to extract the interface circuitry.
A library with CCS-noise models can be used with PrimeTime SI and other
tools to check for timing and logic failures caused by noise.
The following topics are described in this chapter:
■
Overview of CCS-Noise Characterization
■ Enabling CCS-Noise
■
CCS-Noise Methodology
■
Example Flow
■ User-Defined CCBs

Overview of CCS-Noise Characterization

CCS-noise models in the library enable PrimeTime SI and other tools to
accurately analyze the timing and logic effects of crosstalk noise.
To characterize a library cell for CCS-noise, the SiliconSmart tool builds a
model of the cell using SPICE circuit elements and simulates the effects of
different slews and noise bumps at the cell inputs. Based on the simulation
results, the SiliconSmart tool generates a set of equivalent time-dependent
current-source models that represent the behavior at the cell outputs.

SiliconSmart ACE User Guide 543

L-2016.03
Chapter 13: CCS-Noise Characterization
Overview of CCS-Noise Characterization

PrimeTime SI and other tools use these models to accurately predict the
response of the cell to noise.
CCS-noise characterization requires the cells to be split up into channel
connected blocks (CCBs), then characterizes and models the individual CCBs.
Each CCB has a potential conducting path through transistor sources and
drains. The SiliconSmart tool includes the netlist analysis capabilities to extract
the CCBs and then perform the necessary characterization and modeling
steps.
A simple cell, such as an inverter, has only a single stage from input to output.
A cell such as an AND gate has two stages. A more complex cell, such as a D
flip-flop, has more than two stages. This is shown below.

Figure 96 CCS-Noise Representation

A CCS-noise model represents the noise response of each stage. A single

stage or two stages from input to output results in an arc-based CCS-noise
model, while more than two stages results in a pin-based CCS-noise model.
Each stage (CCB) is characterized for a DC response, noise propagation,
output voltage behavior and miller capacitance. The CCS-noise models for
each stage are then used to construct the CCS-noise model for the whole cell.

544 SiliconSmart ACE User Guide

L-2016.03
 Chapter 13: CCS-Noise Characterization
Enabling CCS-Noise

Enabling CCS-Noise
You can enable the CCS-Noise feature by specifying the –ccs_noise switch
to various commands available in SiliconSmart. The commands that require the
–ccs_noise option for generating CCS-noise models are as follows:
■
configure (CCS-Noise)
■
characterize (CCS-Noise)
■
model (CCS-Noise)
■
Selectively Choosing Pin-Based Noise Models
■
Generating Single CCBs for Input and Output Pins

configure (CCS-Noise)
A cell is configured for CCS-noise by specifying the –ccs_noise option with
the configure command. CCS-noise is configured along with timing, which
means you must also specify the -timing switch:
configure -timing –ccs_noise cell_list

An exception to this is when a memory is being characterized to incrementally

add CCS-noise to an existing timing library, as discussed in Incremental CCSN
Memory Characterization Flow.
Configuration for CCS-noise performs two tasks. First it partitions the cell netlist
to generate interface port Channel Connected Blocks (CCBs). Then it
configures these CCBs for CCS-noise. After a cell is configured for CCS-noise,
an instance file (.inst file) and a netlist is created for each CCB that has been
partitioned. The CCB .inst files are created in the <charpt>/control/<cell>/
directory. The CCB netlists are created in the <charpt>/netlists/<cell> directory.
The netlist partitioning phase of configuration requires N-type and P-type
transistor model names used in the cell SPICE netlist. These must be specified
using two parameters nmos_model_names and pmos_model_names,
defined in the default parameters block in configure.tcl. Consider the following
example:

SiliconSmart ACE User Guide 545

L-2016.03
Chapter 13: CCS-Noise Characterization
Enabling CCS-Noise

Example 322
define_parameters default {
…
set nmos_model_names {list of N-type transistor models}
set pmos_model_names {list of P-type transistor models}

The SiliconSmart tool provides additional parameters to support BJT, resistor,

capacitor, and diode model names in the SPICE netlist:
■
bjt_model_names {list of BJT models}
■
cap_model_names {list of capacitor models}
■
dio_model_names {list of diode models}
■
res_model_names {list of resistor models}
FinFet technology contains 3 terminal MOSFETS. The SiliconSmart tool has
the following parameters to specify the model names for such devices:
■
nmos_drn_gate_shorted_model_names
■
nmos_drn_src_shorted_model_names
■
nmos_gate_src_shorted_model_names
■
pmos_drn_gate_shorted_model_names
For example, nmos_drn_src_shorted_model_names should specify the
list of NMOS devices with drain and source shorted.
See Also
■
Parameter: nmos_model_names
■
Parameter: pmos_model_names

characterize (CCS-Noise)
No additional switches are required for the characterize command to
characterize CCS-noise. All cells/CCBs that have been configured during the
configuration step are characterized.

546 SiliconSmart ACE User Guide

L-2016.03
 Chapter 13: CCS-Noise Characterization
Enabling CCS-Noise

model (CCS-Noise)
Similar to the configuration step, modeling for CCS-noise is performed along
with timing, which means the -timing switch must be specified along with the
-ccs_noise switch for the model command:
model -timing -ccs_noise cell_list

During modeling, the SiliconSmart tool combines the CCS-noise models of

each individual CCB to create a CCS-noise model for the cell.

Selectively Choosing Pin-Based Noise Models

When performing CCS-noise partitioning, CCBs are created for all of the input
and output pins for any cell. To instruct the SiliconSmart tool not to create
CCBs for certain pins of a cell, use the ccsn_exclude_pin parameter. This
parameter takes a list of input and output pins for which CCSN models should
not be created. The SiliconSmart tool will create CCBs for all pins except those
specified with this parameter.
Example 323 Using ccsn_exclude_pin
set_config_opt -cell ccsn_exclude_pin {pin1 pin2 ...}

where -cell is the cell and pin1 pin2 ... are the pins which will not have
CCSN models created.
The usage of this parameter is similar to any other parameter used with the
set_config_opt command. The parameter can be set at the cell-level and
can be specified with one or more pin names in the form of a list.
A check will be done to see if the pin names specified in the parameter value
are legal pin names which belong to the cell. If not, a warning will be generated.
See Also
■
Command: set_config_opt
■
Parameter: ccsn_exclude_pin

SiliconSmart ACE User Guide 547

L-2016.03
Chapter 13: CCS-Noise Characterization
CCS-Noise Methodology

Generating Single CCBs for Input and Output Pins

You can generate a single CCB for each input and output pin by using the
parameter ccb_single_fanout by setting it to one of the following values:
■
0 — generate all CCBs for all the bits of the bus (default)
■
1 — generate only one CCB for the input and output pins. If the input/output
pin is a bus, a single CCB will be generated for each bit of the bus.
■
2 — generate a single CCB for the whole bus. The bit used to create the
CCB is based on the value of the parameter ccb_single_fanout_bit.
■
3 — If the input pin is a bus, all possible CCBs will be generated for the bit
specified by the parameter ccb_single_fanout_bit. For a normal input
pin which is not a bus, setting this parameter to 3 functions as if set to 0.
See Also
■
Parameter: ccb_single_fanout
■
Parameter: ccb_single_fanout_bit

CCS-Noise Methodology
CCS-noise characterization requires four measurements to be performed for
each CCB. These are described in the following sections:
■
CCS-Noise IV
■
CCS-Noise Waveform
■
CCS-Noise Propagation
■ CCS-Noise Miller Capacitance

CCS-Noise IV
This measurement collects the DC current at the output node of a CCB by
sweeping the input and output voltages. The input and output voltages are
swept in the voltage range from -VDD to 2*VDD. The maximum number of input
and output voltage values are clustered in the range from 0 - VDD.
The number of voltage points required is controlled by the pin type parameter
ccsn_numsteps_voltage. The lower limit of this parameter is 6 and the

548 SiliconSmart ACE User Guide

L-2016.03
 Chapter 13: CCS-Noise Characterization
CCS-Noise Methodology

recommended upper limit is 29 (the default). This parameter is specified in the

configure.tcl file, as in the following example:

Example 324
pintype default {
…
set ccsn_numsteps_voltage 17
}

The ccsn_numsteps_voltage parameter also determines the range:

■
If ccsn_numsteps_voltage >=6 and <=16, the range is from -0.1VDD to
1.1VDD.
■
If ccsn_numsteps_voltage >=17 and <=25, the range is from -0.5VDD
to 1.5VDD.
■
If ccsn_numsteps_voltage >=26, the range is from -VDD to 2VDD.
See Also
■
Parameter: ccsn_numsteps_voltage

CCS-Noise Waveform
This measurement is similar to delay measurement, except that five values on
the output voltage waveform are captured at 10%, 30%, 50%, 70%, and 90% of
VDD. The test setup for this measurement requires applying a linear voltage
ramp at the input and recording the corresponding output voltage.
The pin type parameter ccsn_default_load controls the load placed on
internal nodes in the netlist that become outputs once the CCB is partitioned
into a separate netlist. For example, if the first inverter in a buffer is partitioned
out separately, the output can have a small load applied to it to simulate the
second stage inverter it normally drives. As long as this load is smaller than the
original load, the results will be accurate (smaller loads are slightly more
pessimistic than a larger original load.)
This parameter is defined in the configure.tcl file, as in the following example:
Example 325
pintype default {
…
set ccsn_default_load 1e-15
}

SiliconSmart ACE User Guide 549

L-2016.03
Chapter 13: CCS-Noise Characterization
CCS-Noise Methodology

The default value of this parameter is 1e-15.

See Also
■
Parameter: ccsn_default_load

CCS-Noise Propagation
This measurement has two dependencies, namely CCS-Noise IV, and CCS-
Noise Waveform. Input triangular waveform heights and widths for this
measurement are obtained by processing the CCS-Noise IV and CCS-Noise
Waveform measurement data. The measurement applies triangular input
pulses of the calculated widths and heights to the input pin of the CCB. The
output waveform is captured at five specific points: 50% of peak, 80% of peak,
peak, 80% of peak, and 50% of peak.
For internal nodes that become outputs once the CCB is partitioned,
ccsn_default_load can be used, as described previously.
See Also
■
Parameter: ccsn_default_load

CCS-Noise Miller Capacitance

This measurement measures the miller capacitance of the CCB. The miller
capacitance for a CCB is formed by the Cgd of transistors.

Figure 97 Miller Capacitance Measurement Methodology

A voltage source applied at the output of the CCB is swept by  Vout and the
voltage change at the input  Vin is measured. The measurements are done for

550 SiliconSmart ACE User Guide

L-2016.03
 Chapter 13: CCS-Noise Characterization
Example Flow

two different values of input capacitance. The miller capacitance is calculated

as:

Cin1 – Cin2
Cm = ---------------------------------------
Vout
---------------- – Vout
----------------
Vin1 Vin2
The parameter ccsn_use_enhanced_miller_cap can be used for better
receiver modeling. It can take a value of 0, 1, or 2.
■
When set to 0 — the method described above is used.
■ When set to 1 — the method described above is used, but all resistances in
the CCB output will be shorted to take care of the shielding effect in order to
capture the miller cap effectively.
■
When set to 2 — use this only for advanced nodes. It functions as when
ccsn_use_enhanced_miller_cap is set to 1.
See Also
■
Parameter: ccsn_use_enhanced_miller_cap
■
Parameter: miller_capacitance_check_tolerance_pct
■
Parameter: miller_capacitance_edge_ratio

Example Flow
Consider a two stage 2-input AND gate. The first stage is a 2-input NAND gate
and the second stage is an inverter. The input node name of the inverter is

SiliconSmart ACE User Guide 551

L-2016.03
Chapter 13: CCS-Noise Characterization
User-Defined CCBs

internalNode. An example run.tcl file for generating CCS-noise models for a

2-input AND cell is as follows:
Example 326
set cells { AND }
# configure command generates three CCBs one for input pin A,
another for input pin B,
# and one for output pin Z. for e.g. the CCBs generated are
AND__A__internalNode,
# AND__B__internalNode, and AND__internalNode__Z.
configure –timing –ccs_noise cells
# characterization engine loads CCS-Noise acquisition for cell
CCBs and characterizes
# the cell CCBs also.
characterize cells
model –create –timing –ccs_noise –out and_cell_timing_ccsnoise
cells

Refer to Example 15 on page 57 for an example flow for the incremental add-
on of CCS-CCS-noisenoise models to an existing timing library for standard
cells.

User-Defined CCBs
You can use the define_cell_ccb command in the instance file of a cell to
define the CCBs manually for CCS-noise analysis. This is useful for cases
where the SiliconSmart tool cannot partition the cell correctly into CCBs
automatically due to the complex structure of the cell netlist.
Example 327 define_cell_ccb Syntax
define_cell_ccb –relevant_pin cell_pin
[-inputs ccb_input_pin_names] -output ccb_output_pin
[-transistors list_of_transistor_names_in_the_ccb]
[-switching_set list_of_net_names]
[-input_vectors list_of_input_vectors]

where:
■
-relevant_pin — this option is required. It defines the cell input or output
pin for which the CCB has to be manually generated for CCS-noise
measurements.
■
-output — this option is required. It specifies the output of the CCB. The
output of the CCB can be a primary output or an internal pin.

552 SiliconSmart ACE User Guide

L-2016.03
 Chapter 13: CCS-Noise Characterization
User-Defined CCBs

■
-inputs — this optional argument defines the inputs for the CCB. If this
option is not specified, then all the primary input pins of the cell are
considered as inputs to the CCB.
■
-transistors — this optional argument can be used to specify the list of
transistors in CCB. If this argument is not specified, the SiliconSmart tool will
probe the output of the CCB using the whole netlist to make CCS-noise
measurements.
■
-switching_set — this optional argument specifies the pin/net names
that must switch together for the noise propagation to switch from input to
output of the CCB. This option must be used along with the -inputs option.
This option will mostly be useful in case of three-state buffer cells where the
two inputs to the last inverter at the output stage must switch together for
creating a CCS-noise measurement. The pin/net names that can be
specified in the switching_set must be a subset of the pin/net names
specified in the -inputs switch. Any pin that is not specified in the
-inputs switch cannot be used in the -switching_set option.
■
-input_vectors — this optional argument can be used to specify list of
user-defined vectors for the CCB to find out the function of the CCB. If this
option is specified, only these vectors will be used in the instance file to get
the functionality of the CCB. Each vector length should be the same as the
number of inputs specified in the -inputs switch. This option cannot be
specified if -inputs switch has not been specified.

Example 328
define_cell_ccb –relevant_pin { B} –inputs {A B CI} –output {net72}
–input_vectors { {0 0 0 } {0 1 0} }

The above example indicates that the CCB from B to net72 will use only these
user-defined vectors for creating CCS-noise tests. The other possible 6 vectors
will not be considered. It is user’s responsibility to give appropriate vectors in
such cases such that there is a transition at the CCB input which gives an
inverted transition at the CCB output with other inputs not switching. In the
above example, this simply indicates that while B is switching from 0->1, the
output must switch from 1->0 (this will be found by SiliconSmart using this
combination of input vectors) with A and CI held constant at 0. If the output

SiliconSmart ACE User Guide 553

L-2016.03
Chapter 13: CCS-Noise Characterization
User-Defined CCBs

does not switch from 1->0 using these two vectors, no CCS-noise tests will be
generated. The user will have to give new vectors in such a case.
Example 329
A B CI : net72
0 0 0 : <will be found by doing crude simulation>
0 1 0 : <will be found by doing crude simulation>

Example 330 Example of an instance file containing a manual CCB definition:

define_cell_ccb –relevant_pin {B} –output {NMB}
define_cell_ccb –relevant_pin {A} –output {NMA}
define_cell_ccb –relevant_pin {CI} –output {NMCIN}
define_cell_ccb –relevant_pin {CI} –output {NMCINN}
define_cell_ccb –relevant_pin {S} –inputs {NET167} –output {S}
define_cell_ccb –relevant_pin {CO} –inputs {A B CIN} –output {CO}

Example 331 Example of an instance file containing manual CCB definitions for a
tristate buffer:
define_cell_ccb –relevant_pin {A} –output {NMIN}
define_cell_ccb –relevant_pin {A} –inputs {OE A} –output {NET38}
–input_vectors { {1 1} { 1 0}}
define_cell_ccb –relevant_pin {OE} –output {NMEN}
define_cell_ccb –relevant_pin {Y} –inputs {NET38 NMIN} –output
{Y} –switching_set {NET38 NMIN}

554 SiliconSmart ACE User Guide

L-2016.03
 14
14

Command Reference

This chapter describes SiliconSmart commands.

SiliconSmart commands are grouped into three functional categories:

■ Setup Commands
■
Query Commands
■
Processing Commands
■ Memory Commands

Setup Commands
Setup commands initialize SiliconSmart and/or the corresponding files and
directories. These commands are used before a cell is characterized. The
following setup commands are available:
■ add_back_bias_supplies
■
add_channel_length_variation
■
add_channel_width_variation
■
add_fixed_value
■ add_flop
■
add_forbidden_state
■
add_function
■ add_harness_elements

SiliconSmart ACE User Guide 555

L-2016.03
Chapter 14: Command Reference
Setup Commands

■
add_latch
■
add_liberty_group
■
add_one_hot
■
add_opc_grounds
■
add_opc_statistical_parameter
■
add_opc_supplies
■
add_pin
■
add_process_parameter_variation
■
add_switch_tuple
■
add_switching_set
■
add_table
■
add_transistor
■
add_user_stimulus
■
analyze_netlists
■
cell_families_by_name
■
change_parameter
■
clear_config_opts
■
clear_liberty_attribute
■
clear_liberty_group
■
configure
■
create
■
create_harness
■ create_operating_condition
■
define_cell_ccb
■
define_differential_receiver
■
define_parameters
■
enable_api
■
expand_side_inputs
■
find_internal_nodes_for_constraint

556 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

■
find_potential_internal_nodes
■
get_word_line_node
■
man
■
merge
■
pintype
■
remove_driver
■
remove_parameter_block
■
remove_pintype
■
report_arcs
■
set_boundary_distance
■
set_bus_value
■
set_cell_type
■
set_config_opt
■
set_harness_parent
■
set_length_unit
■
set_liberty_attribute
■
set_location
■
set_log_file
■
set_log_level
■
set_log_stdout_level
■
set_maskable_enable_control_output
■
set_measurement_node
■ set_netlist_file
■
set_opc_parameter
■
set_opc_parameter_distribution
■
set_opc_process
■
set_opc_temperature
■
set_opc_default_voltage
■
set_output_differential

SiliconSmart ACE User Guide 557

L-2016.03
Chapter 14: Command Reference
Setup Commands

■
set_parameter
■
set_pins_to_bundle_map
■
set_pintype_parameter
■
set_points_boundary_distance
■
set_stimulus_node
■
set_subckt_ports
■
set_sweep_parameter
■
status
■
test_internal_nodes_for_constraint
■
validate_hdl

add_back_bias_supplies
Adds back bias support by specifying nwell/pwell/deepnwell/deeppwell
supplies.
Syntax
add_back_bias_supplies {
bias_pin pg_type related_supply_pin
…
…
}
Arguments
bias_pin
Back bias supply defined by the command add_opc_supplies.
pg_type
Type for the back bias (nwell/pwell/deepnwell/deeppwell).
related_supply_pin
Associated pg_pin to bias supply.
Description
The following parameters must be set as such to use back bias support:
■ liberty_flavor = 2008.09
■
model_back_bias = 1

558 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

The back_bias_connection parameter defines the physical connection.

Examples
Below is an example for setting up the back bias supply in configure.tcl:
Example 332
set_config_opt model_back_bias 1
set_config_opt back_bias_connection device_layer

add_back_bias_supplies {VNW nwell VDD}

add_back_bias_supplies {VPW pwell VSS}

add_opc_supplies op_cond VDD 0.89 VNW 0.8

add_opc_grounds op_cond VSS 0 VPW 0

SiliconSmart ACE User Guide 559

L-2016.03
Chapter 14: Command Reference
Setup Commands

The output library will have the following attributes associated with pg_pin VNW
and VPW:
Example 333
...
voltage_map(VNW, 0.8); /* bias power */
voltage_map(VPW, 0.0); /* bias ground */

. . .
cell(std_cell) {
cell_footprint : std_cell;
area : 1.0;

pg_pin(VDD) {
voltage_name : VDD;
pg_type : primary_power;
related_bias_pin : "VNW";
}

pg_pin(VSS) {
voltage_name : VSS;
pg_type : primary_ground;
related_bias_pin : "VPW";
}

pg_pin(VNW) {
voltage_name : VNW;
pg_type : nwell;
physical_connection : device_layer;
}

pg_pin(VPW) {
voltage_name : VPW;
pg_type : pwell;
physical_connection : device_layer;
}

...

See Also
add_opc_statistical_parameter

560 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

add_channel_length_variation
This command specifies channel length variation for a transistor as distance
from neighboring cells is varied.
Syntax
add_channel_length_variation transistor_name
-dependent_parameters dependent_parameter_list
-values value_list
Arguments
transistor_name
The name of the transistor as in the netlist.
-dependent_parameters
The boundary distances on which the channel length is dependent.
-values
The list of channel length values.
See Also
add_channel_width_variation
add_opc_statistical_parameter
add_process_parameter_variation
add_transistor
set_length_unit
set_opc_parameter_distribution
set_points_boundary_distance

add_channel_width_variation
This command specifies channel width variation for a transistor as distance
from neighboring cells is varied.
Syntax
add_channel_width_variation transistor_name
-dependent_parameters dependent_parameter_list -values
value_list

SiliconSmart ACE User Guide 561

L-2016.03
Chapter 14: Command Reference
Setup Commands

Arguments
transistor_name
The name of the transistor as in the netlist.
-dependent_parameters
The boundary distances on which the channel length is dependent.
-values
The list of channel width values.
Examples

Example 334
add_channel_width_variation M1 dependent_parameters {lower_left}
-values {200 200 200 200 200 200 200 200 200 200 200 200 200 200
200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200
200 200 200 200 200 200 200 200 200}

In this example, the channel width for transistor M1 depends on distance from
lower left transistor of the cell to neighboring cell. Values in the list specify how
the channel width varies as the distance to neighboring cell is varied.
See Also
add_channel_length_variation
add_opc_statistical_parameter
add_process_parameter_variation
add_transistor
set_length_unit
set_opc_parameter_distribution
set_points_boundary_distance

add_fixed_value
This command sets a constant input value for input or bi-directional pins.
Syntax
add_fixed_value pin value
Arguments
pin
Name of an input or bi-directional pin.

562 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

value
Constant value of the pin, 0 or 1.
Description
The add_fixed_value command allows an input or bi-directional pin to be
set to a constant state (0 or 1). You can use this for pins that do not affect the
logical function of a circuit, and are not expected to transition in an
implementation. When this function is used, SiliconSmart will not measure the
input pin capacitance or any hidden (non-switching) energy for this pin. The
alternative method is to treat the pin as a don't care pin as described in the
Disabling Measurements section.

Note: The add_fixed_value command should be used only for input

pins and should not be used for output part of the inout pins
functionality

Examples
The following command specifies that the voltage reference pin VREF is to be
tied high:
Example 335
add_fixed_value VREF 1

See Also
set_config_opt

add_flop
This command adds an edge-triggered sequential element to the cell.
Syntax
add_flop -clear expression -preset expression
-preset_clear \ values {register inv_register clock_expr
data_expr}
Arguments
-clear expression
A Boolean expression describing the asynchronous clear state.
-preset expression
A Boolean expression describing the asynchronous preset state.

SiliconSmart ACE User Guide 563

L-2016.03
Chapter 14: Command Reference
Setup Commands

-preset_clear values
Specifies the value of the register and inverted register if both the –preset
and –clear conditions are true. values is a Tcl list of two Boolean values
(0, 1) specifying the value of register and inv_register, respectively.
register
The name of the non-inverted register.
inv_register
The name of the inverted register.
clock_expr
A Boolean expression for the flop clock function.
data_expr
A Boolean expression for the data input function.
Description
The add_flop command adds an edge-triggered sequential element to the
description of the cell. The flop expressions can be a combination of input (and
bi-directional) pins, internal pins, and registers from other sequential elements.
If the flop supports it, asynchronous preset and/or clear expressions can be
defined as well. If both are specified, then the switch -preset_clear can be
used to specify the value of the two registers when both expressions are true.
This switch is optional when both –preset and –clear are specified and
illegal otherwise. The value is a Tcl list of two Boolean values (0, 1) reflecting
the value of the register and inverted register, respectively. See the Examples.
Examples
The following describes a simple D-flop:
Example 336
add_flop IQ IQN CK D

The register IQ simply gets the value D when CK rises and IQN gets the
inverted value of D. For a more complex example, consider this command:
Example 337
add_flop IQ IQN !CK {D&SEL | IQN&!SEL} –clear !RB –preset S \
–preset_clear { 1 0 }

This command does several things. First, the flop is triggered off a falling edge
on CK, indicated by the function !CK. Further, the data expression is a simple

564 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

function of D when SEL is true. When SEL is false the flop becomes a toggle
flop where the output toggles each time it is clocked.
An active low clear pin (RB) and active high preset pin (S) are both preset. If
both are asserted at the same time, the –preset_clear switch specifies that
the preset dominates and thus register IQ gets the value 1 and the inverting
register IQN gets the value 0.
See Also
add_function
add_latch
add_table

add_forbidden_state
This command defines a global illegal state for the cell as a Boolean
expression.
Syntax
add_forbidden_state expression
Arguments
expression
Boolean expression specifying the illegal state(s) for this cell.
Description
The add_forbidden_state command is used to restrict the possible legal
states for a cell. This is useful when dealing with multiple switching inputs
where some combinations are illegal, such as when the inputs are
complementary.
One example use of this command is to define the behavior of a flop with
complementary inputs. The description of the cell looks like the following:
Example 338
add_flop IQ IQN {CK&!CKB} D
add_switching_set { CK CKB }
add_forbidden_state { !(CK^CKB)}

These commands first define the clocking event of the flop as the case where
CK rises and CKB falls. The add_switch_tuple is necessary to specify that
CK and CKB can switch as a set. The add_forbidden_state command is
necessary to specify that CK and CKB must always be complementary to each
other–the case of CK&CKB is not legal.

SiliconSmart ACE User Guide 565

L-2016.03
Chapter 14: Command Reference
Setup Commands

See Also
add_one_hot
add_switching_set
add_switch_tuple

add_function
This command defines the logical function of a pin.
Syntax
add_function [-hi_z expression] [-illegal expression] pin
expression
Arguments
-hi_z
A Boolean expression defining when the pin is in a high-impedance state.
-illegal
A Boolean expression definition when the pin is in an illegal or unknown
state.
pin
Name of a pin defined with add_pin.
expression
A Boolean expression defining the output value of the pin for all conditions
not covered by the high impedance or illegal conditions.
Description
The add_function command is used to define the combinational function of
a pin in terms of other input (or bi-directional) pins, internal pins, and registers.
In the simplest form, the command takes a single Boolean expression that
defines the output value. Two other optional expressions can be provided to
define when the output is in a high-impedance (undriven) state or in an illegal/
undefined state.
The add_function command can be used to define the function of internal
pins. This can be used to define the function of a cell structurally instead of
attempting to capture the complete description in a single function or table.

566 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Examples
The following example describes a bi-directional, differential I/O pad. When the
EN pin is true, the PAD pins are driven; when false they are inputs and control
the Z pin. The following commands define the behavior of the cell:
Example 339
add_function PADP A –hi_z !EN
add_function PADN !A –hi_z !EN
add_function Z {PADP&!PADN} –illegal {PADP&PADN | !PADP&!PADN}

The first two lines describe the function of the differential outputs. Notice that
the –hi_z switch is used to indicate that the pad pins are not driven when EN is
low. The third line describes Z as a function of the differential pins. The
expression following the –illegal switch indicates that it is illegal for PADP
and PADN to be in the same state, which would result in an undefined value for
Z.
See Also
add_pin
add_switching_set
add_table
define_differential_receiver
set_output_differential

add_harness_elements
This command adds one or more circuit elements to a harness.
Syntax
add_harness_elements name element_list
Arguments
name
Name of a harness created with the create_harness command.
element_list
A list of one or more circuit elements as described below.
Description
This command adds a set of circuit elements to a harness using a format
similar to SPICE. The elements can be connected to pins on the cell, supplies

SiliconSmart ACE User Guide 567

L-2016.03
Chapter 14: Command Reference
Setup Commands

defined in the operating conditions, or nodes in the harness. Nodes are created
in the harness when referenced.
The element_list parameter is a Tcl list of elements, where each element is a
line of the following format:
Example 340
type name node1 [node2 ... nodeN] parameter1

where type is one of the types defined in the following table. Each type of circuit
element requires one or more nodes to connect to and a parameter value. The
meaning of the parameter depends on the element and is described in the table
as well.

Type Element Nodes Parameter

R Resistor 2 Resistance (ohms)

C Capacitor 2 Capacitance
(Farads)

L Inductor 2 Inductance
(Henrys)

X Subcircuit User defined Subcircuit name.

VCVS Voltage-controlled 4a Voltage ratio

voltage source

VCR Voltage-controlled 4a Voltage/resistance

resistor ratio (V/Ohms)

VCCS Voltage-controlled 4a Voltage/current

current source ratio (V/amps)

The first two nodes are the controlled nodes; the second pair are the reference
nodes.
Legal node names include the name of any pin on the cell and any supply
defined in the operating condition. Additionally, the first time an unknown node
name is referenced, the node is created. Similar to some SPICE simulators, a
warning is generated for any nodes with only a single connection. Node names
must begin with a letter and can consist of letters, numbers, and underscores.

568 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

If the parameter value for any of the circuit elements is anything other than a
floating-point value, the value is assumed to be the name of a parameter. The
parameter name is looked up in the current operating condition (see
set_opc_parameter) and then in the current parameter block (default, or
another block set through the parameters option to set_config_opt). The
value of that parameter is then used as the value of the circuit element.
Arbitrary, user-defined subcircuits can be included. In this case, the number
and meaning of the nodes are dependent on the subcircuit definition.To use the
subcircuits, a file with the subcircuit definition must be included in the
simulation. You can do this by including the appropriate line in the process
section of the operating condition definition. (See set_opc_process) This
mechanism allows the subcircuit definitions to change based on operating
condition.
Care should be exercised when connecting elements to the supplies used by
the cell itself since any current consumed by the harness will be included in the
power calculations for the cell. The preferred method is to create separate
supply definitions in the operating condition that are used only for the harness.
See Simulation Harnesses.
Examples
The following commands create a JEDEC class 1 resistor termination harness
and apply it to the PAD pin of a cell. The harness consists of a voltage divider
tied between the PAD pin and supply VTT. Node node1 is created between the
resistors and used as the measurement point. The resistance of resistor RT is
rt_resistance, meaning that the parameter rt_resistance must be set
in the parameter block default or in the operating conditions. In this case, the
parameter has been made operating condition-specific, and is 35 ohms in the
worst-case condition and 20 ohms in the best case.

SiliconSmart ACE User Guide 569

L-2016.03
Chapter 14: Command Reference
Setup Commands

The value of this parameter is used as the value of the resistor.

Example 341
set_opc_parameter worst_pvt rt_resistance 35
set_opc_parameter best_pvt rt_resistance 20
…
create_harness jedec_class1
add_harness_elements jedec_class1 {
R RS PAD node1 25
R RT node1 VTT rt_resistance
C PAD VSS load_PAD
}
set_sweep_parameter jedec_class1 -load PAD load_PAD
set_measurement_node jedec_class1 node1
…
set_config_opt tempCut –type delay –to PAD harness jedec_class1

See Also
create_harness
set_measurement_node
set_opc_parameter_distribution
set_stimulus_node
set_sweep_parameter

add_latch
This command adds a level-sensitive sequential element to the behavioral
description.
Syntax
add_latch [-clear expression] [-preset expression]
[-preset_clear values {register inv_register enable_expr
data_expr}]
Arguments
-clear expression
A Boolean expression describing the asynchronous clear state.
-preset expression
A Boolean expression describing the asynchronous preset state.

570 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

-preset_clear values
Specifies the value of the register and inverted register if both the –preset
and –clear expressions are true. values is a Tcl list of two Boolean
values (0, 1) specifying the value of register and inv_register,
respectively.
register
The name of the non-inverted register.
inv_register
The name of the inverted register.
enable_expr
A Boolean expression for the latch enable function.
data_expr
A Boolean expression for the data input function.
Description
The add_latch command adds a level-sensitive sequential element to the
description of the cell. The latch expressions can be a combination of input
(and bi-directional) pins, internal pins, and registers from other sequential
elements.
If the latch supports it, asynchronous preset and/or clear expressions can be
defined as well. If both are specified, then the switch –preset_clear can be
used to specify the value of the two registers when both expressions are true.
This switch is optional when both –preset and –clear are specified and
illegal otherwise. The value is a Tcl list of two Boolean values (0, 1).
Examples
The following describes a simple D-latch:
Example 342
add_latch IQ IQN G D

The register IQ simply gets the value D when G is true and IQN gets the
inverted value of D. For a more complex example, consider this command:
Example 343
add_latch IQ IQN G&EN D –clear !RB –preset S –preset_clear { 1 0 }

This command does several things. First, the data expression is a simple
function of D, but the enable function is a function of both G and EN. Both must

SiliconSmart ACE User Guide 571

L-2016.03
Chapter 14: Command Reference
Setup Commands

be true to enable the latch. An active low clear pin (RB) and active high preset
pin (S) are both present. If both are asserted at the same time, the
–preset_clear switch specifies that the preset dominates and thus register gets
the value 1’and the inverting register gets a 0.
See Also
add_flop
add_function
add_table

add_liberty_group
This command can be used to add any group to Liberty file. Use this command
before modeling to add a group at library-level, cell-level, or at pin-level.
Syntax
add_liberty_group [-library] [-cell cell_name] [-pin
pin_name] group_type group_name
tcl_key_value_pairs_of_attributes [-explicit]
Arguments
-library
Specifies the group to be added at library-level.
-cell
Specifies the cell to apply the command to.
-pin
Specifies the pin name to apply the command to.
group type
Group type.
group name
Group name.
tcl_key_value_pairs_of_attributes
List of attribute name value pairs in the group.
-explicit
Add any type of complex group. Can also can be used to generate a
test_cell (see the Generating a test_cell section for more information).

572 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

For example, to add the wire_load group shown below:

set wl " \
resistance : 8.5e-8; \
capacitance : 1.5e-4;
area : 0.7; \
slope : 266.668; \
fanout_length (1,266.668); \
fanout_length (2,366.668); \
fanout_length (3,466.668); \ "

add_liberty_group -explicit -library wire_load ABCD "\"$wl\""

add_one_hot
The add_one_hot command is a convenience function for defining the
behavior of one-hot multiplexers. One-hot multiplexers are cells in which one
and only one select line is active (hot) at any time.
Defining the behavior requires a function definition that defines the output in
terms of the select and data lines, and also specifies as illegal any state in
which zero or two or more select lines are active at once. All illegal states are
tagged as forbidden states. This command internally calls the add_function,
add_switch_tuple and add_forbidden_state commands to describe
this behavior.
In the simplest form, this command takes the name of an output pin and two
lists, one of select expressions and one of data expressions. These lists are
paired one-to-one where each select expression enables the corresponding
data expression.
Syntax
add_one_hot [-hi_z expression] [-tuple_addition_type type]
output_pin select_exprs data_exprs
Arguments
-hi_z expression
A boolean expression that specifies when the output pin is in a high-
impedence (undriven) state.
-tuple_addition_type
A string to indicate how many pairs of selects will be added. Choices are:
all_pairs, minimal_pairs, or no_pairs.

SiliconSmart ACE User Guide 573

L-2016.03
Chapter 14: Command Reference
Setup Commands

output_pin
The name of the output pin.
select_exprs
A Tcl list of input or bi-directional pins, each of which enables a data
expression in the corresponding position in the data_exprs list.
data_exprs
A Tcl list of boolean expressions, each of which is enabled by a select pin in
the corresponding position in the select_exprs list.
Description
The format of each select pin is of the {Si 0/1}. Here Si indicates the port
name while 0/1 indicates the polarity. A polarity value of 0 (1) identifies the
select as active low (high).
If the polarity is left unspecified, it is assumed to be 1. As a result, a shorthand
way to specify {Si 1} is by simply writing Si.
The select port can also be specified as a complementary input pin pair of the
form {Si Sibar}. Such a setting indicates the select enabled case as
Si&!Sibar. In this case the polarity is required to be specified as a 1.
Adding the -hi_z switch specifies a Boolean function that controls when the
output pin is in high-impedance mode.
The -tuple_addition_type switch indicates how many pairs of selects will
be identified as switch tuple.
■
Among n selects, a switch value of all_pairs indicates that all (n choose
2)=n*(n-1)/2 pairs will be considered as switch tuples.
■
A value of minimial_pairs will generate a total of n switch tuples by
considering only the adjacent pairs of selects as switch tuples. Additionally,
the last select will be paired up with the first select value for the sake of
symmetry.
■
A value of no_pairs will add no tuples. Instead the user is expected to
identify switch tuples separately.
This command internally calls set_config_opt to exclude arcs from select
pin from containing all other select pins in their state coverage.
This command also calls set_config_opt to set the preference order for the
secondary switching inputs. The priority order is identical to the list of select
pins.

574 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Examples
The following command creates a simple, three-input, one-hot multiplexer with
select lines S0, S1, and S2 and data lines D0, D1, and D2 and output pin Y:
Example 344
add_one_hot Y { {S0 1} {S1 1} {S2 1} } { D0 D1 D2 }

is equivalent to:
Example 345
add_one_hot { S0 S1 S2 } { D0 D1 D2 }

This command is analogous to calling the following commands separately:

Example 346
set illegal { !S0&!S1&!S2 | S1&S2 | S0&S2 | S0&S1 }
add_function Y {D0&S0 | D1&S1 | D2&S2} -illegal illegal
add_forbidden_state illegal
add_switch_tuple {S0 S1}
add_switch_tuple {S0 S2}
add_switch_tuple {S1 S2}

add_one_hot Y { S0 S1 } { D0 1 }

can be used when one of the data ports is tied to a fixed value.

Example 347
add_one_hot Y { {{S0 S0N} 1} {{S1 S1N} 1} {S3 0} } {D0 D1 D3}

indicates a one_hot mux with two pairs of complementary select pins and one
active low select.
See Also
add_function
add_forbidden_state
add_switch_tuple

add_opc_grounds
You can use the add_opc_grounds command to specify the list of ground
supplies and its voltage values for an operating condition.

SiliconSmart ACE User Guide 575

L-2016.03
Chapter 14: Command Reference
Setup Commands

Syntax
add_opc_grounds operating_condition
{list_of_ground_supply_names_with_their_voltage_values}
Description
The usage of this command is similar to add_opc_supplies command. You
should specify all the power supplies and their voltage values through the
add_opc_supplies command. Similarly, all the ground supplies should be
specified using the add_opc_grounds command.
Examples

Example 348
add_opc_grounds NCCOM VSS 0 VPW 0

SiliconSmart FR will use the list of power supplies and ground supplies as
mentioned through the add_opc_supplies and add_opc_grounds
commands for an operating condition. SiliconSmart functional recognition
process is okay with cells that do not actually use all the specified power and
ground pins.

Note: Supplies can explicitly be specified on the import command via

the -powers and -grounds options on the import command
which override the list of supplies specified by the
add_opc_supplies and add_opc_grounds commands.
For backward compatibility, both powers and grounds can be
specified by add_opc_supplies command when the
add_opc_grounds command is not provided.

add_opc_statistical_parameter
This command adds a statistical process parameter to an operating condition.
Syntax
add_opc_statistical_parameter opc_name (-intercell|
-intracell) \
param1 [param2] (-model) transistor ...

576 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Arguments
opc_name
Name of the operating condition as created with the
set_operating_condition command.
-model
Specifies the transistor name that the specified parameter applies to for
intra-cell parameters.
-intercell | -intracell
Flag to indicate type of variation.
param1, param2, …
Names of one or more process parameters to add.
Description
Statistical characterization attempts to capture the effect of process variations
on the behavior of a cell. The process variations are described by specific
parameters in the SPICE process model. SiliconSmart varies each of the
parameters independently and captures the effect they have on the delay
through a cell.
The add_opc_statistical_parameter command is used to specify the
name of the parameters to be varied per operating condition. Each parameter
name must match the name of a statistical parameter in the SPICE process
model.
The switches –intercell and –intracell indicate whether the parameter
is varied consistently across each device in the cell or whether each device
varies independently, respectively.

SiliconSmart ACE User Guide 577

L-2016.03
Chapter 14: Command Reference
Setup Commands

Examples
The following command creates an operating condition and adds two
parameters, PARAM1 and PARAM2 to the operating condition:
Example 349
create_operating_condition nom_pvt
…
add_opc_statistical_parameter nom_pvt –intercell PARAM1 PARAM2
set_opc_parameter_distribution nom_pvt –points {-1.0 -0.33 0.33
1.0 }\
-nominal_value 0.0 –variation_range { -1.0 1.0 } –
distribution_type \
gaussian –sigma 0.33 PARAM1
set_opc_parameter_distribution nom_pvt –points { 0.25 0.27 } \
-nominal_value 0.26 –variation_range { 0.23 0.30 } \
–distribution_type linear –sigma 0.01 PARAM2
…
add_opc_statistical_parameter pvt_fast -intracell VTH_NMOS -model
N_HVT

The analyze_netlists command automatically parameterizes

the matching transistors with this specified parameter.
See Also
configure
create_operating_condition
model
set_opc_parameter_distribution

add_opc_supplies
This command adds one or more power supply rail definitions to the specified
operating condition.
Syntax
add_opc_supplies opc_cond supply voltage [supply voltage]
Arguments
op_cond
The name of an existing operating condition created with the command
create_operating_condition.
supply
The name of a supply rail used by SPICE netlists of the cell.

578 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

voltage
The voltage of the above supply.
Description
This command is used to specify the power supply rails required by the SPICE
netlists of the cells to be characterized. At least one supply and one ground
need to be defined for each operating condition; additional supplies can be
defined as needed.
Examples
The following example creates the operating condition worst and creates a
ground rail, and two supply rails, VDD and VDD3:
Example 350
create_operating_condition worst
add_opc_supplies worst VSS 0.0 VDD 1.08 VDD3 3.1

See Also
create_operating_condition
set_opc_parameter_distribution
set_opc_temperature

add_pin
This command adds a pin to the structural description of the cell.
Syntax
add_pin pin_name pin_type (-async | -input | -inputZ |
-output | -inout | -clock | -internal | -retention |
-supply) [-spice_node node] [-no_model]
Arguments
-alias
Provides a short-hand way of specifying the pin_name_alias parameter.
-async
Specifies asynchronous pins in a cell. For example:
add_pin P default -async

is equivalent to:
add_pin P default -input set_config_opt -pin P pin_category
async_control

SiliconSmart ACE User Guide 579

L-2016.03
Chapter 14: Command Reference
Setup Commands

-clock
Specifies that the pin is an input pin that is used as a clocking signal.
-inout
Specifies that the pin is a bi-directional pin.
-input
Specifies that the pin is an input pin.
-inputZ
Specifies to leave an input pin floating during all acquisitions.
-internal
Specifies that the pin is an internal node in the circuit.
-no_model
Specified only for internal nodes and indicates that the internal node should
not be added to the resulting model.
-output
Specifies that the pin is an output pin.
-retention
Specifies that the pin is an input pin and is used as a retaining signal. See
Defining a Retention Cell for more information.
-spice_node
For internal nodes only, this specifies the simulator-specific name of the
node.
-supply
Specifies that the pin is a supply pin to the cell.
pin_name
Name of the pin.
pin_type
Name of the pin type of the pin. The name must be one of the pin types
defined by the pintype command.
Description
This command defines a pin, its direction, and electrical attributes and adds it
to the structural description of the cell. The pin’s direction is specified through

580 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

one of the required switches –input, -output, -inout, -clock,

-internal, and –supply. The first three specify a standard input, output, or
bi-directional pin. The –clock switch specifies an input pin that is also
identified as a clocking signal. As such, it will be modeled as a clock pin as
appropriate in the generated models.
Internal pins, as specified with –internal, are nodes that are internal to the
circuit and generally not accessible. Internal nodes can be used in the behavior
description of the cell and allow the cell to be defined structurally. See I/O Cells
and Other Complex Cells on page 46. By default, internal nodes are used only
to simplify the logical description of the cell and no measurements are made to
or from these nodes. However, the –spice_node switch can be used to
specify the simulator-specific name of a node in the circuit that is logically
equivalent to the internal node. When this is specified, SiliconSmart will make
use of the internal node when making constraint measurements if appropriate.
See the Constraint Measurements to Internal Nodes section for more
information.
Supply pins are used for some advanced measurements, such as the
decoupling capacitance measurement. Supply pins only need to be defined in
these cases, otherwise they can be omitted. The pin_type field specifies the
name of a pin type that describes the electrical attributes of the cell. See the
pintype command for more details.
Examples
The following commands define a simple level-shifting buffer. Notice that the Z
pin has a different pin type reflecting the different electrical characteristics.
Example 351
add_pin –input A pin_10V
add_pin –output Z pin_12V

The below option provides a short-hand way of specifying the

pin_name_alias parameter.
Example 352 -alias Usage
add_pin A_0 default -input -alias A<0>

is equivalent to:
Example 353
add_pin A_0 default -input
set_config_opt -pin A_0 pin_name_alias A<0>

SiliconSmart ACE User Guide 581

L-2016.03
Chapter 14: Command Reference
Setup Commands

SiliconSmart does not support the use of [] or <> in pin names such as A[0]
A[1]. In order to characterize cells with those types of names, the pin names
must be changed in the netlist and the instance file and aliased in the add_pin
section of the instance file. The alias will cause the Liberty model to be written
with the correct pin names.
See Also
pintype
set_subckt_ports

add_process_parameter_variation
This command is used to specify parameters to be varied for a transistor for an
operating condition.
Syntax
add_process_parameter_variation opc_name transistor_name
parameter_name
Arguments
opc_name
The name of the operating condition as created with the
set_operating_condition command.
transistor_name
The name of the transistor for which the process parameter must be varied.
parameter_name
The name of the process parameter that is varied.
Examples

Example 354
add_process_parameter_variation slow_pvt XM1 NVTH0
add_process_parameter_variation slow_pvt XM2 PVTH0

The previous commands specify that NVTH0 is varied for the transistor XM1 and
PVTH0 is varied for XM2. This is used in intra-cell characterization where you
must vary process parameters on a per-transistor basis.
See Also
add_channel_width_variation

582 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

add_opc_statistical_parameter
add_process_parameter_variation
add_transistor
set_length_unit
set_opc_parameter_distribution
set_points_boundary_distance

add_switch_tuple
This command specifies a set of pins that can all switch simultaneously.
Syntax
add_switch_tuple list_of_pins
Arguments
list_of_pins
A list of two or more pin names
Description
The add_switch_tuple command is used to define a set of pins in which
can all switch simultaneously. This differs from the add_switching_set
command, which defines a set in which any two pins can switch together.
add_switch_tuple is a low-level command in which each set of switch
combinations must be specified.
For example, consider a one-hot mux with complementary select lines
consisting of S0 and S0B, S1 and S1B, and S2 and S2B. Because each pair will
switch together and at the same time as a second pair is switching, there are
three possible groups:
Example 355
add_switch_tuple { S0 S0B S1 S1B }
add_switch_tuple { S0 S0B S2 S2B }
add_switch_tuple { S1 S1B S2 S2B }

In this case, three different groups of four pins will be considered. When using
this command it is important to define the function of the cell such that the
illegal conditions are explicit made illegal. For example, in this case the
add_function or add_table commands would need to make the case of
!(S0^S0B) (^ is the exclusive-OR operator) illegal and repeat that for each
complementary pair.

SiliconSmart ACE User Guide 583

L-2016.03
Chapter 14: Command Reference
Setup Commands

See Also
add_forbidden_state
add_one_hot
add_switching_set

add_switching_set
This command specifies a set of input pins that can transition in pairs.
Syntax
add_switching_set list_of_pins
Arguments
list_of_pins
A list of input (or bi-directional) pin names
Description
The add_switching_set command is used to create a set of pins that can
transition individually or in pairs. This case can occur in cells with differential
pins, complementary clocks, or in one-hot multiplexers. The single argument to
this command is a Tcl list of input (or bi-directional) pin names.
This command differs from the define_differential_receiver
command in that the pins are allowed to switch individually or in pairs as
allowed by the function of the cell and delays are measured as for standard
delay measurements. (define_differential_receiver causes
measurements to be made from the crossover point.)
Examples
The following commands create a definition for a flop with complementary
inputs:
Example 356
add_table {
CK CKN D : IQ IQN : IQ IQN
R F 0/1 : - - : 0/1 1/0
~R ~F - : - - : N N
}
add_switching_set { CK CKN }

See Also
add_one_hot
add_table

584 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

define_differential_receiver
set_output_differential

add_table
This commands adds a truth-table or state-table description to the cell.
Syntax
A truth table is defined with the following syntax:
add_table {
input_pins : output_pins
input_pin_settings : output_pin_results ...
}
A state table is defined with the following syntax:
add_table {
input_pins : current_state_regs : next_state_regs
input_pin_settings : current_state_settings :
next_state_settings ...}
Arguments
input_pins
A sequence of independent input (or bi-directional or internal) pin names.
output_pins
A sequence of dependent output (or bi-directional) pin names.
input_pin_settings
A sequence of input pin values; one for each pin in input_pins.
output_pin_results
A sequence of output pin values; one for each pin in output_pins.
current_state_regs
A sequence of register names used to define the current state.
next_state_regs
A sequence of register names used to defined the next state. This argument
should be the same as current_state_regs.

SiliconSmart ACE User Guide 585

L-2016.03
Chapter 14: Command Reference
Setup Commands

current_state_settings
A sequence of values for each current-state register.
next_state_settings
A sequence of values for each next-state register.
Description
SiliconSmart supports truth table and state table descriptions of cell behavior.
The tabular form can be convenient for describing complex behavior,
particularly state behavior. The inputs to a table are a combination of standard
input and bi-directional pins, internal nodes, or registers. Truth tables map
combinations of the inputs to output pin values. State tables also combine the
current state of any registers and map new values to the register set. The
registers can then be used to drive output pins.
Each table definition is a multi-line description. Each line specifies the values of
each of the inputs and the resulting output values. Blank lines are ignored and
comment lines are illegal.
Table 33 add_table Input/Output Pin Value Descriptors

Descriptor(s) Description Applies To

0, l, L logic zero input, output, register

1, h, H logic one input, output, register

z, Z high-impedance or input, output, register

disconnected

r, R rising input

~r, ~R not rising input

f, F falling input

~f, ~F not falling input

- (hyphen) don't care input, output, register

x, X illegal or undefined input, output, register

n, N no change output, register

t, T toggle output, register

586 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Each column must contain a value in the form of one of the defined tokens. The
legal tokens are show in Table 33. Multiple values for a pin can be listed in a
single column, separated by slashes. If more than one column in a row has
multiple values then each must have the same number of values. This is
equivalent to a separate row for each value with single value columns repeated.
For example, the following two specifications for Y are equivalent:
Example 357
A B : Y
0 1 : 1
1 0 : 0

A B : Y
0/1 1/0 : 1/0

Examples
A flip-flop table could be defined as follows, using the add_table command:
Example 358
add_table {
C D : IQ IQN : IQ IQN
R 0/1 : - - : 0/1 1/0
~R - : - - : N N
}
add_table {
IQ IQN : Q QB
0/1 1/0 : 0/1 1/0
}

The first add_table command defines the sequential behavior where the
state changes on a rising edge on pin C. The second table defines the value of
the output pins Q and QB in terms of the state registers defined in the first table.
These definitions are equivalent to the following commands:
Example 359
add_flop IQ IQN C D
add_function Q IQ
add_function QB IQN

See Also
add_flop
add_function
add_latch

SiliconSmart ACE User Guide 587

L-2016.03
Chapter 14: Command Reference
Setup Commands

add_transistor
This command is used to specify a transistor’s nominal channel length and
nominal channel width.
Syntax
add_transistor transistor_name channel_length channel_width
Arguments
transistor name
The name of the transistor as in the netlist.
channel length
The nominal channel length of the transistor.
channel widh
The nominal channel width of the transistor.
Examples

Example 360
add_transistor M5 59.44 200

In this example, 59.44 is the nominal channel length and 200 is the nominal
channel width. Units of channel length/width can be specified using the
set_length_unit command. This is used in the context of si-shapes
characterization.
See Also
add_channel_length_variation
add_channel_width_variation
set_length_unit

add_user_stimulus
This command is used to add a user-defined input stimulus and measurements
for cases which are not handled by the automated methods. See the Adding a
User-Defined Stimulus section for more details and examples of this command.

588 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Syntax
add_user_stimulus [-cell] [-substitute]
[-explicit_permutation|
-all_permutations] [-rise_fall] sequence
sequence ::= { row * }
row ::= { (in pin_values|out pin_values|not pin_values|meas
meas_spec)* }
pin_values ::= { (pin 0|1|Z|X)* }
meas_spec ::= { (type meas_type|from pin|ref pin|to
pin|states logic)* }
meas_type ::= delay|energy|constraint|mpw|leakage
Arguments
cell
List of cell names.
substitute
A key-value pair list of pin pattern followed by corresponding pin names,
which can be used to alias actual pin names with appropriate identifiers.
explicit_permutation
List of pin names followed by a list of pin settings.
all_permutations
Requires only a list of pin names, and is equivalent to specifying -
explicit_permutations for N pins in combination with pow(2,N) pin
settings.
rise_fall
List of transitioning pins for which both polarities will be considered while the
arcs are generated from the stimulus.
Description
Each row specifies the driven inputs (in), the observed outputs (out) or the
outputs not expected (not), and measurements which can be taken at that
point in the stimulus (meas).
The measurement specification is similar to that for set_config_opt. The
type is a subset of the -type from set_config_opt. The states field is a
logic expression describing all states to which the measurement applies (as
well as the one actually measured).
If the -cell option is specified as a list, and the cell instance is not part of this
list, then all measurements specified by this stimulus are skipped.

SiliconSmart ACE User Guide 589

L-2016.03
Chapter 14: Command Reference
Setup Commands

The -substitute option can be used to alias actual pin names with
appropriate identifiers. This option is specified as a key-value pair list of pin
pattern followed by corresponding pin names. If multiple substitutions are
specified, then the cross-product across all substitutions is considered.
The -explicit_permutation option can be used to specify fixed settings
for a certain collection of pins. This option accepts a list of pin names followed
by a list of pin settings. The -all_permutations option only requires a list of
pin names. This option is equivalent to specifying
-explicit_permutations for N pins in combination with pow(2,N) pin
settings. Both permutation options cannot be specified at the same time.
The -rise_fall option accepts a list of pins for which both polarities will be
considered while the arcs are generated from the stimulus. Each pin in this list
must be a transitioning pin.
Examples

Example 361
add_user_stimulus {
{ in { A 1 CLK 1} out { Q 1} }
{ in { A 0 } out { Q 0 }
meas { type delay from A to Q}
meas { type energy to Q} }
{ in { CLK 0 }
meas { type energy from CLK states CLK }
meas { type constraint from A ref CLK } }
{ in { A 1 } not { Q 1 }
meas { type delay from A to Q}
meas { type energy to Q}
meas { type constraint from A ref CLK } }
}

add_user_stimulus {
{ in { A 1 CLK 1} out { Q 1} }
{ in { CLK 0} }
meas { type energy from CLK states !CLK }
{ in { A 0 } }
{ in { CLK 1} out { Q 0} }
{ in { CLK 0 }
meas { type mpw from CLK } }
}

See Also
set_config_opt

590 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

analyze_netlists
This command analyzes the transistor netlists of a set of cells and prepares
them for path-based constraint analysis and statistical characterization.
Syntax
analyze_netlists [-constraint_nodes] [-statistical]
[-litho_table file] [cells]
Arguments
-constraint_nodes
Recognizes the nodes in the feedback loop of the latch or flop structures for
use with path-based constraints.
-litho_table
Specifies an input file of change length variations from the lithographic
simulator.
-statistical
Prepares netlists and cell instance files for statistical characterization.
Description
The analyze_netlists command reads the netlist for each cell to
determine the structure of the circuit. This information is used both to setup the
cell for path-based constraint analysis and statistical characterization.
Path-based constraint analysis requires the identification of the feedback nodes
in the latch structure(s) of the cell and the ends of the enable/clock signals. The
result is a set of Tcl commands written to the file
charpt/control/path/cell.path. This command can recognize common latch and
flop topologies. More complex cells may need to be set up manually. See
Analyzing the Netlist (Optional).
The -statistical switch is part of the SiliconSmart DFM product and is
required for intra-cell (random variation) or SI-shapes characterization. This
switch causes every cell netlist to be parameterized and written to the directory
charpt/netlists/op_cond. SPICE simulators do not support adding arbitrary
parameters as instance parameters for MOS models, so SiliconSmart requires
the models to be in subcircuit form in the model file. For example, if a netlist has
an instance of xnch in the netlist similar to the following:
Example 362
XM1 A B C D E xnch L=0.06u W=0.39u

SiliconSmart ACE User Guide 591

L-2016.03
Chapter 14: Command Reference
Setup Commands

analyze_netlist -statistical will replace this line with:

Example 363
XM1 A B C D E xnch L=0.06u W=0.39u param1=XM1_param1

See Also
configure
characterize

cell_families_by_name
This command accepts a list of cell names and categorizes them according to
the pattern specified by the -pattern option.
Syntax
cell_families_by_name -pattern cells
Arguments
cells
List of cell names to be categorized.
-pattern
The pattern by which cell family names are identified
Description
If -pattern is left unspecified, then it is taken as xX\[0-9\]\$ which
identifies all cells with the pattern xX<num> at the end of the cell name. The
categorized cells are returned as a list of list of (dictionary) sorted cell names.
Examples

Example 364
cell_families_by_name {ANDX1 INVX3 ANDX2 ORX4 ORX1}

returns:
{ {ANDX1 ANDX2} INVX3 {ORX1 ORX4} }

Example 365
cell_families_by_name -pattern _D\[0-9\]\*_ { AND2_D10_TR
AND2_D2_TR AND2_D1_TR AND3_D1_TR }

592 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

returns:
{ {AND2_D1_TR AND2_D2_TR AND2_D10_TR} AND3_D1_TR }

change_parameter
This command changes the value of other parameters. Currently it can change
only the run_list_maxsize parameter.
change_parameter [parameter_block] <parameter_name>
<desired_value>
See Also
run_list_maxsize

clear_config_opts
This command clears all of the configuration options set at the global level
(outside of a cell’s instance file).
Syntax
clear_config_opts
Description
The clear_config_opts command flushes any configuration options set by
calling set_config_opt outside of a cell’s instance file. This command does
not affect any settings made from within an instance file.
See Also
set_config_opt
set_parameter
set_pintype_parameter
write_config_opts

clear_liberty_attribute
This command clears specified attributes being written to the Liberty file.
Syntax
clear_liberty_attribute [-library] [-cell cell] [-pin pin]
{attribute1 attribute2 ...}

SiliconSmart ACE User Guide 593

L-2016.03
Chapter 14: Command Reference
Setup Commands

Arguments
library
Specifies to clear the specified library level attributes.
cell
Specifies the name of the cell clear the attributes from.
pin
Specifies the name of the pin to clear the attributes from.
Description
This command can be used to clear specified attributes being written to the
Liberty file. The attributes are classified as library, cell, and pin-level attributes.
If you do not want an attribute to be written to the Liberty file, use this command
before the model command. If no argument is specified, all attributes are
cleared. If the command is used only with the -library option, only the
library-level attributes are cleared. If only the -cell cell argument is
provided, all the cell attributes are cleared. If the -pin pin attribute is
mentioned with the -cell attribute, all the pin attributes are cleared. You can
selectively clear attributes by mentioning specific attribute(s) as a list.
This command works only for a single specified cell. To clear attributes for a list
of cells, you must specify a foreach loop as shown in Example 367.
Examples

Example 366
clear_liberty_attribute -cell LAGCEP is_level_shifter
level_shifter_type

Clears the cell attributes is_level_shifter and level_shifter_type

for cell LAGCEP.

Example 367
foreach cell_item $cells_list {
clear_liberty_attribute -cell $cell_item user_function_class
clear_liberty_attribute -cell $cell_item cell_footprint
}

Clears the attributes of a list of cells.

Example 368
clear_liberty_attribute -cell LAGCEP -pin A

594 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Clears all the attributes of pin A belong to cell LAGCEP that are set by the user.

Example 369
clear_liberty_attribute -cell LAGCEP -pin VDD retention_pin

Clears the retention_pin attribute of pin VDD of cell LAGCEP.

Example 370
clear_liberty_attribute -library

Clears all the library-level attributes that are set by the user.

Example 371
clear_liberty_attribute

Clears all the attributes that are set by user.

See Also
set_liberty_attribute
clear_liberty_group

clear_liberty_group
Deletes library, cell, or pin group information from Liberty.
Syntax
clear_liberty_group [-cell cell_name] [-pin pin_name]
group_object_type group_object_key
group_object_type (group_object_key) {
contents_of_block
}
Description
Writing group_object_type and group_object_key are mandatory. You
can use the glob-type wild card for cell, pin and group_object_key
values. If you have no values for group_object_key, you can specify a null
string as "".
If you do not specify -cell cell | -cell cell -pin pin, by default
SiliconSmart operates at the library level group. Also, you cannot specify -pin
pin without -cell cell.

SiliconSmart ACE User Guide 595

L-2016.03
Chapter 14: Command Reference
Setup Commands

Examples
SiliconSmart deletes all those groups in which it matches. Otherwise, the
command is ignored.
Example 372
clear_liberty_group operating_conditions fast

The above removes operating_conditions groups that have the key fast
at the library level.

Example 373
clear_liberty_group -cell A2DFFQNX0P5MA10TR leakage_power ""

The above command removes all leakage_power() from the cell.

Example 374
clear_liberty_group -cell A2DFFQNX0P5MA10TR pin B

This command removes pin(B) group from the cell.

configure
This command generates a characterization plan for each cell and prepares it
for characterization.
Syntax
configure [-timing] [-ecsm] [-em] [-emx] [-ccs] [-ccs_noise]
[-power] [-ccs_power] [-fast] [-si] [-lvf] [-aocv]
[-pocv][-ibis] [cells]
Arguments
aocv
Enables AOCV characterization.
ccs
Enables CCS current waveform capture and CCS capacitance
measurements during delay measurements. This switch implies -timing
is set as well.

596 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

ccs_noise
Enables CCS-noise measurements. This option causes the cell netlists to
be partitioned into sub-cells representing the channel-connected block(s)
for the cell, which are characterized as needed.
ccs_power
Enables CCS power characterization.
ccs_va
Enables CCS-VA characterization.
ecsm
Enables ECSM waveform capture and ECSM capacitance measurements
during delay measurements. This switch implies -timing is set as well.
em
Enables measurement for electromigration (EM) characterization.
emx
Enables current threshold measurement for electromigration (EM) analysis.
This will generate EMX files under the [get_location]/control/emx directory
only without performing circuit simulations that measure the actual currents
through resistive wires.
fast
Configures in parallel, via LSF, NC, or SunGrid job schedulers. This option
is enabled by default and does not need to be specified. The SiliconSmart
tool will start non-fast configuration only when the following settings are
matched:
• job_scheduler=standalone
• run_list_maxsize=1
• no -fast specified for configure
ibis
Enables measurements for the IBIS format, including VT curves, IV curves,
and differential launch delays as appropriate.
lvf
Enables LVF characterization.

SiliconSmart ACE User Guide 597

L-2016.03
Chapter 14: Command Reference
Setup Commands

pocv
Enables POCV characterization.
power
Enables power measurements, including switching energy, hidden energy,
and leakage power.
si
Enables Liberty noise measurements, including steady-state IV curves,
noise immunity, and noise propagation.
timing
Enables timing measurements, including delays, Z-enable, Z-disable, and
constraint measurements.
Description
This command configures a set of cells for characterization and generates the
characterization plan. The default action generates tests for standard timing
and power models. If any of the switches are specified, then none are on by
default. This means that the command:
Example 375
configure –si

will generate a characterization plan containing only signal integrity

measurements. This can be useful if you are planning to add the SI constructs
to an existing library.
However, if timing, power, and signal integrity are all to be characterized the
following command must be used:
Example 376
configure –timing –power –si

The resulting characterization plans are written to the file

char_dir/etc/templates/cell.t where cell is the name of the given cell.
The set_location command must be called prior to calling configure.
You can use the -fast option to enable cell configuration in parallel using your
job distribution engine. For CCS-noise configuration, this feature is
recommended as CCS-noise configuration may take a while for each cell.

598 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

See Also
characterize
model

create
This command creates a characterization directory structure for the current
cell.
Syntax
create char_dir [-clean]
Arguments
char_dir
Root directory for the characterization directory structure. This can be
specified as an absolute or relative path.
clean
Clears the characterization directory location before creating it (if it already
exists).
Description
This command creates the characterization directory structure with the
specified root. This directory is created if nonexistent. It contains all of the data
used for characterization and specification compliance testing. The command
set_location must be used to establish this characterization directory as
the current working directory.
Errors
An error message is displayed if the directory is invalid or already populated.
See Also
set_location

create_harness
This command creates an electrical harness to be applied during
characterization.
Syntax
create_harness name

SiliconSmart ACE User Guide 599

L-2016.03
Chapter 14: Command Reference
Setup Commands

Arguments
name
Name of the harness.
Description
This command creates a new harness with the given name. Electrical elements
can be added to build a circuit to be applied to a cell during characterization.
The harness can be used to apply additional circuit elements to one or more of
the pins on the cell. For example, some cells require resistor termination on
one or more output pins. A harness allows the termination network to be added
to the characterization simulations. Circuit elements are added using the
command add_harness_elements. Once the harness is created, it can be
applied to a measurements using the harness option to the
set_config_opt command.
Examples
The following commands create a JEDEC class 1 resistor termination harness
and apply it to the PAD pin of a cell. The harness is applied to all delay
measurements and the node used for measurements is moved to a node in
voltage divider.
Example 377
create_harness jedec_class1
add_harness_elements jedec_class1 {
R RS PAD node1 25
R RT node1 VTT 25
}
set_measurement_node jedec_class1 node1
set_config_opt –type delay –to PAD harness jedec_class1

See Also
add_harness_elements
set_config_opt
set_measurement_node
set_stimulus_node
set_sweep_parameter

create_operating_condition
This command creates an operating condition that specifies the process,
voltage, and temperature settings for the simulation.

600 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Syntax
create_operating_condition op_cond_name
Arguments
op_cond_name
The name of the operating condition to be created.
Description
This command creates a new operating condition specification. Each operating
condition specifies the process, voltage, and temperature settings to be used
when characterizing the cells.
Examples
The following example creates an operating condition named worst and sets
the power and ground supply rails:
Example 378
create_operating_condition worst
add_opc_supplies worst VSS 0.0 VDD 1.08

See Also
add_latch
set_opc_parameter_distribution
set_opc_temperature

define_cell_ccb
Use this command in the instance file of a cell to define the CCBs manually for
CCS-noise analysis. Refer to User-Defined CCBs for more information on using
this command.
Syntax
define_cell_ccb –relevant_pin cell_pin
[-inputs ccb_input_pin_names] -output ccb_output_pin
[-transistors list_of_transistor_names_in_the_ccb]
[-switching_set list_of_net_names]
[-input_vectors list_of_input_vectors]
Arguments
-relevant_pin
This option is required. It defines the cell input or output pin for which the
CCB has to be manually generated for CCS-noise measurements.

SiliconSmart ACE User Guide 601

L-2016.03
Chapter 14: Command Reference
Setup Commands

-inputs
This optional argument defines the inputs for the CCB. If this option is not
specified, then all the primary input pins of the cell are considered as inputs
to the CCB.
-output
This option is required. It specifies the output of the CCB. The output of the
CCB can be a primary output or an internal pin.
-transistors
This optional argument can be used to specify the list of transistors in CCB.
If this argument is not specified, SiliconSmart will probe the output of the
CCB using the whole netlist to make CCS-noise measurements.
-switching_set
This optional argument specifies the pin/net names that must switch
together for the noise propagation to switch from input to output of the CCB.
This option must be used along with the -inputs option.
-input_vectors
This optional argument can be used to specify list of user-defined vectors
for the CCB to find out the function of the CCB. If this option is specified, only
these vectors will be used in the instance file to get the functionality of the
CCB. Each vector length should be the same as the number of inputs
specified in the -inputs switch. This option cannot be specified if -inputs
switch has not been specified.
Examples

Example 379
define_cell_ccb –relevant_pin { B} –inputs {A B CI} –output {net72}
–input_vectors { {0 0 0 } {0 1 0} }

This example indicates that the CCB from B to net72 will use only these user-
defined vectors for creating CCS-noise tests. The other possible 6 vectors will
not be considered.
See Also
User-Defined CCBs

602 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

define_differential_receiver
This command specifies that a pair of inputs behave differentially with respect
to a given output pin.
Syntax
define_differential_receiver output_pin pos_input neg_input
Arguments
output_pin
Name of the output pin
pos_input
Name of the positive input pin
neg_input
Name of the negative input pin
Description
The define_differential_receiver command specifies that a pair of
input pins behave differentially when controlling the named output pin. This has
two implications. First, delay measurements are made relative to the crossover
point of the two inputs as opposed to from the standard delay threshold.
Second, it means that only arcs in which both pins transition at the same time
are considered. This differs from the add_switching_set command, which
indicates that a set of input pins can transition in pairs, but can also switch
individually.
The output pin is specified to distinguish it from outputs that may be a function
of only one of the input pins. See the Complementary Inputs and Differential
Pins section for more details.
Examples
The following commands define the behavior of a cell with a differential input
pair and three outputs, one each reflecting the state of one of the inputs and
one that is a function of the differential comparator:
Example 380
add_function Z PADP&!PADN –illegal {PADP&PADN | !PADP&!PADN}
add_function ZP PADP
add_function ZN PADN
define_differential_receiver Z PADP PADN

SiliconSmart ACE User Guide 603

L-2016.03
Chapter 14: Command Reference
Setup Commands

In this example, ZP and ZN follow the individual inputs and switch in response
to only a single input. Pin Z however requires that both inputs switch
simultaneously.
See Also
add_function
add_switching_set
add_table
set_output_differential

define_parameters
This command defines a block of configuration parameters that control various
functions of SiliconSmart.
Syntax
define_parameters [-append] [name] [ -> parent ] settings
Arguments
-append
Appends the settings to an existing parameter block. By default, if the
parameter block already exists, the existing parameters are cleared.
name
Optional argument gives the name of the parameter block. The default name
is default, which is used for global parameters only.
-> parent
The name of an optional existing parameter block whose contents will be
automatically copied and then extended as the new parameter block.
settings
One or more set (parameter) commands.
Description
This command defines a block of configuration parameters. Each block controls
a specific aspect of the operation of SiliconSmart such as third-party tool
integration or modeling. The last argument to this command is a list of set
statements that define the parameters in the parameter block. The -> operator
allows an existing parameter block to be copied and extended under a new
name.

604 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Errors
Error messages are displayed if the parent parameter block is invalid or
undefined, or any of the Tcl set commands are invalid.
Examples

Example 381
# Create a default parameter block
# All parameters are the same as default, except for
trailing_delay,
# which is changed to 1e-6.
define_parameters {
set job_scheduler standalone
.
.
.
}
# Create a block for weak states that inherits from default
define_parameters weak -> default {
set trailing_delay 1e-6
}

# Create a block of Liberty model attributes

define_parameters liberty_model {
set time_unit "1ns"
}

See Also
get_parameter
list_parameter_blocks
list_parameters
set_parameter

enable_api
This command loads an optional package of commands and makes them
available in the io_shell Tcl interpreter.
Syntax
enable_api api_name
Arguments
api_name
The name of an optional API package.

SiliconSmart ACE User Guide 605

L-2016.03
Chapter 14: Command Reference
Setup Commands

Description
SiliconSmart includes a set of Application Programming Interface packages
that can be optionally enabled. These commands provide additional
functionality for added control or breadth of functionality. These packages are
described in the appendixes of this manual.
Examples
The following command enables the model publishing API (described in
Appendix C, Model Publishing API):
Example 382
enable_api pub

expand_side_inputs
This command provides an expansion of the provided side inputs according to
expansion_type using whens as the pivots.
Syntax
expand_side_inputs [-whens whens] [-side_inputs sinps]
[-expansion_type (ones_count|complete_binary|one_hot)]
Arguments
-whens
List of when conditions that will be used as pivots.
-side_inputs
List of side inputs across which the expansion is performed.
-expansion_type
Type of expansion to be performed:
• ones_count — default expansion type. When used, the maximum
number of when expressions returned is (num_whens*
(1+num_side_inputs)).
• complete_binary — when used, the maximum number of when
expressions returned is (num_whens*pow(2,num_side_inputs)).
• one_hot — when used, the maximum number of when expressions
returned is (num_whens*num_side_inputs).

606 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

find_internal_nodes_for_constraint
This push-button command first finds out potential candidates for the internal
nodes and then runs constraint tests on each of these nodes and outputs the
final actual internal node that can be used for the actual characterization for
measuring constraints
Syntax
find_internal_nodes_for_constraint -match expression
-mem_int_node dummy_node [-get_word_line_node]
Arguments
-match
Specifies a Tcl regular expression to run only those variant of constraint arcs
that match the regular expression. This can be used when you want to run
a small set of constraint arcs to find out the potential internal nodes.
-mem_int_node
Specifies the dummy node that is used in the instance file to assign the
actual SPICE node name to the internal node or register. The default value
of this argument is mem_int_node.
-get_word_line_node
Gets the word line used while generating the pruned netlist of the energy
arcs.
Examples
If the dummy node name in the instance file is specified as follows:
Example 383
add_pin mem_int default -internal -spice_node [get_config_opt
dummy_node]

If you want to run only setup arcs to find out the internal nodes, the command
can be used as follows:
Example 384
find_internal_nodes_for_constraint -match setup__* -mem_int_node
dummy_node

SiliconSmart ACE User Guide 607

L-2016.03
Chapter 14: Command Reference
Setup Commands

If the dummy node name in the instance file is specified as follows:

Example 385
add_pin mem_int default -internal -spice_node [get_config_opt
mem_int_node]

If you want to run only setup and hold arcs to find out the internal node
corresponding to 'mem_int', this command can be used as follows:
Example 386
find_internal_nodes_for_constraint -match (setup__*|hold__*)

See Also
find_potential_internal_nodes
get_word_line_node

find_potential_internal_nodes
This command runs very fast SPICE simulations on some variant of constraint
arcs that measure constraint at the internal node to find out the potential
candidates.
Syntax
find_potential_internal_nodes [-match expression]
[-mem_int_node dummy_node]
Arguments
-match
Specifies a Tcl regular expression to run only those variant of constraint arcs
that match the regular expression. This can be used when you want to run
a small set of constraint arcs to find out the potential internal nodes.
-mem_int_node
Specifies the dummy node that is used in the instance file to assign the
actual SPICE node name to the internal node or register. The default value
of this argument is mem_int_node.
Examples
If the dummy node name in the instance file is specified as follows:
Example 387
add_pin mem_int default -internal -spice_node [get_config_opt
dummy_node]

608 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

If you want to run only setup arcs to find out the potential internal nodes, this
command can be used as follows:
Example 388
find_potential_internal_nodes -match setup__* -mem_int_node
dummy_node

If the dummy node name in the instance file is specified as follows:

Example 389
add_pin mem_int default -internal -spice_node [get_config_opt
mem_int_node]

If you want to run only setup and hold arcs to find out the potential internal node
corresponding to 'mem_int', this command can be used as follows:
Example 390
find_potential_internal_nodes -match (setup__*|hold__*)

Example 391
find_potential_internal_nodes

This command if used as such will run all the variants of constraint arcs to find
out the potential internal nodes corresponding to the dummy node
mem_int_node.
See Also
find_internal_nodes_for_constraint

get_word_line_node
The word line is used while generating the pruned netlist of the energy arcs.
The energy numbers from pruning are in the same range as energy numbers
obtained without pruning.
Syntax
get_word_line_node internal_node
Arguments
internal_node
The internal node (found with the
find_internal_nodes_for_constraint command).

SiliconSmart ACE User Guide 609

L-2016.03
Chapter 14: Command Reference
Setup Commands

See Also
find_internal_nodes_for_constraint
find_potential_internal_nodes

man
Returns parameter documentation.
Syntax
man [-internal] param_name_or_glob
Description
For example, if you are looking for information about threshold, you can issue
the command man *thresh*, and SiliconSmart returns the following
information:
Example 392
logic_high_threshold pintype 0.8
logic_low_threshold pintype 0.2
logic_low_threshold_rise pintype logic_low_threshold
logic_low_threshold pintype logic_high_threshold
power_stabilization_threshold Default 0.05

If you issue the command man logic_high_threshold, SiliconSmart

returns the following information:
Example 393
Parameter: logic_high_threshold
Block: pintype
Default: 0.8
Type: Floating point number
Valid values: Between 0.0 and 1.0

merge
Generates a merged library from the cell-level library.
Syntax
merge [-directory dir_name] [-output filename] [-compact]
[-extension ext_name] [-header filename] [cell_list]

610 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Arguments
-directory
Specifies which directory the cell level .libs reside. If not provided, the
models will be picked up from the default location where models are written
by model command, i.e., the charpt/models/liberty directory.
-compact
Compacts the model if CCS timing, power, noise, or CCS-VA data is
available in the model. If the cell models contain CCS-VA data, they will
always be compacted since that is required by the CCS-VA format.
-extension
Creates different libraries for the same cell. For example, for a MUX you can
create ECSM, CCS, and NLDM libraries. So you would differentiate
between them by putting different extensions, such as ecsm.lib or ccs.lib.
For merging, you need to know which are the cells under the same criteria.
-output
Path to the merged .lib file. If only a file name is specified, it goes to the
current working directory.
-header
Header file which is concatenated to the header section of the merged .lib
file. This is a flat file containing attributes and groups. There should not be
a library level container group. Consider the following example:

Example 394
my_new_lib_attr : 3432;
define(foo, bar);
wire_load(model1) {
length : 3;
hello : 2;
}
new_lib_attr : “hello world”;

cell_list
List of cells. If no list is provided, it merges all files with a .lib extension found
in the source directory.

SiliconSmart ACE User Guide 611

L-2016.03
Chapter 14: Command Reference
Setup Commands

Description
Use this command to generate a complete multi-cell library from for a set of
single cell level libraries. Single cell level library means that a .lib is created only
for a single cell using the SiliconSmart model command.
When merging many cells with lots of measurements, especially when CCS-
noise and/or CCS-VA are enabled, the model command may not be able to
handle the memory capacity to create a full library. For this scenario, you can
generate cell level .lib files, and then use the merge command to merge the
cells.
Another scenario in which the merge command is useful, is if you are using a
cell level flow where SiliconSmart may be invoked once per cell to go through
the whole characterization flow. In this case, the result would be multiple .lib
files per cell, and they can then be merged using the merge command.
All the cell level .lib files are to be placed in the dir_name directory. The files in
this directory MUST have a .lib extension, otherwise they will be ignored.
The header for all the cell level model files must be consistent. There should
not be any conflicts on attribute names and values. For example, the units and
de-rating factors, etc., must match for all the cell level .lib files. The look-up
table templates are an exception, and will be handled correctly by the merge
command.

Generating Compact CCS Models with the merge Command

The -compact switch is used to generate a compact-CCS merged library. The
merge command supports CCS-timing, CCS-power, and CCS-VA compact-
CCS libraries. Compact CCS-noise are not yet supported.
In order to generate compact models, you must use the –nocompact switch on
the model command when generating CCS-VA models. Although a non-
compact CCS-VA format is not defined by the Liberty standard, SiliconSmart
will write out a non-compact CCS-VA model so that it can easily be compacted
during the merge step. Please note, the non-compact CCS-VA model per cell is
a requirement to generate compact CCS-VA models using the merge
command. To generate non-compact CCS-VA a cell level models, use the
–nocompact switch on the model command. Consider the following example:
Example 395
model –timing –power –ccs_va –nocompact cells

612 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Examples

Example 396
merge –directory my_models –output merged.lib cells
merge –directory my_models –compact –output merged_compact.lib
cells

pintype
This command defines a new pin type in the configuration.
Syntax
pintype name [-> parent] settings
Arguments
name
The name of the new pin type to be defined.
-> parent
The name of an optional existing pin type, whose contents will be
automatically copied and then extended as the new pin type.
settings
One or more set (parameter) commands.
Description
This command specifies a new pin type that is used for cell characterization
and modeling, usually used in the configure.tcl file. A pin type defines a data
structure for named pin attributes, such as logic_high_name and
logic_low_name, that are specific to one particular type of pin. The ->
operator allows an existing pin type to be copied and extended under the new
name specified. New attributes can then be added to the copy or existing ones
redefined.
Errors
If the named pin type already exists, the existing parameters are cleared before
the new parameters are set. Error messages are displayed if the parent is
invalid or undefined, or any of the Tcl set commands is invalid.

SiliconSmart ACE User Guide 613

L-2016.03
Chapter 14: Command Reference
Setup Commands

Examples

Example 397
# Defines a new pin type based on a previous defined type named
'default'.
pintype pad -> default {
set logic_high_name VDD_HI
}

See Also
get_pintype_parameter
list_pintype_parameters
list_pintypes
set_pintype_parameter
remove_pintype

remove_driver
This command removes an imported driver cell and all related characterization
data.
Syntax
remove_driver cell
Arguments
cell
The name of a driver cell.
Description
This command deletes a driver cell imported with the command
import_driver. When the driver cell is removed, any characterization data is
associated with it is also deleted.
Errors
An error is returned if the driver cell does not exist.
See Also
import_driver
report_drivers

614 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

remove_parameter_block
Deletes a parameter block and all associated parameters.
Syntax
remove_parameter_block block

remove_pintype
This command deletes a defined pin type.
Syntax
remove_pintype pintype
Arguments
pintype
The name of a defined pin type to be deleted.
Description
This command deletes a defined pin type and all parameters defined for it. Pin
types that used it as a parent (see the pintype command) are unaffected.
Errors
An error is returned if the pin type does not exist.
See Also
pintype
list_pintype_parameters
list_pintypes

report_arcs
Lists to std_out all the arcs generated by the configure command.

set_boundary_distance
This command is used to specify distance from boundary transistors to cell
boundary.

SiliconSmart ACE User Guide 615

L-2016.03
Chapter 14: Command Reference
Setup Commands

Syntax
set_boundary_distance {lower_left_distance
upper_left_distance lower_right_distance
upper_right_distance}
Arguments
lower_left_distance
The distance of the lower left transistor from the cell boundary.
upper_left_distance
The distance of the upper left transistor from the cell boundary.
lower_right_distance
The distance of the lower right transistor from the cell boundary.
upper_right_distance
The distance of the upper right transistor from the cell boundary.
Examples

Example 398
set_boundary_distance { 290 290 270 270}

See Also
set_points_boundary_distance

set_bus_value
Ties a fixed value to a bus with a bus name and binary string. This command is
only supported for extra-margin adjustment buses.
Syntax
set_bus_value name value
Arguments
name
Name of the bus to be tied.

616 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

value
Value of the binary string, where:
• The binary string is of the form 0bAn-1…A0 where each of Ai is either
0 or 1.
• The width of the bus is equal to n. The bus is split into n individual bits,
i.e., An-1 to A0
• An-1 to A0 are assigned starting from MSB to LSB of the bus,
respectively.

set_cell_type
This command can be invoked from the .inst file only. It gives flexibility to define
the cell-type of a cell and SiliconSmart automatically takes care of many
secondary steps internally during characterization and/or modeling. This high
level command calls many user-level commands internally while modeling. One
of the user-level commands called by set_cell_type command is
set_liberty_attribute.
Syntax
set_cell_type type_name
[-virtual_supply_name_map name_map] \
[-type switch_type switch_direction] \
[-enable_pin enable_pin_list] \
[-data_pin data_pin_list] \
[-input_voltage_range inp_range] \
[-output_voltage_range out_range]
-no_state_table
Arguments
data_pin_list
Tcl list of data pins.
enable_pin_list
The enable pin or list of pins for the switch cell. This is a Tcl list of values like
{EN S_EN}
inp_range
Input voltage range. This is a Tcl list of low and high voltage limits. For
example, {0.0 1.1}

SiliconSmart ACE User Guide 617

L-2016.03
Chapter 14: Command Reference
Setup Commands

out_range
Output voltage range. This is a Tcl list of low and high voltage limits. For
example, {0.0 1.5}
-data_pin
Used to specify the data pin of the cell like a level shifter.
-enable_pin
Used to specify the switch cell’s enabling pin.
-input_voltage_range
Used to specify the input voltage range for level shifters.
-output_voltage_range
Used to specify the output voltage range for level shifters.
-switch_direction
Specifies the switch enabling direction. Valid values are HL_LH, HL, LH.
-type
Supported types are coarse_grain and fine_grain.
type_name
The cell type: valid values are mtcmos, level_shifter,
isolation_cell, memory.
-virtual_supply_name_map
List of pairs of virtual supply name and actual supply name. For example,
{vvdd vdd .. ..}
Description
This command gives flexibility to define the cell-type of a cell and SiliconSmart
automatically takes care of many secondary steps internally during
characterization and/or modeling. This high level command calls many user-
level commands internally while modeling.
One of the user level commands called by set_cell_type command is
set_liberty_attribute.
For MT-CMOS switch cells, you must define:
Example 399
set_cell_type mtcmos -type coarse_grain|fine_grain
–virtual_supply_name_map {virtual_PG_pin PG_pin}

618 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

The –type option is required for specifying the type of the switch. The value
can be either coarse_grain or fine_grain. The default is coarse_grain.
For level shifter cells, you must define:
Example 400
set_cell_type level_shifter –type HL_LH|LH|HL -enable_pin {pin} \
-data_pin {pin} \
-input_voltage_range {Llimit Hlimit} \
-output_voltage_range {Llimit Hlimit} \

The default value of -type switch for level shifter is HL_LH. All other switches
are optional and give the flexibility to user to set cell-level attribute:
level_shifter_type and pin-level attributes:
level_shifter_enable_pin, level_shifter_data_pin,
input_voltage_range and output_voltage_range, respectively in the
generated Liberty file.

For isolation cells, you must define:

Example 401
set_cell_type isolation_cell -enable_pin {pin} -data_pin {pin}

This behavior is similar to level shifter cells.

If set_cell_type is set to memory, SiliconSmart will automatically remove
the state table from the .lib while modeling.
See Also
clear_liberty_attribute
set_liberty_attribute

set_config_opt
This command sets the characterization and modeling configuration option for
a cell, measurement type, or specific measurement.
Syntax
set_config_opt
-cell cell -ccb ccb -opcond opcond
[-type (decap | decap_ccs | delay | cin_css | zen | zdis |
energy | tout | timing | setup | hold | recovery |
asynch_recover | removal | asynch_removal | leakage_power
| constraint | cmpw | ncmpw | mpw | input_capacitance |
nochange | nochange_hold | nochange_setup | noise |

SiliconSmart ACE User Guide 619

L-2016.03
Chapter 14: Command Reference
Setup Commands

noise_iv | noise_immunity | noise_prop | ccs_noise |

ibis_iv | ibis_vt | statistical_delay |
stat_leakage_power | statistical_hold |
statistical_setup | binning | binning_timing |
binning_energy | binning_constraints | nldm_noise)]
[-from (pin | pin_list)]
[-from_direction (direction | direction_list)]
[-reference pin] [-overdriver_on_pin]
[-reference_direction (direction | direction_list)]
[-pin pin] [-to (pin|pin_list|none)]
[-to_direction (direction | direction_list)]
[-when expression]
option value
Arguments
ccb
Specifies the names of CCBs to which the parameters apply.
cell
Specifies the name of a cell or a list of cells to apply the configuration
options to. This switch can only be used when set_config_opt is not
being called from a cell's instance file.
from
Matches all measurements beginning with the pin or pins specified in the
value. The value can be the name of a pin or a Tcl list of pin names.
opcond
Specifies the names of operating conditions to which the parameters apply.
option
Specifies the name of the configuration option to set.
over_driver_on_pin
Specifies an external power supply (which is not part of the netlist) to
overdrive the input pin.
pin
Specifies the name of the pin to which the option should be applied. This
switch is only valid for pin-based options such as pintype or
dontcare_value.

620 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

reference
Matches the reference pin for constraint acquisitions. The value can be the
name of a pin or a Tcl list of pin names.
to
Matches all measurements ending with the pin or pins specified in the value.
The value can be the name of a pin or a Tcl list of pin names. If the value is
the keyword none, only measurements involving only an input pin are
matched.
type
Specifies the measurement type to which the option applies. If no type is
specified, the option applies to all types. Can be a single type or a
type_list.
The timing type applies to delay, zenable, and zdisable. The
constraint type applies to setup, hold, recovery, and removal. The
mpw type applies to cmpw and ncmpw.
The nldm_noise value covers all noise measurements not covered by
ccs_noise. Precharacterization and import have modified to use the
nldm_noise tag instead of noise for setting state-related parameters.
Existing .inst and .prechar files will not be affected.
The nochange type is the master type for nochange_hold and
nochange_setup.
Refer to Specifying set_config_opt -type for more information and hierarchy
diagrams of these types.
value
Specifies the value of the option being set.
when
Specifies a boolean condition of states on the cell’s input pins. This allows
options to be set based on the state of pins which control the electrical
behavior of a cell, such as drive strength control.
Description
Legal direction values include LH, HL, LZ, HZ, ZL, or ZH. The
set_config_opt command supports global style wildcards for cell names,
pin names and transitions. For example, -pin * will mean all the pins.
When SiliconSmart generates the measurements for each cell, it consults the
set of options specified with the set_config_opt command. Any option

SiliconSmart ACE User Guide 621

L-2016.03
Chapter 14: Command Reference
Setup Commands

settings that match the type, from pin, and/or to pin of a given measurement are
applied to that measurement. The following table describes the available
options.
See the Using the set_config_opt Command section for more details on using
this command.
See Also
get_config_opt
set_parameter
set_pintype_parameter

set_harness_parent
This command pick ups the harness elements for any pin not included in a
particular harness.
Syntax
set_harness_parent new_harness default

set_length_unit
This command specifies the unit in which the transistor lengths are specified.
Syntax
set_length_unit lenth_unit
Arguments
length_unit
The channel length/channel width unit for si-shapes characterization.
Possible values are nm and um.
Description
This command is used with add_transistor and related commands to
specify the units in which the transistor channel lengths are specified. Legal
values are nm (nanometers) and um (micrometers).
See Also
add_transistor
add_channel_length_variation
add_channel_width_variation

622 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

set_liberty_attribute
This command sets a Liberty attribute.
Syntax
set_liberty_attribute [-library] [-cell cell] [-pin pin]
[-complex] attribute1 va1ue1 {attribute2 va1ue2 ...}
Arguments
-library
Specifies the attribute being is to be set as library attribute. The –cell and
–pin arguments cannot be specified with this argument.
-cell
Specifies the name of the cell to apply the liberty attributes to.
-pin
Specifies the name of the pin to apply the liberty attributes to.
-complex
Specifies whether to set a complex attribute.
attributes
Attributes specified as a paired list of attribute and value.
Description
The attributes are to be mentioned as a paired list of attribute and value. The
Liberty attributes are classified as library, cell and pin attributes. The following
table enlists the list of cell/pin attributes that are standard Liberty attributes. You
can add and set any attribute in the Liberty file. SiliconSmart only reports a
warning for the non-standard attributes being set. All user-defined attributes will
be the final attributes found before the first group.
If you want to set any cell/pin attribute, this command can also be invoked from
the instance file of cell. But you should omit –cell cell option if used from
instance file.
The -library options cannot be used together with –cell or –pin options.
All non-standard attributes will be set as a simple attribute in the Liberty file.
Check the clear_liberty_attribute command to know how to unset an
attribute defined by set_liberty_attributes.

SiliconSmart ACE User Guide 623

L-2016.03
Chapter 14: Command Reference
Setup Commands

There are two ways in SiliconSmart to set an attribute for a Liberty model:
■
Using specific parameters in the configure.tcl file, as with
liberty_max|min_capacitance|transition which enables the
SiliconSmart modeler to write an attribute accordingly into the output Liberty
file.
■
Using the set_liberty_attribute command in the run script or the cell
instance file, which sets/overrides any existing known or user-defined
attributes in the output model from the model command.
The priorities for the set_liberty_attribute command are as follows from
lowest to highest priority:
1. configure.tcl parameters or set_parameter calls.
2. set_liberty_attribute in run script or command-line calls.
3. set_liberty_attribute calls in cell instance (.inst) file.
A set_liberty_attribute call in the run script or in the cell .inst file will
override attribute values by using the
liberty_max|min_capacitance|transition parameters:
■
Set the following parameter in the configure.tcl which sets
max_transition 3.0e-9 (3ns) set liberty_max_transition 1
■
Call the set_liberty_attribute command in the run script, as follows:

Example 402
set_liberty_attribute cell CELL1 pin PIN1 max_transition
2.0e-9

In this case, the final value of max_transiiton for pin PIN1 under cell
CELL1 will be 2.0e-09 (2ns) as set_liberty_attribute has a higher
priority than that set by the parameter settings specified in the configure.tcl
file.
The set_liberty_attribute command can be called from the run
script and/or the .inst file. When you set a cell/pin level attribute in the run
script and also set/override the same using the set_liberty_attribute
command in the cell .inst file, SiliconSmart uses the
set_liberty_attribute call in the .inst file and ignores the
set_liberty_attribute in the run script as the .inst file takes
precedence.

624 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Example 403
set_liberty_attribute -cell CELL1 -pin PIN1 max_transtion
2.0e-9
■
set_liberty_attribute call in cell .inst file (CELL1.inst):

Example 404
set_liberty_attribute -pin PIN1 max_transition 1.0e-09

For the previous case, SiliconSmart will write max_transition 1.0e-09 (1ns)
into the Liberty model written by the model command for pin PIN1 under cell
CELL1 as set_liberty_attribute in the .inst file takes priority over the
set_liberty_attribute call in the run script.
The following standard cell attributes are currently supported for cell type
level_shifter:
Table 34

Attribute Type/ Default Example

Permitted
values

Cell Attributes

is_level_shifter true|fal None is_level_shifter true

se

level_shifter_type HL|LH|HL HL_LH level_shifter_type LH

_LH

input_voltage_range List of two None input_voltage_range { 0.2

float values 2.2 }

output_voltage_range List of two None output_voltage_range { 2.0

float values 3.0}

Pin Attributes

level_shifter_enable_pin true|fal None -pin A

se level_shifter_enable_pin
true

level_shifter_data_ true|fal None -pin B

pin se level_shifter_enable_pin
true

SiliconSmart ACE User Guide 625

L-2016.03
Chapter 14: Command Reference
Setup Commands

The following standard attributes are supported for cell type isolation cell:

Attribute Type/ Default Example

permitted
values

Cell Attributes

Is_isolation_cell true| None is_isolation_cell

false true

Pin Attributes

isolation_cell_enabl true| None isolation_cell_enabl

e_pin false e_pin true

The following standard attributes are supported for cell type switch:

Attribute Type/ Default Example

permitted
values

Cell Attributes

switch_cell_type fine_grai coarse_ switch_cell_type

n| grain fine_grain
coarse_gr
ain

You can use set_liberty_attribute to define complex attributes such as

define, voltage_map, and define_group. Simply set them like standard
attributes and SiliconSmart will automatically format them as complex
attributes. For complex attributes other than these three, you must use the
-complex switch to format them as complex attributes as opposed to simple
attributes.
Complex attributes can also be duplicated in a single Liberty model. Duplicates
can be accomplished by simply repeating the duplicate definitions of the
complex attributes in a single set_liberty_attribute command.

626 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Examples

Example 405
set_liberty_attribute –cell LAGCEP is_level_shifter true
level_shifter_type HL

Sets the cell type of cell LAGCEP as level shifter with level shifter type identified
as HL:
Example 406
set_liberty_attribute –cell LAGCEP is_level_shifter true
level_shifter_type HL input_voltage_range {0.0 02}
output_voltage_range {0.1 1.5}

Sets the cell type of cell LAGCEP as level shifter with the following attributes
being set:
Example 407
level_shifter_type : HL
input_voltage_range (0.0 02)
output_voltage_range (0.1 1.5)
set_liberty_attributes –cell LAGCEP –pin VDD pg_type backup_power

Sets the pg_type of the supply pin VDD of cell LAGCEP as backup_power.
Example 408
set_liberty_attribute –library default_cell_leakage_power 1.1

Sets a value 1.1 to library attribute default_cell_leakage_power in the

Liberty file.

Example 409 Set a Complex Attribute

set_liberty_attribute -library voltage_map {VDD 1.1}

The above will produce a single complex attribute named voltage_map in the
Liberty model.

Example 410 Set 3 Complex Attributes of the Same Name

set_liberty_attribute -library voltage_map {VDD 1.1} voltage_map
{VDDG 1.1} voltage_map {VDDH 1.1}
voltage_map(VDD, 1.1);
voltage_map(VDDG, 1.1);
voltage_map(VDDH, 1.1);

SiliconSmart ACE User Guide 627

L-2016.03
Chapter 14: Command Reference
Setup Commands

This will generate a 3 voltage_map attributes in the Liberty model. Note that
set_liberty_attribute will not write duplicates of the both the name and
value of the attribute are duplicates; that is, the values must be unique for the
duplicate attributes to appear in the model. So the output model will have:

Example 411 Set a Custom Complex Attribute

set_liberty_attribute –complex -library my_complex_attribute
{perimeter, 5.3}

This will produce the following in Liberty model:

my_complex_attribute(perimeter, 5.3); [code font]

See Also
clear_liberty_attribute

set_location
This command selects the characterization directory to be used and reads the
configuration.
Syntax
set_location char_dir
Arguments
char_dir
The absolute or relative path to a valid characterization directory.
Description
This command specifies the target characterization directory for all
characterization-related data files. The path specified can be absolute or
relative and must refer to a valid SiliconSmart directory structure generated by
the create command.
Errors
Missing file or bad path messages can result from other commands if an invalid
directory (one not created by the create command) to set_location.
See Also
create
get_location

628 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

set_log_file
This command sets the destination for the logging messages.
Syntax
set_log_file filename
Arguments
filename
The name of a file to write logging messages to.
Description
This command sets the file that all logging messages will be written to. If the file
already exists, you must have permission to write to it and new messages are
appended to the file.
Errors
An error is returned if the file is not writable.
See Also
set_log_level
set_log_stdout_level

set_log_level
This command sets the minimum severity level of messages written to the log
file.
Syntax
set_log_level level
Arguments
level
One of ERROR, WARNING, INFO, or VERBOSE.
Description
Sets the minimum severity level of messages written to the log file. The lowest
severity is INFO. If VERBOSE is specified, additional debugging messages are
generated.
Errors
Level must be one of the specified levels.

SiliconSmart ACE User Guide 629

L-2016.03
Chapter 14: Command Reference
Setup Commands

See Also
set_log_file
set_log_stdout_level

set_log_stdout_level
This command sets the minimum severity level of messages written to the
terminal.
Syntax
set_log_stdout_level level
Arguments
level
One of ERROR, WARNING, INFO, or VERBOSE.
Description
This command sets the minimum severity level of messages written to the
terminal. The lowest severity is INFO. If VERBOSE is specified, additional
debugging messages are generated.
Errors
Level must be one of the specified levels.
See Also
set_log_file
set_log_level

set_maskable_enable_control_output
It accepts an ON or OFF value. This command is only necessary when the
maskable write enable signal is present and write through mode is ON.When
write through mode is ON and the maskable write enable signal is present, the
memory may behave in one of two different ways.
1. When write through mode is ON and maskable write enable signal is active,
then during the write operation the data will be written to both memory and
output.
2. When write through mode is ON and maskable write enable signal is not
active then during the write operation data will not be written into memory
but it will be written to output.

630 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

As shown above, when write through mode is ON, the output is not dependent
on the maskable write enable signal state.
When an OFF value is given to set_maskablewrite_enable_output, the
behavior of memory is as described above.
When write through mode is ON and the maskable write enable signal is active,
then during write operation the data will be written to both memory and output,
which is the same behavior as before. However, when write through mode is ON
and the maskable write enable signal is not active, then during write operation
data will not be written into memory or output.
With this new command, when write through mode is ON, the output is
dependent on the maskable write enable signal state.

set_measurement_node
This command specifies the node in a harness network that measurements are
placed on instead of measuring an output pin directly.
Syntax
set_measurement_node harness_name pin_name node_name
Arguments
harness_name
Name of a harness created with the command create_harness.
pin_name
Name of an output or bidirectional pin on the CUT to which the harness is
connected.
node_name
The name of a node in the harness network. See the
add_harness_elements command.
Description
When a harness is applied to the output pin of a cell, it is sometimes necessary
to change the location where measurements are taken. For example, if a
terminating resistor network is used, sometimes the delay measurements must
be taken at a node inside the harness network instead of at the output pin itself.
This command allows the measurement point for one or more output pins to be
specified.

SiliconSmart ACE User Guide 631

L-2016.03
Chapter 14: Command Reference
Setup Commands

The specified node name must be a node implicitly created in the network (i.e.,
not another pin on the cell or a voltage supply). Two pins should not have the
same measurement node.
Examples
The following commands create a JEDEC class 1 resistor termination harness
and apply it to the PAD pin of a cell. The harness is applied to all delay
measurements and the node used for measurements is moved to the node
node1 in the voltage divider.
Example 412
create_harness jedec_class1
add_harness_elements jedec_class1 {
R RS PAD node1 25
R RT node1 VTT 25
C Cload PAD VSS load_PAD
}
set_measurement_node jedec_class1 PAD node1
set_sweep_parameter jedec_class1 -load PAD load_PAD
set_config_opt -type delay -to PAD harness jedec_class1

See Also
add_harness_elements
create_harness
set_config_opt
set_measurement_node
set_stimulus_node
set_sweep_parameter

set_netlist_file
This command specifies the path to the simulator netlist for the cell.
Syntax
set_netlist_file file [tag [file_tag] ...]
Arguments
file
Path to the simulator netlist file for this cell.
tag
Name of an operating condition for which this netlist should be used.

632 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Description
The set_netlist_file command is used to specify the path to the
simulator netlist for the cell. In most cases a single netlist is valid for all
operating conditions in which case only a single argument is needed.
SiliconSmart supports operating condition-specific netlists. In this case, the
command accepts one or more pairs of arguments consisting of a path name
and the name of an operating condition. The operating condition must be
defined with the create_operating_condition command.
A special tag name of __default__ is reserved for indicating the default
netlist. If no netlist is specified for a given operating condition then this netlist is
used.
Examples
The following command specifies the path to the netlist in the current
characterization directory for a cell named INV1:
Example 413
set_netlist_file [get_location]/netlists/INV1.cir

The following command performs the same operation, but specifies two
different netlist files for the operating conditions worst_pvt and best_pvt:
Example 414
set_netlist_file [get_location]/netlists/INV1_ss.cir worst_pvt \
[get_location]/netlists/INV1_ff.cir best_pvt

See Also
create_operating_condition
get_location

set_opc_parameter
This command sets an operating condition specific parameter.
Syntax
set_opc_parameter op_cond_name parameter_name value
Arguments
op_cond_name
The name of an operating condition created with the command
create_operating_condition.

SiliconSmart ACE User Guide 633

L-2016.03
Chapter 14: Command Reference
Setup Commands

parameter_name
Name of the parameter to be set.
value
Value of the parameter.
Description
This command sets the value of a parameter on an operating condition.
Operating condition parameters can be used in simulation harnesses to adjust
the harness for the process/voltage/temperature of the simulation. See
add_harness_elements for information on how to use parameters with
circuit elements in a harness.
Examples
The following commands create a JEDEC class 1 resistor termination harness
and apply it to the PAD pin of a cell. The harness consists of a voltage divider
tied between the PAD pin and supply VTT. Node node1 is created between the
resistors and used as the measurement point. The resistance of resistor RT is
rt_resistance, meaning that the parameter rt_resistance must be set in the
parameter block default or in the operating conditions. In this case, the
parameter has been made operating condition-specific, and is 35 ohms in the
worst-case condition and 20 ohms in the best case. The value of this parameter
is used as the value of the resistor.
Example 415
set_opc_parameter worst_pvt rt_resistance 35
set_opc_parameter best_pvt rt_resistance 20
…
create_harness jedec_class1
add_harness_elements jedec_class1 {
R RS PAD node1 25
R RT node1 VTT rt_resistance
}
set_measurement_node jedec_class1 node1
…
set_config_opt –type delay –to PAD harness jedec_class1

set_opc_parameter_distribution
Specifies the type of distribution to be applied to a statistical process
parameter.

634 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Syntax
set_opc_parameter_distribution opc_name -points
{list_of_points} \
–nominal_value value -variation_range {begin end} \
-distribution_type distribution -sigma value param1
param2 ...
Arguments
opc_name
Name of the operating condition as created with the
set_operating_condition command.
-points
Specifies an explicit list of one or more parameter values to be used during
characterization.
-nominal_value
Specifies the nominal value of the parameter. This value will be added to the
set of points specified with –points.
-distribution_type
This value is not used by characterization, but is passed through to the
generated Liberty file and is consumed by the statistical timer.
-sigma
This value is not used by characterization, but is passed through to the
generated Liberty file and is consumed by the statistical timer.
-variation_range
Range of parameter value within which the sensitivity is valid. This is used
when computing the sensitivity coefficients.
Param1
Name of one or more parameters to apply the distributions to.
Description
The set_opc_parameter_distribution command specifies the range of
values to be used for each process parameter. SiliconSmart will independently
vary each statistical process parameter over the range of points specified while
holding the other parameters at the nominal value. A set of one or more values
must be specified for each parameter via the –points switch.

SiliconSmart ACE User Guide 635

L-2016.03
Chapter 14: Command Reference
Setup Commands

The nominal value for each parameter is specified with –nominal. This value
is added to the set of points over which each parameter is varied.
The variation range (-variation_range) specifies the maximum range over
which a given parameter can vary. For example, a parameter may vary between
-1.0 and 1.0 corresponding to an expected range over three standard
deviations but the characterization may only be performed at points within one
standard deviation of the nominal. The variation range is used during modeling
to compute the sensitivity of the parameter over the entire variation range.
The switches –distribution_type and –sigma are not used in
characterization, and are only passed through to the modeling step. These are
set in the Liberty model statistical extensions and consumed by the statistical
timing analysis tool.
Examples
The following example creates the operating condition nom_pvt and adds two
parameters, PARAM1 and PARAM2 to it.
Example 416
create_operating_condition nom_pvt
…
add_opc_statistical_parameter nom_pvt –intercell PARAM1 PARAM2
set_opc_parameter_distribution nom_pvt –points { -0.33 0.33 }\
-nominal_value 0.0 –variation_range { -1.0 1.0 } –
distribution_type \ gaussian –sigma 0.33 PARAM1
set_opc_parameter_distribution nom_pvt –points { 0.25 0.27 } \
-nominal_value 0.26 –variation_range { 0.23 0.30 }
–distribution_type linear –signal 0.01 PARAM2

See Also
add_opc_statistical_parameter
configure
create_operating_condition
model

set_opc_process
Sets the SPICE process model information for an operating condition.
Syntax
set_opc_process op_cond_name process_list

636 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Arguments
op_cond_name
Name of an operating condition created by
create_operating_condition.
process_list
Tcl list of lines added to the SPICE deck that loads the appropriate models.
Description
This command adds a list of lines to an operating condition that will be added to
the generated SPICE deck(s). The lines must be legal for the SPICE simulator
being used, load the necessary process models, and be provided as a Tcl list.
Examples
The following commands create the operating condition worst and add the lines
needed to load the specified process models.
Example 417
//Case 1 (SPICE-Compatible Syntax)
create_operating_condition worst
set_opc_process worst {
{.inc "/projects/spice_models/13nm_process.params"}
{.lib "/projects/spice_models/13nm_process.lib" SS}
{.lib "/projects/spice_models/13nm_process.lib" SS_33}
}
//Case 2 (Spectre-Compatible Syntax)
create_operating_condition worst
set_opc_process worst {
{include "/projects/spice_models/13nm_process.params"}
{include "/projects/spice_models/13nm_process.lib" section=SS}
{include "/projects/spice_models/13nm_process.lib" SS_33}
}

See Also
add_latch
create_operating_condition
set_opc_temperature

set_opc_temperature
This command sets the junction temperature setting for an operating condition.

SiliconSmart ACE User Guide 637

L-2016.03
Chapter 14: Command Reference
Setup Commands

Syntax
set_opc_temperature op_cond_name temperature
Arguments
op_cond_name
The name of an operating condition created with the command
create_operating_condition.
temperature
The junction temperature setting for the operating condition in degrees C.
Description
This command sets the temperature setting for an operating condition. This
temperature will be used in any simulations of cells at this operating condition.
Examples
The following commands create an operating condition named worst and set
the temperature to 125 degrees Celsius:
Example 418
create_operating_condition worst
set_opc_temperature worst 125

See Also
add_latch
create_operating_condition
set_opc_parameter_distribution

set_opc_default_voltage
This command sets the default voltage for any operating condition in cases
when there are multi-voltage rails used in the library.
Syntax
set_opc_default_voltage opc_name voltage
Arguments
opc_name
The name of an operating condition defined by
create_operating_condition.

638 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

voltage
The default voltage (in Volts) for the library.
Description
This command is used when multi-voltage Liberty models are being generated
to specify the default library voltage. The voltage specified should be the same
value as one of the supplies defined for the operating condition (set
add_opc_supplies). This is modeled as the library voltage. The default
setting is to select the smallest positive supply defined for the library.
For example, if supplies VDD, VDDPAD, and VSS are defined as 1.1V, 3.3V, and
0V, respectively, the default library voltage is 1.1V.
See Also
add_opc_supplies
create_operating_condition

set_output_differential
This command defines a pair of differential output pins.
Syntax
set_output_differential pos_output neg_output
[-absolute_separation value]
[-relative_separation value]
Arguments
[-absolute_separation]
Specifies the voltage difference between the differential pair. Defaults is 0.
[-relative_separation]
Specifies the relative difference between the differential pair in terms of the
percentage of the final voltage separation between the differential pins.
Defaults is 0.
pos_output
Name of the positive output pin.
neg_output
Name of the negative output pin.

SiliconSmart ACE User Guide 639

L-2016.03
Chapter 14: Command Reference
Setup Commands

Description
The set_output_differential command causes SiliconSmart to treat the pair of
output pins as differential pins. This means that they are expected to transition
as a pair and delays are measured to the crossover point of the signals instead
of to the standard delay threshold. This means that differential pairs with a
voltage swing smaller than the typical rail voltages are handled correctly.
Examples
The following commands define a simple differential output buffer:
Example 419
add_function PADP A
add_function PADN !A
set_output_differential PADP PADN

See Also
add_function
define_differential_receiver

set_parameter
This command sets the value of a configuration parameter.
Syntax
set_parameter [block] name value
Arguments
block
The optional name of a parameter block. Defaults to default.
name
The name of the parameter.
Description
This command sets the value of a configuration parameter in the specified
parameter block. If the parameter has already been set, it is overwritten.
See Also
get_parameter
list_parameter_blocks
list_parameters

640 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

set_pins_to_bundle_map
This command, when used from the instance file, specifies the mapping from
the bundle name to the corresponding set of pin names (individual bits).
Syntax
set_pins_to_bundle_map -bundle bundle_name -pins pin_list
[-unsplit]
Arguments
bundle
Name of the bundle.
pins
List of pin names corresponding to the bundle.
unsplit
Unsplit individual bits/pin names.
Description
This command has the following behavior:
■
The -unsplit option must be used when the when conditions contain
references to the individual bits but the final model is constructed using only
at the bundle level.
■
If specified along with this command, the liberty_bundle_as_pins
takes precedence. The bits will be split out and the -unsplit option will be
ignored.
■
If the bits are specified individually in the instance file (for example:
add_pin D1, D2, D3 ...) then the bits are always split out in the Liberty
model even if the -unsplit option was specified.
Examples

Example 420
set_pins_to_bundle_map -bundle Q -pins { Q0 Q1 }
set_pins_to_bundle_map -bundle D -pins { D0 D1 } -unsplit

See Also
liberty_bundle_as_pins

SiliconSmart ACE User Guide 641

L-2016.03
Chapter 14: Command Reference
Setup Commands

set_pintype_parameter
This command sets a parameter in a defined pin type.
Syntax
set_pintype_parameter pintype name value
Arguments
pintype
The name of a pin type.
name
The name of the parameter to be set.
value
The value of the parameter being set.
Description
This command sets the value of a parameter in a pin type. If the pin type does
not exist, it is created. If the parameter already exists it is overwritten.
See Also
get_pintype_parameter
list_pintype_parameters
set_parameter

set_points_boundary_distance
This command specify how neighboring cell distances are varied to
characterize channel length variation (using litho simulation)
Syntax
set_points_boundary_distance boundary values
Arguments
boundary
This can be one of lower_left, upper_left, lower_right and
upper_right.
values
The list of boundary distances used for litho characterization.

642 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Examples

Example 421
set_points_boundary_distance lower_left {450 460 470 480 490 500
510 520 530 540 550 560 570 580 590 600 610 620 630 640 650 660
670 680 690 700 710 720 730 740 750 760 770 780 790}
set_points_boundary_distance upper_left {450 460 470 480 490 500
510 520 530 540 550 560 570 580 590 600 610 620 630 640 650 660
670 680 690 700 710 720 730 740 750 760 770 780 790}
set_points_boundary_distance lower_right {450 460 470 480 490 500
510 520 530 540 550 560 570 580 590 600 610 620 630 640 650 660
670 680 690 700 710 720 730 740 750 760 770 780 790}
set_points_boundary_distance upper_right {450 460 470 480 490 500
510 520 530 540 550 560 570 580 590 600 610 620 630 640 650 660
670 680 690 700 710 720 730 740 750 760 770 780 790}

The previous example says that the four boundary distances are varied from
450nm to 790nm in steps of 10nm to do litho characterization.
See Also
set_boundary_distance

set_stimulus_node
This command specifies a node in a harness network that stimulus is applied to
instead of driving an input pin directly.
Syntax
set_stimulus_node harness_name pin_name node_name
Arguments
harness_name
Name of a harness created with the command create_harness.
pin_name
Name of an input or bidirectional pin on the CUT to which the harness is
connected.
node_name
The name of a node in the harness network.
Description
When a harness is applied to the input pin of a cell, it is sometimes necessary
to change the location where the stimulus is injected. For example, if a

SiliconSmart ACE User Guide 643

L-2016.03
Chapter 14: Command Reference
Setup Commands

terminating resistor network is used, the driver for the input pin needs to drive a
node in the network instead of the input pin directly. This command specifies an
alternate node for the stimulus for an input pin. The specified node name must
be a node implicitly created in the network (that is, not another pin on the cell or
a voltage supply). Two pins should not have the same stimulus node.
Examples
The following commands create a JEDEC class 1 resistor termination harness
and apply it to the PAD pin (input) of a cell. The harness is applied to all delay
measurements and the stimulus is applied to the node node1 in the harness.
Example 422
create_harness jedec_class1
add_harness_elements jedec_class1 {
R RS PAD node1 25
R RT node1 VTT 25
C Cload PAD VSS cap_load
}
set_stimulus_node jedec_class1 PAD node1
set_sweep_parameter jadec_class1 -load PAD cap_load
set_config_opt -type delay -from PAD harness jedec_class1

See Also
add_harness_elements
create_harness
set_measurement_node
set_sweep_parameter

set_subckt_ports
This command specifies the order of the pins in the cell’s subcircuit in the netlist
file.
Syntax
set_subckt_ports pin_list
Arguments
pin_list
A list of pins and supply voltages in the order in which they appear in the
subcircuit definition.

644 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Description
To generate the simulations to characterize a cell, SiliconSmart must know the
order of the pins that appear in the subcircuit definition of the cell in the
simulator netlist. (The file specified by the set_netlist_file command.) In
most cases SiliconSmart is able to parse this file and automatically determine
the ordering of the pins. The set_subckt_ports command is provided as a
fallback for cases where it is unable to do so.
The single argument to this command is a list of pins and supply voltages in the
order that they appear in the netlist file. The pins must have been created by
the add_pin command and supplies defined with add_opc_supplies.
Examples
If SiliconSmart were unable to parse a SPICE netlist file containing the
following subcircuit definition:
Example 423
.subckt Z A VSS VDD

Then the following command should be used:

Example 424
set_subckt_ports { Z A VSS VDD }

See Also
add_opc_statistical_parameter
add_pin

set_sweep_parameter
This command specifies a parameter of a circuit element which is to be swept
over a range of values during characterization.
Syntax
set_sweep_parameter [-load pin] harness_name parameter
Arguments
harness_name
Name created with the command create_harness.

SiliconSmart ACE User Guide 645

L-2016.03
Chapter 14: Command Reference
Setup Commands

-load
Specifies that the parameter reflects the capacitive load of the pin. The pin
must be an output or bidirectional pin.
parameter
Name used as the value for a circuit element in the harness.
Description
This command specifies a parameter of a circuit element to be swept over a
range of values. Currently, you use this command to select a capacitor (by way
of specifying its parameter) to represent the capacitive load on the cell during
characterization. The option -load indicates that the parameter is to be swept
over the load range for the cell. See the parameters smallest_load and
largest_load for more information.
Examples
The following commands create a JEDEC class 1 resistor termination harness
and apply it to the pins DP and DM. The two capacitors, Cload_dp and
Cload_dm, will be swept over the load ranges for their respective pins.
Example 425
create_harness diff_harness
add_harness_elements diff_harness {
R DP_RS DP node1 25
R DP_RT node1 VTT 25
R DM_RS DM node2 25
R DM_RT node2 VTT 25
C Cload_dp DP VSS cap_load_dp
C Cload_dm DM VSS cap_load_dm
}
set_sweep_parameter jadec_class1 -load DP cap_load_dp
set_sweep_parameter jadec_class1 -load DM cap_load_dm
set_config_opt -type delay -from {DP DM} harness jedec_class1

See Also
add_harness_elements
create_harness
set_config_opt
set_measurement_node
set_sweep_parameter

646 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

status
This command returns the status (done/failed) of each cell in the
characterization database.
Syntax
status [-verbose] [-fail_only]
Returns
This command returns the following:
■
done – means that corresponding step was complete and clean for that cell.
■
failed – means that corresponding step for that cell has errors. More
information on the error can be found in the siliconsmart.log
■
An “*” following the status of a step name e.g., “model done*”, means that
this step was run multiple times and status is reported for the latest run.
Arguments
-verbose
Prints the status to the log file, with the last stage run being marked by an
asterisk.
-fail_only
Prints only cells with failing stages.
Description
The result of this command is returned as a tcl list of cells, with each major
stage of the characterization flow run, and the completion status. This can be
redirected in the shell to a file or variable for further processing.
Examples
Basic run:
status
Info: DFFX1 {import done configure done characterize done model
done*} INVX1 {characterize done*} OR2X1 {import done configure
done characterize done model done*} TLATNCAX3 {import done
configure done characterize failed model failed*}

SiliconSmart ACE User Guide 647

L-2016.03
Chapter 14: Command Reference
Setup Commands

Verbose run:
status -verbose
Info: Cell Status:
Info: DFFX1: import (done) configure (done) characterize
(done) model (done*)
Info: INVX1: characterize (done*)
Info: OR2X1: import (done) configure (done) characterize
(done) model (done*)
Info: TLATNCAX3: import (done) configure (done) characterize
(failed) model (failed*)
Info: DFFX1 {import done configure done characterize done model
done*} INVX1 {characterize done*} OR2X1 {import done configure
done characterize done model done*} TLATNCAX3 {import done
configure done characterize failed model failed*}

List failed cells only:

set_location <charpt_name>
status -fail_only
Info: TLATNCAX3 {import done configure done characterize failed
model failed*}

test_internal_nodes_for_constraint
If you already have some knowledge on the potential candidates for selected
nodes (Refer to the find_potential_internal_nodes command) that
can be classified as the actual internal bit cell of the memory where the data is
stored, This command can be used to run constraint tests on each of these
nodes to find out the actual internal node among the lot.
Syntax
test_internal_nodes_for_constraint -node_list
list_of_nodes [-match expression]
[-mem_int_node dummy_name]
Arguments
-node_list
Specifies the list of potential candidates for the internal node.
-match
Specifies a Tcl regular expression to run only those variant of constraint arcs
that match the regular expression. This can be used when you want to run
a small set of constraint arcs to find out the potential internal nodes.

648 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

-mem_int_node
Specifies the dummy node that is used in the instance file to assign the
actual SPICE node name to the internal node or register. The default value
of this argument is mem_int_node.
Examples
If you want to run all the constraint tests to select the actual internal node from
a subset of nodes returned by the command
find_potential_internal_nodes, this command should be used as
follows:
Example 426
test_internal_nodes_for_constraint -node_list {n1 n2 n3 }

If the dummy node name in the instance file is specified as follows:

Example 427
add_pin mem_int default -internal -spice_node [get_config_opt
dummy_node]

You want to test nodes a and b and wants to run only setup arcs to select the
internal nodes, this command can be used as follows:
Example 428
test_internal_nodes_for_constraint -node_list {a b} -match
setup__* -mem_int_node dummy_node

See Also
find_internal_nodes_for_constraint

validate_hdl
HDL validation intends to cross-verify the correctness of the HDL models to the
Liberty timing model. This in turn cross checks SiliconSmart and the STA tool
for consistency in the timing model.
Syntax
validate_hdl [-verilog | -vhdl] -lib_file liberty_file
-hdl_file hdl_file [-skip_sdf] [-skip_hdl_sim] [-no_map]

SiliconSmart ACE User Guide 649

L-2016.03
Chapter 14: Command Reference
Setup Commands

Arguments
-fast
Distributes the Verilog simulation and the VCD and SDF mapping process
across the LSF/machine, based on the user’s job scheduler settings.
-hdl_file
Path to hdl file (verilog).
-lib_file
Path to .lib file.
-no_map
This switch is optional and instructs the validation tool to not run the VCD
and SDF timing verification correlation flow to verify back-annotation.
-skip_hdl_sim
This switch is optional and is specified when you want to skip SDF back-
annotation.
-skip_sdf
This switch is optional and is specified only when you want to skip SDF
generation, perhaps because of an already existing or generated SDF file.
-verilog | -vhdl
HDL netlist types that are to be validated.
Description
HDL validation is comprised of the following phases:
■
SDF generation
■
HDL simulation
■
functional verification
■
Timing verification
See the Running HDL Validation section for more information on these
validation phases.

650 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Setup Commands

Parameters
Define the following parameters in either the validation block in configure.tcl or
interactive:

Parameter Default Value

generate_sdf_cmd_file [get_install_path]/etc/validation/validate_hdl/
generate_sdf.tcl. Here, get_install_path is a
command that returns install path for SiliconSmart.

sdf_source_tool_cmd pt_shell [get_parameter validation

generate_sdf_cmd_file]

hdl_target_simulator Verilog XL.

hdl_target_simulator Verilog.

Example 429
validate_hdl -verilog -lib_file liberty_fast.lib -hdl_file
verilog.v

The Verilog reports and log files are stored in the following directory structure:
charpt/validation/validate_hdl/verilog

Under these directories lie the reports and log files:

simulator/hdl_compile.log
simulator/hdl_sim.log
simulator/vcd/cell.vcd
simulator/reports/cell_vcd_sdf_compare.txt
simulator/hdl_ba.txt

where charpt is the characterization point, simulator is the name of the

simulator used, hdl is the HDL netlist, cell is the cell name that is being verified.
All the SDF related files/directories such as vtop.v sdf_source_tool.log,
generate_sdf.tcl all.sdf and cell_sdf_files will appear in directory
charpt/validation/validate_hdl/sdf.

SiliconSmart ACE User Guide 651

L-2016.03
Chapter 14: Command Reference
Query Commands

Query Commands
Query commands are used to find useful data from the tool. This data can be
used as information echoed to the user or within the Tcl environment for
automated processing. The following query commands are available:
■
get_cells
■
get_config_opt
■
get_location
■
get_parameter
■
get_pintype_parameter
■
get_version_info
■
help
■
list_parameter_blocks
■
list_parameters
■
list_pintype_parameters
■
list_pintypes
■
print_options
■
report_drivers
■
report_pruning
■
report_sim_results
■
report_sim_stats
■
write_config_opts

get_cells
This command returns a list of the names of all imported cells.
Syntax
get_cells [cells]

652 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

Arguments
cells
One or more cell names or wildcard expressions specifying the cells to be
characterized. If the keyword all is specified, all cells are characterized.
The default is all.
Description
This command returns a list of cells that have been imported in the current
characterization directory. The default is to return all cells. A subset of cells can
be selected by specifying cell names or wildcard expressions (Tcl 'glob'
expressions) selecting one or more cells.
For example, the following command returns a list of cells containing the cell
USB1_1 and all cells starting with LVDS:

Example 430
io_shell> get_cells USB1_1 LVDS*

Errors
An error message is displayed if set_location has not been executed prior
to invoking get_cells.
See Also
set_location
import

get_config_opt
This command returns the value of the specified parameter in the context
described by the flags.
Syntax
get_config_opt
-cell cell
[-type (decap | decap_ccs | delay | zen | zdis | energy |
timing | setup | hold | recovery | asynch_recover | removal
| asynch_removal | leakage_power | constraint | cmpw |
ncmpw | mpw | input_capacitance | nochange | nochange_hold
| nochange_setup | noise | noise_iv | noise_immunity |
noise_prop | ccs_noise | ibis_iv | ibis_vt |
statistical_delay| stat_leakage_power | statistical_hold
| statistical_setup)]

SiliconSmart ACE User Guide 653

L-2016.03
Chapter 14: Command Reference
Query Commands

[-from (pin | pin_list)]

[-from_direction (direction | direction_list)]
[-reference pin]
[-reference_direction (direction | direction_list)]
[-pin pin]
[-to (pin|pin_list|none)]
[-to_direction (direction | direction_list)]
[-when expression]
option
Arguments
cell
Specifies the name of a cell or a list of cells to apply the configuration
options to. This switch can only be used when set_config_opt is not
being called from a cell's instance file.
from
Matches all measurements beginning with the pin or pins specified in the
value. The value can be the name of a pin or a Tcl list of pin names.
option
Specifies the name of the configuration option to set.
pin
Specifies the name of the pin to which the option should be applied. This
switch is only valid for pin-based options such as pintype or
dontcare_value.
reference
Matches the reference pin for constraint acquisitions. The value can be the
name of a pin or a Tcl list of pin names.
to
Matches all measurements ending with the pin or pins specified in the value.
The value can be the name of a pin or a Tcl list of pin names. If the value is
the keyword none, only measurements involving only an input pin are
matched.
type
Specifies the measurement type to which the option applies. If no type is
specified, the option applies to all types. Can be a single type or a type_list.

654 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

• The timing type applies to binning_timing, delay, retain, zenable, and

zdisable.
• The delay type applies to delay, constraint_delay, statistical_delay, and
tout.
• The constraint type applies to setup, hold, recovery, and removal.
• The mpw type applies to cmpw and ncmpw.
• The nochange type is the master type for nochange_hold and
nochange_setup.
when
Specifies a boolean condition of states on the cell’s input pins. This allows
options to be set based on the state of pins which control the electrical
behavior of a cell, such as drive strength control.
Description
Legal direction values include LH, HL, LZ, HZ, ZL, or ZH. The
get_config_opt command supports glob style wildcards for cell names, pin
names and transitions. For example, -pin * will mean all the pins
See Also
set_config_opt
set_parameter
set_pintype_parameter
get_parameter
get_pintype_parameter

get_location
This command returns the current characterization directory location.
Syntax
get_location
Description
This command returns the current characterization directory. If set_location
has not been called, get_location returns nothing.
See Also
set_location

SiliconSmart ACE User Guide 655

L-2016.03
Chapter 14: Command Reference
Query Commands

get_parameter
This command returns the value of a configuration parameter.
Syntax
get_parameter [-quiet] [-default value] [block] name
Arguments
-quiet
Suppresses the error reported if the parameter does not exist.
-default
If parameter name does not exist, value is returned.
block
The optional name of a parameter block. This defaults to default.
name
The name of the parameter.
Description
This command returns the value of parameter name in parameter block block. If
the parameter has not been set, an error is returned unless -quiet or
-default has been specified.
If -quiet is selected and the parameter has not been set, an empty string is
returned. If -default is specified and the parameter has not been set, value
is returned.
Errors
An error message is displayed if the parameter does not exist.
See Also
get_pintype_parameter
list_parameter_blocks
list_parameters
set_parameter

get_pintype_parameter
This command returns the value of a parameter for a pin type definition.

656 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

Syntax
get_pintype_parameter [-quiet] pintype name
Arguments
-quiet
Suppresses the error normally generated if the parameter does not exist.
pintype
The name of a pin type defined with the pintype command.
name
The name of a parameter defined in specified pin type.
Description
This command returns the value of a parameter defined in a pin type. If the
parameter has not been set, an error is required unless –quiet is specified. If
the parameter does not exist and –quiet is given the return value is an empty
string.
Errors
An error message is displayed if the parameter does not exist, unless
suppressed with –quiet.
See Also
get_parameter
list_parameter_blocks
list_parameters
list_pintype_parameters
list_pintypes

get_version_info
This command returns information about the current version of SiliconSmart.
Syntax
get_version_info

SiliconSmart ACE User Guide 657

L-2016.03
Chapter 14: Command Reference
Query Commands

Description
This command returns a Tcl list with information about the current executable.
The list elements are: executable name, release number, build number, and
build date as shown in the following example:
Example 431
siliconsmart 2005.07 717 "Tue Jun 21 01:27:20 CDT 2005"

help
This command displays help text.
Syntax
help [command]
Arguments
command
A SiliconSmart command name or wildcard pattern.
Description
This command displays help text for the specified command. The command
name can be a wildcard pattern, such as get_*, in which case help is
displayed for all matching commands. The default is to display help for all
commands. If no command is supplied, then a list of all available commands is
listed along with the usage.

list_parameter_blocks
This command returns a list of the defined parameter blocks.
Syntax
list_parameter_blocks [pattern]
Arguments
pattern
A wildcard against which each parameter block name is matched. The
default is to match all names (*).
Description
This command returns a list of the names of all defined parameter blocks. If
pattern is specified, only the parameter block names matching it are returned.

658 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

See Also
get_parameter
list_parameters
list_pintype_parameters
list_pintypes

list_parameters
This command lists the configuration parameters in the given block.
Syntax
list_parameters block pattern
list_parameters pattern
list_parameters
Arguments
block
The optional name of a parameter block. This defaults to default.
pattern
A wildcard pattern used to match the parameter names. The default is to
match all parameter names (*).
Description
This command returns a list of the parameters defined in a parameter block. If
the pattern is specified, only those parameter names matching the pattern are
returned. If only a single argument is given, the argument is assumed to be a
pattern and the block name defaults to default.
Errors
An error message is displayed if the parameter block does not exist.
See Also
get_parameter
list_parameter_blocks
list_pintype_parameters
list_pintypes

SiliconSmart ACE User Guide 659

L-2016.03
Chapter 14: Command Reference
Query Commands

list_pintype_parameters
This command returns a list of the names of all parameters defined for a pin
type.
Syntax
list_pintype_parameters pintype [pattern]
Arguments
pintype
The name of a defined pin type.
pattern
An optional pattern against which each parameter name is compared.
Defaults to matching all names (*).
Description
Returns a list of the names of all parameters defined in a pin type. If pattern is
specified, only the parameter names matching the pattern are returned. The
pattern argument is a wildcard expression and defaults to matching everything
(*).
See Also
get_parameter
list_parameter_blocks
list_parameters
list_pintypes

list_pintypes
This command returns a list of the names of the defined pin types.
Syntax
list_pintypes [pattern]
Arguments
pattern
A wildcard against which each pin type name is matched. The default is to
match all names (*).

660 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

Description
This command returns a list of the names of all defined pin types. If pattern is
specified, only those names matching the pattern are returned.
See Also
get_parameter
list_parameter_blocks
list_parameters
list_pintype_parameters

print_options
This command requires that the characterization directory be specified using
set_location. All active settings specified using set_config_opt are
listed, in the context that they are set. The output of the command are printed to
the tcl shell output, and can be redirected to a file or variable using the CCI
redirect command.
This command takes no arguments.
Syntax
print_options

report_drivers
This command generates a textual report describing the driver cells that have
been imported.
Syntax
report_drivers [-verbose] [pattern]
Arguments
-verbose
Generates a more detailed description of each driver cell.
pattern
An optional wildcard pattern against which each driver cell name is
matched. Only matching names are reported.

SiliconSmart ACE User Guide 661

L-2016.03
Chapter 14: Command Reference
Query Commands

Description
The report_drivers command generates a textual description of the driver
cells that have been imported. The basic report displays the cell, the selected
arc, and the SPICE netlist file. If –verbose is specified, the report also
displays the conditions under which each cell has been characterized. The
conditions reflect the process, voltage, and temperature variations in the
simulations where the driver has been used.
See Also
import_driver
remove_driver

report_pruning
Reports the percentage of devices pruned for each arc for memory
characterization.
Syntax
report_pruning [-output file_name]
Arguments
-output
Specifies the output filename. If not specified, the report will be written on
the standard output.

report_sim_results
This command presents the SOF file in a readable format. The SOF file format
has fast read/write capabilities and a small file size. Because the .sof file is not
human readable, this command gets an ASCII table format report of the results.
Syntax
report_sim_results -cell cell_pattern|all [-sof
sof_pattern] [-tcl]|[-outputDir directory]
Arguments
cell
Text pattern of the cells to be processed

662 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

sof
Text pattern of the SOFs to be processed
outputDir
Redirects dump file to the specified output directory
tcl
Returns a Tcl list as the result
Description
The mandatory -cell option is used to specify the cells to be processed. The
-sof pattern filters the list of SOFs to be dumped. If this is not specified, all
SOF files are processed. For each name.sof file a corresponding
name.sof_dump is created. The default output directory is the same as the
location of the SOF files. This can be overridden by specifying the
-outputDir option. The -tcl option is provided if you want to capture the
results in a Tcl list and process it later. The options -tcl and -outputDir are
mutually exclusive.
Example 432
report_sim_results -cell BUF
report_sim_results -cell AND2 -sof delay__A1__hl__Z__hl__ACQ_1
report_sim_results -cell DFF* -sof energy* -outputDir
[get_location]/reports
array set myArr [report_sim_results -cell DFFX1 -sof
delay__D__lh__Q__lh__ACQ_1 -tcl]

report_sim_stats
This command runs a report for specified cells and precharacterization
simulation. If nothing is specified, it runs the report for all cells. The output goes
to the screen unless you specify -output and direct it to a file.
Syntax
Usage: report_sim_stats [-characterize] [-precharacterize]
[-import] [-configure] [-model] [-preconfigure]
[-verbose] [-output filename] [cells...]
Arguments
verbose
Generates a report on a per-simulation basis. The default is per-cell.

SiliconSmart ACE User Guide 663

L-2016.03
Chapter 14: Command Reference
Query Commands

output filename
Redirects output to a file instead of the screen.
cells
The list of cells to report on.
import
Reports runtime for import.
configure
Reports runtime for configure.
model
Reports runtime for model.
preconfigure
Reports runtime for configure done during precharacterization.
precharacterize
Reports runtime statistics for precharacterization.
characterize
Reports runtime for characterization.
Description
If no cells are specified, it runs the report for all cells. The output goes to the
screen unless you specify –output and direct it to a file. The standard output
looks like this:

664 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

Example 433
Measurement SiS Time Child Time Wall Time # Sims
--------------------------------- --------- ---------- -------
-- ---
Total for cell MY_IO_PAD 174.30 9257.68 9608.03 223
--------------------------------- --------- ---------- -------
-- ---
Total 174.30 9257.68 9608.03 223

Summary by simulation host:

Host Wall Time # Sims # Acqs
------------------------------- --------- ------ ------
exec-host-45 9608.03 223 223

Summary by measurement type:

Measurement SiS Time Child Time Wall Time # Sims # Acqs

----------------------- ------- ---------- ---------- ----
-- ---
delay 53.03 3035.90 3144.78 68 68
energy 75.36 5024.97 5192.76 122 122
leakage_power 0.14 7.39 8.09 1 1
zdis 3.27 251.21 264.48 16 16
zen 42.50 938.21 997.92 16 16

In the first table, the column SiS Time shows the number of CPU seconds
consumed by SiliconSmart to generate the simulation(s) and process the
results. The column Child Time shows the number of CPU seconds consumed
by all child processes. Primarily, this is the simulator, but also includes the
processes necessary to compress and archive the results if archiving is
enabled. Notice that both of these columns are in CPU seconds, which exclude
I/O wait time or time consumed by other processes running on the same CPU.
These times correspond to the numerical values returned by the times() system
call from sys/times.h, where Child Time is the sum of all child processes’
system and user times, and SiS Time is the sum of the SiliconSmart system
and user times.
The column Wall Time shows the total elapsed time from the start of the
acquisition to the end. This is the sum of the SiS Time and Child Time columns
plus any time in which CPU cycles were not consumed, such as when waiting
for I/O or when other processes were consuming the CPU.
The column # Sims shows the number of simulations performed. This is the
number of times the simulator was invoked. For most acquisitions there will be
one simulation. However, for constraints or when multiple operating conditions
are being captured together, there will be multiple simulations per acquisition.

SiliconSmart ACE User Guide 665

L-2016.03
Chapter 14: Command Reference
Query Commands

In the summary by host (second) table, the Wall Time and # Sims mean the
same as in the main table, but are summarized by host. Because SiliconSmart
utilizes the underlying functionality of the simulator to ascertain the execution
hosts, this feature will only work with certain simulators, notably HSPICE. No
table will be presented if the functionality is not available. The # Acqs is the
number of acquisitions performed. A single acquisition may correspond to
multiple simulations, as is the case with optimizations like setup and hold.
The third table contains the same columns as the main table, but summarized
by the type of measurement performed.
The -verbose switch includes the data in the main table displayed for each
arc as well as a total for each cell, including begin and end times for each arc's
execution.

Example 434
Characterization time report:

Measurement SiS Time Child Time Wall Time # Sims Start Time End Time
----------- ------- ---------- -------- ------ ------------
-------
delay__A__hl__IO__hl__ACQ_1
0.72 63.44 65.16 1 09/18/06 10:52:34
09/18/06 10:53:39
delay__A__hl__JTAGAZ__hl__ACQ_1
0.89 28.65 30.37 1 09/18/06 10:52:44
09/18/06 10:53:14
delay__A__hl__JTAGZI__hl__ACQ_1
0.95 61.89 63.48 1 09/18/06 10:52:45
09/18/06 10:53:48
delay__A__hl__PO__lh__ACQ_1
0.75 62.80 64.15 1 09/18/06 10:52:56
09/18/06 10:54:00

.
.
.

Example 435
zen__TN__lh__IO__lzh__ACQ_1
2.54 63.10 66.50 1 09/18/06 10:50:49
09/18/06 10:51:55
Total for cell MY_IO_PAD
174.30 9257.68 9608.03 223
------- ------ ------- -------- ------
Total 174.30 9257.68 9608.03 223

666 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Query Commands

Example 436
Summary by measurement type:
Measurement SiS Time Child Time Wall Time # Sims # Acqs
------------------------ --------- ---------- --------- ----
-- ---
delay 53.03 3035.90 3144.78 68 68
energy 75.36 5024.97 5192.76 122 122
leakage_power 0.14 7.39 8.09 1 1
zdis 3.27 251.21 264.48 16 16
zen 42.50 938.21 997.92 16 16

The report is formatted so that you can write it to a file and import it into a
standard spreadsheet or other analysis tool. For example, to import it into
Microsoft Excel, go to Data>Import External Data>Import Data. It will
recognize it as a fixed-width file and figure out the columns correctly. You can
then use the spreadsheet to compute percentages, averages, min/max, or
integrals.
The report_sim_stats command is provided to help diagnose cases where
SiliconSmart may not be performing as efficiently as possible.
The most common situation is a network issue that causes the total elapsed
time for a simulation to be much longer than the number of CPU seconds
indicate. This can be a result of slow access to disk storage, slow response
from SiliconSmart or the simulator's license server, or other processes sharing
the CPU. This case can be identified by comparing the sum of the SiS Time
and CPU Times to the Wall time for a given acquisition or cell. If the Wall Time
exceeds the sum of the CPU times by more than 10-20%, there is probably an
issue affecting the individual jobs.
One example of this occurs when the parameter simulation_tmpdir is set to a
network-mounted disk instead of a local disk (such as /tmp). This parameter
specifies the location used for all temporary files and the increased latency in
accessing network storage can reduce performance.
A second check to make is to compare the total wall time for an entire
characterization run against the elapsed time of the characterize command
itself. The sum of the wall times of the acquisitions measures the total time that
SiliconSmart was actively running the characterization tasks. If this total when
divided by the number of CPUs used (run_list_maxsize parameter) is more
than 10-15% less than the elapsed time for the characterize command, the
system is not running efficiently. This is usually due to not getting the total
number of CPUs desired, either because other users are competing for the

SiliconSmart ACE User Guide 667

L-2016.03
Chapter 14: Command Reference
Query Commands

same queue or because SiliconSmart is not receiving up-to-date information

about the queue from the load sharing system.

write_config_opts
This command writes all of the configuration options set at the global level to
the screen or a file.
Syntax
write_config_opts [-output file]
Arguments
-output
Specifies the name of a file to write the output to.
Description
The write_config_opts command is used to write out all of the
configuration options that have been set via the set_config_opt command
at the global level (outside a cell’s instance file). The display is in the form of
set_config_opt commands that can be reloaded by using the Tcl source
command. The commands are sorted by the option being set, though the order
of the individual settings is preserved. This command does not write out any
settings made by commands in a cell’s instance file.
The –output switch can be used to direct the output to a file. For example:
Example 437
write_config_opts –output configs_opts.tcl

See Also
clear_config_opts
set_config_opt
set_parameter
set_pintype_parameter

668 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

Processing Commands
The processing commands perform characterization and generate models or
reports. The following processing commands are available:
■
characterize
■
compare_library
■
delete_model
■
generate_datasheet
■
import
■
import_driver
■
model
■
precharacterize
■
qualify_library

characterize
This command performs the simulations needed to characterize timing, power,
and/or specification-specific electrical behaviors.
Syntax
characterize [-fast] [-match expression] cells
Arguments
-fast
Characterizes in parallel, via LSF, NC, or SunGrid job schedulers. This
option is enabled by default and does not need to be specified.
-match
This switch specifies to run selective simulations. It accepts wildcards in the
Tcl regexp format. For example:

Example 438
characterize –match {setup__*|hold__*} cells

cells
Cells to characterize.

SiliconSmart ACE User Guide 669

L-2016.03
Chapter 14: Command Reference
Processing Commands

Description
This command performs the simulations needed to characterize timing, and
power for a set of cells. The simulations associated with characterization can
be distributed over various machines on a network with load sharing software.
Distributed simulations can be controlled with the appropriate parameters in the
configure.tcl file.
Errors
An error message is displayed if set_location is not executed prior to
invoking the characterize command. An error message is also displayed if
the configure command has not been run. A warning message is displayed if
the cell control file has been modified more recently than the templates.
See Also
configure
generate_datasheet
model
report_drivers
set_location

compare_library
Performs structural comparison of two Liberty files. See Comparing Liberty
Files with compare_library for more information.
Syntax
compare_library -reference ref.lib -test test.lib
[-output_dir dir] [-tolerances] [-value] [-user_defined]
[-verbose] [-gui] [-all_points] [-compare_ccst_voltage]
[-sigma_error_1] [-max_rel_diff double] [-cells cells]
[-skip_cells cells] [-ignore_groups liberty_groups]
[-compare_values liberty_groups]
Arguments
[-reference ref.lib]
Reference library path.
[-test test.lib]
Test library path.
[-output_dir location]
Specifies the output directory location.

670 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

[-tolerances]
Prints current tolerance settings and exit.
[-value]
Compare numerical data values.
[-verbose]
Specifies verbose mode.
[-gui]
Displays a GUI to examine results after the comparison.
[-all_points]
Writes all points to .csv file. Expect a runtime increase.
[-compare_ccst_voltage]
Compare CCS-timing voltage from CCS output_current models.
[-sigma_error_1]
Use normalized 3-sigma difference formula to compute relative error of
sigma values.
[-max_rel_diff double]
Maximum absolute relative difference that is not an outlier (-1 to deactivate).
[-cells cells]
List of cells to compare.
[-skip_cells cells]
List of cells to skip.
[-ignore_groups groups]
List of Liberty groups to ignore. The special keywords
ccs|ccst|ccsn|ccsp|lvf are supported.
[-compare_values groups]
List of Liberty groups whose values are compared. The special keywords
ccs|ccst|ccsn|ccsp|lvf are supported.)
[-user_defined]
Includes user-defined attributes from the libraries in the comparison.

SiliconSmart ACE User Guide 671

L-2016.03
Chapter 14: Command Reference
Processing Commands

delete_model
Deletes specified Liberty models.
Syntax
delete_model -input_lib_path -output_lib_path [-nldm]
[-nlpm] [-ccs_timing] [-ccs_power] [-css_noise]
[-ecsm_timing] [-em] [-lvf]
Arguments
-input_lib_path
Input library path to .lib or .lib.gz.
-output_lib_path
Output library path.
-nldm
Delete nldm model.
-nlpm
Delete nlpm model.
-ccs_timing
Delete ccs_timing model.
-ccs_power
Delete ccs_power model.
-ccs_noise
Delete ccs_noise model.
-ecsm_timing
Delete ecsm_timing model.
-em
Delete electromigration model.
-lvf
Delete LVF data from Liberty models.

672 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

generate_datasheet
Generates an HTML data sheet describing a cells digital timing behavior.
Syntax
generate_datasheet [-output outdir] [-fast]
[-parameter_blocks param_block_list]
[-operating_condition opc_list]
[-merge] [-file filename] [cells]
Arguments
cells
One or more cell names or wildcard expressions selecting the cells to be
generated. The keyword all can be used to select all cells. The default is
all.
fast
Allows jobs to run in parallel using the LSF/Grid queue.
merge
Use this to merge all of the generated data sheets.
operating_condition
Specifies a list of operating conditions from which cells will be selected
(such as best and worst). Each operating condition corresponds to one
PVT in the characterization. If omitted, all available operating conditions are
used.
output
Specifies the target directory for all data sheet files. Defaults to the char_dir/
reports/datasheets directory.
parameter_blocks
Specifies one or more parameter blocks from which all report parameters
will be obtained. It defaults to ioreport.
file
Writes the generated html datasheet as filename. Use this only with the
-merge option.

SiliconSmart ACE User Guide 673

L-2016.03
Chapter 14: Command Reference
Processing Commands

Description
This command can succeed only if a valid characterization directory location is
active, otherwise an error will be returned. You can start using an established
characterization location by using the set_location command.
For multi-corner characterization points, the command will generate the content
for all the pvts in a file named multCorner.html. The data corresponding to each
pvt is written under the pvt heading.
Examples

Example 439
generate_datasheet -output teralib/ds –operating_condition typ

See Also
add_pin
model
report_drivers

import
This command imports a set of cells from a SiliconSmart characterization
directory or Liberty model into the current characterization directory.
Syntax
import [-liberty liberty_file]
[-netlist netlist_file] [-recognize] [-overwrite]
[-configure] [-fast] [-flatten] [-inouts inouts]
[-inputs inputs] [-outputs outputs] [-powers powers]
[-netlist_dir dir] [-no_copy 0|1] [-sensitization]
[-extension netlist_ext]
[-ideal_netlist_ext netlist_ext][-rechar]
[-state_independent] [-use_default_slews]
[-use_default_loads] [-use_constraint_seeds]
[-use_default_whens] [-compress_flops]
[-write_internal_nodes] [-noheader] [-skeleton]
[-nocellmodel] [cells]

674 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

Arguments
cells
One or more cell names or wildcard patterns that specify the cell or cells to
be characterized. If all is specified, all cells are characterized. The default
is all.
char_point
Specifies the path to a SiliconSmart characterization directory from which
the cell(s) will be imported.
clocks
When -recognized is used and -liberty is not used, you must set the
clock pin for the sequential cells with this option.
compress_flops
Identifies a flop with two latches. The default is to report two latches. This is
only used with -recognize.
configure
This option causes the configure.tcl to be overwritten with one containing
the default values from the SiliconSmart characterization directory. Any
changes to the existing configure.tcl will be lost.
extension
Specifies the file name extension for the file netlist. This is used when
generating the cell instance files when importing from a Liberty file. If used
with the -netlist_dir switch it also specifies the extension of the files to
be copied.
flatten
When -recognize is used and the SPICE netlist is hierarchical,
SiliconSmart needs this option to detect the correct port’s direction.
fast
Distributes the import process across the LSF/machine, based on the user’s
job scheduler settings.
grounds
When -recognize is used, SiliconSmart will use the ground names in the
configure.tcl file by default. You can define the ground names using this
option and this will override the ground names in configure.tcl for function
recognition.

SiliconSmart ACE User Guide 675

L-2016.03
Chapter 14: Command Reference
Processing Commands

hierarchical
Used only for back-annotation for memories. Specifies that the CDL netlist
is hierarchical; it will be flattened internally and then used for pruning and
finding the internal node.
ideal_netlist_ext
Specifies the file name extension for the ideal netlists. This is used for
electromigration (EM) characterization when performing CustomSim
Reliability Analysis (XA RA) to get current threshold information on resistive
wires. It is used with the -netlist_dir switch to specify the location
where the ideal netlist files can be found.
inouts
When -recognize is used, SiliconSmart will detect the inout ports. You
can define the inout ports using this option manually.
inputs
When -recognize is used, SiliconSmart will detect the input ports. You
can define the input ports using this option manually.
liberty
Specifies the path to a Liberty (.lib) file from which the cell(s) will be
imported.
model_file
When -recognize is used, SiliconSmart will read the process model files
defined in the configure.tcl file, compact it and generate a process model file
for function recognition automatically. You can set the process model file
manually for function recognition with this option.
netlist
Specifies the path to a SPICE netlist file to import a cell from.
netlist_dir
When used with the -liberty switch this option causes SiliconSmart to
copy a netlist file from the given directory for each cell to be imported. The
netlist file extension will be automatically determined unless specified with
the -extension switch.

676 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

no_buffer
When -recognize is used, SiliconSmart must modify some parts of the
netlist to detect the correct function using buffer insertion. The buffer will not
be inserted if this option is used.
-no_copy
By default, the SiliconSmart tool will create symbolic links to all of the
specified netlist files instead of copying the netlist files from the source to the
netlist’s directory. If you want to copy the cell netlist files over, specify
-no_copy 0 after the import -netlist_dir command.
nocellmodel
Indicates not to generate cell.lib(s) in charpt/models/liberty/cellmodels.
noheader
Indicates not to generate header.lib in charpt/models/liberty/cellmodels.
outputs
When -recognize is used, SiliconSmart will detect the output ports. You
can define the output ports using this option manually.
overwrite
Forces SiliconSmart to overwrite existing cell instance files. The default is to
update only the timing model data.
powers
When -recognize is used, SiliconSmart will use the power names in the
configure.tcl file. You can define the power names using this option and this
will override the power names in configure.tcl for the function recognition.
rechar
Specifies to automatically import the operating conditions, automatically
create pintypes, and create a skeleton rechar.tcl into the char_point/config
directory.
recognize
Reads the SPICE netlist(s) and detects the function(s) automatically.
sensitization
Specifies to read sensitization vector information from the reference Liberty
and automatically generate instance files with an add_user_stimulus
based on the sensitization vector information.

SiliconSmart ACE User Guide 677

L-2016.03
Chapter 14: Command Reference
Processing Commands

shared_loop_latches
There are some special kinds of sequential cells in which two latches share
a state loop. In this case, SiliconSmart generates the state tables using this
option. Used with -recognize.
skeleton
For use with recharacterization, discards all timing, constraint,
internal_power, and CCS timing/power/noise tables from the reference
Liberty.
state_independent
Configures only a single state for the arc. By default, the import command
configures the instance files for imported cells to characterize all of the arc
states (when conditions) found in the imported timing models.
use_constraint_seeds
Enables the SiliconSmart tool to use constraint data in an imported library
as seeds.
use_default_loads
Configures the instance files for imported cells to use the default slew
ranges from the pin type for each pin. By default the exact slew points from
the transition tables for the timing models are preserved.
use_default_slews
Configures the instance files for imported cells to use the default slew
ranges from the pin type for each pin. By default the exact slew points from
the transition tables for the timing models are preserved.
use_default_whens
Suppresses the generation of set_config_opt commands setting
state_partitions settings. This differs from -state_independent, which
sets state_partions to 1 for all arcs in the original .lib file.
write_internal_nodes
Write corresponding SPICE nodes for the internal and output nodes. Use
together with -recognize.
Description
This command imports one or more cells from a SiliconSmart characterization
directory, Liberty file, or SPICE netlist. In order for a cell to be used with
SiliconSmart it must have an instance file which describes its behavior, a timing

678 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

model in Liberty format, and a SPICE netlist. These files can be imported from
a variety of sources.
The -configure switch can be used with to generate a configure.tcl file
containing the configuration information from SiliconSmart. This is a convenient
way to import settings such as which simulator to use and how to setup the
load sharing system.
The -liberty switch causes SiliconSmart to load the library and import cells
from it. The library provides enough information to generate the cell's instance
file and the timing models. The instance file is only created if one does not
already exists. The timing model is always overwritten. The SPICE netlist must
be copied in use the -netlist_dir switch or by manually copying the files to
the char_dir/netlists directory. SiliconSmart will attempt to automatically
determine the extension of the cell netlists in the directory provided. You can
specify an extension with the -extension switch.
The -netlist switch imports a single SPICE netlist and copies it into the
char_dir/netlists directory. A template of an instance file is created with the pins
from the netlist. You must fill in the behavioral information and import a timing
model for the cell using the -liberty switch.
By default SiliconSmart will not overwrite a cell's instance file when importing a
cell because these files often contain user customizations. The -overwrite
switch overrides this behavior and causes the file to be overwritten.
The remaining options, -state_independent, -use_default_slews,
-use_default_loads, and -use_constraint_seeds control how each
cell's instance file is generated when importing from SiliconSmart or a Liberty
file. The -state_independent option ignores imported arc states (when
conditions) and characterizes the arc according to only one state. This requires
less characterization time but is less accurate. The default is state dependent
and preserves each of the arc states (when conditions) in the instance file.
When the cell is characterized, each arc will be characterized at each of these
states.
SiliconSmart also defaults to preserving the slew and load indexes found in the
transition tables (rise_transition, fall_transition, etc.) of the timing
data. This ensures that the I/O data is characterized at the same points. If you
do not wish to preserve this data and instead use the ranges specified by the
pin type of each pin, use the switches -use_default_slews and/or
-use_default_loads.

SiliconSmart ACE User Guide 679

L-2016.03
Chapter 14: Command Reference
Processing Commands

The SiliconSmart tool will use the imported setup and hold tables as seeds to
the setup and hold measurements for faster characterization and more
accurate data.
Examples
This command can be used to reimport the timing models from the
characterization directory without touching the rest of the setup. This is useful
when the cells have been recharacterized for a different process model or at a
different voltage or temperature. The -configure command would usually be
omitted to avoid overwriting the configure.tcl file.
Cells can also be imported from a Liberty file. This command imports all of the
cells from a Liberty model and copies the netlists with the extension .cir out of
an existing directory:
Example 440
import -liberty lib90nm -netlist_dir lib90nm_netlists -extension
.cir

See Also
create
set_location

import_driver
This command imports a cell for use as an active driver.
Syntax
import_driver cell –netlist netlist -input_pin pin
-output_pin pin [-inverting] [-ground_pin] [-supply_pin]
[-characterize]
Arguments
cell
Name of the cell to be imported.
-input_pin
Specifies the name of the input pin on the driver cell. The name must match
a pin in the SPICE netlist.
-inverting
Specifies that an inverter is being used as the driver.

680 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

-netlist
Specifies the path to the cell netlist file.
-output_pin
Specifies the name of the output pin on the driver cell. The name must
match a pin in the SPICE netlist.
-characterize
Reloads and immediately characterizes the driver for all pin types that
reference the driver and for the active_pvts. That driver will not be
subsequently auto-characterized; it will only be characterized by a
subsequent import_driver command. If a driver is required for a pin
type/pvt combination which has not been characterized, the table from
another existing pin type/pvt combination will be used.
-ground_pin
Specifies a ground pin.
-supply_pin
Specifies a supply pin.
Description
The import_driver command imports a cell to be used as an active driver
model. Active driver cells are used to apply realistic waveforms to the inputs of
a cell-under-test. The –netlist option specifies the SPICE netlist file of the
driver cell. The –input_pin and –output_pin options specify the input and
output pins, respectively. When the cell is used as a driver, stimulus is applied
to the input pin and the output pin is connected to the input of the CUT.
To use a cell as an active driver, set the pin type parameter driver to the
name of the imported cell. When characterizing a CUT, SiliconSmart uses an
instance of the driver cell to generate the input waveforms. SiliconSmart
precharacterizes the driver cells to determine the necessary capacitive loading
to generate the necessary output slew rate at each require PVT combination.
The parameter driver_load_steps controls the resolution of this
precharacterization step.
See Also
add_pin
import

SiliconSmart ACE User Guide 681

L-2016.03
Chapter 14: Command Reference
Processing Commands

model
This command publishes the characterized data in the selected format.
Distributed simulations can be controlled with the appropriate parameters in the
configure.tcl file.
Syntax
model [-timing] [-ecsm] [-ccs] [-ccs_noise]
[-em] [-power] [-si] [aocv] [pocv] [lvf]
[-create_new_model] [-liberty | -verilog | -ibis]
[-lib_name lib_name] [-operating_condition pvt_name]
[-split] [-library_type (best | typ | worst)]
[-leakage_power_calc calc] [-skeleton]
[-output filename | -filename_path]
[-nocompact] [-no_state_table] [-no_backslash][cells]
Arguments
aocv
Enables AOCV model generation.
ccs
Includes CCS current waveform data in the generated model. (Applies to the
Liberty format only and implies -timing.)
ccs_noise
Includes CCS-noise models in the resulting .lib model. The model command
must either have the -timing switch as well or have an existing, imported
.lib with the appropriate time arcs.
ccs_power
Enables CCS power modeling.
ccs_va
Writes out the Synopsys CCS-VA model.
compact_ccs
Enables CCS compact model generation.
create_new_model
Creates a new model without any existing timing or power data or attributes.
The default is to use the imported Liberty file as a starting point for modeling.
If no Liberty file has been imported, a new model is created automatically.

682 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

ecsm
Includes ECSM voltage waveform data in the generated model. (Applies to
the Liberty format only and implies -timing.)
em
Includes electromigration (EM) data in the generated model.
ibis
Specifies the generation of IBIS I/O electrical models.
leakage_power_calc
Selects the method of determining the default cell leakage power value. The
value calc can be best, typ, or worst. The default is to use the type
specified by -library_type.
lib_name
Specifies a user-specified library name as a prefix to the pvt name to
construct a full library name. The library name will be lib_name_pvt_name,
and you will find the Liberty header as library(lib_name_pvt_name).
liberty
Specifies the Liberty modeling format (default).
library_type
Specifies the type of library to be generated. Enables SiliconSmart to select
the appropriate default arc. Possible values are best, typ, and worst.This
switch controls the how the default arcs are selected and how the cell
leakage power is computed. See Default Arc Modeling for more information
on using this switch.
lvf
Enables LVF model generation.
no_state_table
Removes the state table explicitly from .lib for any cell.
no_backslash
Specifies not to break a line mid-line with a backslash.

SiliconSmart ACE User Guide 683

L-2016.03
Chapter 14: Command Reference
Processing Commands

nocompact
Use this option if you want to merge multiple Liberty files later using the
merge command and get a compact CCS model or CCS-VA model. Use this
option only with CCS, CCS-VA or CCS power. For more details, see the
merge command.
nomerge
Specifies not to merge the final cell .libs into a single, final .lib file (the
default). If both -nomerge and -output switches are used, the -output
switch will be ignored.
operating_condition
Specifies one or more operating conditions for which models are to be
generated. If multiple operating condition names are specified, they must be
in a Tcl list.
output
Specifies a prefix for the model output file, the file extension and, for the
Liberty format, the operating condition name.
pocv
Enables POCV model generation.
power
Includes power data in the generated model (default).
recharacterize
Default mode; writes out the model based on user-provided Liberty model.
si
Includes the Liberty noise constructs in the generated model.
skeleton
For use with recharacterization, discards all timing, constraint,
internal_power, and CCS timing/power/noise tables from the reference
Liberty.
split
Splits the Verilog model files into separate files for each cell in a library. This
will create new directories to contain the cell HDL model files, for example:
<charpt>/models/verilog/cells

684 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

The original Verilog file that contains the entire set of library HDL models still
remains as before.
timing
includes timing data in the generated model (default).
verilog
Specifies the generation of Verilog timing models, which include the
interface of the cell and the specify blocks containing the timing arcs.
Description
SiliconSmart is capable of characterizing many aspects of a cell’s behavior,
including timing, power, and signal integrity. Not all of the data is appropriate for
all formats and all tool flows. Select the data you want to characterize with the
configure command. The model command reads this data once
characterization is complete and publishes it in the selected format.
You can select a subset of characterized data to publish with the switches
–timing, -ecsm, -ccs, -power, and –si. These switches can be used in
any combination to turn on the specified type of data. If you have not configured
the cell for a particular type of data or the data does not apply to a particular
cell, the switch will be ignored. The switches –ecsm and –ccs enable voltage
or current waveforms that are extension to the standard timing models.
Enabling either of these switches implicitly enables –timing as well.
Both -ecsm* and -ccs* can be modeled at the same time in the same
Liberty with one command, allowing all views (NLDM, NLPM, CCST, CCSN,
CCSP, ECSMT, ECSMP) to be modeled at once in one Liberty.
If none of the characterization data switches (-timing, -power, and so on)
are specified, then –timing and –power are enabled by default. If any of the
switches are specified, then none are on by default. This means that if you want
timing, power, and SI constructs all three switches must be specified.
By default, SiliconSmart checks for an imported Liberty model for each cell
and, if present, uses it as a starting point. This method of operation is referred
to as recharacterization because any data characterized by SiliconSmart will
replace the data in the original Liberty model, but the rest of the contents of the
model remain untouched. Thus you can model one type of data without
affecting the other parts of the model.

SiliconSmart ACE User Guide 685

L-2016.03
Chapter 14: Command Reference
Processing Commands

Note: The signal integrity constructs in Liberty are added to existing

timing arcs. This means that when the –si switch is used, the
timing arcs must either come from the imported Liberty model via
recharacterization or the –timing switch must be used. If no
timing arcs are present the SI data will not appear in the model.

Liberty models are written to the char_dir/models/liberty directory and are

named liberty_op_cond.lib where op_cond is the name of one or more
operating conditions being modeled.
The IBIS format is used to model the detailed electrical behavior of I/O pads.
SiliconSmart supports version 4.1 of the IBIS format and will characterize the
IV curves, VT curves, and differential launch delay of the cells. The resulting
IBIS models are written to the directory char_dir/models/ibis.
The –verilog switch is used to write out Verilog timing models. Both formats
are used with timing data from a static timing analyzer that is back annotated
onto the VHDL or Verilog simulation. Because the timing results are to be back
annotated, the models themselves only include unit or zero delays. See the
HDL Model Generation section for more information.
The –library_type switch is used to specify whether the Library is a worst-
case, typical, or best-case library. This switch controls the how the default arcs
are selected and how the cell leakage power is computed. See Default Arc
Modeling for more information.
Examples
To generate a Liberty model with timing, power, and SI data, use the command:
Example 441
model –timing –power –si

Because Liberty is the default format, the –liberty switch is optional.

Alternatively, if a Library with good timing and power data has already been
imported, SI data can be added to this library without affecting the timing and
power data with the following command:
Example 442
model –si

Verilog timing models can be generated with the following command:

Example 443
model –verilog

686 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

IBIS models can contain either one or three operating conditions. When three
operating conditions are to be modeled, they must be specified with the
–operating_condition switch as a Tcl list. The order is best, typical, worst.
For example:
Example 444
model –ibis –operating_condition {typ_pvt best_pvt worst_pvt } \
–output iopads IOPAD*

This command causes the file char_pt/models/ibis/iopads.ibis to be created

and contains all of the cells starting with IOPAD.
See Also
characterize
configure
create_operating_condition

precharacterize
This command reduces characterization time by binning or grouping states with
similar timing or power characteristics, and by multi-corner load ranging.
Syntax
precharacterize [-reanalyze] [-fast][-report report_file]
cells
Arguments
-fast
The analysis step in precharacterization will be parallelized using the job
scheduler specified by the user (LSF/GRID/NC).
-reanalyze
Precharacterizes without executing the simulations. Intended for cases
where precharacterization parameters are changed to obtain, for example,
different binning arrangements from the same data. An error is returned if
simulation results are not present when the command is invoked.
-report
Creates a report in the specified file when precharacterization is completed.
The report contains binning information for each arc in an easy-to-read
format.

SiliconSmart ACE User Guide 687

L-2016.03
Chapter 14: Command Reference
Processing Commands

Description
This command should be run before the configure command. It produces data
that the configure command will use to generate the characterization tests.
Three parameters, prechar_binning_timing,
prechar_binning_power, and prechar_binning_constraints
configure precharacterization for timing, power and constraints respectively.
Possible values for each are all, the default, for generating all bins; best, for
generating only the best case; worst, for selecting only the worst case; and
none, to turn off binning for that measurement type. The all option is disabled
for constraint binning. best and worst are provided for those who would like
to use the best and worst cases for each arc in their analysis. The default value
for constraints is none.
Example 445
set_parameter prechar_binning_timing {none | all}
set_parameter prechar_binning_power {none | all}
set_parameter prechar_binning_constraints {none | worst | best}

The parameter prechar_binning_method directs measurement coverage

of timing and energy state binning results. It has two possible values: all-by-
timing and independent. all-by-timing directs SiliconSmart to use
only timing simulations to bin timing and power states. independent, the
default value, uses timing simulations for binning timing states and power for
power states.
Example 446
set_parameter prechar_binning_method {independent | all-by-
timing}

Another configuration parameter, prechar_autorange_load, turns the

precharacterization of maximum load autoranging on or off. Possible values are
true and false. The default is true.
The parameter prechar_binning_max_bins directs the state binning
functionality to group states into the specified number of bins. The default is 3,
and 0 means heuristically find the best fitting number of bins, with an absolute
maximum of 10 bins.
The parameter prechar_keep_intermediate_files directs SiliconSmart
to avoid deleting intermediate files in the runtime directory after simulations are
run, for analysis. Possible values are true and false. The default is false
(delete intermediate files).

688 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Processing Commands

See the Precharacterization section for a complete explanation of

precharacterization.
See Also
characterize
configure

qualify_library
The qualify_library feature enables validation of libraries generated by
the SiliconSmart tool to ensure their correctness when consumed by
downstream tools.
The qualify_library feature is built on top of the capabilities in the Library
Compiler tool from Synopsys. It supports validation of library files and provides
the following key features:
■
Faster cell-level distributed processing, allowing jobs to be run on compute
farms.
■
A comprehensive HTML-based interface for presenting and analyzing
results, including graphs and histograms.
See Qualifying the Liberty File with qualify_library for more information on
using this feature.
Syntax
qualify_library test.lib [-aggressor string]
[-sim_options string] [-cells list_of_strings]
[-check list_of_strings] [-slews list_of_strings]
[-loads list_of_strings] [-power_rails list_of_strings]
[-report_only] [-finesim] [-no_zip] [-first_load] string
Arguments
[-aggressor string]
Aggressor cell name for glitch analysis.
[-sim_options string]
User-specified simulator options line.
[-cells list_of_strings]
List of cells to qualify.

SiliconSmart ACE User Guide 689

L-2016.03
Chapter 14: Command Reference
Memory Commands

[-check list_of_strings]
List of additional checks to run (index).
[-slews list_of_strings]
Slew points to use for correlation (mid, max, all, <fractions>).
[-loads list_of_strings]
Load points to use for correlation (mid, max, all, <fractions>).
[-power_rails list_of_strings]
Voltage supply names and pairs for non-pg libraries.
[-report_only]
Only compile results from existing data.
[-finesim]
Use FineSim (default is HSPICE).
[-no_zip]
Do not gzip cell libraries.
[-first_load]
Include first load (not included by default).
string
Input library name.

Memory Commands
The following sections describe memory commands:
■
Tcl Memory Commands
■
Functional Mode Commands
■
Test Mode Commands
■
General Memory Commands
■
Scan Chain Commands

690 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

Tcl Memory Commands

The following Tcl commands can be used in a template file:
■
set_memory_type
■
set_memory_name
■
set_mem_internal_node
■
set_maximum_addressable_word
■
set_rom_code_file
■
set_separate_statetable_mode
■
set_bypass_mode
■
set_pipeline_mode
■
set_writethrough_mode
■
set_bist_mode
■
set_extramargin_adjustment_mode
■
set_maskablewrite_enable_control_output
■
set_light_sleep_enable
■
set_deep_sleep_enable
■
set_shut_down_enable
■
set_asynchronous_reset
■
set_register_scan_reset
■
create_readwrite_port

set_memory_type
Sets the memory type.
Syntax
set_memory_type memory_type
Arguments
memory_type
Memory type, which can be one of single_port_ram,
multi_port_ram, or single_port_rom.

SiliconSmart ACE User Guide 691

L-2016.03
Chapter 14: Command Reference
Memory Commands

set_memory_name
Sets the memory name. This command is required when import -template
is used without a Liberty file.
Syntax
set_memory_name memory_name

set_mem_internal_node
Defines mem_internal node, which is used during constraint measurement.
This command is also used to define a dummy node if constraint measurement
is not required.

set_maximum_addressable_word
The maximum possible memory address is determined by the width of the
address bus of the memory. However, when the memory size is less than the
maximum possible address, the user has to manually set the
default_bus_value_1 parameter in the configure.tcl file for the concerned
pin to the size of memory. This command will perform this automatically.
Syntax
set_maximum_addressable_value value
Arguments
value
Any integer between 0 to pow (2,width of address bus) -1.
Description
This command is useful for single_port_ram, multi_port_ram and for
single_port_rom when the rom code file is not present.
For single_port_rom, when the rom code file is present, it automatically
sets the default_bus_value_0 and default_bus_value_1 parameters
in configure.tcl for the concerned pin type.
The value can be any integer between 0 to pow (2,width of address bus) -1. If
the value given to the command is 0 or equal to the maximum possible
address, the following warning message is generated and the program
continues:
"The maximum addressable word for this memory is assumed to be
<address value>. If a different value is to be used please change
in configure.tcl"

692 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

If the value given to the command is greater than the maximum possible
address, the program exits with the following error message:
"Maximum addressable word <add value> can not be greater than
maximum possible word <add Val> ".

default_address_value_1 is added to the correct pin type only when the

given value is less than the maximum possible address and the memory type is
single_port_ram, multi_port_ram, or single_port_rom without the
memory template file.
For single_port_ram, multi_port_ram, and single_port_rom with no
rom code file, when maximum addressable memory is less then maximum
possible address, new pin types are created during the import stage,
irrespective of the fact whether import is done with or without the Liberty file.

set_rom_code_file
This command sets the rom code file.
Syntax
set_rom_code_file file_name
Description
single_port_rom is supported through template flow. When the memory
type is single_port_rom, the rcf file associated with the ROM will be parsed
to find out the proper target bits, default lower address values, and default
higher address values. These values are being set correctly in the configure
file.
When the rcf is not specified, the user has to modify the configure file to set the
target bits, default higher address values, and default lower address values
appropriately.
For ROM, if the rcf file is specified and the Liberty file is given as input to the
import step, then for every pin type present in the Liberty file, a new pin type is
created in the configure.tcl file.
For RAMs and even for ROMs with no rcf file, a new pin type is created in
configure.tcl only if configure.tcl did not contain a pin type definition of the same
name as found in the Liberty file.

set_separate_statetable_mode
This command decides whether separate state tables will be generated for
individual ports present in a multi-port memory or not.

SiliconSmart ACE User Guide 693

L-2016.03
Chapter 14: Command Reference
Memory Commands

Syntax
set_separate_statetable_mode on|off
Description
For single port memory this command does not have any significance.
For multi-port memory, when separate state table mode is on, for each
individual port a separate state table is created.
■
A single state table for each individual port is created when the ports do not
support pipe line mode.
■
If the port under consideration supports pipeline mode and supports write
operation, then three separate tables (one for write, one for normal read and
one for pipeline read) are created for the port.
■
If the port supports pipeline mode but only the read operation, then only two
tables (one for normal read and another for pipeline read) are created for the
port.

set_bypass_mode
This command sets the bypass mode. When the bypass mode is ON, during
write operation the data is directly written into output without being written into
memory.
Syntax
set_bypass_mode on|off

set_pipeline_mode
This command sets the pipeline mode. When the pipeline mode is ON, the
output from memory will go to output and the last content of output will go to
pipeline output.
Syntax
set_pipeline_mode on|off

set_writethrough_mode
This command sets the write-though mode. When the write though mode is ON
data is written to both memory and output.
Syntax
set_writethrough_mode on|off

694 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

set_bist_mode
This command sets the BIST mode. When the bist mode is ON, memory can
operate in either test mode or functional mode depending on bist enable signal
value. When the bist mode is OFF, the memory operates in functional mode.
Syntax
set_bist_mode on|off

set_extramargin_adjustment_mode
This command sets the extra margin adjustment mode. If the extra margin
adjustment mode is ON, the extra margin adjustment bus is replaced by pins
corresponding to every bit of the extra margin adjustment bus in the generated
instance file.
Syntax
set_extramargin_adjustment_mode on|off

set_maskablewrite_enable_control_output
This command can be used only for a memory with both maskable write-enable
and write-through modes.
Syntax
set_maskablewrite_enable_control_output on|off
Description
With write through mode ON and a maskable write enable signal present, a
memory may behave in one of two different ways:
■
First case — the memory output changes (write-through) only when data is
written into the memory cells. The output is unchanged when data bits are
masked. For this memory the value of the
set_maskablewrite_enable_control_output parameter is set to
ON.
■
Second case — can occur in certain memories where the output changes
(write-through is always enabled) whether maskable write-enable is active
or not. The output will change even when data bits are masked during
writing. In this case the value of the parameter
set_maskablewrite_enable_control_output parameter is set to
OFF.

SiliconSmart ACE User Guide 695

L-2016.03
Chapter 14: Command Reference
Memory Commands

set_light_sleep_enable
This command sets the light slip enable signal associated with the memory.
When light sleep enable signal is in active state, the memory goes to light sleep
mode. During normal operation of the memory the light sleep enable signal
should be in inactive state.
Syntax
set_light_sleep_enable name [–width width] –active L|H
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Active value of the signal. Can be L or H.

set_deep_sleep_enable
This command sets the deep slip enable signal associated with the memory.
When deep sleep enable signal is in active state and shut down enable signal
is in inactive state, the memory goes to deep sleep mode (no change in
memory cells and output goes to ‘0’ state). During normal operation of the
memory the deep sleep enable signal should be in inactive state.
Syntax
set_deep_sleep_enable name [–width width] –active L/H
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Active value of the signal. Can be L or H.

696 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

set_shut_down_enable
This command sets the shut down enable signal associated with the memory.
Syntax
set_shut_down_enable name [–width width] –active L/H
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Active value of the signal. Can be L or H.
Description
When shut down enable signal is in active state the memory goes to shut down
mode (data content of memory cells is unknown and output goes to ‘0’ state).
During normal operation of the memory the shut down enable signal should be
in inactive state.
For a memory, when light sleep enable, deep sleep enable, and shut down
enable signals are present, a separate state table of the following form is
created to indicate the behavior of memory when each of these signals is in
active state. As mentioned earlier, for normal function of the memory, each of
these signals should be present in inactive state.
Examples
For the below example, for each of these signals, H is the active state logic
value:
Example 447
add_table {
LS DS SD ME : mem mem_2 iqa : mem mem_2 iqa
- - H H : - - - : x x0
- H L H : - - - : n n 0
}

set_asynchronous_reset
This command sets the asynchronous reset signal associated with the
memory. When asynchronous reset signal is in active state the memory resets
(no change takes place in the data content of memory cells is unknown but

SiliconSmart ACE User Guide 697

L-2016.03
Chapter 14: Command Reference
Memory Commands

output goes to L state). During normal operation of the memory the

asynchronous reset signal should be in inactive state.
Syntax
set_asynchronous_reset name [–width width] –active L/H
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Active value of the signal. Can be L or H.

set_register_scan_reset
This command sets the register scan reset pin.
Syntax
set_register_scan_reset name –active r/f
Arguments
name
Name of the register scan reset pin.
-active
Indicates whether the pin is active at the rising (r) or falling (f) edge.
Examples
When this pin is present, one additional state table is created in the instance
file which looks like:
Example 448
add_table {
RSCRST : int_rscrst : int_rscrst
f : - : H
- : - : n
}

In the above table, RSCRST is the pin which will be specified using the
set_register_scan_reset command. int_rscrst is an internal pin
which will be present in all the state table entries which correspond to write

698 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

operation. That means the write operation will be performed only when the
value associated with int_rscrst is H.

create_readwrite_port
This is a mandatory command in the template. A memory can have either a
single port or multiple ports to access data. Each of these ports can have their
very own address/data or other enable signals. This command is needed to
bring together all of the signals which are associated with a particular port. This
allows the template generator to recognize how the pins/buses are related to
each other. In case of memories with multiple ports, more than one
readwrite_port can be present in the memory template.
Syntax
create_readwrite_port port_name
Arguments
port_name
A string.

Functional Mode Commands

The memory can either operate in functional mode or test mode. The following
commands are to be used to set up the memory to operate in functional mode:
■
set_clock
■
set_address_bus
■
set_data_bus
■ set_asynchronous_write_through
■
set_asynchronous_write_through_logic
■ set_output_enable
■
set_read_enable
■
set_write_enable
■
set_chip_enable
■
set_memory_enable
■
set_bypass_enable
■
set_writethrough_enable

SiliconSmart ACE User Guide 699

L-2016.03
Chapter 14: Command Reference
Memory Commands

■
set_bist_enable
■
set_pipelinemode_enable
■
set_extramargin_adjustment_enable
■
set_extramargin_adjustment
■
set_testclk_enable name
■
set_maskable_enable_control_output
■
set_maskablewrite_enable
■
set_data_output
■
set_pipeline_output

set_clock
This command sets the clock associated with a port.
Syntax
set_clock pin_name -port port -active r/f
Arguments
pin_name
Name of the clock.
-port
Port name of the clock.
-active
Indicates whether the clock is active at the rising (r) or falling (f) edge.

set_address_bus
This command sets the address bus associated with the port. More than one
address bus can be associated with a single port. Each address bus should be
specified with a separate set_address_bus command.
Syntax
set_address_bus name [-width width] -port port
Arguments
name
Name of the address bus.

700 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

[-width]
Optional argument with default value 1. Width of the address bus.
-port
Port name of the address bus.

set_data_bus
This command sets the data bus associated with the port. More than one data
bus can be associated with a single port. Each data bus should be specified
with a separate set_data_bus command.
Syntax
set_data_bus name [-width width] -port port
Arguments
name
Name of the data bus.
[-width]
Optional argument with default value 1. Width of the data bus.
-port
Port name of the data bus.

set_asynchronous_write_through
This command sets the asynchronous write through signal associated with the
port. More than one asynchronous write through signal can be associated with
a single port. Each asynchronous write through signal should be specified with
a separate set_asynchronous_write_through command.
Syntax
set_asynchronous_write_through name [-width width] -active
L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.

SiliconSmart ACE User Guide 701

L-2016.03
Chapter 14: Command Reference
Memory Commands

-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.
Examples
When a asynchronous write through signal goes to the active state, the output
either assumes the data bus value or maskable write enable value.
This functionality is represented with the help of the following two tables:
The following table depicts that when AWT is high, the data (D) goes to the
output register iqa asynchronously:
Example 449
add_table {
int_rscrstBISTMODEBISTECLKTCLKTDD AWT : iqa: iqa
H L L - - - H/L H : - : H/L
H L H - - H/L - H : - : H/L
- - - - - - - L : - : n
}

The following table depicts that when AWT is high, the write-enable (WEM) and
test write enable (TWEM) goes to the output register iqwem asynchronously.
Example 450
add_table {
int_rscrstBISTMODEBISTECLKTCLKWEMTWEMAWT: iqwem : iqwem
H L L - - H/L - H : - : H/L
H L H - - - H/L H : - : H/L
- - - - - - - L : - : n

The function associated with output Q looks like:

Example 451
add_function Q { (iqa&AWT) | iqwem & AWT) | iq) }

set_asynchronous_write_through_logic
This command specifies the logic to be used while calculating the
asynchronous write through function.

702 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

Syntax
set_asynchronous_write_through_logic logic_operation
Arguments
logic_operation
Name of the logic operation, which can be one of OR, AND, XOR, NOR, NAND
or XNOR. If no set_asynchronous_write_through_logic command
is present in a template file, then OR will be used as the logic operation.
Description
As specified in the set_asynchronous_write_through command, when
asynchronous write through signal goes to active state, the output either
assumes the data bus value or maskable write enable value. Using the same
notation as used for the set_asynchronous_write_through command,
the add_function command takes the following form:

Example 452
add_function Q { ((iqa<asynchronous write through logic> iqwem)&
AWT)) | iq) }

set_output_enable
This command sets the output enable signal associated with the port. More
than one output enable signal can be associated with a single port. Each output
enable signal should be specified with a separate set_output_enable
command.
Syntax
set_output_enable name [–width width] –active L/H –port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

SiliconSmart ACE User Guide 703

L-2016.03
Chapter 14: Command Reference
Memory Commands

Examples
For synchronous memory (for which CLK is present), when the signal is in
active state, the normal read and write operation takes place on the port. When
the signal is in inactive state the output goes to hiZ state. The state table will
not contain a row corresponding to inactive value of output enable signal rather
a add_function construct will be added to the instance file to reflect the
correct behavior. If Q is the primary output and OEN is the output enable signal
(with active value of L) the following line will be added to the instance file:
Example 453
add_function Q iqa -hi_z OEN

For asynchronous memory (for which CLK is not present) output enable signal
comes into picture only during read operation. When the output enable signal is
in active state, the normal read operation takes place. When the output enable
signal is in inactive state the output goes to hiZ state. This functionality where
output goes to hiZ state, is depicted through state table.

set_read_enable
This command sets the read enable signal associated with the port.
When the signal is active the read operation takes place on the port. More than
one read enable signal can be associated with a single port. Each read enable
signal should be specified with a separate set_read_enable command.
Syntax
set_read_enable name [-width width] –active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

704 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

set_write_enable
This command sets the write enable signal associated with the port.
When the signal is active the write operation takes place on the port. More than
one write enable signal can be associated with a single port. Each write enable
signal should be specified with a separate set_write_enable command.
Syntax
set_write_enable name [-width width] –active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_chip_enable
This command sets the chip enable signal associated with the port.
When the signal is active the memory remains active and read and write
operations can take place on the port in functional mode. More than one chip
enable signal can be associated with a single port. Each chip enable signal
should be specified with a separate set_chip_enable command.
Syntax
set_chip_enable name [-width width] –active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.

SiliconSmart ACE User Guide 705

L-2016.03
Chapter 14: Command Reference
Memory Commands

-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_memory_enable
This command sets the memory enable signal associated with the port.
When the signal is active the memory remains active and read and write
operations can takes place on the port in functional mode. More than one
memory enable signal can be associated with a single port. Each memory
enable signal should be specified with a separate set_memory_enable
command.
Syntax
set_memory_enable name [-width width] –active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_bypass_enable
This command sets the memory enable signal associated with the port.
When the signal is active the memory operates in bypass mode while operating
in functional mode. More than one bypass enable signal can be associated with
a single port. Each bypass enable signal should be specified with a separate
set_bypass_enable command.
Syntax
set_bypass_enable name [-width width] –active L/H -port port

706 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_writethrough_enable
This command sets the write through enable signal associated with the port.
When the signal is active the memory operates in write through mode while
operating in functional mode. More than one write through enable signal can be
associated with a single port. Each write through enable signal should be
specified with a separate set_writethrough_enable command.
Syntax
set_writethrough_enable name [-width width] -active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_bist_enable
This command sets the memory enable signal associated with the port.

SiliconSmart ACE User Guide 707

L-2016.03
Chapter 14: Command Reference
Memory Commands

When the signal is active the memory operates in test mode. When the
memory operates in functional mode this signal remains inactive. More than
one bist enable signal can be associated with a single port. Each bist enable
signal should be specified with a separate set_bist_enable command.
Syntax
set_bist_enable name [-width width] –active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_pipelinemode_enable
This command sets the memory enable signal associated with the port.
When the signal is active the memory operates in pipeline mode while
operating in functional mode. More than one pipeline mode enable signal can
be associated with a single port. Each pipeline mode enable signal should be
specified with a separate set_pipelinemode_enable command.
Syntax
set_pipelinemode_enable name [-width width] –active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.

708 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

-port
Port name of the signal.

set_extramargin_adjustment_enable
This command sets the memory enable signal associated with the port. This
signal does not have any significance as far as state table is concerned but
comes into picture in when conditions.
Syntax
set_extramargin_adjustment_enable name [-width width]
-active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_extramargin_adjustment
This command sets the extra-margin adjustment bus associated with the port.
More than one extra margin adjustment signal can be associated with a single
port.
Each extra margin adjustment signal should be specified with a separate
set_extramargin_adjustement command. The extra margin adjustment
pin does not take part in state table. When extra margin adjustment mode is ON
(set_extramargin_adjustment_mode ON), in the generated instance file
the extra-margin adjustment bus is replaced by pins corresponding to every bit
of the extra-margin adjustment bus.
Syntax
set_extramargin_adjustment name [–width width] -port port

SiliconSmart ACE User Guide 709

L-2016.03
Chapter 14: Command Reference
Memory Commands

Arguments
name
Name of the bus.
[-width]
Optional argument with default value 1. Width of the bus.
-port
Port name of the bus.

set_testclk_enable name
This command sets the test CLK enable pin. When test clock enable signal is
active, testmode clock is selected (basically used when memory operates in
test mode).
When test clock enable signal is not active then CLK is selected (basically used
when memory operates in functional mode).
Syntax
set_testclk_enable name –active L/H -port port
Arguments
name
Name of the clock.
[-width]
Optional argument with default value 1. Width of the clock.
-port
Port name of the clock.

set_maskable_enable_control_output
This command is only necessary when the maskable write enable signal is
present and write through mode is ON. When write through mode is ON and the

710 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

maskable write enable signal is present, the memory may behave in one of two
different ways.
1. When write through mode is ON and maskable write enable signal is active,
then during the write operation the data will be written to both memory and
output.
2. When write through mode is ON and maskable write enable signal is not
active then during the write operation data will not be written into memory
but it will be written to output.
As shown above, when write through mode is ON, the output is not dependent
on the maskable write enable signal state.
When an OFF value is given to set_maskablewrite_enable_output, the
behavior of memory is as described above. When an ON value is given, the
memory behaves in the following way:
When write through mode is ON and the maskable write enable signal is active,
then during write operation the data will be written to both memory and output,
which is the same behavior as before. However, when write through mode is ON
and the maskable write enable signal is not active, then during write operation
data will not be written into memory or output.
With this command, when write through mode is ON, the output is dependent on
the maskable write enable signal state.
Syntax
set_maskable_enable_control_output on|off

set_maskablewrite_enable
This command sets the maskable write enable signal associated with the port.
Write enable signal controls whether the write operation is possible for all the
bits present in the word or not. Maskable write enable, on the other hand,
controls the write operation to some of the bits of the word. If the word width is
32 bits and maskable write enable is of width 4, then every bit of maskable
write enable controls 8 different bits of word. So by setting or unsetting the bits
of maskable write enable signal, we can control which bits of the word is to be
written to.
Syntax
set_maskablewrite_enable name –width width -port port
-active L/H

SiliconSmart ACE User Guide 711

L-2016.03
Chapter 14: Command Reference
Memory Commands

Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_data_output
This command sets the data output associated with the port. Data is written
into data output during read operation on memory.
Syntax
set_data_output name -port port
Arguments
name
Name of the data output.
port
Associated port name.

set_pipeline_output
This command sets the pipeline output associated with the port. Data present
in data output is written into pipeline output during pipeline read operation on
memory.
Syntax
set_pipeline_output name -port port
Arguments
name
Name of the pipeline output.

712 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

port
Associated port name.

Test Mode Commands

If TestMode is present, we have to take from user the following inputs. A port
can operate in both functional mode as well as test mode. To make it
operational in test mode bist mode should be set by using the set_bistmode
ON command.
The description of following test mode commands is similar to that of the
corresponding functional mode commands.
The following commands are to be used for setting up the memory to operate in
test mode:
■
set_testmode_clock
■
set_testmode_address_bus
■
set_testmode_data_bus
■
set_testmode_read_enable
■
set_testmode_write_enable
■
set_testmode_chip_enable
■
set_testmode_memory_enable
■
set_testmode_bypass_enable
■
set_testmode_writethrough_enable
■
set_testmode_bist_enable
■
set_testmode_pipelinemode_enable
■
set_testmode_extramargin_adjustment_enable
■
set_testmode_extramargin_adjustment
■
set_testmode_maskablewrite_enable
■
set_testmode_data_output
■
set_testmode_pipeline_output

SiliconSmart ACE User Guide 713

L-2016.03
Chapter 14: Command Reference
Memory Commands

set_testmode_clock
This command sets the clock associated with a port.
Syntax
set_testmode_clock pin_name -port port -active r/f
Arguments
pin_name
Name of the clock.
-port
Port name of the clock.
-active
Indicates whether the clock is active at the rising (r) or falling (f) edge.

set_testmode_address_bus
This command sets the address bus associated with the port. More than one
address bus can be associated with a single port. Each address bus should be
specified with a separate set_testmode_address_bus command.
Syntax
set_testmode_address_bus name [-width width] -port port
Arguments
name
Name of the address bus.
[-width]
Optional argument with default value 1. Width of the address bus.
-port
Port name of the address bus.

set_testmode_data_bus
This command sets the data bus associated with the port. More than one data
bus can be associated with a single port. Each data bus should be specified
with a separate set_testmode_data_bus command.

714 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

Syntax
set_testmode_data_bus name [-width width] -port port
Arguments
name
Name of the data bus.
[-width]
Optional argument with default value 1. Width of the data bus.
-port
Port name of the data bus.

set_testmode_read_enable
This command sets the read enable signal associated with the port.
When the signal is active the read operation takes place on the port. More than
one read enable signal can be associated with a single port. Each read enable
signal should be specified with a separate set_testmode_read_enable
command.
Syntax
set_testmode_read_enable name [-width width] –active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_write_enable
This command sets the write enable signal associated with the port.

SiliconSmart ACE User Guide 715

L-2016.03
Chapter 14: Command Reference
Memory Commands

When the signal is active the write operation takes place on the port. More than
one write enable signal can be associated with a single port. Each write enable
signal should be specified with a separate set_wtestmode_rite_enable
command.
Syntax
set_testmode_write_enable name [-width width] –active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_chip_enable
This command sets the chip enable signal associated with the port.
When the signal is active the memory remains active and read and write
operations can take place on the port in functional mode. More than one chip
enable signal can be associated with a single port. Each chip enable signal
should be specified with a separate set_testmode_chip_enable
command.
Syntax
set_testmode_chip_enable name [-width width] –active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.

716 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_memory_enable
This command sets the memory enable signal associated with the port.
When the signal is active the memory remains active and read and write
operations can takes place on the port in functional mode. More than one
memory enable signal can be associated with a single port. Each memory
enable signal should be specified with a separate
set_testmode_memory_enable command.
Syntax
set_testmode_memory_enable name [-width width] –active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_bypass_enable
This command sets the memory enable signal associated with the port.
When the signal is active the memory operates in bypass mode while operating
in functional mode. More than one bypass enable signal can be associated with
a single port. Each bypass enable signal should be specified with a separate
set_testmode_bypass_enable command.

SiliconSmart ACE User Guide 717

L-2016.03
Chapter 14: Command Reference
Memory Commands

Syntax
set_testmode_bypass_enable name [-width width] –active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_writethrough_enable
This command sets the write through enable signal associated with the port.
When the signal is active the memory operates in write through mode while
operating in functional mode. More than one write through enable signal can be
associated with a single port. Each write through enable signal should be
specified with a separate set_testmode_writethrough_enable
command.
Syntax
set_testmode_writethrough_enable name [-width width]
-active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

718 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

set_testmode_bist_enable
This command sets the memory enable signal associated with the port.
When the signal is active the memory operates in test mode. When the
memory operates in functional mode this signal remains inactive. More than
one bist enable signal can be associated with a single port. Each bist enable
signal should be specified with a separate set_testmode_bist_enable
command.
Syntax
set_testmode_bist_enable name [-width width] –active L/H
-port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_pipelinemode_enable
This command sets the memory enable signal associated with the port.
When the signal is active the memory operates in pipeline mode while
operating in functional mode. More than one pipeline mode enable signal can
be associated with a single port. Each pipeline mode enable signal should be
specified with a separate set_testmode_pipelinemode_enable
command.
Syntax
set_testmode_pipelinemode_enable name [-width width]
–active L/H -port port
Arguments
name
Name of the signal.

SiliconSmart ACE User Guide 719

L-2016.03
Chapter 14: Command Reference
Memory Commands

[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_extramargin_adjustment_enable
This command sets the memory enable signal associated with the port. This
signal does not have any significance as far as state table is concerned but
comes into picture in when conditions.
Syntax
set_testmode_extramargin_adjustment_enable name
[-width width] -active L/H -port port
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.
-port
Port name of the signal.

set_testmode_extramargin_adjustment
This command sets the extra-margin adjustment bus associated with the port.
More than one extra margin adjustment signal can be associated with a single
port.
Each extra margin adjustment signal should be specified with a separate
set_testmode_extramargin_adjustment command. The extra margin
adjustment pin does not take part in state table. When extra margin adjustment
mode is ON (set_testmode_extramargin_adjustment_mode ON), in the

720 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

generated instance file the extra-margin adjustment bus is replaced by pins

corresponding to every bit of the extra-margin adjustment bus.
Syntax
set_testmode_extramargin_adjustment name [–width width]
-port port
Arguments
name
Name of the bus.
[-width]
Optional argument with default value 1. Width of the bus.
-port
Port name of the bus.

set_testmode_maskablewrite_enable
This command sets the maskable write enable signal associated with the port.
Write enable signal controls whether the write operation is possible for all the
bits present in the word or not. Maskable write enable, on the other hand,
controls the write operation to some of the bits of the word. If the word width is
32 bits and maskable write enable is of width 4, then every bit of maskable
write enable controls 8 different bits of word. So by setting or unsetting the bits
of maskable write enable signal, we can control which bits of the word is to be
written to.
Syntax
set_testmode_maskablewrite_enable name –width width
-port port -active L/H
Arguments
name
Name of the signal.
[-width]
Optional argument with default value 1. Width of the signal.
-active
Indicates active value of the signal. Can be L or H.

SiliconSmart ACE User Guide 721

L-2016.03
Chapter 14: Command Reference
Memory Commands

-port
Port name of the signal.

set_testmode_data_output
This command sets the data output associated with the port. Data is written
into data output during read operation on memory.
Syntax
set_testmode_data_output name -port port
Arguments
name
Name of the data output.
port
Associated port name.

set_testmode_pipeline_output
This command sets the pipeline output associated with the port. Data present
in data output is written into pipeline output during pipeline read operation on
memory.
Syntax
set_testmode_pipeline_output name -port port
Arguments
name
Name of the pipeline output.
port
Associated port name.

General Memory Commands

The following commands are not associated with any port; rather, they are
associated with the memory as a whole:
■ add_input_pin
■
add_output_pin

722 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

■
set_input_pins_tiedto_low
■
set_input_pins_tiedto_high
■
set_internal_supply
■
set_output_state_on_shutdown
■
set_shutdown_type

add_input_pin
This command adds an input pin. More than one pin can be added as input pin
and each such is to be added through a separate add_input_pin command.
Syntax
add_input_pin name [-width width]
Arguments
name
Name of the pin.
[-width]
Optional argument with default value of 1. Width of the pin.

add_output_pin
This command adds an output pin. More than one pin can be added as output
pin and each such is to be added through a separate add_output_pin
command.
Syntax
add_output_pin name [-width width] -function function
-hiZ_function hiZ_function
Arguments
name
Name of the pin.
[-width]
Optional argument with default value of 1. Width of the pin.
-function
Function associated with the pin.

SiliconSmart ACE User Guide 723

L-2016.03
Chapter 14: Command Reference
Memory Commands

-hiZ_function
hiZ function associated with the pin.

set_input_pins_tiedto_low
This command sets the input pins which are tied to low.
Syntax
set_input_pins_tiedto_low {pinName1 pinName2 pinName3 ...}
Arguments
{pinName1, pinName2, pinName3, ...}
List of pin names.

set_input_pins_tiedto_high
This command sets the input pins which are tied to high.
Syntax
set_input_pins_tiedto_high {pinName1 pinName2 pinName3 ...}
Arguments
{pinName1, pinName2, pinName3, ...}
List of pin names.

set_internal_supply
This command automatically adds the internal supply name to the subcircuit
port list of the netlist file. The internal supply name will appear in the subcircuit
port list in the instance file and will also be defined as an in-out pin in the
instance file.
Syntax
set_internal_supply name_of_internal_supply
Examples
This internal supply is used for the PowerDown function. In the template.tcl file:
Example 454
set_internal_supply VDDHD
set_shut_down_enable PD -active H

724 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

The above example adds the following two constructs to the instance file:
Example 455
inst file add this function “add_function VDDHD 1 -hi_z PD” and
find timing delay b/w PD to VDDHD

set_config_opt -type { zdisable zenable } -from PD -to VDDHD --

state_partitions one

set_output_state_on_shutdown
This command determines the output pin value during shutdown mode.
Syntax
set_output_state_on_shutdown 0|1

set_shutdown_type
This command can take type1, type2, and type3 as an argument, although
only type2 can be used currently. When this command is used, internal supply
specific functionality and scan chain specific functionality will be enabled.
Syntax
set_shutdown_type type1|type2|type3

Scan Chain Commands

The below commands are used if the memory contains a scan chain to hold
redundant addresses. The template parameters create the function necessary
to obtain the scan chain delay (scan clock -> scan output, scan reset -> scan
output) and scan constraint (scan clock -> scan input) arcs.
■ set_scan_chain
■
set_scan_chain_def
■ set_scan_input
■
set_scan_clock
■
set_scan_reset
■
set_scan_preset
■
set_scan_output
■
set_scan_internal_node

SiliconSmart ACE User Guide 725

L-2016.03
Chapter 14: Command Reference
Memory Commands

set_scan_chain
This command sets the scan chain length. The number of cycles is equal to
the number of scan flops in this chain.
Syntax
set_scan_chain -cycles integer -port port
Arguments
-cycles
The number of scan flops in the chain.
-port
Name of the readwrite port.
Examples

Example 456
set_scan_chain –cycles 18 –port A

set_scan_chain_def
This command specifies how the flip-flops present in the scan chain will be
described.
Syntax
set_scan_chain_def value integer -port port
Arguments
value
Either AUS or FF. If scan chain is present in a memory, the default is
represented through AUS. This is case insensitive.
When FF is specified, then for every flip-flop present in the scan chain,
add_flop commands of following form are added to the instance file.
-port
Name of the readwrite port.

set_scan_input
This command specifies the scan input pin.

726 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

Syntax
set_scan_input pin -port port
Arguments
pin
Name of the input pin.
-port
Name of the readwrite port.
Examples

Example 457
set_scan_input SDIN –port A

set_scan_clock
This command specifies the clock pin of the scan chain.
Syntax
set_scan_clock pin -port port
Arguments
pin
Name of the clock pin.
-port
Name of the readwrite port.
Examples

Example 458
set_scan_clock SCLK –port A

set_scan_reset
This command specifies the reset pin of the scan chain. It is assumed that a
single reset pin is used across the entire scan chain.
Syntax
set_scan_reset pin -port port

SiliconSmart ACE User Guide 727

L-2016.03
Chapter 14: Command Reference
Memory Commands

Arguments
pin
Name of the reset pin.
-port
Name of the readwrite port.
Examples

Example 459
set_scan_reset RSTB –port A

set_scan_preset
This command specifies the preset pin of the scan chain. It is assumed that a
single preset pin is used across the entire scan chain.
Syntax
set_scan_preset pin -port port
Arguments
pin
Name of the preset pin.
-port
Name of the readwrite port.
Examples

Example 460
set_scan_preset SETB –port A

set_scan_output
This command specifies the output pin of the scan chain. The delay is
measured at this pin after the number of clock cycles specified in the -cycles
parameter of the set_scan_chain parameter above.
Syntax
set_scan_output pin -port port

728 SiliconSmart ACE User Guide

L-2016.03
 Chapter 14: Command Reference
Memory Commands

Arguments
pin
Name of the output pin.
-port
Name of the readwrite port.
Examples

Example 461
set_scan_output SDOUT –port A

set_scan_internal_node
This command specifies the scan internal node. This is the output of the first
scan flop. This node is necessary to measure the constraint arcs between the
scan input pin and the scan clock.
Syntax
set_scan_output node_name -port port
Arguments
node_name
Name of the internal SPICE node.
-port
Name of the readwrite port.
Examples

Example 462
set_scan_internal_node {XI0/XRED_CTRL/XI12/WLB_AD[8]} –port A

SiliconSmart ACE User Guide 729

L-2016.03
Chapter 14: Command Reference
Memory Commands

730 SiliconSmart ACE User Guide

L-2016.03
 15
SiliconSmart Parameters
15

This chapter provides the list of parameter blocks and parameters available in
the SiliconSmart tool.

The following parameter blocks exist within the SiliconSmart tool:

■
ibis Parameters
■ liberty_model Parameters
■
param Parameters
■
pintype Parameters
■ validation Parameters

ibis Parameters
The following parameter are available in ibis block:
■ ibis_package_c
■
ibis_package_c_max
■
ibis_package_c_min
■
ibis_package_c_typ
■
ibis_package_l
■
ibis_package_l_max
■ ibis_package_l_min
■
ibis_package_l_typ
■
ibis_package_r

SiliconSmart ACE User Guide 731

L-2016.03
Chapter 15: SiliconSmart Parameters
ibis Parameters

■
ibis_package_r_max
■
ibis_package_r_min
■
ibis_package_r_typ
■
ibis_pulldown_supply
■
ibis_pullup_supply
■
ibis_c_comp_max
■
ibis_c_comp_min
■
ibis_c_comp_typ
■
ibis_c_series_max
■
ibis_c_series_min
■
ibis_c_series_typ
■
ibis_clamping_iv_points
■
ibis_enable
■
ibis_l_series_max
■
ibis_l_series_min
■
ibis_l_series_typ
■
ibis_model_type
■
ibis_polarity
■
ibis_r_series_max
■
ibis_r_series_min
■
ibis_r_series_typ
■
ibis_vdiff

ibis_package_c
Specifies the capacitance of the package.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-12)

732 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_package_c_max
Specifies the capacitance of the package in max corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-12)

ibis_package_c_min
Specifies the capacitance of the package in min corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-12)

ibis_package_c_typ
Specifies the capacitance of the package in typ corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-12)

ibis_package_l
Specifies the inductance of the package.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-6)

SiliconSmart ACE User Guide 733

L-2016.03
Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_package_l_max
Specifies the inductance of the package in max corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-6)

ibis_package_l_min
Specifies the inductance of the package in min corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-6)

ibis_package_l_typ
Specifies the inductance of the package in typ corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 1e-6)

ibis_package_r
Specifies the resistance of package.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 50.0)

734 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_package_r_max
Specifies the resistance of package in max corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 50.0)

ibis_package_r_min
Specifies the resistance of package in min corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 50.0)

ibis_package_r_typ
Specifies the resistance of package in typ corner.

Block Default Value Valid Range

unchecked 0.0 Float(0.0, 50.0)

ibis_pulldown_supply
Specifies an alternate supply name to be used as the reference voltage during
pulldown measurements.

Block Default Value Valid Range

pintype logic_low_name String()

SiliconSmart ACE User Guide 735

L-2016.03
Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_pullup_supply
Specifies an alternate supply name to be used as the reference voltage during
pullup measurements.

Block Default Value Valid Range

pintype logic_high_name String()

ibis_c_comp_max
The die capacitance of the pin not including package capacitances. These
parameters default to the value of the pintype parameter ibis_c_comp. They
can be overridden here.

Block Default Value Valid Range

ibis 1e-14 Float(0.0, 1e-9)

ibis_c_comp_min
The die capacitance of the pin not including package capacitances. These
parameters default to the value of the pintype parameter ibis_c_comp. They
can be overridden here.

Block Default Value Valid Range

ibis 1e-14 Float(0.0, 1e-9)

736 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_c_comp_typ
The die capacitance of the pin not including package capacitances. These
parameters default to the value of the pintype parameter ibis_c_comp. They
can be overridden here.

Block Default Value Valid Range

ibis 1e-14 Float(0.0, 1e-9)

ibis_c_series_max
Specifies [C series] value for max corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

ibis_c_series_min
Specifies [C series] value for min corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

ibis_c_series_typ
Specifies [C series] value for typ corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

SiliconSmart ACE User Guide 737

L-2016.03
Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_clamping_iv_points
Specifies the number of sample points to be used in Douglas-Peucker
interpolation for IV and clamping curves for different voltage range.
For example, if you specify this parameter to be {20 30 40} and the IV/clamping
swing is from -1.8V to 3.6V, 20 points would be generated between (-1.8V, 0),
30 points for (0, 1.8V) and 40 points for (1.8V, 3.6V). Only 3 values are allowed
for 3 ranges. This parameter doesn't affect what the exact DC sweep voltage
values are selected or finally printed.

Block Default Value Valid Range

param empty_list() List(new Integer)

ibis_enable
Set to Active-High or Active-Low to specify whether an output pin is active-high
or active-low .

Block Default Value Valid Range

ibis \"\" String()

ibis_l_series_max
Specifies [L series] value for max corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

738 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_l_series_min
Specifies [L series] value for min corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

ibis_l_series_typ
Specifies [L series] value for typ corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

ibis_model_type
Specifies one of the defined IBIS model types to be written to the model. This
parameter is set by the tool automatically based on the pin direction, but may
be overridden.

Block Default Value Valid Range

ibis \"\" Flag()

ibis_polarity
Set to Non-inverting or Inverting to specify whether a pin is an inverting or non-
inverting output.

Block Default Value Valid Range

ibis \"\" String()

SiliconSmart ACE User Guide 739

L-2016.03
Chapter 15: SiliconSmart Parameters
ibis Parameters

ibis_r_series_max
Specifies [R series] value for max corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

ibis_r_series_min
Specifies [R series] value for min corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

ibis_r_series_typ
Specifies [R series] value for typ corner.

Block Default Value Valid Range

ibis 0.0 Float(0,None)

ibis_vdiff
Specifies the capacitance, resistance, and voltage used in the test loads.

Block Default Value Valid Range

ibis \"\" String()

740 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
liberty_model Parameters

liberty_model Parameters
The following parameters are available in liberty_model block:
■
delay_model

delay_model
This is the liberty header attribute used when modeling with the
-create_new_model switch

Block Default Value Valid Range

liberty_model \"table_lookup\" String()

param Parameters
The following parameter are available in param block:
■ absolute_leakage_threshold_value
■
active_pvts
■
add_constraint_margin
■ add_lvf_constraint_margin
■
add_lvf_delay_margin
■ add_lvf_slew_margin
■ add_stat_constraint_margin
■
advanced_dp
■
advanced_node
■ advanced_sof
■
aocv_correlation_coeff_between_stages
■ aocv_early_sigma
■
aocv_fanout_cells
■
aocv_fanout_load

SiliconSmart ACE User Guide 741

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
aocv_fast_char
■
aocv_input_pin
■
aocv_interconnect_model
■
aocv_late_sigma
■
aocv_mc_mode
■
aocv_num_fanouts
■
aocv_num_stages
■
aocv_output_pin
■
aocv_passive_load
■
aocv_sample_size
■
aocv_sensitivity_based
■
archive_condition_for_pruning
■
archive_condition_on_failure
■
archive_condition_on_success
■
archive_level
■
auto_fix
■
back_bias_connection
■
backup_simulation_tmpdir
■
bjt_model_names
■
bundle_bit_independent_descriptor
■
bundle_bit_independent_descriptor_mode
■
cap_model_names
■ ccb_separator
■
ccb_single_fanout
■
ccb_single_fanout_bit
■
ccbs_for_input_driving_passgate
■
ccs_delay_abs_tolerance
■
ccs_delay_tolerance
■
ccs_noise_iv_dc_analysis_mode

742 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
ccs_noise_miller_resistance
■
ccs_power_modeling_load_indices
■
ccs_power_modeling_slew_indices
■
ccs_power_optimize_waveform
■
ccs_receiver1_check_ratio
■
ccs_receiver2_check_ratio
■
ccs_segment_tolerance
■
ccsn_add_second_level_ccb_load
■
ccsn_cmiller_check_mode
■
ccsn_cmiller_default_value
■
ccsn_exclude_pin
■
ccsn_ignore_char_failures_during_modeling
■
ccsn_initial_delay
■
ccsn_model_default_pin_based_models
■
ccsn_truncate_long_ccb_name
■
ccsn_model_passgate_ccb
■
ccsn_use_enhanced_hw_method
■
ccsn_use_enhanced_miller_cap
■
ccsn_use_optimal_node_selection_method
■
ccsn_use_partial_netlist
■
ccsp_cross_point_selection
■
cdpl_alt_submission
■ cdpl_host_file
■
cdpl_long_task_alert
■
cdpl_submission_cmd
■
cdpl_submission_timeout
■
cdpl_task_max_lifespan
■
cdpl_worker_max_tasks
■
cdpl_worker_timeout

SiliconSmart ACE User Guide 743

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
cell_families
■
cell_type
■
char_engine_max_lifespan
■
check_pins_in_netlist
■
check_sof
■
check_templates
■
combine_delay_and_cin
■
combine_energy_and_cin
■
combine_lvf_cin
■
combine_timing_and_power
■
compact_ccs_tolerance
■
configure_all_states_for_ccb
■
configure_constraint_delay
■
configure_internal_node_arcs
■
configure_from_function
■
configure_from_structure
■
configure_preferred_secondary_input
■
configure_write_fugues
■
configure_zdisable_pull
■
constraint_exclude_outputs
■
constraint_glitch_time_delta
■
constraint_matched_internal_state
■ constraint_mode
■
constraint_monotonicity_tolerance_pct
■
constraint_outputs
■
constraint_pulse_cratering
■
constraint_seed_by_slew
■
constraint_seed_step
■
constraint_seed_values

744 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
constraint_simulated_seed
■
constraint_simulated_seed_acq_based
■
constraint_simulated_seed_finesim_mode
■
constraint_simulated_seed_simulator
■
constraint_simulation_mode
■
constraint_trigger_node
■
construct_ncx_templates
■
current_absolute_tolerance
■
current_relative_tolerance
■
cut_netlist
■
cut_stat_netlist
■
datasheet_truth_table
■
dc_current_absolute_tolerance
■
dc_current_product_tolerance
■
dc_current_relative_tolerance
■
dc_current_threshold
■
default_load_position
■
default_netlist_size
■
default_position_selection
■
default_slew_position
■
delay_based_constraint_mode
■
delay_matching_cin
■ detect_internal_power_nodes
■
detect_internal_power_nodes_for_pruning
■
differential_delay_mode
■
differential_delay_probe_style
■
differential_pair_timing_duplication
■
dio_model_names
■
disable_negative_power_adjustments

SiliconSmart ACE User Guide 745

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
disable_sim_stats
■
do_zero_modeling
■
dontcare_bias_on_output
■
dontcare_values
■
driver_load_steps
■
ecsm_power_modeling_load_indices
■
ecsm_power_modeling_slew_indices
■
ecsm_threshold_pcts_fall
■
ecsm_threshold_pcts_rise
■
em_analyze_power_nets
■
em_table_with_current_types
■
em_threshold_simulator
■
em_threshold_simulator_cmd
■
em_threshold_tolerance
■
em_use_xba
■
enable_ac_decap
■
enable_ac_decap_merge
■
enable_cache
■
enable_cell_leakage_power_modeling
■
enable_dc_leakage
■
enable_exhaustive_modeling_of_ccbs
■
enable_external_simulator_pruning
■ enable_fast_sweep
■
enable_fse_log
■
enable_gated_hold_constraint
■
enable_macro_pruning
■
enable_memory_pruning
■
enable_netlist_pruning
■
enable_parallel_sweeps

746 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
enable_parasitic_sweep
■
enable_rechar_reporting
■
enable_status
■
energy_fast_mode_leakage
■
energy_fast_mode_leakage_interval
■
ensure_constraint_monotonicity
■
event_rank
■
excluded_acquisitions
■
extrapolate_ccs_cin_slew
■
finesim_so_path
■
force_removal_recovery_modeling
■
fr_archive_condition_on_failure
■
fr_archive_condition_on_success
■
fse_preprocess_cmd
■
fse_user_cmd
■
gate_leakage_time_scaling_factor
■
generate_all_ccbs_after_passgate
■
graphviz_location
■
gzip_cellmodel_libs
■
harness
■
HDL_cell_postprocess
■
hdl_vector_time_step
■ hierarchy_separator
■
hsp_keep_model
■
hspice_client
■
ibis_add_submodel
■
ibis_ami
■
ibis_ami_bit_time
■
ibis_ami_sample_interval

SiliconSmart ACE User Guide 747

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
ibis_ami_taps
■
ibis_ami_weights
■
ibis_c_comp_user_only
■
ibis_clamping_curve_make_monotonic
■
ibis_clamping_iv_analysis_mode_dc
■
ibis_clamping_iv_num_points
■
ibis_cref
■
ibis_diff_pin_single_model
■
ibis_odt_driver_only
■
ibis_odt_linear_regression_max_scale
■
ibis_odt_linear_regression_min_scale
■
ibis_odt_mode
■
ibis_odt_mode_name
■
ibis_odt_pulldown_modes
■
ibis_odt_pullup_modes
■
ibis_odt_receiver_only
■
ibis_pin_alias
■
ibis_pin_mapping
■
ibis_plan_for_corner_merge
■
ibis_prog_driver_mode
■
ibis_prog_driver_mode_name
■
ibis_rref
■ ibis_single_pvt_corner_name
■
ibis_source
■
ibis_typ_pvt
■
ibis_use_exact_mode_name
■
ibis_validate_bit_slew
■
ibis_validate_bit_time
■
ibis_validate_input_pin_name

748 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
ibis_validate_prbs_size
■
ibis_validate_terminating_resistor
■
ibis_vcross_high
■
ibis_vcross_low
■
ibis_vdiff_ac
■
ibis_vdiff_dc
■
ibis_version
■
ibis_vinh
■
ibis_vinh_max
■
ibis_vinh_min
■
ibis_vinh_typ
■
ibis_vinl
■
ibis_vinl_max
■
ibis_vinl_min
■
ibis_vinl_typ
■
ibis_vmeas
■
ibis_vmeas_max
■
ibis_vmeas_min
■
ibis_vmeas_typ
■
ibis_vref
■
ibis_vt_curve_make_monotonic
■
ibischk_cmd
■ ideal_netlist_ext
■
import_explicit_points_per_arc
■
import_liberty_ndw
■
initial_delay_multiplier
■
insert_liberty_default_ndw
■
init_internal_pins
■
initialization_cycles

SiliconSmart ACE User Guide 749

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
internal_ground_nets
■
internal_ground_supply_spice_nets
■
internal_nodes_transition_data
■
internal_power_nets
■
internal_power_supply_spice_nets
■
intrinsic_cap_with_phase_diff
■
io_retry
■
job_scheduler
■
keep_loading_effect_with_pruning
■
leakage_current_substitution_value
■
leakage_sum_threshold
■
left_bus_identifier
■
liberty_attributes_at_bundle
■
liberty_blackbox_model
■
liberty_cap_unit
■
liberty_cell_postprocess
■
liberty_combine_complementary_models
■
liberty_constraint_type
■
liberty_current_unit
■
liberty_data_reduce
■
liberty_fast_option
■
liberty_fill_out_power_with
■ liberty_flavor
■
liberty_increasing_delay_with_ecsm
■
liberty_increasing_delay_with_ccs
■
liberty_increasing_delay_with_load
■
liberty_increasing_delay_with_slew
■
liberty_increasing_time_points
■
liberty_increasing_transition_with_load

750 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
liberty_leakage_power_unit
■
liberty_max_capacitance
■
liberty_max_capacitance_mode
■
liberty_max_transition
■
liberty_min_capacitance
■
liberty_min_transition
■
liberty_minimize_constraint_when
■
liberty_minimize_groups
■
liberty_minimize_timing_when
■
liberty_multi_rail_format
■
liberty_power_down_function
■
liberty_power_down_function_pins
■
liberty_resistance_unit
■
liberty_select_min_period
■
liberty_select_min_pulse_width
■
liberty_state_independent
■
liberty_statetable_for_gcl
■
liberty_time_unit
■
liberty_timing_type
■
liberty_whens
■
lvf_check_errors
■
lvf_check_sigma_pct
■ lvf_check_slew_sigma_pct
■
lvf_check_suppress
■
lvf_constraint_models
■
lvf_constraint_seed_step
■
lvf_enable_sanity_check
■
lvf_model_slew
■
lvf_param_abs_threshold

SiliconSmart ACE User Guide 751

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
lvf_param_rel_threshold
■
lvf_sigma_max
■
lvf_sigma_min
■
lvf_sigma_scaling
■
lvf_to_ocv_input_pins
■
lvf_to_ocv_load_indices
■
lvf_to_ocv_method
■
lvf_to_ocv_slew_indices
■
lvf_to_ocv_output_pins
■
lvf_tol_early_to_late
■
lvf_tol_sigma_to_nom
■
make_cdb_path
■
make_small_dc_current_values_as_zero
■
max_constraint_iterations
■
maximum_stack_depth
■
measure_side_input_power
■
memory_ccsn_partial_netlist
■
miller_capacitance_check_tolerance_pct
■
miller_capacitance_edge_ratio
■
miller_output_slew
■
min_disk_space
■
min_period_precharge_threshold_factor
■ min_period_with_precharge_delay
■
minimum_constraint_sum_margin
■
model_arc_and_pin_cap
■
model_as_non_unate
■
model_back_bias
■
model_bundle_bit_level
■
model_bus_timing

752 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
model_default_arcs
■
model_default_constraints
■
model_default_power_arc
■
model_ecsm_threshold_pct
■
model_equalize_cap_averaging
■
model_exclude_supplies
■
model_expanded_states
■
model_failed_cells_in_lib
■
model_input_leakage_current
■
model_leakage_current_file
■
model_mpw_attribute
■
model_neg_constraint_chk_opposite_edge
■
model_neg_constraint_sum
■
model_neg_constraint_sum_margin
■
model_neg_constraint_sum_threshold
■
model_negative_constraints
■
model_negative_delays
■
model_negative_energy
■
model_negative_leakage
■
model_normalized_constraint_driver_waveform
■
model_normalized_driver_waveform
■
model_pg_pin_groups
■ model_pin_cap_calc
■
model_power_on_output
■
model_power_per_supply
■
model_reverse_polarity_current
■
model_rise_fall_capacitance
■
model_rise_fall_capacitance_range
■
model_sensitization_vector

SiliconSmart ACE User Guide 753

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
model_significant_digits
■
model_significant_digits_area
■
model_uncharacterized_tables
■
mpw_rail_to_rail
■
monitor_internal_nodes
■
mpp_simulator
■
mpw_table_dimensions
■
mpw_v2_transition_inputs
■
netlist_max_sweeps
■
new_operating_condition
■
nmos_drn_gate_shorted_model_names
■
nmos_drn_src_shorted_model_names
■
nmos_gate_src_shorted_model_names
■
nmos_model_names
■
nochange_threshold
■
nochange_variance
■
non_scan_model
■
normal_queue
■
normalized_driver_significant_digits
■
nsamples
■
opc_grounds
■
opc_process
■ opc_supplies
■
opc_temperature
■
opc_voltage
■
output_sweep_order
■
param_change_period
■
parameters
■
partition_by_output_transitions

754 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
path_based_clock_nodes
■
path_based_signal_nodes
■
path_constraint_enable
■
path_constraint_enable_negative
■
path_constraint_enable_positive
■
path_constraint_feedback
■
path_constraint_mode
■
path_constraint_pintype
■
periodic_clock_stimulus
■
pin_name_alias
■
pmos_drn_gate_shorted_model_names
■
pmos_drn_src_shorted_model_names
■
pmos_gate_src_shorted_model_names
■
pmos_model_names
■
point_to_point_default_selection
■
potential_internal_node_list
■
power_dynamic_end_threshold
■
power_load_energy_on_rise
■
power_meas_grounds
■
power_meas_map
■
power_meas_supplies
■
power_stabilization_threshold
■ power_stabilization_threshold_absolute
■
prechar_autorange_load
■
prechar_binning_abs_tol
■
prechar_binning_constraints
■
prechar_binning_hidden_power
■
prechar_binning_max_bins
■
prechar_binning_method

SiliconSmart ACE User Guide 755

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
prechar_binning_mode
■
prechar_binning_power
■
prechar_binning_rel_tol
■
prechar_binning_timing
■
prechar_enable_fast_analysis
■
prechar_keep_intermediate_files
■
prechar_numsteps
■
prechar_sampling_size
■
prechar_simulator
■
prechar_state_partitions
■
preferred_switching_input
■
reduce_ccs_power_table
■
primary_index
■
propagate_warnings
■
publish_internal_pin_states
■
receiver_cap_for_zdisable
■
receiver_trip_threshold_pct_fall
■
receiver_trip_threshold_pct_rise
■
rechar_add_attributes
■
rechar_update_attributes
■
reduce_ecsm_power_table
■
replace_negative_leakage_with
■ report_constraint_iterations
■
res_model_names
■
right_bus_identifier
■
run_list_maxsize
■
running_prechar
■
save_farm_logs
■
scan_enable

756 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
scan_input
■
scan_enable_inverted
■
scan_output
■
scan_output_inverted
■
scan_start_pin
■
scan_type
■
scd_debug_subtract_power_tables
■
scheduler_poll_time
■
sdf_cond_equality_operator
■
secondary_run_list_maxsize
■
separate_cell_initialization
■
separate_cell_initialization_levels
■
signal_capture_pct
■
simcomp_version
■
simulator_case_sensitive
■
simulation_max_inactive_time
■
simulation_max_runtime
■
simulation_node_initialization_file
■
simulation_tmpdir
■
simulator
■
simulator_bisection
■
simulator_cmd
■ simulator_default_options
■
simulator_options
■
simulator_warning_limit
■
single_bit_degenerate
■
single_cell_mode
■
sis_cell_type_memory
■
sis_exclude_internal_power_nets

SiliconSmart ACE User Guide 757

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
sis_gzip_enable
■
sis_gzip_enable_for_lib
■
sis_pruning_with_flat_netlist
■
sishapes_channel_length_offset
■
sishapes_minimum_feature_length
■
slew_derate_lower_threshold
■
slew_derate_upper_threshold
■
slew_matching_cin
■
spectre_ccb
■
spectre_fake_model
■
spectre_macmod
■
srf_multiplier
■
stat_hold_sensitivity_ratios
■
state_coverage_exclude_pins
■
state_partitions
■
state_rank
■
state_selection
■
statistical_avoid_screening_acquisition
■
statistical_constraint_screening_points
■
statistical_constraint_screening_tolerance
■
statistical_enable_constraint_sensitivity
■
statistical_model_sigma_montecarlo
■ statistical_montecarlo_sample_size
■
statistical_reduction_factor
■
statistical_screening_points
■
statistical_screening_tolerance
■
statistical_significant_transistors
■
statistical_simulation_points
■
statistical_simulator_bisection

758 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
statistical_timing_abs_tolerance
■
statistical_timing_rel_tolerance
■
statistical_two_sided_screening
■
statistical_use_pruned_netlist_for_nominal
■
submit_list_maxsize
■
subtract_pin_capacitance
■
sweep_states
■
table_dimension_for_internal_node
■
table_dimensions
■
time_res_high
■
time_res_low
■
update_cache_last
■
use_ccs_init_delay
■
use_ccs_native_current
■
use_ccsn_initial_delay
■
use_exact_when
■
use_gates
■
use_measured_slew_for_combined_setuphold
■
use_save_for_initialization
■
use_simulator_licenses
■
verilog_atpg_syntax
■
verilog_combine_function_timing_blocks
■ verilog_default_combinational_delay
■
verilog_default_constraint_delay
■
verilog_default_sequential_delay
■
verilog_delay_path_polarity
■
verilog_flavor
■
verilog_function
■
verilog_functional_file

SiliconSmart ACE User Guide 759

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
verilog_hierarchy_separator
■
verilog_model_notifier
■
verilog_model_power_as_inout
■
verilog_model_power_as_output
■
verilog_model_power_supplies
■
verilog_model_removal_as_hold
■
verilog_model_use_recrem
■
verilog_model_use_setuphold
■
verilog_notifier_name
■
verilog_table_indices
■
verilog_udp_file
■
verilog_unit_delay
■
verilog_unused_pins_format
■
vg_allow_floating_nets
■
vg_enable_constraint_measurements
■
vg_enable_hidden_measurements
■
vg_enable_pulse_measurements
■
vg_enable_steady_measurements
■
vg_enable_switching_measurements
■
vg_explicit_leakage_states
■
vg_log_level
■
vg_max_arcs_per_input_transition
■ vg_max_leakage_states
■
vg_partial_circuit_collapse
■
vg_restricted_inputs
■
vg_restricted_states
■
vg_state_selection
■
voltage_name_map
■
weak

760 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

■
whens
■
workers_as_daemons

absolute_leakage_threshold_value
This parameter takes effect when the parameter
'model_reverse_polarity_current' is set to 0 and the measured gate leakage
current or pg current is of reverse polarity.
In this case, if the absolute value of the leakage current is below this threshold
value, we will make it small positive number that is controlled by the parameter
'leakage_current_substitution_value'.

Block Default Value Valid Range

param 0 Float(0.0, 1.0)

active_pvts
Specifies the names of the operating condition across which all measurements
are performed. A Liberty model is written out for the operating condition
specified with this parameter. Only one PVT should be specified with
active_pvts. If a multi-PVT characterization is desired, it is recommended to
run characterization for each PVT separately in its own respective charpoint.
When generating IBIS models, this parameter can take multiple operating
conditions and is order-dependent. The order of the process voltage
temperature points must be set active_pvts {typ min max}. If you do not
adhere to this order, the resulting IBIS models will be incorrect. For more
details, see the IBIS Model Format Support section of Chapter 14, IBIS.

Block Default Value Valid Range

param empty_list() List(new String())

add_constraint_margin
Add the specifies margin value to the constraint tables. The margin value can
apply to setup, hold, recovery, removal, mpw, nochange, etc. Using

SiliconSmart ACE User Guide 761

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

set_config_opt -type {setup hold} add_constraint_margin

1e-10 will have it apply only to setup, hold constraint tables.

Block Default Value Valid Range

param 0 Float(0.0, 1e-6)

add_lvf_constraint_margin
Adds a percentage margin to LVF constraint sigma.

Block Default Value Valid Range

param 0 Float()

add_lvf_delay_margin
Adds a percentage margin to LVF delay sigma.

Block Default Value Valid Range

param 0 Float()

add_lvf_slew_margin
Adds a percentage margin to LVF slew sigma.

Block Default Value Valid Range

param 0 Float()

762 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

add_stat_constraint_margin
The margin value to be added to statistical constraint tables. The table can be
lvf_constraint, stat_hold, etc.

Block Default Value Valid Range

param 0 Float(0.0, 1e-6)

advanced_dp
Uses the new CDPL based distributed computing core.

Block Default Value Valid Range

param 1 Flag()

advanced_node
Enables model preprocessing. See Model Preprocessing for more information.

Block Default Value Valid Range

param 0 0, 1

advanced_sof
New SOF file format with improved performance.

Block Default Value Valid Range

param 1 Flag()

SiliconSmart ACE User Guide 763

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

aocv_correlation_coeff_between_stages
Specifies the correlation coefficient between the current stage and next 2
stages. The first value is the coefficient between the stage and the next stage.
The last value is the coefficient between the stage and the next stage.

Block Default Value Valid Range

param list(0.0, 0.0) List(new Float(0.0, 10.0))

aocv_early_sigma
Number of sigma's to be used for aocv early table

Block Default Value Valid Range

param -3 Integer(-6,-1)

aocv_fanout_cells
List of cells to be used as load at each stage for aocv characterization.

Block Default Value Valid Range

param empty_list() List(new String())

aocv_fanout_load
For lumped interconnect model, the lumped capacitor is a value in Farads, for
example 0.02e-12. For pi interconnect model, the PI model is specified as a Tcl
list of {C1 R C2} in Farads, Ohms, and Farads, respectively. For example,
{0.01e-12 100 0.03e-12}.

Block Default Value Valid Range

param 1e-15 List(new String())

764 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

aocv_fast_char
Enable this parameter to speed up AOCV char. This simulates a reduced
number of stages and comes up with the derate factor analytically for all
stages.

Block Default Value Valid Range

param 1 Flag()

aocv_input_pin
Load to be connected at the output of active load.

Block Default Value Valid Range

param \"\" String()

aocv_interconnect_model
Specifies the interconnect loading structure to be placed at the end of each
stage. Lumped load (lumped) and PI model (pi) are supported.Default is ot to
put any load.

Block Default Value Valid Range

param \"none\" Enumerated("lumped, pi,none")

aocv_late_sigma
Number of sigma's to be used for aocv late table.

Block Default Value Valid Range

param 3 Integer(1,6)

SiliconSmart ACE User Guide 765

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

aocv_mc_mode
Monte Carlo mode to be used by finesim for aocv characterization.

Block Default Value Valid Range

param \"traditional\" Enumerated("traditional,fast")

aocv_num_fanouts
Number of cells to be connected at the output of each stage for aocv
characterization.It can either be a single integer in which case the same
number of cells will be connected at the output of each stage or a list of
integers in which case the entries in the list will specify the number of outputs
are each stage

Block Default Value Valid Range

param 0 List(new Integer())

aocv_num_stages
Number of cells to be connected in series for AOCV characterization.

Block Default Value Valid Range

param 10 Integer(2,1000)

aocv_output_pin
Load to be connected at the output of active load.

Block Default Value Valid Range

param \"\" String()

766 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

aocv_passive_load
Load to be connected at the output of active load.

Block Default Value Valid Range

param 1e-15 Float()

aocv_sample_size
Number of samples to be used for MonteCarlo simulations for AOCV

Block Default Value Valid Range

param 200 Integer()

aocv_sensitivity_based
If enabled, do sensitivity based AOCV char instead of MonteCarlo simulation
based

Block Default Value Valid Range

param 0 Flag()

archive_condition_for_pruning
Determines whether the pruning results are archived as a compressed tar file
(compress, no).

Block Default Value Valid Range

param \"no\" Enumerated("no, compress")

SiliconSmart ACE User Guide 767

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

archive_condition_on_failure
Determines whether the SPICE simulation results are archived (yes), archived
as a compressed tar file (compress), or only sof.log will be saved (no) when a
simulation fails.

Block Default Value Valid Range

param \"yes\" Enumerated("yes, no, compress,

empty")

archive_condition_on_success
Determines whether the compressed SPICE simulation results are archived as
a compressed tar file (yes, compress), or only sof.log will be saved (no) when a
simulation succeeds.

Block Default Value Valid Range

param \"no\" Enumerated("{\

'yes':'compress',\
'no':'no',\
'compress':'compress',\
'empty':'empty'}")

archive_level
Determines how much SPICE result is saved. If it is 0, no sof.log will be saved.

Block Default Value Valid Range

param 0 Integer(0,1)

768 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

auto_fix
The limit of autofix retries for failed tasks

Block Default Value Valid Range

param 1 0 - 10

back_bias_connection
Controls the generation of the simple attribute physical_connection under
pg_pin group for cell-level attribute within a Liberty model. The
physical_connection attribute can have the following values: device_layer and
routing_pin.
■
The device_layer value specifies that the bias connection is physically
external to the cell. In this case, the library provides biasing tap cells that
connect through the device layers.
■
The routing_pin value specifies that the bias connection is inside a cell and
is exported as a physical geometry and a routing pin. For more details
please refer to Library Compiler User Guide.

Block Default Value Valid Range

param \"device_layer\" Enumerated("device_layer,

routing_pin")

backup_simulation_tmpdir
Specifies the backup directory in which the temporary files for a simulation are
to be written. Siliconsmart will honor simulation_tmpdir first. If the simulation
failed due to disk issue, it will try backup_simulation_tmpdir if it's not empty.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 769

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

bjt_model_names
Names of diode models used by netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

bundle_bit_independent_descriptor
When this parameter is enabled, the SiliconSmart tool treats each 1-bit entity of
the multi-bit cell independently. This parameter should be specified before the
configure command.
For example, for a 2-bit DFF with the following description (in the instance file),
the constraint arc between D0 and CK can be characterized for two states of
D1 (D1 =0 and D1=1). When bundle_bit_independent_descriptor is
set to 1, this constraint arc will be characterized only for D1=0.
add_pin CK default -input
add_pin D0 default -input
add_pin D1 default -input
add_pin Q0 default -output
add_pin Q1 default -output

add_flop IQ0 IQN0 CK {D0}

add_flop IQ1 IQN1 CK {D1}
add_function Q0 IQ0
add_function Q1 IQ1

Block Default Value Valid Range

param 0 Flag()

bundle_bit_independent_descriptor_mode
Specifies modes of state selection when
bundle_bit_independent_descriptor is turned on. The value 1
indicates independent treatment of bits, and value 2 indicates an enhancement

770 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

from value 1 with additional states representing average values. You should
specify this flag before configure..

Block Default Value Valid Range

param 1 0, 1, 2

cap_model_names
Names of capacitor models used by netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

ccb_separator
The string parameter used as the separator when creating the CCB names for
CCS-Noise characterization.

Block Default Value Valid Range

param \"__\" String()

ccb_single_fanout
Generates a single CCB for each input and output pin as below:
■
0 — generate all CCBs for all the bits of the bus (default)
■
1 — generate only one CCB for the input and output pins. If the input/output
pin is a bus, a single CCB will be generated for each bit of the bus.

SiliconSmart ACE User Guide 771

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
2 — generate a single CCB for the whole bus. The bit used to create the
CCB is based on the value of the parameter ccb_single_fanout_bit.
■ 3 — If the input pin is a bus, all possible CCBs will be generated for the bit
specified by the parameter ccb_single_fanout_bit. For a normal input
pin which is not a bus, setting this parameter to 3 functions as if set to 0.

Block Default Value Valid Range

param 0 0, 1, 2, 3

ccb_single_fanout_bit
Specifies the bit which should be used to create the CCB for a bus. By default,
the 0th bit will be used. This parameter works only for CCSN flow for memories.
This parameter will take effect when the parameter ccb_single_fanout is
set to 2.

Block Default Value Valid Range

param 0 Integer(0, 1000)

ccbs_for_input_driving_passgate
When set to 1 for a cell, the SiliconSmart tool internally sets the following
parameters automatically as below:
set_config_opt –cell {cell} liberty_minimize_timing_whens 0
set_config_opt –cell {cell} ccsn_model_default_pin_based_models 1

When set to 2, the liberty_minimize_timing_whens parameter will not

be forced to 0 internally, which will leave when conditions of timing groups
unaffected. Only modeling can be run on the existing charpoint. As before, this
flag will create new CCSN models.

Block Default Value Valid Range

param 0 0, 1, 2

772 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ccs_delay_abs_tolerance
Controls absolute delay difference between CCS and NLDM delay

Block Default Value Valid Range

param 2.0e-12 Float()

ccs_delay_tolerance
Specifies the acceptable difference between measured delay from simulation
and delay obtained from the CCS waveform, expressed as a fraction of the
measured delay from simulation

Block Default Value Valid Range

param 0.02 Float()

ccs_noise_iv_dc_analysis_mode
This is a Boolean parameter which applies to ccs-noise iv generation. If set to
true, dc analysis is used in generating iv curves. If set to false, it uses transient
analysis to generate iv curves.

Block Default Value Valid Range

param 1 Flag()

ccs_noise_miller_resistance
This defines a high resistance value that is put between the input node and
ground for measuring Miller capacitance.

Block Default Value Valid Range

param 5e+8 Float()

SiliconSmart ACE User Guide 773

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ccs_power_modeling_load_indices
This parameter specifies the load indices to be used for ccs power modeling.
By default all the characterized load indices are modeled. But this parameter
can be used to model a subset of the load indices.

Block Default Value Valid Range

param empty_list() List(new Integer())

ccs_power_modeling_slew_indices
This parameter specifies the slew indices to be used for ccs power modeling.
By default all the characterized slew indices are modeled. But this parameter
can be used to model a subset of the slew indices.

Block Default Value Valid Range

param empty_list() List(new Integer())

ccs_power_optimize_waveform
Determines whether to apply optimized segmentation to reduce the current
waveforms in CCS power models.

Block Default Value Valid Range

param 1 0, 1

ccs_receiver1_check_ratio
Will raise warning if the ratio between recv_cap1 and nldm cap is more than
ccs_receiver1_check_ratio.

Block Default Value Valid Range

param 2 Integer(1,None)

774 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ccs_receiver2_check_ratio
Will raise warning if the ratio between recv_cap2 and nldm cap is more than
ccs_receiver2_check_ratio.

Block Default Value Valid Range

param 5 Integer(1,None)

ccs_segment_tolerance
Specifies maximum allowedvoltagedifference between the simulation waveform
and the CCS waveform, used for selecting the CCS model

Block Default Value Valid Range

param 0.005 Float()

ccsn_add_second_level_ccb_load
Direct SiliconSmart to add load at second level CCB output.

Block Default Value Valid Range

param 1 Flag()

ccsn_cmiller_check_mode
This parameter defines the various modes of handling negative miller
capacitance values. If the value of this parameter is set to 1, the negative miller
cap values are replaced by the parameter value 'ccsn_cmiller_default_value'
during modeling. If the value of the parameter is set to 2 and if one of the rise/
fall miller cap is negative, then Siliconsmart copies the value from the opposite
side measure onto the negative side. If both the rise and fall miller cap values
are negative, then Siliconsmart will error out. If the value of this parameter is 3,

SiliconSmart ACE User Guide 775

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

then Siliconsmart will error out if any of the rise/fall miller cap values are
negative.

Block Default Value Valid Range

param 2 Integer(1,3)

ccsn_cmiller_default_value
Specifies the default value for replacing negative miller capacitance values
during encountered during modeling.

Block Default Value Valid Range

param 1e-15 Float(0.0,None)

ccsn_exclude_pin
This parameter can be used to specify list of pins for which CCB creation needs
to be suppressed.
This parameter can also be applied to bits of a bus while characterizing CCSN
for memories or cells with bussed pins. It is possible to use regular expressions
to specify the pins instead of having to specify all the pins of the bus as a list.
For example, if you want to configure//model CCS-noise only for bit A[0] of bus
A, which is 7-bit wide (A[0-6]), you can set the following:
set_config_opt ccsn_exclude_pin {A\[[1-6]+]}

Block Default Value Valid Range

param empty_list() List(new String())

ccsn_ignore_char_failures_during_modeling
When set to 1, the SiliconSmart tool will ignore any characterization failures
during CCSN characterization and will continue modeling the CCB data as if
nothing happened. The final CCSN model will be checked if all of the timing

776 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

arcs are covered by valid minimal CCB data or if all of the pins have minimal
pin-based data. The SiliconSmart tool will only fail the cell if that condition is not
met.

Block Default Value Valid Range

param 0 Flag()

ccsn_initial_delay
Initial delay used for noise waveform and noise propagation. The value
specified by this parameter is applied only if use_ccsn_initial_delay is
set to 1.

Block Default Value Valid Range

param 100e-11 Float(1e-12, 2.5e3)

ccsn_model_default_pin_based_models
Direct SiliconSmart to model default pin-based ccsn models at input pin and
output pin. If set to 0, the SiliconSmart tool will disable default pin-based
models.

Block Default Value Valid Range

param 1 Flag()

ccsn_truncate_long_ccb_name
This parameter when enabled truncates CCB names if the length of CCB name
exceeds 100 characters.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 777

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ccsn_model_passgate_ccb
This parameter when set to 'pin' models CCBs with pass-gates as pin-based
models. If set to 'arc', it models the CCbs with pass-gates as arc-based models
if the path from input to output is a 1 or 2 stage path.

Block Default Value Valid Range

param \"arc\" EnumeratedNoCase("pin, arc")

ccsn_use_enhanced_hw_method
Direct SiliconSmart to use enhanced algorithm to calculate height and width for
ccsn characterization .

Block Default Value Valid Range

param 1 Flag()

ccsn_use_enhanced_miller_cap
This parameter when enabled uses an enhanced method to determine miller
cap for CCSN characterization. This should result in better reciever modeling.

Block Default Value Valid Range

param 1 Integer(0,2)

ccsn_use_optimal_node_selection_method
This parameter causes SiliconSmart to use different internal node selection
algorithm for CCB outputs. If the value is 0, then the source/drain node of a
MOSFET is selected. If the value is 2, the node with least average resistance to
all source and sinks is used. If the value is 3, the node name with shortest

778 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

length is used. If the value is 1 (default), the node is selected based on a

optimization algorithm.

Block Default Value Valid Range

param 1 Integer(0,3)

ccsn_use_partial_netlist
Enables a CCSN partial CCB cut for user-specified cells. This parameter is
specified at the cell-level with the set_config_opt command.

Note: If the option -use_partial_netlist is specified with the

configure command, the ccsn_use_partial_netlist
parameter will not take effect.

Block Default Value Valid Range

param 0 Flag()

To apply the partial netlist flow to all cells:

set_config_opt ccsn_use_partial_netlist 1

To apply the partial netlist flow to a particular set of cells (where cells
contains the set of cells where the partial CCB cut flow will be used):
set_config_opt -cell cells ccsn_use_partial netlist 1

ccsp_cross_point_selection
For multi-output cells, the cross-type CCSP tables contain duplicated cross-
points with slightly different data, which will cause LBDB-860 errors when
compiled by LC. To ensure data consistency, data in one of the duplicated
points is selected to replace the data in the other cross-points.
If this parameter is set to alphabetical, the cross-point is selected
alphabetically using the name of the output pin associated with the data point.
Otherwise, the selection is determined by the processing order of the
pg_current vectors, which sometimes leads to arbitrary changes of the

SiliconSmart ACE User Guide 779

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

CCSP waveforms for the cross-points due to a different selection of cross-point

data.

Block Default Value Valid Range

param nondeterministic alphabetical, nondeterministic

cdpl_alt_submission
By default, CDPL submits workers through interactive interface of qsub or bsub.
This option will let CDPL submit workers in non-interative mode to prevent it
from violating some special farm policy in customer sites.

Block Default Value Valid Range

param 0 Flag()

cdpl_host_file
Specifies the CDPL host file to enable customized configuration of farms.
Please refer to the CDPL guide for the hosts.cfg file format.

Block Default Value Valid Range

param \"\" String()

cdpl_long_task_alert
This option lets CDPL issue a warning if it takes exceptionally long time for
some tasks to finish.

Block Default Value Valid Range

param 3600 Integer(60, 360000)

780 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

cdpl_submission_cmd
Specifies customized submission command instead of the usual farm
commands supported by CDPL. This option only comes into effect when
cdpl_alt_submission is set to 1.

Block Default Value Valid Range

param \"\" String()

cdpl_submission_timeout
This option controls the timeout tolerance of which CDPL waits for the farm to
obtain a submitted worker. Default value is 0, meaning that CDPL will wait
forever.

Block Default Value Valid Range

param 0 Integer(0, 36000)

cdpl_task_max_lifespan
Defines a limit on the maximum execution time of a task (in minutes). Once a
task exceeds the time limit, it will be immediately killed and all simulation
progress will be lost. It is recommended to use this option with auto_fix to
prevent random hanging tasks.

Block Default Value Valid Range

param 1200 Integer

SiliconSmart ACE User Guide 781

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

cdpl_worker_max_tasks
Limit of maximum number of tasks that an FSE worker can execute. Warning:
setting a small number for this option will impact performance.

Block Default Value Valid Range

param -1 Integer(-1,500000)

cdpl_worker_timeout
Idle timeout threshold in seconds for CDPL workers.

Block Default Value Valid Range

param 600 Integer(30,100000)

cell_families
This parameter is used to categorize cells into separate subsets of families. It is
specified as a list of list of cell names.

Block Default Value Valid Range

param \"\" List(new List(new String()))

cell_type
One of stdCell, ioCell, or memory. The SiliconSmart uses some heuristics to
detect the cell type and uses this for the license checking.

Block Default Value Valid Range

param \"\" String()

782 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

char_engine_max_lifespan
This parameter defines a lifespan (in minutes) for characterization engines and
workers. Any characterization engine or worker that exceeds this limit will
terminate itself when its current job is completed.

Block Default Value Valid Range

param 1200 Integer

check_pins_in_netlist
Checks the netlist for pins and SPICE nodes. When set to 1, the parameter
checks:
1. Consistency of pin names between the instance file and netlist.
2. Whether internal nodes in add_pin statements are present in the netlist.
For example:
add_pin name -spice_node int_node

In the above, check_pins_in_netlist will check to see if int_node is

present in the netlist.

Block Default Value Valid Range

param 0 0, 1

check_sof
Check SOF files after characterization tasks are done.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 783

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

check_templates
Check template files (.t) after configure tasks are done.

Block Default Value Valid Range

param 0 Flag()

combine_delay_and_cin
Direct SiliconSmart to do timing and pin capacitance measurements for each
arc and pin respectively from delay deck.

Block Default Value Valid Range

param 1 Flag()

combine_energy_and_cin
Direct the SiliconSmart tool to do energy and pin capacitance measurements in
the same deck for non-propagating states.

Block Default Value Valid Range

param 1 Flag()

combine_lvf_cin
Directs the SiliconSmart tool to perform statistical timing and pin capacitance
measurements for each arc and pin, respectively, from statistical delay deck.

Block Default Value Valid Range

param 0 0, 1

784 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

combine_timing_and_power
Directs SiliconSmart to perform timing and energy measurements for each arc
from the delay deck.

Block Default Value Valid Range

param 1 Flag()

compact_ccs_tolerance
tolerance for ccs waveform compression to generate compact ccs model

Block Default Value Valid Range

param 0.01 Float(1e-6, 0.1)

configure_all_states_for_ccb
Direct SiliconSmart to configure and characterize all the possible states for a
ccb.

Block Default Value Valid Range

param 0 Flag()

configure_constraint_delay
If a setup or recovery constraint exists for an input pin, SiliconSmart measures
delay with the constraining pin at minimum setup. This is best used when
constraint_style is set to pushout-degradation, which ensures that the setup/
hold time is not so aggressive that it would be unstable.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 785

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

configure_internal_node_arcs
When set to 1, then appropriate timing arcs from and to internal node are
created during the configure step using the functional description of the cell.

Block Default Value Valid Range

param 0 0, 1

configure_from_function
Use the function-based analysis method.

Block Default Value Valid Range

param 1 Flag()

configure_from_structure
Use the FR structural description for configuration, if available. This parameter
is used to enable the vector generator module.

Block Default Value Valid Range

param 0 Flag()

configure_preferred_secondary_input
This parameters accepts a list of pin names that will be used as a priority list.
Suppose for a given state, an arc can be constructed with multiple switching
inputs. If there are multiple possibilities for the secondary switching pin, those
set of pins will be considered in the order of priority given by this parameter.

Block Default Value Valid Range

param empty_list() List(new String())

786 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

configure_write_fugues
Write a fugue description file after configuration.

Block Default Value Valid Range

param 0 Flag()

configure_zdisable_pull
If a three-state output has a pull up/down/middle resistor built in, then it is
possible to measure some disable arcs as a delay to an output transition rather
than the standard current-based methodology. If that is desired then this
variable should be set to the name of the supply to which the pull resistor is
attached.

Block Default Value Valid Range

param \"\" String()

constraint_exclude_outputs
List of output pins to be excluded from the stimulus while performing a
constraint measurement. This is relevant in the context of reducing the
observable nodes for constraints when multiple choices are available for a
given arc.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 787

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

constraint_glitch_time_delta
Interval between an expected edge and an opposite edge indicating a failed
transition.

Block Default Value Valid Range

param 1e-15 Float(0.0, 1e-3)

constraint_matched_internal_state
Normally a constraint measurement is designed so that an output is
transitioning when the constraint passes. In many cases (flops) this will mean
that the setup and hold (or recovery and removal) for the same transitions will
be measured for different internal states.
This parameter reverses the preference for hold and removal so that the same
internal state will be used for hold as for setup and for removal as for recovery.

Block Default Value Valid Range

param 0 Flag()

constraint_mode
Controls the method used to acquire setup and hold constraints. The methods
are described in See the Methodology in Chapter 11, Timing Measurements.

Block Default Value Valid Range

param \"independent\" Enumerated("independent,

dependent, dependent-setup,
dependent-hold")

788 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

constraint_monotonicity_tolerance_pct
It is the tolerance value by which the value will be adjusted if a non-
monotonicity is detected.

Block Default Value Valid Range

param 1 Integer(1,None)

constraint_outputs
List of output pins to be considered in evaluating constraints.

Block Default Value Valid Range

param empty_list() List(new String())

constraint_pulse_cratering
Allow the input pulse for mpw and combined setup and hold to reduce to less
than a full rail transition. This does not apply to if driver_mode is active.

Block Default Value Valid Range

param 0 Flag()

constraint_seed_by_slew
Specifies the step size used while expanding the constraint window during
constraint measurement. This value is multiplied by each average input slew to
determine the uncertainty of the initial constraint seed. Set this to 0 to disable.

Block Default Value Valid Range

param 0.3 Float(0.0, 2.0)

SiliconSmart ACE User Guide 789

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

constraint_seed_step
Specifies the step size used while expanding the constraint window during
constraint measurement.

Block Default Value Valid Range

param 1.99 Float(0.9, 1000.0)

constraint_seed_values
Specifies the default values used for independent setup and hold constraint
acquisitions. The defaults help reduce the amount of simulation time by
providing a good initial guess.
This parameter can be set to a scalar value based on the input transition times
of the data and clock pins. See Constraints in Measurement and Modeling
Methodology.

Block Default Value Valid Range

param empty_list() LookupTableType()

constraint_simulated_seed
If there are no seed values provided by the user to find constraint values within
the constraint resolution, the SiliconSmart tool will need to simulate a number
of times. This parameter can artificially generate these seed values by creating
a 2x2 table to estimate the values for the entire table and use those values as
the seed.
The default value is 2, which means this method is applied for cell type memory
but not for standard cells. When set to 1, this method is applied irrespective of
cell type. When set to 0, this method is not used.

Block Default Value Valid Range

param 2 0, 1, 2

790 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

constraint_simulated_seed_acq_based
ACE feature. To create simluated seed for each when condition.

Block Default Value Valid Range

param 0 Flag()

constraint_simulated_seed_finesim_mode
Simulator option to be used for constraint seed simulations.

Block Default Value Valid Range

param \"default\" String()

constraint_simulated_seed_simulator
Simulator to be used for constraint_simulated_seed related simulations.

Block Default Value Valid Range

param \"default\" Enumerated("default, hspice,

hspice_cs, smartspice, spectre,
spectre11, eldo, msim, tispice, finesim,
finesim_embedded,
finesim_embedded_spectre, lynx,
eldo_native, finesim_embedded_eldo,
mica")

constraint_simulation_mode
Can be set to full (original simulator), fse (FSE + sign off (original simulator)), or
hybrid (FSE + original simulator).

Block Default Value Valid Range

param \"full\" Enumerated("full, fse, hybrid")

SiliconSmart ACE User Guide 791

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

constraint_trigger_node
Specifies either data pin or clock pin as the trigger pin. Trigger pin is the pin
from which delay will be measured up to the internal node which is being
monitored.

Block Default Value Valid Range

param empty_list() Dict()

construct_ncx_templates
Enables the construction of NCX templates.

Block Default Value Valid Range

param 0 Flag()

current_absolute_tolerance
Absolute tolerance for comparing current values in output_current vectors.

Block Default Value Valid Range

validation 0.04 Float()

current_relative_tolerance
Relative tolerance for comparing current values in output_current vectors.

Block Default Value Valid Range

validation 0.01 Float()

792 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

cut_netlist
Specifies the netlist to use for the circuit under test. This can be overridden for
different measurements and operating conditions. If a relative path is used, the
root directory is the netlists directory. When unspecified, uses the cell name
and netlist_extension.

Block Default Value Valid Range

param \"\" String()

cut_stat_netlist
Specifies the parameterized netlist which is generated by the
analyze_netlists -statistical command for the statistical
characterization.

Block Default Value Valid Range

param none String()

datasheet_truth_table
This parameter accepts a list of lists of strings for the user supplied truth table
in the datasheet.

Block Default Value Valid Range

param empty_list() List(new List(new String()))

dc_current_absolute_tolerance
Absolute tolerance for dc_current table comparison. Used by the
compare_library command. Reports failures in the report if error is larger than

SiliconSmart ACE User Guide 793

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.01 Float()

dc_current_product_tolerance
Product tolerance for dc_current table comparison. Here product is the
relative_tolerance multiplied by the absolute_tolerance. Used by the
compare_library command. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

dc_current_relative_tolerance
Relative tolerance for dc_current table comparison. Valid value range is
between 0 and 1. Used by the compare_library command. Reports failures in
the report if error is larger than the specified tolerance. Note that all specified
tolerances have to be exceeded for an error to be reported. A value of zero
disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

794 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

dc_current_threshold
If the parameter make_small_dc_current_value_as_zero is on and if the
absolute value of dc_current is less than or equal to dc_current_threshold
value then the dc_current value is made as zero.

Block Default Value Valid Range

param 1e-40 Float()

default_load_position
Specifies position of load in load table.The value of load corresponding to this
position and the value of slew (see default_slew_position) will be used in
selecting default arc. This selection is controlled by the
default_position_selection parameter.

Block Default Value Valid Range

param 1 Integer(1, none)

default_netlist_size
This parameter is used to skip the evaluation of the .inst file when calculating
job weight. When set to non-zero, SiliconSmart uses it as the netlist file size; or
SiliconSmart will evaluate the .inst file to get the real file name and size.

Block Default Value Valid Range

param 0 Integer(0, None)

SiliconSmart ACE User Guide 795

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

default_position_selection
Ensures default arc selection based on slew and load value. You can give
position of slew and load (see default_load_position and
default_slew_position) along with this parameter.

Block Default Value Valid Range

param 0 0, 1

default_slew_position
Specifies position of slew in slew table. The value of slew corresponding to this
position and the value of load (see default_load_position) will be used in
selecting the default arc. This selection is controlled by the
default_position_selection parameter.

Block Default Value Valid Range

param 1 Integer(1, none)

delay_based_constraint_mode
Enables path-based constraint analysis to reduce characterization time of
setup and hold constraints for memories. A value of off disables path-based
constraint analysis.

Block Default Value Valid Range

param \"off\" Enumerated("off, on, unchecked")

delay_matching_cin
Enable the delay matching methodology for pin capacitance measurement.
Matching of delay is done against a driver precharacterization data which
contains a table of capacitance values and the resulting delay.

796 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

The parameter delay_matching_cin_driver is used to specify the driver. The

driver can be either a buffer or an inverter.

Block Default Value Valid Range

param 0 Flag()

detect_internal_power_nodes
flag to detect internal power nets.

Block Default Value Valid Range

param 1 Flag()

detect_internal_power_nodes_for_pruning
flag to detect internal power and supply nets for pruning.

Block Default Value Valid Range

param 1 Flag()

differential_delay_mode
Controls the method for measuring delay to/from a differential pin pair:
■ If zdiff, applies to differential mode for zenable measurement; voltage for
z-state is set to middle of the power rails for both pin and its complementary
pin.
■ If crossover, measure at the crossover point.

SiliconSmart ACE User Guide 797

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
If single, treat the pin as a normal single-ended pin.
■
if legacy, use the original method, measured relative to the partial swing
rails.

Block Default Value Valid Range

param crossover Enumerated("single, crossover,

legacy, zdiff")

differential_delay_probe_style
Influences the measurement style used to probe differential output crossovers
when differential_delay_mode is crossover. If cross_first, the first cross of the
differential output pair, after the related input(s) toggle(s) is considered as the
crossover point. When cross_last, the last cross between the differential output
pair, after the related input(s) toggle(s) is considered as the crossover point.
rise_fall infers the crossover point as the time, after the related input(s)
toggle(s), when the differential output pair toggles in the desired direction and
equal in voltage.

Block Default Value Valid Range

param rise_fall Enumerated("rise_fall, cross_last,

cross_first")

differential_pair_timing_duplication
This parameter restricts SiliconSmart from automatically copying timing table
for differential output pair. By default, for a differential output pair, the data is
usually copied from one pin to the other if any of the output pin function is
undefined. Setting differential_pair_timing_duplication to 1 will
disable the copying. The default is 0.

Note: If configure_from_function is 0, then this parameter is not

needed to disable the copying.

Block Default Value Valid Range

param 1 0, 1

798 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

dio_model_names
Names of diode models used by netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

disable_negative_power_adjustments

Block Default Value Valid Range

param 0 Flag()

disable_sim_stats

Block Default Value Valid Range

param 0 Flag()

do_zero_modeling
Used along with enable_rechar_reporting param to follow zero modeling for
rechar reporting

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 799

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

dontcare_bias_on_output
If true (default), dontcare_bias is used to force output and internal pin state. If
false, then not.

Block Default Value Valid Range

param 1 Flag()

dontcare_values
Specifies a list of values which apply to the pins specified with dontcare_pins.
The values can 0 or 1 and must match one-for-one with the pin list.

Block Default Value Valid Range

param empty_list() List(new Enumerated("0, 1, Z"))

driver_load_steps
Specifies the number steps the output capacitance is stepped through when
characterizing a cell to be used as an active driver. A greater number of steps
improves the predictability of the input slew rate to the CUT, at the expense of
run time.

Block Default Value Valid Range

param 200 Integer(1,None)

800 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ecsm_power_modeling_load_indices
This parameter specifies the load indices to be used for ecsm power modeling.
By default all the characterized load indices are modeled. But this parameter
can be used to model a subset of the load indices.

Block Default Value Valid Range

param empty_list() List(new Integer())

ecsm_power_modeling_slew_indices
This parameter specifies the slew indices to be used for ecsm power modeling.
By default all the characterized slew indices are modeled. But this parameter
can be used to model a subset of the slew indices.

Block Default Value Valid Range

param empty_list() List(new Integer())

ecsm_threshold_pcts_fall
List of threshold percentages for measuring ecsm capacitance fall

Block Default Value Valid Range

param empty_list() List(new Float(0.0, 1.0))

ecsm_threshold_pcts_rise
List of threshold percentages for measuring ecsm capacitance rise

Block Default Value Valid Range

param empty_list() List(new Float(0.0, 1.0))

SiliconSmart ACE User Guide 801

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

em_analyze_power_nets
When set to 0, power nets will not be included in EM analysis. The default is 1.

Block Default Value Valid Range

param 1 0, 1

em_table_with_current_types
Generate separate EM toggle rate tables for different current types (average,
RMS, peak) . The default is 0.

Block Default Value Valid Range

param 0 Flag()

em_threshold_simulator
Specifies the type of simulator used for EM current threshold calculation. The
only supported simulation is CustomSim (xa).

Block Default Value Valid Range

param \"xa\" Enumerated("xa")

em_threshold_simulator_cmd
Sets the command used by SiliconSmart to invoke the simulator for EM current
threshold calculations. The format of the command should be similar to an
actual command-line execution of the simulator, with the string [input_deck]
used in place of the input file, and [listing_file] for the output file. [input_deck]
and [listing_file] are automatically replaced with the file names generated by

802 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

SiliconSmart when the command defined by simulator_cmd is issued. The

default value is xa [input_deck] -o [listing_file].

Block Default Value Valid Range

param \"xa <input_deck> -o String()

<listing_file>\"

em_threshold_tolerance
Specify a value in Amperes for EM current thresholds below which the
threshold is treated as zero and is ignored.

Block Default Value Valid Range

param 2.5e-18 Float(0.0, 1.0e-12)

em_use_xba
Enables the extended back-annotation (XBA) flow for EM current threshould
calculation by CustomSim (xa). The default is 1.

Block Default Value Valid Range

param 1 Flag()

enable_ac_decap
This is a boolean parameter which is applied to intrinsic capacitance
characterization in CCS. If set to true, ac analysis is used in characterizing
intrinsic capacitance. The default is 0.

Note: For FineSim, only version 2015.06 and later supports this
parameter.

Block Default Value Valid Range

param 0 0, 1

SiliconSmart ACE User Guide 803

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

enable_ac_decap_merge
This is a boolean parameter which is applied to intrinsic capacitance
characterization in CCS using AC analysis. If set to true, Siliconsmart tries to
merge netlists to improve performance. The default is 0. Note that if
enable_ac_decap_merge is set to true then enable_ac_decap is automatically
set to true.

Note: For FineSim, only version 2015.06 and later supports this
parameter.

Block Default Value Valid Range

param 0 0, 1

enable_cache
Use this parameter to enable or disable the caching mechanism for
evaluations. When enabled, the simulation results will be cached for the first
time and then for other simulations, the cache is checked first. Simulation is
avoided if there are cache hits. Cache checking is disabled by default.

Block Default Value Valid Range

param 0 0, 1

enable_cell_leakage_power_modeling
When true, the 'cell_leakage_power' attribute will be modeled for the cell even if
the value of the parameter 'liberty_multi_rail_format' is v1 or v2.

Block Default Value Valid Range

param 0 Flag()

804 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

enable_dc_leakage
This is a Boolean parameter which applies to leakage current. If set to true, dc
analysis is used in measuring leakage currents. If set to false, it uses transient
analysis in measuring leakage currents.

Block Default Value Valid Range

param 0 Flag()

enable_exhaustive_modeling_of_ccbs
Direct SiliconSmart to model all the possible ccbs as ccsn_first_stage or
ccsn_last_stage when multiple ccbs are available.

Block Default Value Valid Range

param 1 Flag()

enable_external_simulator_pruning
Enables netlist pruning algorithms to employ standalone, external simulators.
Currently, only FineSim is supported. When this option is disabled, the
embedded FineSim engine is used regardless of the simulator type, and will
require the availability of the requisite license features.

Block Default Value Valid Range

param 0 0, 1

enable_fast_sweep
Enables FSE fast sweep.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 805

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

enable_fse_log
Enables FSE log file.

Block Default Value Valid Range

param 0 Flag()

enable_gated_hold_constraint
When enabled, the SiliconSmart tool uses gated measurements for hold
constraint. This means that hold constraint will use glitch measurements on the
output to find out the hold value under all circumstances as much as possible.

Block Default Value Valid Range

param 0 0, 1

enable_macro_pruning
Enables the same netlist pruning algorithm as memory to run for before
simulation.

Block Default Value Valid Range

param 0 Flag()

enable_memory_pruning
Enables the netlist pruning algorithm to run for memory before simulation.

Block Default Value Valid Range

param 0 Flag()

806 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

enable_netlist_pruning
Enables netlist pruning for noise propagation measurements. See the Netlist
Pruning section in the Characterization and Modeling chapter for more
information.

Block Default Value Valid Range

param 0 Flag()

enable_parallel_sweeps
Simulates sweeps across multiple decks in parallel.

Block Default Value Valid Range

param 0 0, 1

enable_parasitic_sweep
A parameter which is applied to intrinsic parasitic characterization in CCS. This
enables voltage sweep of intrinsic capacitance and resistance. Use
numsteps_voltage to set the number of steps in the voltage sweep. The default
is 0.

Block Default Value Valid Range

param 0 0, 1

enable_rechar_reporting
Enables rechar reporting mechanism.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 807

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

enable_status
Enables support of status command.

Block Default Value Valid Range

param 1 Flag()

energy_fast_mode_leakage
Conducts leakage measurement after energy measurement, when
energy_fast_mode is set to 1.

Block Default Value Valid Range

param 0 0, 1

energy_fast_mode_leakage_interval
Sets interval of conducted leakage measurement after energy measurement,
when energy_fast_mode is set to 1.

Block Default Value Valid Range

param list(1.1, 1.2)</ List(new Float(1.0, 5.0))

ensure_constraint_monotonicity
Any non-monotonicity detected in the characterization flow will be flagged by a
warning.

Block Default Value Valid Range

param 0 Flag()

808 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

event_rank
This parameter specifies a list of possible events for an arc in order from best to
worst. It takes a list of pairs consisting of a Boolean expression representing
states and a string representing the event identifier. Event ids are typically used
in cases where the same state can be represented by multiple events eg.,
cases involving multiple switching inputs. Only one of event_rank or state_rank
needs to be specified. If both parameters are specified, then event_rank is
used and state_rank is ignored.

Block Default Value Valid Range

param empty_list() List(new String())

excluded_acquisitions
Acquisitions will be matched against this list and excluded if they match any
one of the elements.

Block Default Value Valid Range

param empty_list() List(new String())

extrapolate_ccs_cin_slew
Controls whether to extend the slew range of ccs cin tables to cover the normal
slew range.

Block Default Value Valid Range

param 0 0, 1

SiliconSmart ACE User Guide 809

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

finesim_so_path
If available, use {finesim_so_path}/{platform}/lib/libfinesim.so for
finesim_embedded.

Block Default Value Valid Range

param \"\" String()

force_removal_recovery_modeling
Used with removal and recovery arcs. When set to 0, the SiliconSmart tool will
skip modeling removal_rising when both rising and falling constraints are
characterized. When set to 1, the tool will write out only rising constraints for
removal_rising. Similar logic applies to removal_falling,
recovery_rising, and recovery_falling arcs.

Block Default Value Valid Range

param 0 0, 1

fr_archive_condition_on_failure
Determines whether the FR results are archived as a compressed tar file
(compress, no).

Block Default Value Valid Range

param \"yes\" Enumerated("yes, no, compress")

810 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

fr_archive_condition_on_success
Determines whether the FR results are archived as a compressed tar file
(compress, no).

Block Default Value Valid Range

param \"no\" Enumerated("no, compress")

fse_preprocess_cmd
Sets the command used by SiliconSmart to preprocess for simulation when fse
is used. It is used with fse_user_cmd.

Block Default Value Valid Range

param simulator_cmd String()

fse_user_cmd
run user command before simulation.

Block Default Value Valid Range

param 0 Flag()

gate_leakage_time_scaling_factor
SiliconSmart uses a predefined simulation time to calculate the leakage current
through various supplies and also the gate leakage current through the inputs.
This simulation time used by SiliconSmart is sufficient to capture the correct
polarity of leakage currents most of the time. However, for some cells, this
simulation time may not be sufficient enough to capture the correct polarity of
gate leakage especially if it changes very slowly over time. (This could be
verified by looking at the nature of the current waveform using FineWave).
In that case, the user may be given a warning during modeling that the gate
leakage current for a particular input pin for some when condition (say 'W') is

SiliconSmart ACE User Guide 811

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

less than the value which is possible for that state. In such cases, the
parameter 'gate_leakage_time_scaling_factor' should be used to increase the
total simulation time. The default value of this parameter is 1.0 which means
the gate leakage will be measured between (1*pp) and ((1*pp)+pp) under
default conditions where pp equals 1.32e-8s.
The user can set the parameter 'gate_leakage_time_scaling_factor' to an
appropriate value such as 50.0 for example and then reconfigure,
recharacterize (after deleting the cache) and model the cell. This will measure
the gate leakage current between (50*pp) and ((50*pp)+pp) [if it is set to 50.0].
If the gate leakage current for some when conditions is still unexpected and/or
of reverse polarity, it means that the time scaling factor 50.0 is not sufficient.
The parameter needs to be set to a larger value may be 75.0 or 100.0 or 150.
The user will need to reconfigure, recharacterize the cell every time (after
deleting the cache), this parameter is set to a new value.

Block Default Value Valid Range

param 1.0 Float(0.0, 1e3)

generate_all_ccbs_after_passgate
Direct SiliconSmart to create all the ccbs after the pass-gate.

Block Default Value Valid Range

param 1 Flag()

graphviz_location
This parameter specifies the path to the location of the Graphviz directory.

Block Default Value Valid Range

param \"[get_install_path]/etc/ String()

graphviz-2.28.0\"

812 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

gzip_cellmodel_libs
Provides control over gzipping of intermediate library files under models/liberty/
cellmodels..

Block Default Value Valid Range

param 0 0, 1

harness
This parameter is usually used with 'set_config_opt' command to specify the
name of a harness created with the 'create_harness' command to be applied to
the cell.

Block Default Value Valid Range

param \"default\" String()

HDL_cell_postprocess
Runs a script after HDL modeling is complete. The script name supplied by this
parameter is passed to the SiliconSmart tool and is executed after the HDL
modeling is complete. The file name passed as the first argument to that script
is the main model file: char_point/models/{verilog|vital}
For example:
# set HDL_cell_postprocess parameter with script name:
set_config_opt HDL_cell_postprocess myScript.tcl

# model command with library name myStdCellLib

model -verilog -output myStdCellLib
…
# <eof>

SiliconSmart ACE User Guide 813

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

After the model command creates Verilog , the script HDL_postProcess.tcl is

run and the file name “myStdCellLib.v” for Verilog is passed to the script
“myScript.tcl” as the first argument:
########################
# myScript .tcl
########################

# first argument is /char_directory/models/verilog/myStdCellLib.v

# open argument as file name:

set HDL_file [lindex $argv 1]
set fh [open $HDL_file “r”]

# do something with the HDL file:

while { [gets $fh data] >= 0 } {
puts $data
}

Block Default Value Valid Range

param none String()

hdl_vector_time_step
This specifies the delay between test vectors in a Verilog test bench.

Block Default Value Valid Range

param 20 Integer(1,None)

hierarchy_separator
This is used to specify the hierarchy separator in the memory netlist to
Siliconsmart when it is used to created a pruned flat netlist. By default, the
value of the separator is ‘/’. However, in some cases, the hierarchy separator in
the netlist is determined with other characters like ‘|’. In such cases, this

814 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

parameter can be used to specify the correct character to as the hierarchy

separator.

Block Default Value Valid Range

param / String()

hsp_keep_model
Enable -share to keep the models across the tasks in one job in hspice client
server mode

Block Default Value Valid Range

param 1 Flag()

hspice_client
Use HSPICE client binary for performance.

Block Default Value Valid Range

param 1 Flag()

ibis_add_submodel
This is a Boolean parameter which applies to clamp generation in IBIS. The
default is true, generating [Add Submodel] when odt clamps are present in the
cell. If set to false, [Add Submodel] keyword is not generated and the currents
are accomodated in the clamping tables.

Block Default Value Valid Range

param 1 Flag()

SiliconSmart ACE User Guide 815

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ibis_ami
This parameter will enable AMI modeling for cells

Block Default Value Valid Range

param 0 Flag()

ibis_ami_bit_time
This parameter is to determine input bit series width

Block Default Value Valid Range

param 100e-12 Float(1e-15,1e-6)

ibis_ami_sample_interval
This parameter determines the internal sampling interval for AMI model
extraction.

Block Default Value Valid Range

param 1e-12 Float(1e-30,1e-6)

ibis_ami_taps
This parameter is to specify taps for a typical FIR filter. Example: set
ibis_ami_taps {-1, 0, 1, 2, 3}, which will specify a 5 taps filter

Block Default Value Valid Range

param List(0,1) List(new Integer())

816 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ibis_ami_weights
This parameter is to determine tap weights, must have same length as
ibis_ami_taps

Block Default Value Valid Range

param List(1.0,1.0) List(new Float())

ibis_c_comp_user_only
This is a Boolean parameter which decides on what value to use in C_comp. If
true, the user supplied values (ibis_c_comp_typ, ibis_c_comp_min,
ibis_c_comp_max) overrides the C_comp values characterized by
Siliconsmart. If false, the preference is given to the values generated by
Siliconsmart. The default value is false.

Block Default Value Valid Range

param 0 Flag()

ibis_clamping_curve_make_monotonic
This is a Boolean parameter which applies to all the pins in the cell. If true the
clamping curves of the IBIS model are forced to be monotonic. The default
value is true. This is because IBIS complains if there are non-monotonic curves
in the generated IBIS model.

Block Default Value Valid Range

param 1 Flag()

ibis_clamping_iv_analysis_mode_dc
This is a Boolean parameter which applies to both clamping and iv generation
in IBIS. If set to true, dc analysis is used in generating clamping and iv curves.

SiliconSmart ACE User Guide 817

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

The default is false which uses transient analysis to generate clamping and iv
curves.

Block Default Value Valid Range

param 0 Flag()

ibis_clamping_iv_num_points
Specifies the number of points to be sampled while characterizing a cell for IV
and clamping curves. For example, if you specify this parameter to be 200 and
the IV/clamping swing is from -1.8V to 3.6V, 200 points would be generated
between -1.8V and 3.6V. Then these 200 points would be reduced to 100
points that best describe the curve.
The IBIS specification limits the number of points in the IV/clamping curves to
100. The default number of steps generated is 90. Not that for this parameter to
work, you must set ibis_clamping_iv_analysis_mode_dc to true. SiliconSmart
supports a user-specified number of points only when the IV/Clamping
characterization is done using DC analysis.

Block Default Value Valid Range

param 90 Integer()

ibis_cref
Specifies the capacitance, resistance, and voltage used in the test loads.

Block Default Value Valid Range

param \"\" String()

818 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ibis_diff_pin_single_model
This is a Boolean parameter to control how many models to generate for a
differential pin pair. If set to true only one model is generated for a pair.
Otherwise models are generated for both pins and this is the default setting.

Block Default Value Valid Range

param 0 Flag()

ibis_odt_driver_only
For IBIS clamping, specifies whether a particular mode is only for drivers.

Block Default Value Valid Range

param empty_list() List(new String())

ibis_odt_linear_regression_max_scale
This parameter can be set to a floating point value between (-1.0,2.0]. For
example, if it is set to 0.5, the regression uses data till 0.5*logic_high_name.
The start point of the data range is determined using
ibis_odt_linear_regression_min_scale.

Block Default Value Valid Range

param 1.0 Float(-1.0,2.0)

ibis_odt_linear_regression_min_scale
This parameter can be set to a floating point value between [-1.0,2.0). For
example, if it is set to -0.5, the regression uses data from -

SiliconSmart ACE User Guide 819

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

0.5*logic_high_name. The end point of the data range is determined using

ibis_odt_linear_regression_max_scale.

Block Default Value Valid Range

param 0.0 Float(-1.0,2.0)

ibis_odt_mode
Specifies a comment for each ODT mode. All ODT modes must be defined
here. Use this parameter in configuration to determine state partitioning.

Block Default Value Valid Range

param empty_list() Dict(new String())

ibis_odt_mode_name
Specifies a name for each ODT mode keyed by condition. This parameter is
optional when specifying ODT modes and provides the flexibility to specify a
model name.

Block Default Value Valid Range

param empty_list() Dict(new String())

ibis_odt_pulldown_modes
Specifies whether a particular mode (keyed by condition) has a pull-down
resistor.

Block Default Value Valid Range

param empty_list() List(new String())

820 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ibis_odt_pullup_modes
Specifies whether a particular mode (keyed by condition) has a pull-up resistor.

Block Default Value Valid Range

param empty_list() List(new String())

ibis_odt_receiver_only
For IBIS clamping, specifies whether a particular mode is only for receivers.

Block Default Value Valid Range

param empty_list() List(new String())

ibis_pin_alias
This parameter is used with 'set_config_opt' command. This is useful for
renaming pin names in the IBIS model file. Example usage: set_config_opt -pin
PAD ibis_pin_alias PADQV The IBIS model file will contain model with name
starting with MPADQV instead of usual MPAD.

Block Default Value Valid Range

param \"\" String()

ibis_pin_mapping
This boolean parameter controls the appearance of the [Pin Mapping] section
in IBIS model. This section is recommended by IBIS standards not required.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 821

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ibis_plan_for_corner_merge
If you are generating typ, min, max corner data using separate characterization
points and you want to merge the data into a single IBIS file, you must set this
Boolean parameter to true in each one of the characterization points (typ, min,
max). When set to true, the simulation ranges in each corner are manipulated
so that the interpolation and extrapolation errors are minimized while merging.

Block Default Value Valid Range

param 0 Flag()

ibis_prog_driver_mode
Specifies a comment for each programmable driver mode. All programmable
driver modes must be defined here. Use this parameter in configuration to
determine state partitioning.

Block Default Value Valid Range

param empty_list() Dict(new String())

ibis_prog_driver_mode_name
Specifies a name for each programmable driver mode keyed by condition. This
parameter is optional when specifying programmable driver modes and
provides the flexibility to specify a model name.

Block Default Value Valid Range

param empty_list() Dict(new String())

822 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ibis_rref
Specifies the capacitance, resistance, and voltage used in the test loads.

Block Default Value Valid Range

param \"\" String()

ibis_single_pvt_corner_name
Suppose you have all the three corners (typ/min/max) specified and you want
to generate a single corner file with `min' values. This keyword must be set to
`min'. This keyword is ignored if you are generating IBIS data for all the three
corners in a single file.

Block Default Value Valid Range

param \"typ\" Enumerated("typ, min, max")

ibis_source
This parameter controls ibis source section which would be written to the ibis
files

Block Default Value Valid Range

param \"\" String()

ibis_typ_pvt
The first operating condition in active_pvts will be set as the typical PVT.

Block Default Value Valid Range

param \"\" String()

SiliconSmart ACE User Guide 823

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ibis_use_exact_mode_name
This is a boolean parameter which decides whether
ibis_prog_driver_mode_name and/or ibis_odt_mode_name is used
directly to construct model names. If not set, a mixture of cell and pin
information is used to construct model names. The default value is false.

Block Default Value Valid Range

param 0 Flag()

Two scenarios are detailed below.

Scenario 1: With ibis_odt_mode_name not set and with
ibis_prog_driver_mode_name set to the below:
{ S0&!S1 “TX1”
!S0&S1 “TX2”
S0&S1 “TX3”}

The above will generate an IBIS model with the following name convention:
[Model Selector]
| Model Description
|
TX1
TX2
TX3
|
[Model] TX1
[Model] TX2
[Model] TX3

Scenario 2: With ibis_odt_mode_name set and with

ibis_prog_driver_mode_name set to the below:
{ !PE “No_ODT”
PE&!PS “PD_ODT”
PE&PS “PU_ODT”
}

824 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

The above will generate an IBIS model with the following name convention:
[Model Selector]
| Model Description
|
TX1_No_ODT
TX2_No_ODT
TX3_No_ODT
TX1_PD_ODT
TX2_PD_ODT
TX3_PD_ODT
TX1_PU_ODT
TX2_PU_ODT
TX3_PU_ODT
|
[Model] TX1_No_ODT
[Model] TX2_No_ODT
[Model] TX3_No_ODT
[Model] TX1_PD_ODT
[Model] TX2_PD_ODT
[Model] TX3_PD_ODT
[Model] TX1_PU_ODT
[Model] TX2_PU_ODT
[Model] TX3_PU_ODT

ibis_validate_bit_slew
This parameter is used to set the slew of input PRBS vector in the validation
deck. NOTE: Siliconsmart generates validation decks for LVDS like differential
buffers. The quality of the IBIS file is measured using eye diagram. The eye
diagram generation requires a random stream of bits.

Block Default Value Valid Range

param 1e-10 Float(1e-15, 1e-7)

ibis_validate_bit_time
This parameter is used to set the bit time of input PRBS vector in the validation
deck. NOTE: Siliconsmart generates validation decks for LVDS like differential

SiliconSmart ACE User Guide 825

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

buffers. The quality of the IBIS file is measured using eye diagram. The eye
diagram generation requires a random stream of bits.

Block Default Value Valid Range

param 1e-9 Float(1e-15, 1e-6)

ibis_validate_input_pin_name
This parameter is used to set the input pin name in the IBIS Validation deck.
NOTE: Siliconsmart generates validation decks for LVDS like differential
buffers. The quality of the IBIS file is measured using eye diagram. The eye
diagram generation requires a random stream of bits.

Block Default Value Valid Range

param \"\" String()

ibis_validate_prbs_size
This parameter is used to set the size of input PRBS vector in the validation
deck. NOTE: Siliconsmart generates validation decks for LVDS like differential
buffers. The quality of the IBIS file is measured using eye diagram. The eye
diagram generation requires a random stream of bits.

Block Default Value Valid Range

param 50 Integer()

ibis_validate_terminating_resistor
This parameter is used to set the value of terminating resistor between
differential pins in the IBIS Validation deck. NOTE: Siliconsmart generates
validation decks for LVDS like differential buffers. The quality of the IBIS file is

826 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

measured using eye diagram. The eye diagram generation requires a random
stream of bits.

Block Default Value Valid Range

param 0 Float()

ibis_vcross_high
Used in [Receiver Threshold].

Block Default Value Valid Range

param 0 Float(-100.0, 100.0)

ibis_vcross_low
Used in [Receiver Threshold].

Block Default Value Valid Range

param 0 Float(-100.0, 100.0)

ibis_vdiff_ac
Used in [Receiver Threshold].

Block Default Value Valid Range

param 0 Float(-100.0, 100.0)

SiliconSmart ACE User Guide 827

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ibis_vdiff_dc
Used in [Receiver Threshold].

Block Default Value Valid Range

param 0 Float(-100.0, 100.0)

ibis_version
This parameter controls the ibis version number written to the ibis files (default:
4.1).

Block Default Value Valid Range

param \"4.1\" String()

ibis_vinh
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 2.0 Float(-100.0, 100.0)

ibis_vinh_max
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

828 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ibis_vinh_min
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

ibis_vinh_typ
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

ibis_vinl
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 0.8 Float(-100.0, 100.0)

ibis_vinl_max
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

SiliconSmart ACE User Guide 829

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ibis_vinl_min
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

ibis_vinl_typ
The minimum voltage for a high signal and the maximum voltage for a low
signal.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

ibis_vmeas
Voltage measurement reference used for propagation delay measurements.

Block Default Value Valid Range

param \"\" String()

ibis_vmeas_max
Voltage measurement reference used for propagation delay measurements.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

830 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

ibis_vmeas_min
Voltage measurement reference used for propagation delay measurements.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

ibis_vmeas_typ
Voltage measurement reference used for propagation delay measurements.

Block Default Value Valid Range

param 0.0 Float(-100.0, 100.0)

ibis_vref
Specifies the capacitance, resistance, and voltage used in the test loads.

Block Default Value Valid Range

param \"\" String()

ibis_vt_curve_make_monotonic
This is a Boolean parameter which applies to all the pins in the cell. If true the
VT curves of the IBIS model are forced to be monotonic. The default value is
true. This is because IBIS complains if there are non-monotonic curves in the
generated IBIS model.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 831

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ibischk_cmd
Sets the command used by SiliconSmart to run the IBIS golden parser on the
generated ibis file

Block Default Value Valid Range

param \"\" String()

ideal_netlist_ext
Specifies the filename extension (including the '.') for pre-layout cell netlists
used for EM current threshold simulation by CustomSim. Defaults to an empty
string.

Block Default Value Valid Range

param \"\" String()

import_explicit_points_per_arc
On import, the same explicit_points for different arcs may be combined into a
single parameter setting in the instance file. If this parameter is enabled, then
the parameter setting for each arc is kept separate.

Block Default Value Valid Range

param 0 Flag()

import_liberty_ndw
By default, this parameter is set to 0, which means the tool will use the driver
defined in the driver_mode parameter in configure.tcl. Set to 1 to

832 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

recharacterize the library using the driver waveform from the reference library.
This must be set before the import step.

Block Default Value Valid Range

param 0 0, 1

initial_delay_multiplier
This Option comes into picture when \"energy_fast_mode\" parameter is set to
1. This specifies which multiplying factor is to be multiplied with intial delay to
calculate duration of simulation time.

Block Default Value Valid Range

param 1 Integer(0, 50)

insert_liberty_default_ndw
Uses normalized driver waveforms in the imported liberty file to define the
driver for recharacterization

Block Default Value Valid Range

param 0 Flag()

init_internal_pins
When set to 1, the simulation netlist will contain initial node voltages for all
internal nodes based on the sensitization of the input pins for the particular
acquisition.
Internal pins are specified with the add_pin command and the related function
is specified with the add_function command. The framework setup is:
Example 463 Framework setup
add_pin in1 default -input
add_pin int1 default -internal -spice_node sp_node1
add_function intl {in1}

SiliconSmart ACE User Guide 833

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

Example 464 Example usage

set_config_opt -cell cell1 init_internal_pins 1

Note: For this option to be effective, the

separate_cell_initialization option should be set to
off, as it will override the pin settings.

Block Default Value Valid Range

param 0 0, 1

initialization_cycles
Specifies the number of times to cycle the inputs to the cell before taking the
measurements. The default value is 0.

Block Default Value Valid Range

param 0 Integer(0,None)

internal_ground_nets
This parameter specifies the list of nets in the spice netlist that can be treated
as ground nets for memories.

Block Default Value Valid Range

param empty_list() List(new String())

internal_ground_supply_spice_nets
This parameter specifies the list of nets in the spice netlist that can be treated
as ground nets in addition to the nets specified in the operating condition. This

834 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

could be the interface nets or some internal nets that the pruner cannot detect
in some cases. This can help to greatly improve the pruning for memories.

Block Default Value Valid Range

param empty_list() List(new String())

internal_nodes_transition_data
List of internal nodes to be monitored without the function description. The list
comprises triplets of node_name, pintype and the expected no. of transitions to
look for on that node during the constraint measurement. Any number of such
triplets can be specified in the list.

Block Default Value Valid Range

param empty_list() List(new String())

internal_power_nets
This parameter specifies the list of nets in the spice netlist that can be treated
as power nets for memories.

Block Default Value Valid Range

param empty_list() List(new String())

internal_power_supply_spice_nets
This parameter specifies the list of nets in the spice netlist that can be treated
as power nets in addition to the nets specified in the operating condition. This
could be the interface nets or some internal nets that the pruner cannot detect
in some cases. This can help to greatly improve the pruning for memories.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 835

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

intrinsic_cap_with_phase_diff
Internal flag to calculate intrinsic_cap where phase difference also taken into
account.

Block Default Value Valid Range

param 0 Flag()

io_retry
Number of retries of file I/O to tolerate network latency

Block Default Value Valid Range

param 3 Integer(0, 10)

job_scheduler
Specifies the job scheduler for SiliconSmart. You can set it to standalone, LSF,
or grid. Stand-alone mode allows multiple simulations to be performed in
parallel on the machine on which SiliconSmart is invoked. LSF mode uses
Platform LSF to distribute jobs to a network of resources. Grid mode uses Sun
Microsystem's Grid Engine load sharing software. The LSF and Grid Engine
software must be installed separately on the network for SiliconSmart to work.

Block Default Value Valid Range

param \"standalone\" EnumeratedNoCase("standalone, lsf,

grid, nc, custom")

keep_loading_effect_with_pruning
Specifies if the loading effect should be preserved with pruning. The default
behaviour is to preserve the loading effect which involves propagation of
switching activity in the netlist. If set to 0, the switching activity propagation will

836 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

not take place. This might give a very good pruning but inaccurate results.
Please be careful to use set this parameter to 0.

Block Default Value Valid Range

param 1 Flag()

leakage_current_substitution_value
This parameter takes effect when the parameter
'model_reverse_polarity_current' is set to 0 and the measured gate leakage
current or pg current is of reverse polarity. In this case, if the absolute value of
the leakage current is below this threshold value, we will make it small positive
number that is controlled by the value of this parameter.

Block Default Value Valid Range

param 0 Float(0.0, 1.0)

leakage_sum_threshold
Threshold for factor obtained from positive Current and negative. Depending on
this value the current adjustment will be done so that the sum of positive and
negative currents is 0.

Block Default Value Valid Range

param 0.1 Float(0.0, 1.0)

left_bus_identifier
String that separates a bus name from its bit number when naming each bit
separately. This parameter identifies the left separator.

Block Default Value Valid Range

param \"_\" String()

SiliconSmart ACE User Guide 837

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

liberty_attributes_at_bundle
When set to 0, the SiliconSmart tool will place the following attributes at pin-
level instead of at bundle-level:
■
capacitance
■
direction
■
fall_capacitance
■
input_voltage
■
max_transition
■
rise_capacitance
■
related_bias_pin
■
related_power_pin
■
related_ground_pin
■
and etc.
Attributes such as members, nextstate_type, etc., will remain at bundle-
level.

Block Default Value Valid Range

param 0 0, 1

liberty_blackbox_model
Do not generate function information in the liberty model.

Block Default Value Valid Range

param 0 Flag()

838 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

liberty_cap_unit
Specifies the units to use for capacitance values. Belongs in the default
parameter block. The values for this parameter are case-sensitive.
Example 465
set liberty_cap_unit 1ff|10ff|100ff|1pf|10pf|100pf

Block Default Value Valid Range

param 1pf 1ff, 10ff, 100ff, 1pf, 10pf, 100pf

liberty_cell_postprocess
Use this parameter to specify a Tcl script to post-process a Liberty model on a
per-cell level in a distributed mode along with modeling.
When the model command runs and a liberty_cell_postprocess script
exists, the SiliconSmart tool will run modeling and post-processing in parallel
for each cell specified in the script.
Set the parameter as below:
set_config_opt liberty_cell_postprocess /home/cell_post.tcl

where /home/cell_post.tcl is the location of the cell post-processing Tcl script.

Below is an example cell_post.tcl script for adding a custom attribute to the cell:
enable_api pub
catch {namespace import pub::*}

set lib_file_path [lindex $argv 0]

set lib [read_model -liberty $lib_file_path]
set cell [lindex [get_obj_list $lib type cell] 0]
set_obj_attr $cell [list characterized_on [clock format [clock
seconds] -format "%D %T"]]
write_model $lib $lib_file_path

Block Default Value Valid Range

param none Specified Tcl script

SiliconSmart ACE User Guide 839

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

liberty_combine_complementary_models
Combine complementary (rise/fall) models so that, for instance, a flop will have
a single timing group from clock, instead of two, one for D and one for !D.

Block Default Value Valid Range

param 1 Flag()

liberty_constraint_type
Used to override the usual constraint type when generating a Liberty model.
This is used if the constraint type derived by Siliconsmart from the pin types is
not what is wanted in the Liberty.

Block Default Value Valid Range

param \"default\" Enumerated("setup_hold,

recovery_removal, non_seq,
nochange, default")

liberty_current_unit
Specifies the unit for current (current_unit).

Block Default Value Valid Range

param 1mA String()

liberty_data_reduce
This parameter controls the type of operation performed on the data collected
for each when conditions listed for liberty_whens for energy, leakage, and

840 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

constraint arcs (constraint arcs include setup, hold, recovery, removal, mpw,
nochange). This parameter can be set to mean, max, min, or sum.

Block Default Value Valid Range

param mean mean, max, min, sum

liberty_fast_option
ACE feature. For debugging purpose if some one need to run old tcl function
mergeByWhen then (s)he should disable this flag .

Block Default Value Valid Range

param 1 Integer(0,1)

liberty_fill_out_power_with
Specifies what to put for power tables that do not really occur, whether to fill it
with zeroes or copy values from the opposite power edge.
In some cells/circuits with different functionality, it may happen that for a certain
arc, input/output can only transition in one direction and not both. So we may
be able to only measure/report rise_power or fall_power, but not both.
However, for Liberty format/syntax consistency, we still have to report both, so
the options for a power table that can actually not be measured for the circuit
are either to fill it with zeroes or copy values from the opposite power table.

Block Default Value Valid Range

param opposite_edge opposite_edge, zero

liberty_flavor
Controls the generation of the input_voltage and output_voltage
groups in generated Liberty models. The below details its usage:

SiliconSmart ACE User Guide 841

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

■
If set to 2007.03 or above, the SiliconSmart output library will allow CCS
power, CCS VA, and compact CCS formats and support switch cell specific
acquisitions (dc_current).
■
If set to 2008.09 or above, the SiliconSmart output library will contain the
back bias model if the modeling parameter model_back_bias is enabled.
■
If set to 2010.03, retention attributes, which are set through the
set_liberty_attributes and add_liberty_group commands in
the instance file, will be generated in the output Liberty file.
■
If set to 2006.06, the above mentioned Liberty constructs will not be
supported.

Block Default Value Valid Range

param 2007.03 2010.03, 2008.09, 2007.03, 2006.06

liberty_increasing_delay_with_ecsm
True value makes slew values monotonic in ECSM transition table data.

Block Default Value Valid Range

param 0 Flag()

liberty_increasing_delay_with_ccs
If true, liberty_increasing_delay_with_slew/load will NOT be
disabled by the presence of CCS or ECSM data.

Block Default Value Valid Range

param 0 Flag()

842 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

liberty_increasing_delay_with_load
Specifies the minimum delta between delay values in a table as load increases.
Belongs in the default parameter block.

Block Default Value Valid Range

param \"off\" OneOf(new Enumerated("off"), new

Float(0.0,None))

liberty_increasing_delay_with_slew
Specifies the minimum delta between delay values in a table as slew increases.
Belongs in the default parameter block.

Block Default Value Valid Range

param \"off\" OneOf(new Enumerated("off"), new

Float(0.0,None))

liberty_increasing_time_points
When set to 1, the SiliconSmart tool will shift large CCS reference time and
waveform time indexes properly to avoid accuracy degradation due to finite
precision.

Block Default Value Valid Range

param 1 0, 1

SiliconSmart ACE User Guide 843

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

liberty_increasing_transition_with_load
This parameter fixes slew monotonicity in both directions (increasing input slew
and increasing output load). When set to 1, the minimum delay that is used will
be based on liberty_increasing_delay_with_slew/load.

Block Default Value Valid Range

param 0 0, 1

liberty_leakage_power_unit
Specifies the unit for power values (leakage_power_unit).

Block Default Value Valid Range

param 1uW String()

liberty_max_capacitance
Controls the generation of the Liberty max_capacitance attribute. When set to
1 the attribute max_capacitance is set as upper limit of capacitive load for
output and inout pins. For output/inout pins, selects the minimum of the
maximum among all capacitive load indices for all timing arcs that terminate at
that pin(output/inout). The default value of this parameter is 1.

Block Default Value Valid Range

param 1 0, 1

liberty_max_capacitance_mode
Controls the generation of the Liberty max_capacitance attribute. When set to
0, the max_capacitance attribute is not modified. When set to 1 the attribute
max_capacitance is set as upper limit of capacitive load for output and inout
pins. For output/inout pins, selects the minimum of the maximum among all
capacitive load indices for all timing arcs that terminate at that pin(output/inout).

844 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

When set to 2, the max_capacitance is determined by the output capacitance

where the output transition = max_tout, or the maximum capacitance index if
max_tout is larger than the largest tout in the rise/fall_transition tables. The
default value of this parameter is 1.

Block Default Value Valid Range

param 1 0, 1, 2

liberty_max_transition
Controls the generation of the Liberty max_transition attribute. When set to 1
the attribute is generated in the published Liberty models. When the
-recharacterize switch is specified to the model command, SiliconSmart will
modify the max_transition attribute if liberty_max_transition is set to 1. The
default value is 0, in which case the attribute is not added or modified.

Block Default Value Valid Range

param 0 Flag()

liberty_min_capacitance
Controls the generation of the liberty min_capacitance attribute to all output
pins. When set to 1, the attribute is set to all output pins with the max of
minimum load index for each pin.

Block Default Value Valid Range

param 1 Flag()

SiliconSmart ACE User Guide 845

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

liberty_min_transition
Controls the generation of the liberty min_transition attribute to all inout pins.
When set to 1, the attribute is set to all inout pins with the max of minimum slew
index for each pin.

Block Default Value Valid Range

param 1 Flag()

liberty_minimize_constraint_when
When true (the default), the when attribute on a constraint group will be
reduced to the minimum needed to distinguish different cases of the same arc.
When false, the when attribute may include the enabling condition for that arc
as well.

Block Default Value Valid Range

param 1 Flag()

liberty_minimize_groups
Places fall and rise under the same timing/power table. Set this parameter to 0
to disable this behavior.

Block Default Value Valid Range

param 1 0, 1

liberty_minimize_timing_when
When set to 1 (default), the when attribute on a timing group will be reduced to
the minimum needed to distinguish different cases of the same arc.
When set to 0, pins will not be dropped from the when condition at any cost,
even for non-essential pins with a state that is implicit to the actual state.

846 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

For example, say that a timing group has only one pin in the when condition
such that cell_rise is possible for when = “d” and cell_fall is possible for
when = “!d”. If liberty_minimize_timing_when = 0, the SiliconSmart
tool will model these separately, each with its own when conditions. However, if
the user has specified model_default_timing_arcs as always, then in
addition to these two timing arcs, one default arc will be created which contains
cell_rise and cell_fall as before.
The result is shown below:
timing() {
when: ‘d’
cell_rise()
}

timing() {
when: ‘!d’
cell_fall()
}

timing() { //default arc that is still created

cell_rise()
cell_fall()
}

Block Default Value Valid Range

param 1 0, 1

liberty_multi_rail_format
SiliconSmart supports both multi-rail leakage modeling and liberty pg_pin
syntax. You can use the liberty_multi_rail_format parameter to enable this
functionality. Possible values for this parameters are none, v1 and v2. The
default value is none. The value v1 enables a older multi-rail power syntax. The
value v2 causes SiliconSmart to generate newer multi-rail format.

Block Default Value Valid Range

param not_specified none, v1, v2

SiliconSmart ACE User Guide 847

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

liberty_power_down_function
When true, the 'power_down_function' attribute will be modeled for the output
pins if the value of the parameter 'liberty_multi_rail_format' is v2.

Block Default Value Valid Range

param 0 Flag()

liberty_power_down_function_pins
Which pins to consider when determined the supplies/grounds to include in the
power down function.

Block Default Value Valid Range

param \"inputs_only\" Enumerated("inputs_only, output_only,

inputs_and_output")

liberty_resistance_unit
Specifies the unit for pulling resistance (pulling_resistance_unit). The
values for this parameter are case-sensitive.
Example 466
set liberty_resistance_unit 1ohm|1kohm|1mohm

Block Default Value Valid Range

param 1ohm 1ohm, 1kohm, 1mohm

848 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

liberty_select_min_period
By selecting one of the attribute best, worst or typ we can select the
corresponding best, worst or typ for min_period.By default it is worst.

Block Default Value Valid Range

param \"worst\" Enumerated("best, worst, typ")

liberty_select_min_pulse_width
By selecting one of the attribute best, worst or typ we can select the
corresponding best, worst or typ for min_pulse_width.By default it is worst.

Block Default Value Valid Range

param \"worst\" Enumerated("best, worst, typ")

liberty_state_independent
By selecting one of the attribute best, worst or best_and_worst we can select
the corresponding best, worst or best_and_worst arcs.By default it is off as a
result sis user will get default arc with other expected arcs. For best sis will add
min_delay_flag to true and for worst it will set false.

Block Default Value Valid Range

param \"off\" Enumerated("best, worst, off,

best_and_worst")

SiliconSmart ACE User Guide 849

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

liberty_statetable_for_gcl
When true, always convert cell function block to state tables for GCL-like
functions, i.e. those which would normally require a state_function on the
output.

Block Default Value Valid Range

param 1 Flag()

liberty_time_unit
Specifies the units to use for time values. The values for this parameter are
case-sensitive.
Example 467
set liberty_time_unit 1ps|10ps|100ps|1ns

Block Default Value Valid Range

param 1ns 1ps, 10ps, 100ps, 1ns

liberty_timing_type
Used to override the usual timing type when generating a Liberty model. It is
targeted at the case in which a clock pin must produce a combinational arc but
SiliconSmart does not recognize the cell as a clock gating cell and produces a
rising/falling_edge instead. This parameter should be set with set_config_opt
for particular arcs, that is set_config_opt -from clock liberty_timing_type comb.
It can also be used to force the use of rising/falling_edge or clear or preset for
timing_type, if that is required.

Block Default Value Valid Range

param \"default\" Enumerated("comb, seq, clear, preset,

default")

850 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

liberty_whens
This parameter is used specify the when conditions to use in the Liberty model
separate from the whens used from characterization. The state coverage of
each acquisition is compared to the liberty_whens for that acquisition, and
a model is added for each liberty_whens for which there is overlap. This
results in three cases: one model for each acquisition but with the when
condition modified; multiple models for each acquisition, which allows reduced
numbers of characterizations while maintaining a desired Liberty structure with
more models; and many acquisitions combined into a single model, which
allows a reduced size model with better accuracy than if just a single
acquisition was done.
For the many-to-one case, the model is created using
liberty_data_reduce for energy, leakage, and constraint arcs. Constraint
arcs include setup, hold, recovery, removal, mpw, and nochange. Other types
of models select an arbitrary instance for the many-to-one mode, so this mode
is not recommended.

Block Default Value Valid Range

param empty_list() List(new String())

lvf_check_errors
Specifies a list of LVF checks to be classified as errors (default: checks 0, 1, 2,
3, 5, 9, 10 reported as LVF_ERROR).

Block Default Value Valid Range

param list(0, 1, 2, 3, 5, 9, 10) List(new Integer())

SiliconSmart ACE User Guide 851

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

lvf_check_sigma_pct
If specified, LVF sanity checks will use the table to check sigma/nominal ratio
instead of a fixed number.

Block Default Value Valid Range

param empty_list() List(new Float())

lvf_check_slew_sigma_pct
If specified, LVF sanity checks will use the table to check slew sigma/nominal
ratio, otherwise it will fall back to using lvf_check_sigma_pct.

Block Default Value Valid Range

param empty_list() List(new Float())

lvf_check_suppress
Specifies a list of LVF checks to be suppressed during checking.

Block Default Value Valid Range

param empty_list() List(new Integer())

lvf_constraint_models
Specifies LVF constraint types to model. Supports: setup, hold, recovery,
removal, asynch_recovery, asynch_removal.

Block Default Value Valid Range

param setup, hold List("setup, hold, recover, removal,

asynch_recovery, asynch_removal")

852 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

lvf_constraint_seed_step
Specifies the step size used while expanding the LVF constraint window during
constraint measurement.

Block Default Value Valid Range

param 0.9 Float(0.49, 1000.0)

lvf_enable_sanity_check
When set to 1, enables LVF table sanity check in modeling.

Block Default Value Valid Range

param 1 0, 1

lvf_model_slew
Model LVF slew sigmas when turned on.

Block Default Value Valid Range

param 0 Flag()

lvf_param_abs_threshold
Specifies the absolute threshold of parameter sensitivity to be considered in
LVF screening.

Block Default Value Valid Range

param 3e-14 Float(0.0, 10.0)

SiliconSmart ACE User Guide 853

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

lvf_param_rel_threshold
Specifies the relative threshold, against nominal data, of parameter sensitivity
to be considered in LVF screening.

Block Default Value Valid Range

param 5e-4 Float(0.0, 10.0)

lvf_sigma_max
Upper bound of LVF sigma values for table checking.

Block Default Value Valid Range

param 1.0 Float(0, None)

lvf_sigma_min
Lower bound of LVF sigma values for table checking.

Block Default Value Valid Range

param 1e-6 Float(0, None)

lvf_sigma_scaling
Scales LVF sigma by the ratio of measured delay and input delay.

Block Default Value Valid Range

param 1 0, 1

854 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

lvf_to_ocv_input_pins
Specifies a list of input pins with which the OCV values are computed from LVF
table when generating OCV side tables.

Block Default Value Valid Range

param 1 0, 1

lvf_to_ocv_load_indices
Specifies the list of load indices (starting with 0) with which the OCV values are
computed from LVF table when generating OCV side tables

Block Default Value Valid Range

param empty_list() List(new Integer(0, None))

lvf_to_ocv_method
Specifies the method to select the value from LVF table for AOCV/POCV
computation (default is max).

Block Default Value Valid Range

param max min, mean, max

lvf_to_ocv_slew_indices
Specifies the list of slew indices (starting with 0) with which the OCV values are
computed from LVF table when generating OCV side tables.

Block Default Value Valid Range

param empty_list() List(new Integer(0, None))

SiliconSmart ACE User Guide 855

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

lvf_to_ocv_output_pins
Specifies a list of output pins with which the OCV values are computed from
LVF table when generating OCV side tables.

Block Default Value Valid Range

param empty_list() List(new String())

lvf_tol_early_to_late
Tolerance of LVF sigma ratio between early table and late table.

Block Default Value Valid Range

param 3.0 Float(1.0, None)

lvf_tol_sigma_to_nom
Tolerance of LVF sigma value to its nominal value (>1.0).

Block Default Value Valid Range

param 0.25 Float(0.0, None)

856 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

make_cdb_path

Block Default Value Valid Range

param \"\" String()

make_small_dc_current_values_as_zero
If this parameter is on, if the absolute value of dc_current is less than or equal
to dc_current_threshold value then the dc_current value is made as zero.

Block Default Value Valid Range

param 0 Flag()

max_constraint_iterations
Sets the maximum iteration limit for constraint measurements. This parameter
can be used for both the SiliconSmart native bisection method and the
simulator bisection method.
Example:
set_config_opt max_constraint_iterations 40

Block Default Value Valid Range

param 50 Integer(1, 1000)

maximum_stack_depth
Specifies the depth of nmos/pmos stack in a cell design, that may degrade
signal quality.

Block Default Value Valid Range

param 4 Integer(1, None)

SiliconSmart ACE User Guide 857

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

measure_side_input_power
Measures the power of side-input pins. The default is 0, which means the
SiliconSmart tool will only measure the energy consumed by a cell through the
power supplies. When this parameter is set to 1, then during NLPM power
measurements, the SiliconSmart tool will also include the energy going in and
out of a cell through side-input pins.
If the parameter model_power_per_supply is also enabled, then the energy
measured on a side-input is added to the internal power table of the same
power supply that is driving the side-input.
If the power on a side-input comes from a voltage domain not found in the
receiving cell, the energy on the side-input will be split up so that each
measured power supply gets an equal share.

Block Default Value Valid Range

param 0 0, 1

memory_ccsn_partial_netlist
To use the pruned netlist like a donut type for memory ccsn.

Block Default Value Valid Range

param 0 Flag()

miller_capacitance_check_tolerance_pct
Will raise warning if the ratio between miller capacitance and nldm capacitance
is more than miller_capacitance_check_tolerance_pct.

Block Default Value Valid Range

param 10 Integer(1,None)

858 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

miller_capacitance_edge_ratio
Will raise warning if the ratio between miller capacitance rise and miller
capacitance fall is more than miller_capacitance_edge_ratio.

Block Default Value Valid Range

param 5 Integer(1,None)

miller_output_slew
Slew to use to generate glitches for the Miller capacitance measurement.

Block Default Value Valid Range

param 7.9e-10 Float(1e-15, 1e-3)

min_disk_space
Specifies minimum disk space required to finish the characterization
successfully. A negative number will skip the check.

Block Default Value Valid Range

param -1.0 Float()

min_period_precharge_threshold_factor
This parameter sets the threshold for calculating the precharge delay of the bit-
lines from the last transition of the clock.

Block Default Value Valid Range

param 0.9 Float(0.1,1.0)

SiliconSmart ACE User Guide 859

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

min_period_with_precharge_delay
This parameter if set to 1 calculates the minimum period taking into account of
the precharge effects of the bitlines. In the default case, the minimum period is
calculated using the max of CLK->Q delay or the min_period.
When measuring the min_period of the clock pin, taking into account the
precharge delay of the bit line, you must call the following command explicitly
after running find_internal_nodes_for_constraint to get the bit line
node:
get_bit_line_node {<bit cell node name>}

For example, if the internal bit cell node is xi1/xi1/xi1/xi1_1/cored_, you must
use the following command: needs to call the following command:
get_bit_line_node {xi1/xi1/xi1/xi1_1/cored_}

This commands finds the bit line node and updates the instance file with the bit
line node name.Then, run the configure, characterize, and model
commands as a regular flow.

Block Default Value Valid Range

param 0 0, 1

minimum_constraint_sum_margin
Specifies the minimum constraint sum. The default is 0. If the setup+hold is
less than minimum_constraint_sum_margin (mcsm), the value is set to
mcsm. If mcsm is 0, the value is not adjusted and the flow is left untouched as
before. In this case, the rules which apply to model_neg_constraint_sum
will be used.
Additionally, the constraint sum will only be checked on the same edge (i.e.,
setup_rising+hold_rising, not setup_rising+hold_falling), though the opposite
edge is checked by default for the negative constraint sum.

Block Default Value Valid Range

param 0 0, 1

860 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

model_arc_and_pin_cap
Model both arc based and pin based receiver cap/ecsm cap

Block Default Value Valid Range

param 0 Flag()

model_as_non_unate
Determines when non_unate arcs should get created in the output library for
create_new flow.

Block Default Value Valid Range

param 0 Flag()

model_back_bias
Control the back bias support in Sis. To use this parameter user should specify
\'liberty_flavor\' as \'2008.09\'.

Block Default Value Valid Range

param 1 Flag()

model_bundle_bit_level
Bundle pins for a multi-bit cell can be represented in the Liberty model at either
the bundle level or the individual pin/member level. The SiliconSmart tool
supports either the bundle format or the individual pin/member format, but not
both together.
Setting the parameter model_bundle_bit_level allows the user to model
the bundles of the multi-bit cell at the individual pin/member level. In this case,
each pin/member of the bus has to be defined in the instance file.

SiliconSmart ACE User Guide 861

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

For example:
//defining individual pins
add_pin D1 default –input
add_pin D2 default –input
add_pin CK default –clock
add_pin Q1 default –output
add_pin Q2 default –output

//function definition at pin level

add_flop IQ0 IQN0 CK D1
add_flop IQ1 IQN1 CK D2
add_function Q1 IQ0
add_function Q2 IQ1

//defining the relation between pins and bundles

set_pins_to_bundle_map -bundle Q -pins { Q1 Q2 }
set_pins_to_bundle_map -bundle IQ -pins { IQ0 IQ1 }
set_pins_to_bundle_map -bundle IQN -pins { IQN0 IQN1 }
set_pins_to_bundle_map -bundle D -pins { D1 D2 }

If the parameter is disabled (default), the instance file has to be defined at the
bundle level:
//defining bundle in instance file
add_pin D bundle_2 –input
add_pin CK default –clock
add_pin Q bundle_2 –output
add_pin QB bundle_2 –output

// to represent what are the members present in bundle pin

set_config_opt -pin D members {D1 D2}
set_config_opt -pin Q members {Q1 Q2}
set_config_opt -pin QB members {Q1B Q2B}

// function definition at bundle level

add_flop IQ IQN CK D
add_function Q IQ
add_function QB IQN1

When a multi-bit cell is being imported from a reference liberty that is modeled
at the individual pin/member level, the parameter should be enabled before the
import command. The SiliconSmart tool will automatically create the instance
file at the pin/member level.

862 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

Note: The SiliconSmart tool does not support bundle cells which have
a series of flops/latches.

Block Default Value Valid Range

param 0 0, 1

model_bus_timing
This parameter models unconditional timing groups at the bus level, by
specified point-wise selection from among unconditional and conditional timing
arcs characterized at the level of the pins in the bus. The timing groups at the
pin level are then deleted. If any timing groups are detected at the bus level
prior to this operation, they are deleted prior to this operation. This is primarily
expected to be used in macro cell characterization.

Block Default Value Valid Range

param \"none\" Enumerated("none,max,min,avg")

model_default_arcs
Setting the appropriate value to the parameter model_default_arcs will
trigger the generation of default tables for timing groups (cell_rise,
cell_fall, rise_transition, fall_transition, retaining_rise,
and retaining_fall).
Please not that enabling model_default_arcs will not generate default
tables for constraint/power/leakage arcs.
The model_default_arcs parameter has the following behavior:
■
Set to 0, off, no, never, false — No default arcs will be modeled.
However, if an arc can be characterized at one and only one when condition,
the SiliconSmart tool will omit this when condition. Such a table may appear
to be a default table (as it will not have a when condition).
■ Set to 1, on, yes, always, true — Default tables will be modeled.
■
Set to 2, cond, conditional — Default tables will be modeled if and only
if all possible when conditions are already not covered.

SiliconSmart ACE User Guide 863

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

See Default Arc Modeling for more information on generating default arcs.

Block Default Value Valid Range

param 1, on, yes, always, true 0, off, no, never, false

1, on, yes, always, true

2, cond, conditional

model_default_constraints
Default arcs for constraints will be added to library if this parameter is specified
as true. By default it is off. See Default Arc Modeling for more information.

Block Default Value Valid Range

param off off, min, mean, max

model_default_power_arc
Specifies if the default power arc will be written in the generated liberty file. See
Default Arc Modeling for more information.

Block Default Value Valid Range

param 0 0, 1, false, true

model_ecsm_threshold_pct
Determines whether ecsm_capacitance is measured/modeled at multiple
thresholds. While disabled, ecsm_capacitance will be modeled at one point

864 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

only. If enabled, ecsm_capacitance will be modeled depending on the

below:
■ If model_ecsm_threshold_pcts_fall/rise are defined,
ecsm_capacitance will be modeled for each defined threshold.
■
Otherwise, ecsm_capacitance will be determined based on the
prop_delay_level parameter value (default is 50).

Block Default Value Valid Range

param 1 Flag()

model_equalize_cap_averaging
Assigns equal weightage to propagating and non-propagating capacitance
values during the calculation of average NLDM pin capacitances. When set to
1, propagating and non-propagating arcs will have the same weightage. The
default is 0. This parameter works with model_pin_cap_calc "ave/mean".

Block Default Value Valid Range

param 0 0, 1

model_exclude_supplies
The supplies specified by this are forcibly prevented from appearing in models.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 865

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

model_expanded_states
Produces fine-grained, fully expanded when conditions in the Liberty model. A
single simulation potentially can be mapped to multiple Liberty entries using
this parameter.

Block Default Value Valid Range

param 0 Flag()

model_failed_cells_in_lib
Omits failed cells during the modeling step. If set to 1, any cells where
characterization data was corrupt or not present will be omitted from the
modeled library.

Block Default Value Valid Range

param 1 0, 1

model_input_leakage_current
Add gate contributions to leakage measurements

Block Default Value Valid Range

param 0 Flag()

model_leakage_current_file
Add gate contributions to leakage measurements.

Block Default Value Valid Range

param \"\" String()

866 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

model_mpw_attribute
For mpw, use the min_pulse_width attribute instead of a timing group.

Block Default Value Valid Range

param 1 Flag()

model_neg_constraint_chk_opposite_edge
If set to 1, then setup (recovery) + hold (removal) is checked for negative value
on opposite edge also. For example: setup_rising + hold_falling. If set to 0, only
the same edge is checked like setup_falling + hold falling. Has no effect unless
model_neg_constraint_sum is set to false.

Block Default Value Valid Range

param 1 0, 1

model_neg_constraint_sum
If false, then adjust hold and removal values such that hold >= -setup and
removal >= -recovery for each pair of constrained transitions.

Block Default Value Valid Range

param true Flag()

model_neg_constraint_sum_margin
If model_neg_constraint_sum is 0 and constraint sum is >
model_neg_constraint_sum_threshold; Tool corrects the constraint numbers to

SiliconSmart ACE User Guide 867

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

make the sum marginally positive. This parameter is to configure this 'marginal
positive number'.

Block Default Value Valid Range

param 1e-06 Float()

model_neg_constraint_sum_threshold
The value of this parameter is used to compare the constraint sum against to
determine whether to give a warning or error. If the sum is negative but within
the limit set with model_neg_constraint_sum_threshold, a warning will
be generated. If it is outside of this limit, an error will be generated.
This parameter does not have a default value. The user must choose and set a
value for this threshold. If model_neg_constraint_sum is set to 0 and no
value is set for model_neg_constraint_sum_threshold, the SiliconSmart
tool will generate an error to set an appropriate value for the threshold.
See Negative Constraint Sum Modeling for more information on using this
parameter.

Block Default Value Valid Range

param none Float(0.0, 1e-3)

model_negative_constraints
When set to false, negative constraint values are forced to 0. Otherwise the
exact values are modeled. The default values of this parameter is true

Block Default Value Valid Range

param 1 Flag()

868 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

model_negative_delays
When set to false, forces negative delay values to 0. Otherwise, negative delay
values are generated in the model. Belongs in the default parameter block.

Block Default Value Valid Range

param 1 Flag()

model_negative_energy
when set to false, negative energy values are forced to 0. Otherwise, the exact
values are modeled. The default value of this parameter is true.

Block Default Value Valid Range

param 1 Flag()

model_negative_leakage
when set to false, negative leakage values are forced to 0. Otherwise, the exact
values are modeled. The default value of this parameter is false.

Block Default Value Valid Range

param 0 Flag()

model_normalized_constraint_driver_waveform
Models the normalized_driver_waveform information related to constraint
acquistions in the Liberty model.

Block Default Value Valid Range

pintype 0 Flag()

SiliconSmart ACE User Guide 869

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

model_normalized_driver_waveform
Models the normalized_driver_waveform information in the Liberty
model.

Block Default Value Valid Range

default 1 Flag()

model_pg_pin_groups
When enabled, the SiliconSmart tool will model relevant pg_pin groups when
modeling NLPM even if the liberty_multi_rail_format is set to none.

Block Default Value Valid Range

param 0 0, 1

model_pin_cap_calc
Controls the calculation of the Liberty attributes capacitance,
rise_capacitance, and fall_capacitance. SiliconSmart measures the
input capacitance for all timing arcs, which means it captures state-dependent
input capacitance. Additionally, it captures input capacitance at each slew/load
combination for which delay/slew is measured.
Because the NLDM Liberty model supports only a single value for input
capacitance, SiliconSmart uses either the minimum, maximum, mean, or
average value of all the measured input capacitances and considers it the
capacitance attribute. For the rise_capacitance and fall_capacitance
attributes, the computation is only done for the rise or fall measurements for the
rise and fall capacitance attributes respectively. Valid values for this parameter
are min, max, mean, or ave. The default value is max.

Block Default Value Valid Range

param \"max\" Enumerated("min, max, mean, ave")

870 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

model_power_on_output
When set to 1 for an arc, the internal_power is modeled at output pin level.

Block Default Value Valid Range

param 0 Flag()

model_power_per_supply
When set to 1, multi-rail power constructs will be written in the liberty model.

Block Default Value Valid Range

param 0 Flag()

model_reverse_polarity_current
This parameter if set to 'true', will model the exact measured value from the
leakage simulation for both pg current and gate leakage current in CCS power
modeling even though the current polarity may be reversed. If the user wants to
zero out such reverse polarity currents in the liberty file, this parameter should
be set to 'false'. The default value of this parameter is 'true'.

Block Default Value Valid Range

param 1 Flag()

model_rise_fall_capacitance
When true, use rise/fall_capacitance liberty attributes. Otherwise use
capacitance attribute.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 871

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

model_rise_fall_capacitance_range
If true and model_rise_fall_capacitance is also true, add rise/
fall_capacitance_range attributes.

Block Default Value Valid Range

param 1 Flag()

model_sensitization_vector
Determines whether to write sensitization vectors (wave_rise, wave_fall
attributes).

Block Default Value Valid Range

param 0 Flag()

model_significant_digits
Specifies the number of significant digits to use for the data in the model.
Belongs in the default parameter block.

Block Default Value Valid Range

param 4 Integer(1,12)

model_significant_digits_area
Specifies the number of significant digits to use for the area attribute in the
library. A value of 0 deactivates this control, and the area is printed as
specified.

Block Default Value Valid Range

param 0 Integer(0, 12)

872 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

model_uncharacterized_tables
When true, a \"zero\" table will be substituted when no sof data is found. When
false, the table is not modeled.

Block Default Value Valid Range

param 1 Flag()

mpw_rail_to_rail
To match NCX value, when constraint_pulse_cratering is 0 or 1, and when
MPW values come from non-full swing input pulse (or input signal does not
swing from rail to rail), SiS uses the NCX equation for MPW. NCX equation for
MPW = input_slew / [(logic_high_threshold-logic_low_threshold)/ (100 *
slew_derating_factor)].

Block Default Value Valid Range

param 0 Flag()

monitor_internal_nodes
Maps internal node names, to monitor for constraints, to attributes: { node1 {
pintype io edges 0 } node2 {} node3 { output Q } }
Default attributes are { pintype default edges 1 }. Keywords are used for
extensibility. Key 'pintype' (default 'default') is the pintype to describe the node.
Key 'edges' (default 1) is the number of expected transitions. Key 'output'
(default '') is a pin which must transition if this node is to be used. Replaces
transition_nodes, steady_state_nodes, internal_nodes_transition_data.

Block Default Value Valid Range

param empty_list() Dict(new Dict(new

Enumerated("pintype, edges, output"),
new String()))

SiliconSmart ACE User Guide 873

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

mpp_simulator
Simulator to be used for model preprocessing.

Block Default Value Valid Range

param \"\" String()

mpw_table_dimensions
Specifies a method to model mpw tables as a scalar value, a 1-dimensional
table, or a 2-dimensional table.
By default, this parameter is set to 0, which means that the mpw value will be
modeled as a scalar attribute.
Setting the parameter to 1 will measure the mpw value by varying the input
slew of the clock pin and model it as a 1-dimensional table.
Setting the parameter to 2 will measure the mpw value by varying both the
input slew and the load at the output pin and model it as a 2-dimensional table.
For example:
set_config_opt mpw_table_dimensions 2

Block Default Value Valid Range

param 0 0, 1, 2

mpw_v2_transition_inputs
This parameter is only relevant when using the mpw-v2 methodology for
minimum pulse width measurements. For each input listed here, SiliconSmart
will only consider those mpw arcs where the input is not fixed to 0/1 but instead
undergoes more than one transition.

Block Default Value Valid Range

param empty_list() List(new String())

874 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

netlist_max_sweeps
Specifies the maximum number of sweeps allowed in a single simulation deck.

Block Default Value Valid Range

param 8000 Integer (10, 10000)

new_operating_condition
Specifies the name of the operating conditions to be used in output liberty. The
default value is empty, which means it will use active_pvt name in create new
model and will use op_cond name from seed.lib in rechar flow.

Block Default Value Valid Range

param none String()

nmos_drn_gate_shorted_model_names
Names of 3-terminal NMOS models with drain and gate shorted used by netlist
pruning.

Block Default Value Valid Range

param empty_list() List(new String())

nmos_drn_src_shorted_model_names
Names of 3-terminal NMOS models with drain and source shorted used by
netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 875

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

nmos_gate_src_shorted_model_names
Names of 3-terminal NMOS models with gate and source shorted used by
netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

nmos_model_names
Names of NMOS models used by netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

nochange_threshold
Glitch threshold allowed for a passing nochange constraint.

Block Default Value Valid Range

param 0.1 Float(0.0, 1.0)

nochange_variance
Maximum output edge jitter allowed for a passing nochange constraint.

Block Default Value Valid Range

param 4.0*time_res_high Float(0.0, 4e-3)

876 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

non_scan_model
Non-scan model name of a cell.

Block Default Value Valid Range

param \"\" String()

normal_queue
Specifies the LSF or Grid Engine queue name to which jobs are submitted.
This parameter is used only if job_scheduler is set to lsf or grid. Please refer to
the LSF or Grid Engine documentation for information on setting up queues.

Note: Do not add -q to the beginning of the normal_queue value.

This is added by default and including it will error out the run.

Block Default Value Valid Range

param \"lsf_queue\" String()

normalized_driver_significant_digits
Specifies the number of significant digits to be printed for
normalized_driver_waveform. Setting the parameter to a value greater
than 1 will specify to print out that number of significant digits.

Block Default Value Valid Range

param 1 Integer

SiliconSmart ACE User Guide 877

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

nsamples
Number of samples for waveform capture.

Block Default Value Valid Range

param 10 Integer(2,None)

opc_grounds
Private parameter list of supplies set by add_opc_grounds command.

Block Default Value Valid Range

param empty_list() List(new String())

opc_process
Specifies the process line to use for a given operating condition and simulation.

Block Default Value Valid Range

param empty_list() List(new String())

opc_supplies
Private parameter list of supplies set by add_opc_supplies command.

Block Default Value Valid Range

param empty_list() List(new String())

878 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

opc_temperature
Specifies the temperature to use for a given operating condition and simulation.

Block Default Value Valid Range

param 0.0 Float()

opc_voltage
Specifies the supply/ground voltage to use for a given operating condition and
simulation. Usually specified per-pin where the pin is the supply/ground name.

Block Default Value Valid Range

param 0.0 Float()

output_sweep_order
This determines the order in which pins are swept when multiple outputs are
switching for a given input transition. This also determines to which pin 3-D
timing and power tables are added.

Block Default Value Valid Range

param empty_list() List(new String())

param_change_period
Time in minutes. This determines the frequency at config/change.tcl is sourced.

Block Default Value Valid Range

param 30 Integer(10,1000000)

SiliconSmart ACE User Guide 879

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

parameters
Specifies an alternate parameter block to be used for characterization and
simulator options.

Block Default Value Valid Range

param \"\" String()

partition_by_output_transitions
This is an additional level of partitioning the state set. If not 0, then each
combination of output transitions results in a separate measurement. When set
to 2, separate states with different output pin states are merged to leave the
final liberty file with states free from output pins.

Block Default Value Valid Range

param 0 0, 1, 2

path_based_clock_nodes
This list represents the list of internal spice nodes corresponding to the clock
path. This parameter is used only in memory characterization flow.

Block Default Value Valid Range

param empty_list() List(new String())

path_based_signal_nodes
This list represents the list of internal spice nodes corresponding to a bit of the
signal bus. The list comprises of the bit number and its corresponding list of

880 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

internal spice nodes for that bit. This parameter is used only in memory
characterization flow.

Block Default Value Valid Range

param empty_list() List(new String())

path_constraint_enable
Clock node used for path-based constraints.

Block Default Value Valid Range

param \"\" String()

path_constraint_enable_negative
Negative clock node used for path-based constraints.

Block Default Value Valid Range

param path_constraint_enable String()

path_constraint_enable_positive
Positive clock node used for path-based constraints.

Block Default Value Valid Range

param path_constraint_enable String()

SiliconSmart ACE User Guide 881

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

path_constraint_feedback
Specifies the name of an internal node in the feedback loop of a latch. This is
used as a part of the path-based constraint analysis described in
Characterization and Modeling.

Block Default Value Valid Range

param \"\" String()

path_constraint_mode
Enables path-based constraint analysis to reduce characterization time of
setup and hold constraints. When set to polish, path-based analysis is used to
provide a seed to the standard search algorithm. When set to verify, the search
algorithm only increases the given constraint if necessary, instead of fully
optimizing it. When set to unchecked, the path-based values are used
unchanged. A value of off disables path-based constraint analysis.

Block Default Value Valid Range

param \"off\" Enumerated("off, polish, verify,

unchecked")

path_constraint_pintype
Specifies the name of the pintype block to use when creating internal pins for
path-based constraint analysis. This is used by the analyze_netlist command.
See Netlist Analysis in Characterization and Modeling for details.

Block Default Value Valid Range

param default_pintype String()

882 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

periodic_clock_stimulus
Indicates whether the time between edges are separated by a fixed interval.
When false, all edges are separated by a fixed interval. When true, clock edges
are separated by a fixed interval and all other edges are fit within that interval.
The default value is false.

Block Default Value Valid Range

param 0 Flag()

pin_name_alias
This parameter is used with 'set_config_opt' command. This is used to rename
pins which have characters not allowed by Siliconsmart.

Block Default Value Valid Range

param \"\" String()

pmos_drn_gate_shorted_model_names
Names of 3-terminal PMOS models with drain and gate shorted used by netlist
pruning.

Block Default Value Valid Range

param empty_list() List(new String())

pmos_drn_src_shorted_model_names
Names of 3-terminal PMOS models with drain and source shorted used by
netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 883

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

pmos_gate_src_shorted_model_names
Names of 3-terminal PMOS models with gate and source shorted used by
netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

pmos_model_names
Names of PMOS models used by netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

point_to_point_default_selection
When point_to_point_default_selection is set to 1, each and every
value of the conditional tables are compared and the true max or worst is
picked for the default table. The default table will be generated piece by piece; it
may or may not be a copy of any one of the tables. The table that contains the
maximum value, among all conditional tables, would be used as the default
table. SiliconSmart would use the entire table, and would not compare every
single value of every table for the true maximum or worst value.
For 2-dimensional LUTs:
■
X = (X1, X2, ..., Xk) — index_1 (e.g., input slew) with k elements
■ Y = (Y1, Y2, ..., Yl) — index_2 (e.g., output load) with l elements
■
T(i) = (T1(i), T2(i), ..., Tk*l(i)) — table values (e.g., delay)
with k*l elements, where i is an index to the arc and ranges from 1 to n (n
is the number of arcs)

884 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

The default arc T will be calculated as min/max/average of T elements across

all arcs. The first element of the default table T would be:
■ For min — T_default = min(T1(1), T1(2), ..., T1(n))
■
For average — T_default = mean(T1(1), T1(2), ..., T1(n))
■
For max — T_default = man(T1(1), T1(2), ..., T1(n))
where T1(i) means the first table element of arc i.
For CCS timing, slew points are selected first, followed by the corresponding
delay and CCS point. If T3(1) is selected as the first point, then the
SiliconSmart tool will select the 3rd table for delay and CCS.
model -timing -library_type [best/typ/worst]

Block Default Value Valid Range

param 0 0, 1

potential_internal_node_list
This represents the list of potential candidates for internal spice nodes to be
used for memory characterization. These nodes will undergo tests to determine
the correct node that can be used for determining constrants. This parameter is
used only in memory characterization flow.

Block Default Value Valid Range

param empty_list() List(new String())

power_dynamic_end_threshold
Specifies the fraction of the total voltage transition which must complete in
order to terminate the supply current integration. A value of zero means there is
no dynamic integration termination.
If you set this, the integration will stop at the specific fraction of the total
transition, and the total will compensate for any remaining transition with the
assumption that the remaining power is only for completing the charge of the
output cap. Differential outputs should behave the same as for any other

SiliconSmart ACE User Guide 885

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

multiple switching output cell. However the power_period still has to be long
enough to cover the complete transition time.

Block Default Value Valid Range

param 0.0 Float(0.0,1.0)

power_load_energy_on_rise
Subtract output load energy from total energy for rising outputs only. The
alternative, which is not recommended, is to subtract half the output energy for
all outputs. This is provided for backward compatibility only.

Block Default Value Valid Range

param 1 Flag()

power_meas_grounds
This parameter specifies the list of primary ground and negative supply names
that should be used for the entire library of cells. The user must specify the
appropriate value of this parameter especially when doing power and CCS
power related measurements

Block Default Value Valid Range

param empty_list() List(new String())

power_meas_map
This parameter is helpful in clubbing power values for different power pins
together. For examples if two power supplies are specified with

886 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

power_meas_supplies, but you want to model the power for both the supplies
together, you can use this parameter to map them.

Block Default Value Valid Range

param empty_list() List(new String())

power_meas_supplies
This parameter specifies the list of positive primary power supply names that
should be used for the entire library of cells. It is important to specify the value
of this parameter especially when doing power related measurements. If any of
the supplies are missing from this list, the current through those supplies will
not be measured and will not be taken into account for power modeling.

Block Default Value Valid Range

param empty_list() List(new String())

power_stabilization_threshold
Specifies a relative tolerance to be used when computing the leakage current
during power. This value is a maximum difference between two samples of the
average current during the tail of the simulation. the default value of the 0.05
corresponds to a difference or no more than 5%.

Block Default Value Valid Range

param 0.05 Float(0.0,1000.0)

power_stabilization_threshold_absolute
Specifies an absolute tolerance to be used when computing the leakage
current during power. This value is a maximum difference between two

SiliconSmart ACE User Guide 887

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

samples of the average current during the tail of the simulation. the default
value of the 1e-18 corresponds to a difference or no more than 1pW.

Block Default Value Valid Range

param 1e-18 Float(0.0,None)

prechar_autorange_load
Enables the precharacterization of maximum load autoranging. Use this
parameter to autorange load across all of the operating conditions and then
choose the lowest value and use it for all operating conditions. This ensures
consist load ranges across multiple .lib files which is a CCS requirement for
voltage scaling.

Block Default Value Valid Range

param 1 Flag()

prechar_binning_abs_tol
The maximum minimum-to-maximum range in a single bin. The larger of
prechar_binning_abs_tol or prechar_binning_rel_tol will take effect. A negative
value is generally used to force each state to have its own bin.

Block Default Value Valid Range

param 3.0*time_res_high Float(-1.0, None)

prechar_binning_constraints
Binning mode specific to constraints. For 'all', a partition is created for each bin
and each bin covers all states in that bin. The state selection for 'all' is specified
as best_median_worst.
The modes 'all_best' and 'all_worst' are identical to the mode 'all except that the
selection is specified as 'best' and 'worst' respectively. For 'best' and 'worst', a
single bin is created which covers only the overall best or worst state. For

888 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

'explicit', no partition is created; the user-specified partitioning scheme is used

and precharacterization only generates the state ranking for a selection within a
bin.

Block Default Value Valid Range

param \"none\" Enumerated("none, all, all_best,

all_worst, all_median, best, worst,
explicit")

prechar_binning_hidden_power
Flag to indicate if precharacterization must be performed for hidden power.

Block Default Value Valid Range

param 0 Flag()

prechar_binning_max_bins
Maximum number of bins requested.

Block Default Value Valid Range

param 9999 Integer(1,None)

prechar_binning_method
Measurements to use for binning states during precharacterization.

Block Default Value Valid Range

param \"all-by-timing\" Enumerated("all-by-timing,

independent")

SiliconSmart ACE User Guide 889

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

prechar_binning_mode
Specifies how precharacterization will create binned states for partitioning. For
'all', a partition is created for each bin and each bin covers all states in that bin.
For 'best' and 'worst', a single bin is created which covers only the best or worst
state. For 'explicit', no partition is created; the user-specified partitioning
scheme is used and precharacterization only generates the state ranking for a
selection within a bin.

Block Default Value Valid Range

param \"all\" Enumerated("none, all, best, worst,

explicit")

prechar_binning_power
Binning mode specific to power. For 'all', a partition is created for each bin and
each bin covers all states in that bin. The state selection for 'all' is specified as
best_median_worst. The modes 'all_best' and 'all_worst' are identical to the
mode 'all except that the selection is specified as 'best' and 'worst' respectively.
For 'best' and 'worst', a single bin is created which covers only the overall best
or worst state. For 'explicit', no partition is created; the user-specified
partitioning scheme is used and precharacterization only generates the state
ranking for a selection within a bin.

Block Default Value Valid Range

param \"all\" Enumerated("none, all, all_best,

all_worst, all_median, best, worst,
explicit")

890 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

prechar_binning_rel_tol
The maximum minimum-to-maximum bin range as a fraction of the maximum
absolute measurement value. The larger of prechar_binning_abs_tol and
prechar_binning_rel_tol will take effect.

Block Default Value Valid Range

param 0.0 Float(0.0, 1.0)

prechar_binning_timing
Binning mode specific to timing. For 'all', a partition is created for each bin and
each bin covers all states in that bin. The state selection for 'all' is specified as
best_median_worst. The modes 'all_best' and 'all_worst' are identical to the
mode 'all except that the selection is specified as 'best' and 'worst' respectively.
For 'best' and 'worst', a single bin is created which covers only the overall best
or worst state. For 'explicit', no partition is created; the user-specified
partitioning scheme is used and precharacterization only generates the state
ranking for a selection within a bin. If set to none, the SiliconSmart tool will
disable binning of conditional timing arcs and enable compatibility with
configure_all_states_for_ccb.

Block Default Value Valid Range

param \"all\" Enumerated("none, all, all_best,

all_worst, all_median, best, worst,
explicit")

prechar_enable_fast_analysis
If the number of states for an arc is greater than this parameter, then prechar
results analysis will use a faster algorithm.

Block Default Value Valid Range

param 16 Integer(1,None)

SiliconSmart ACE User Guide 891

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

prechar_keep_intermediate_files
Directs SiliconSmart to avoid deleting intermediate files in the runtime directory
after simulations are run.

Block Default Value Valid Range

param 0 Flag()

prechar_numsteps
Number of load/slew samples to be used for prechar simulations.

Block Default Value Valid Range

param 2 Integer(1, 20)

prechar_sampling_size
Sampling size for load/slew for precharacterization simulations. When this
parameter is set to 1x1, SiliconSmart chooses one output load and one input
slew point which is either the average of all values in explicit points load/slew if
they are specified or the average of largest/smallest load/slew values. When
set to 2x2, SiliconSmart chooses the two largest/smallest load/slew points. If
prechar_autorange_load is enabled, this parameter must be set to 2x2.

Block Default Value Valid Range

param \"2x2\" Enumerated("1x1, 2x2")

892 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

prechar_simulator
Simulator to be used for precharacterization related (binning) simulations.

Block Default Value Valid Range

param \"finesim_embedded\" Enumerated("hspice, hspice_cs,

smartspice, spectre, spectre11, eldo,
msim, tispice, finesim,
finesim_embedded,
finesim_embedded_spectre, lynx,
eldo_native, finesim_embedded_eldo,
mica")

prechar_state_partitions
State partitions used during precharacterization for the non-VG flow.

Block Default Value Valid Range

param \"all\" Enumerated("all, no_dontcares,

explicit, none")

preferred_switching_input
List of zero or more pins, in order, to use as switching input if available.

Block Default Value Valid Range

param empty_list() List(new String())

reduce_ccs_power_table
Flag to indicate if ccs power tables need to be reduced. By default the size of
the reduced tables will be 3X3.The parameters

SiliconSmart ACE User Guide 893

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

ccs_power_modeling_slew_indices and ccs_power_modeling_load_indices

can be used to specify a different table size.

Block Default Value Valid Range

param 0 Flag()

primary_index
Use this parameter to change the order of index (slew/load) in library lookup
templates and tables. It works only for create_new_model modeling flow.

Block Default Value Valid Range

param \"none\" EnumeratedNoCase("{\

'none' : 'none', \
'slew' : 'slew', \
'load' : 'load' }")

propagate_warnings
This parameter can be set to 1. It means all the warning message in cdpl log
will be populated into the SiliconSmart log.

Block Default Value Valid Range

param 0 Integer(0,1)

publish_internal_pin_states
When set to 1, the states of internal pins will be included in the when
expressions.

Block Default Value Valid Range

param 0 0, 1

894 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

receiver_cap_for_zdisable
Set this parameter to 1 to characterize receiver_capacitance for z-disable
arcs.

Block Default Value Valid Range

param 0 Integer(0,2)

receiver_trip_threshold_pct_fall
List of threshold percentages for measuring receiver capacitance fall

Block Default Value Valid Range

param empty_list() List(new Integer(0, 100))

receiver_trip_threshold_pct_rise
List of threshold percentages for measuring receiver capacitance rise

Block Default Value Valid Range

param empty_list() List(new Integer(0, 100))

rechar_add_attributes
Defines attributes to be added in the generated library. Current supported
attributes are min_capacitance and max_capacitance. You can set the
parameter to all to include all supported attributes.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 895

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

rechar_update_attributes
Defines attributes to be modified from the seed the library during
recharacterization flow. By default, this list is empty so that the generated
liberty matches with the seed library. The currently supported list of attributes
for this parameter are: pg_pin, input_voltage, output_voltage, ff,
ff_bank, latch, latch_bank, max_transition.
The parameter can be set to all to update all the supported attributes. Please
note that as more attributes can be supported in future, the all option will
update more attributes in future.

Block Default Value Valid Range

param empty_list() List(new String())

reduce_ecsm_power_table
Flag to indicate if ecsm power tables need to be reduced. By default the size of
the reduced tables will be 3X3.The parameters
ecsm_power_modeling_slew_indices and
ecsm_power_modeling_load_indices can be used to specify a different table
size.

Block Default Value Valid Range

param 0 Flag()

replace_negative_leakage_with
If the parameter model_negative_leakage is false, the value given with this
parameter is used for replacing negative leakage values. The default is 0.

Block Default Value Valid Range

param 0 Float()

896 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

report_constraint_iterations
Writes detailed data for constraint acquisition search iterations. This is useful
for viewing details on exactly how the search engine converged on a result for
setup/hold/recovery/removal/mpw/no_change measurements. The result is
placed in a CSV file located in the char_point/reports/constraints directory
which can be imported as a spreadsheet for further analysis.

Block Default Value Valid Range

param 0 Flag()

res_model_names
Names of resistor models used by netlist pruning.

Block Default Value Valid Range

param empty_list() List(new String())

right_bus_identifier
String that separates a bus name from its bit number when naming each bit
separately. This parameter identifies the right separator.

Block Default Value Valid Range

param \"\" String()

SiliconSmart ACE User Guide 897

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

run_list_maxsize
Specifies the number of jobs that can be running in the job queue at one time.
In standalone mode, this parameter controls the number of jobs that can run
simultaneously on the local machine.

Block Default Value Valid Range

param 1 OneOf(new Enumerated("unlimited"),

new Integer(1, None))

running_prechar
Non-public parameter that indicates when precharacterize is being used
instead of configure/characterize.

Block Default Value Valid Range

param 0 Flag()

save_farm_logs
Save stdout and stderr of the workers on farm

Block Default Value Valid Range

param 0 Flag()

scan_enable
List of scan enable pin(s) belonging to a cell.

Block Default Value Valid Range

param empty_list() List(new String())

898 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

scan_input
List of scan input pin(s) belonging to a cell.

Block Default Value Valid Range

param empty_list() List(new String())

scan_enable_inverted
List of inverted scan enable pin(s) belonging to a cell.

Block Default Value Valid Range

param empty_list() List(new String())

scan_output
List of scan output(s) belonging to a cell.

Block Default Value Valid Range

param empty_list() List(new String())

scan_output_inverted
List of inverted scan output(s) belonging to a cell.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 899

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

scan_start_pin
Defines a corresponding attribute in Liberty syntax. It specifies the scan output
pin of a sequential element of the multi-bit scan cell, where the internal scan
chain begins. It is defined in the bus or bundle group.

Block Default Value Valid Range

param empty_list() String()

scan_type
Type of scan functionality.

Block Default Value Valid Range

param \"\" String()

scd_debug_subtract_power_tables
This parameter specifies that the hidden energy on an input pin is subtracted
from the switching energy at the output pin during the modeling step if both
these events and their when conditions match or overlap (i.e. the events are not
mutually exclusive). This is done in order to avoid overestimating the power
consumption of the cell. The default value of this parameter is 1.0.

Block Default Value Valid Range

param 1 Flag()

900 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

scheduler_poll_time
The number of seconds SiliconSmart waits between polling the load sharing
system for job status.

Block Default Value Valid Range

param 240 Integer(5, 900)

sdf_cond_equality_operator
Operator to use for equality in sdf_cond attributes.

Block Default Value Valid Range

param \"===\" EnumeratedNoCase("{\

'===' : '===', \
'==' : '==' }")

secondary_run_list_maxsize
Specifies the number of jobs that can be running in the secondary job queue at
one time.

Block Default Value Valid Range

param 0 OneOf(new Enumerated("unlimited"),

new Integer(0, None))

SiliconSmart ACE User Guide 901

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

separate_cell_initialization
If ic or nodeset, the simulation to set the cell to a known state is done
separately and used as the initial condition for constraint measurements.

Block Default Value Valid Range

param \"ic\" EnumeratedNoCase("{\

'ic' : 'ic', \
'1' : 'ic', \
'true' : 'ic', \
'yes' : 'ic', \
'on' : 'ic', \
'nodeset' : 'nodeset', \
'0' : 'off', \
'false' : 'off', \
'no' : 'off' \
'off' : 'off' }")

separate_cell_initialization_levels
This parameter may be set to 'all'(default value) or 'top-internal-only'. Setting it
to 'all' causes all nodes in the cell to be initialized by ic or nodeset.
Occasionally, it may be desirable to have only the internal nodes from the top-
level circuitry in the netlist have their voltages initialized by nodeset or ic. In this
case, this parameter should be set to 'top-internal-only'.

Block Default Value Valid Range

param \"all\" EnumeratedNoCase("{\

'all' : 'all', \
'top-internal-only' : 'top-internal-only'
}")

902 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

signal_capture_pct
Specifies string of node percentage pair indicate the signa capture node and
pct.

Block Default Value Valid Range

param \"\" String()

simcomp_version
Use Python (1) or C++ (2) version of sim compiler with Spectre.

Block Default Value Valid Range

param 1 Integer(1,2)

simulator_case_sensitive
When set to 0, processes a case-insensitive manner. Applies only to Mica
simulator at present.

Block Default Value Valid Range

param 1 0, 1

simulation_max_inactive_time
Time in minutes. If a task takes more than this time, a warning is issued.

Block Default Value Valid Range

param 10000 Integer()

SiliconSmart ACE User Guide 903

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

simulation_max_runtime
Time in minutes. If a task takes more than this time, a warning is issued.

Block Default Value Valid Range

param 120 Integer()

simulation_node_initialization_file
Specifies the full path to the node initialization file that can be used during
simulations for any type of measurement. This file contains .ic/.nodeset
statements in a format that is recognizable by the simulator. Typically, this
parameter is used in the full-AUS flow when the user is providing all arcs
manually to the tool.
If this parameter is used in a non-AUS flow where all the measurements,
including the initialization measurements, are derived from functions provided
by the user in cell instance files, the user specified initialization files set with the
simulation_node_initialization_file parameter will not be used.

Block Default Value Valid Range

param \"\" String()

simulation_tmpdir
Specifies the directory in which the temporary files for a simulation are to be
written. The directory must exist and be writable on each machine that a
simulation is to be executed, and have enough free space to hold the complete
results of the simulations (10Mbytes at least.) On some systems, setting this
value to /tmp can improve performance because /tmp is implemented using the
virtual memory system.

Block Default Value Valid Range

param \"/var/tmp\" String()

904 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

simulator
Specifies the type of simulator used for all circuit simulations. Valid simulators
are listed below.

Block Default Value Valid Range

param finesim_embedded customsim, finesim,

finesim_embedded, finesim_parallel,
hspice, hspice_cs, hspice_embedded

simulator_bisection
If set, does the constraint measurement using simulator native bisection
method. It uses the bisection method internally supported by hspice/finesim
instead of bisection method supported by SiliconSmart.

Block Default Value Valid Range

param 0 Flag()

simulator_cmd
Sets the command used by the SiliconSmart tool to invoke the circuit simulator.
The format of the command should be similar to an actual command-line
execution of the simulator, with the string [input_deck] used in place of the input
file, and [listing_file] for the output file. [input_deck] and [listing_file] are
automatically replaced with the file names generated by SiliconSmart when the
command defined by simulator_cmd is issued. This parameter is not used
when the simulator parameter is set to finesim_embedded.

Block Default Value Valid Range

param hspice -i <input_deck -o String()

<listing_file

SiliconSmart ACE User Guide 905

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

simulator_default_options
When set to 1, the SiliconSmart tool adds its own simulator options to the deck.
You can then add your own options as well, which will override these default
options. When set to 0, no simulator options will be added at all, and all
simulator options must be set manually.

Block Default Value Valid Range

param 1 0, 1

simulator_options
Specifies a string indicating valid simulator options. These options are passed
to the simulator while executing simulations. See Setting Simulator Options for
more information.

Block Default Value Valid Range

param common,finesim_embedded: String()

finesim_output=tr0
finesim_mode=spicehd
probe=1
finesim_method=gear
measdgt=7

simulator_warning_limit
Limits the total number of warnings in the siliconsmart.log file.

Block Default Value Valid Range

param 0 0-10000

single_bit_degenerate
Defines a corresponding layout-related attribute in Liberty syntax. It defines a
name of a single-bit library cell for use on multi-bit bundle cells that are black

906 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

boxes. This allows synthesis and implementation tools to perform mapping

from the single-bit cell to the multi-bit cell.

Block Default Value Valid Range

param none String()

single_cell_mode
Normally, global scope parameters cannot be set in the .inst file because all
parameters set in the .inst are considered to be cell-specific. However, if this
parameter is set to true, then global parameters are permitted for one cell at a
time. Set_location must be called before operations on a different cell can be
done.

Block Default Value Valid Range

param 0 Flag()

sis_cell_type_memory
The primary idea is to flatten a memory cell by default during import. Some
times memory cell needs to be imported without using template flow. When
import is done without using template flow, we try to find the cell type from the
liberty file. If the cell type can not be found out as memory from liberty file when
import is done without using template flow, this parameter must be set to 1 to
indicate that the cell under consideration is memory.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 907

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

sis_exclude_internal_power_nets
String that specifies the internal power and ground nets which are to be
excluded.

Block Default Value Valid Range

param \"*bl* *bt* *bb*\" String()

sis_gzip_enable
Determines whether SiliconSmart should use gzip or not. The gzip operation is
relevant to simulation related files such as SIF files, Spice decks and SOF files.

Block Default Value Valid Range

param 1 Flag()

sis_gzip_enable_for_lib
Determines whether SiliconSmart should use gzip or not. The gzip operation is
relevant to modeling related files such as lib files.

Block Default Value Valid Range

param 1 Flag()

sis_pruning_with_flat_netlist
Specifies if a completely flat netlist will be used for memory pruning

Block Default Value Valid Range

param 0 Flag()

908 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

sishapes_channel_length_offset

Block Default Value Valid Range

param 0.0 Float(0.0,3e-8)

sishapes_minimum_feature_length

Block Default Value Valid Range

param 0.0 Float(0.0,1e-5)

slew_derate_lower_threshold
Lower threshold for slew derating.

Block Default Value Valid Range

param 0.0 Float(0.0, 1.0)

slew_derate_upper_threshold
Upper threshold for slew derating.

Block Default Value Valid Range

param 0.0 Float(0.0, 1.0)

SiliconSmart ACE User Guide 909

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

slew_matching_cin
Enable the slew matching methodology for pin capacitance measurement.
Matching of slew is done against active driver precharacterization data which
contains a table of capacitance values and the resulting output transition time.

Block Default Value Valid Range

param 0 Flag()

spectre_ccb
This tells if the spectre netlist is used for ccs_noise.

Block Default Value Valid Range

param 0 Flag()

spectre_fake_model
If the spectre_macmod is set to 1, this should be set to fake model for spectre.

Block Default Value Valid Range

param \"\" String()

spectre_macmod
This is set to 1 when device models are defined in subckt(macro model).

Block Default Value Valid Range

param 0 Flag()

910 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

srf_multiplier
Used for the reduction factor to generate the sweeper indices for which only
nominal values of process parameters are simulated.

Block Default Value Valid Range

param 0.75 Float(0.5,1.0)

stat_hold_sensitivity_ratios
Specifies the ratio in which -3sigma and +3sigma values are added to get
stat_hold sensitivity. The equation can be expressed as:
optimistic_side_ratio*(nominal_value - optimistic_value) +
pessimistic_side_ratio*(pessimistic_value - nominal_value).
The parameter value is a list of 4 floating point numbers.The 4 values
correspond to optimistic_side_ratio_case1,
pessimistic_side_ratio_case1,optimistic_side_ratio_case2,
pessimistic_side_ratio_case2. case1 corresponds to "pessimistic side greater
than optimistic side" and case2 corresponds to "pessimistic side less than
optimistic side." See Chapter 7, Statistical Characterization for more
information.

Block Default Value Valid Range

param list(0.5, 0.5, 0.5, 0.5) List(new Float(0.0, 10.0))

state_coverage_exclude_pins
This parameters accepts a list of pin names that will be removed from the state
coverage for a particular arc.

Block Default Value Valid Range

param empty_list() List(new String())

SiliconSmart ACE User Guide 911

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

state_partitions
This parameter is used with 'set_config_opt' command to select which possible
states of an event will be grouped together to be represented by a single
measurement. 'one' does a single measurement. 'all' gives each state its own
measurement. 'ones_count' groups all states with the same number of active
input pins into a single measurement. 'no_dontcares' groups all states of those
input pins which are not in support of the events enabling condition. 'none'
disables all measurements.
The remaining modes are only used with white-box cell analysis.
'one_per_path' groups all states which enable the same internal propagation
path. 'all_per_path' groups all states which enable the same path with the same
internal state controlling that path. 'one_per_block_set' groups all states which
propagate a transition through the same set of channel-connected blocks.
'all_per_block_set' groups all states which propagate a transition through the
same set of blocks with the state internal state on those blocks. 'as_given' will
use the supplied state as it is specified.
See State Dependent Measurements (State Partitioning) for more information
on using state_partitions.

Block Default Value Valid Range

param \"one\" Enumerated("one, all, ones_count,

no_dontcares, explicit, one_per_path,
one_per_block_set, all_per_path,
all_per_block_set, as_given, none")

state_rank
This parameter specifies a list of possible states for an arc in order from best to
worst. It takes a list of Boolean expression representing states.

Block Default Value Valid Range

param empty_list() List(new String())

912 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

state_selection
When multiple states are available in a particular bin, the actual state
characterized can be controlled with the 'state_rank' and 'state_selection'
parameter. This parameter specifies whether to choose the best, the median or
the worst case as specified by the 'state_rank' list. A state_selection of arbitrary
selects a state in a deterministic but arbitrary manner (it is equivalent to the
selection of the best case). A state_selection of best_median_worst selects the
best ranked state if available and the worst is not also available, the worst if
available and the best is not also available, and the median otherwise.

Block Default Value Valid Range

param \"arbitrary\" Enumerated("best, worst, median,

arbitrary, best_median_worst")

statistical_avoid_screening_acquisition
If set to 1, screening will be bypassed. But this will increase runtime.

Block Default Value Valid Range

param 0 Flag()

statistical_constraint_screening_points
Specifies slew-slew points to be used for statistical constraint screening. If not
specified, SiliconSmart selects the middle slew-slew point as default.

Block Default Value Valid Range

param empty_list() List(new Integer(0,None))

SiliconSmart ACE User Guide 913

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

statistical_constraint_screening_tolerance
This specifies the tolerance used to consider/ignore a particular coefficient in
statistical constraint screening characterization. Unit is absolute.Default is 0 in
which case constraint_resolution will be taken as the value.

Block Default Value Valid Range

param 0 Float(0.0,1e-9)

statistical_enable_constraint_sensitivity
If true, do setup/hold sensitivity characterization.

Block Default Value Valid Range

param 0 Flag()

statistical_model_sigma_montecarlo
If set to 1, SiliconSmart will use Monte-Carlo simulation to find out sigma
(standard deviation) for delay/slew. This should be used only for debugging
because the runtime will be very high.

Block Default Value Valid Range

param 0 Flag()

statistical_montecarlo_sample_size
This specifies the sample size in case statistical_model_sigma_montecarlo is
1.

Block Default Value Valid Range

param 100 Integer(10,None)

914 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

statistical_reduction_factor
Since SSTA characterization is very expensive in terms of runtime, we give the
option to characterize a sparse table and interpolate data for rest of the table.
This parameter defines how parse the table should be. For example, if this
parameter is set to 0.5, only 50% of the sensitivity values are found out by
simulation and rest 50% is interpolated and put in the model.

Block Default Value Valid Range

param 1.0 Float(0.2,1.0)

statistical_screening_points
Specifies slew-load points to be used for screening. If not specified,
SiliconSmart selects default screening points. For an MxN slew-load table,
default screening points are [N/2, N-1,(M/2)*N,(M*N)/2,(M-1)*N,M*N-1].

Block Default Value Valid Range

param empty_list() List(new Integer(0,None))

statistical_screening_tolerance
Specifies the tolerance in percentage used to screen sweeping parameters for
LVF characterization.

Block Default Value Valid Range

param 0.1 Float(0.0, 1.0)

statistical_significant_transistors
This is used in random/mismatch characterization. This gives the ability to
specify significant transistors on a per arc basis using set_config_opt

SiliconSmart ACE User Guide 915

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

command. Significant transistors in this context means transistors which take

part in a transition and hence influence slew/delay for the arc.

Block Default Value Valid Range

param empty_list() List(new String())

statistical_simulation_points
Specifies slew-load points (indices) to be used for LVF characterization. The
LVF table will be interpolated based on these points. If not specified,
SiliconSmart selects points based on statistical_reduction_factor.

Block Default Value Valid Range

param empty_list() List(new Integer(0,None))

statistical_simulator_bisection
If set to 0 and the parameter simulator_bisection is set to 1, stat_hold
characterization will use internal bisection while nominal hold characterization
will use simulator bisection.

Block Default Value Valid Range

param 1 0, 1

statistical_timing_abs_tolerance
Specifies the absolute value tolerance in nanoseconds for the statistically
measured delay. A warning is issued if the measured delay deviates the
imported delay by more than the tolerance.

Block Default Value Valid Range

param 10.0 Float(0.0, None)

916 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

statistical_timing_rel_tolerance
Specifies the relative value tolerance for the statistically measured delay. A
warning is issued if the measured delay deviates the imported delay by more
than the tolerance.

Block Default Value Valid Range

param 0.5 Float(0.0, None)

statistical_two_sided_screening
When turned on, LVF screening will use two-sided variation to decide
significance of parameters.

Block Default Value Valid Range

param 0 0, 1

statistical_use_pruned_netlist_for_nominal
If netlist pruning is enabled, this parameter gives an option to use pruned netlist
for nominal simulation. By default nominal delay/slew numbers are obtained by
simulating the original netlist. The logic behind this is that the user wants the
nominal delay/slew values to be as accurate as possible and does not want to
use pruned netlist for nominal delay/slew simulation.

Block Default Value Valid Range

param 0 Flag()

SiliconSmart ACE User Guide 917

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

submit_list_maxsize
Specifies the maximum number of jobs that you can submit to the queue at any
time. This must be a positive integer value or the keyword unlimited. Stand-
alone job scheduling mode ignores this parameter.

Block Default Value Valid Range

param 100000 OneOf(new Enumerated("unlimited"),

new Integer(1, None))

subtract_pin_capacitance
Subtract pin capacitance from load indices.

Block Default Value Valid Range

param 1 Flag()

sweep_states
Directs SiliconSmart to characterize all states for a particular arc in the same
acquisition, in so far as possible. This will only apply to arcs which the modeler
can handle when combined.

Block Default Value Valid Range

param 1 Flag()

table_dimension_for_internal_node
Selects between 1-D and 2-D for timing tables for arcs with internal node as
outputs.

Block Default Value Valid Range

param 1 1, 2

918 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

table_dimensions
Selects between 2-D and 3-D for power and delay tables for arcs with multiple
switching outputs.

Block Default Value Valid Range

param -1 Integer(-1,None)

time_res_high
Sets the minimum simulation time-step during the critical analysis period. This
is the smallest unit of simulation time representing the finest timing resolution
for transient measurements.

Block Default Value Valid Range

param 1e-10 Float(1e-15, 1e-3)

time_res_low
Sets the maximum simulation time-step for the simulation. This represents the
coarsest timing resolution for transient measurements.

Block Default Value Valid Range

param 100e-12 Float(1e-15, 1e-3)

update_cache_last
This parameter controls when to update the cache if enable_cache is set to 1
(default is 0). If set to yes, the SiliconSmart tool will update the cache after all

SiliconSmart ACE User Guide 919

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

the characterization job finish; if to no, it will update the cache after each job
finishes.

Block Default Value Valid Range

param 0 Flag()

use_ccs_init_delay
If set to 1, the SiliconSmart tool uses 10ps initial delay for CCST waveforms for
both timing and power, when CCS segmentation is used. If set to 0, the original
delay is preserved.

Block Default Value Valid Range

param 0 0, 1

use_ccs_native_current
If set to true value, it uses native current waveform from simulator while deriving
CCS driver current waveforms.

Block Default Value Valid Range

param 1 0, 1

use_ccsn_initial_delay
This parameter when set uses a fixed initial delay specified by
ccsn_initial_delay value for measuring the noise waveform and noise
propagation.

Block Default Value Valid Range

param 1 0, 1

920 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

use_exact_when
This parameter restricts SiliconSmart from automatically generating when
conditions. For a cell, if an arc has only one possible when condition and the
parameter use_exact_when is not set to 1 for that arc, then the timing group
corresponding to this arc/when condition will automatically become the default
group and no conditional groups will be modeled.
If the parameter use_exact_when is set to 1 for an arc, then the SiliconSmart
tool will model the timing group for this arc with the when condition (the only
one possible) in addition to the default timing group. In this case, the default
group will be a copy of the conditional group, since only one when condition is
possible.

Block Default Value Valid Range

param 0 Flag()

use_gates
Include gate contributions in a supply measurement.

Block Default Value Valid Range

param 1 Flag()

use_measured_slew_for_combined_setuphold
When setup and hold measurements are done through a single measurement
slew is measured again. If this parameter is set to 1, measured slew is used
during modeling. If this parameter is set to 0, origina slew value specified in
instance file is used during modeling.

Block Default Value Valid Range

param 1 Flag()

SiliconSmart ACE User Guide 921

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

use_save_for_initialization
This option specified that the '.save' statement will be used for initialization
purposes rather than using the tr0 file for processing waveforms.

Block Default Value Valid Range

param 1 Flag()

use_simulator_licenses
Enables the opportunistic use of standalone simulator licenses for embedded
simulator use when core licenses are all taken. This is only applicable to the
new product packaging introduced in the 2015.06 release.

Block Default Value Valid Range

param 0 Flag()

verilog_atpg_syntax
Flag to indicate if the UDP definitions must be in ATPG syntax. This parameter
must be enabled to produce models containing scan pins.

Block Default Value Valid Range

param 0 Flag()

verilog_combine_function_timing_blocks
When set to true, the function block (udp) and timing block (specify statements)
appear in one single file.

Block Default Value Valid Range

param 0 Flag()

922 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

verilog_default_combinational_delay
Specifies the default delay to be used for combinational arcs when
verilog_unit_delay is enabled.

Block Default Value Valid Range

param 1.0 Float()

verilog_default_constraint_delay
Specifies the default delay to be used for constraint arcs when
verilog_unit_delay is enabled.

Block Default Value Valid Range

param 1.0 Float()

verilog_default_sequential_delay
Specifies the default delay to be used for sequential arcs when
verilog_unit_delay is enabled.

Block Default Value Valid Range

param 1.0 Float()

verilog_delay_path_polarity
Enables the addition of polarity indicators (A +=> B or A -=> B) to combinatorial
delay path statements.

Block Default Value Valid Range

param 0 0, 1

SiliconSmart ACE User Guide 923

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

verilog_flavor
This parameter sets the simulator to be used. verilog-xl is the default value.

Block Default Value Valid Range

param \"verilog-xl\" String()

verilog_function
This parameter specifies the cell functionality during Verilog modeling.

Block Default Value Valid Range

param \"\" String()

verilog_functional_file
Specifies the name of the user-supplied Verilog specify block file. SiliconSmart
will parse the file for the 'specify' tag and insert the gates and specify
statements at that location.

Block Default Value Valid Range

param \"\" String()

verilog_hierarchy_separator
The string parameter used as the hierarchy separator when creating a pruned
flat netlist. The default value for memory pruning is '.'

Block Default Value Valid Range

param \"/\" String()

924 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

verilog_model_notifier
When set to true, a notifier row is added to the generated UDPs.

Block Default Value Valid Range

param 0 Flag()

verilog_model_power_as_inout
Specifies a list of vdd/gnd power supplies that will be treated as inout ports in
the Verilog model.

Block Default Value Valid Range

param empty list List()

verilog_model_power_as_output
Specifies a list of vdd/gnd power supplies that will be treated as output ports in
the Verilog model.

Block Default Value Valid Range

param empty list List()

verilog_model_power_supplies
This parameter can be used to specify a list of vdd/gnd power supplies that will
be treated as input ports in the Verilog model. This parameter accepts a list of
VDD/GND pin names that will be modeled as input ports for Verilog models.
For example, a typical use case would be specifying

SiliconSmart ACE User Guide 925

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

verilog_model_power_supplies as a concatenation of all pins listed in

the power_meas_supplies and power_meas_ground parameters.

Block Default Value Valid Range

param empty_list() List(new String())

Applying master definition to all cells in the library:

set_config_opt verilog_model_power_supplies [concat
[get_parameter power_meas_supplies] [get_parameter
power_meas_grounds]]

Applying definitions for specific cells with different power supplies:

set_config_opt -cell cells_with_vcc_in
verilog_model_power_supplies [concat [get_config_opt -cell
cells_with_vcc_in power_meas_supplies] [get_config_opt
-cell cells_with_vcc_in power_meas_grounds]]
set_config_opt -cell cells_with_vcc3_in
verilog_model_power_supplies [concat [get_config_opt -cell
cells_with_vcc3_in power_meas_supplies] [get_config_opt
-cell cells_with_vcc3_in power_meas_grounds]]

verilog_model_removal_as_hold
This parameter provides the option of modeling removal constraints in the
Verilog model as hold (instead of removal) timing checks. Removal timing
checks were introduced in SDF v3.0 and were not available prior to that
version. Therefore, this parameter must be enabled based on the SDF version
that will be used during back annotation.

Block Default Value Valid Range

param 0 Flag()

926 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

verilog_model_use_recrem
If this parameter is set to true, the recover task and removal task present in the
Verilog model will be combined into one task recrem.

Block Default Value Valid Range

param 0 0, 1

verilog_model_use_setuphold
If this parameter is set to true, the setup task and hold task present in the
Verilog model will be combined into one task setuphold.

Block Default Value Valid Range

param 0 Flag()

verilog_notifier_name
Specifies the string to be used as the name of the notifier.

Block Default Value Valid Range

param \"notifier\" String()

verilog_table_indices
This parameter is relevant when verilog_unit_delay is disabled. It consists of a
list of six integers to indicate three pairs of pin1/pin2 (eg: slew/load) indices to
be used of min/typ/max entries in the Verilog model. For one-dimensional
tables such as those used for mpw, every second index must be 0. If

SiliconSmart ACE User Guide 927

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

unspecified, SiliconSmart will simply consider the minimum, average and

maximum of all the values in the table.

Block Default Value Valid Range

param empty_list() List(new String())

verilog_udp_file
Specifies the name of the user-supplied Verilog udp file. SiliconSmart will
directly use the specified file instead of generating one that matches the
functional description in the instance file.

Block Default Value Valid Range

param \"\" String()

verilog_unit_delay
When true, all timing delays are modeled as unit delays. This is recommended
when using a back annotation flow. When false, the average delay values from
the .lib are added to the Verilog mode.

Block Default Value Valid Range

param 1 Flag()

verilog_unused_pins_format
Specifies the format to be used for unused pins (for instance, non-existent
preset/clear inputs) in a cell. Can be the simple string 0/1 or 1'b0/1'b1 or one of
supply0/supply1 to tie low/high the unused pins.

Block Default Value Valid Range

param \"0\" Enumerated("0, 1, 1'b0, 1'b1, supply0,

supply1")

928 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

vg_allow_floating_nets
This parameter directs VG to allow floating nets in the circuit graph. VG initially
performs circuit connectivity checks on the circuit graph supplied by FR. This
Boolean parameter indicates if VG should allow for dangling nets in the graph.
In general, there are two types of floating nets: (a) An output net from a block
that has no input nets and (b) An intermediate net from a block that does have
valid inputs but is disconnected from the rest of the circuit. Case (a) will always
result in a fatal error in the form of a failed connectivity check. Case (b) is
sometimes possible if the intermediate net does not influence the logical
functionality of the circuit (for instance, a drive strength pin). By default, VG will
flag both such cases as fatal errors and fail the circuit connectivity test. If this
parameter is set to true, VG will allow for instances of case (b) to pass.

Block Default Value Valid Range

param 1 Flag()

vg_enable_constraint_measurements
This parameter directs VG to perform constraint measurements.

Block Default Value Valid Range

param 1 Flag()

vg_enable_hidden_measurements
This parameter directs VG to perform hidden measurements.

Block Default Value Valid Range

param 1 Flag()

SiliconSmart ACE User Guide 929

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

vg_enable_pulse_measurements
This parameter directs VG to perform pulse width measurements.

Block Default Value Valid Range

param 1 Flag()

vg_enable_steady_measurements
This parameter directs VG to perform steady state (leakage) measurements.

Block Default Value Valid Range

param 1 Flag()

vg_enable_switching_measurements
This parameter directs VG to perform switching measurements.

Block Default Value Valid Range

param 1 Flag()

vg_explicit_leakage_states
List of states to be used to be used to compute leakage fugues in VG. This
parameter is used to supply a list of strings that signify leakage states explicitly.
If this list is provided, the value of state partitions is ignored and only this list of
states is used to produce steady (leakage) fugues. Each supplied string is
converted to a BDD expression if it is in the appropriate format. Nets that are
not part of the circuit but are included in the BDD are filtered. If any one of the

930 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

interface ports (primary inputs, clocks, inouts) is left unassigned, they are set to
0.

Block Default Value Valid Range

param empty_list() List(new String())

vg_log_level
This parameter sets the severity level for the messages appearing in the
VectorGenerator log file.

Block Default Value Valid Range

param \"info\" Enumerated("info, error, warning,

verbose, debug")

vg_max_arcs_per_input_transition
Indicates the maximum number of arcs allowed per input transition for a given
cell. If the actual number of arcs exceeds this number, VG will downgrade the
state_partitions value and proceed with the analysis. Note that no downgrade is
possible if state_partitions is one or one_per_path.

Block Default Value Valid Range

param 2000 Integer(1, 10000)

vg_max_leakage_states
Indicates the maximum number of leakage states allowed per cell.

Block Default Value Valid Range

param 4096 Integer(1, 100000)

SiliconSmart ACE User Guide 931

L-2016.03
Chapter 15: SiliconSmart Parameters
param Parameters

vg_partial_circuit_collapse
This parameter directs VG to partially collapse the circuit graph. This is
primarily useful for large cells to condense the circuit without changing the
functionality.

Block Default Value Valid Range

param 0 Flag()

vg_restricted_inputs
List of inputs to be used in restricted fashion. This should be accompanied by
the parameter vg_restricted_states. See the description for
vg_restricted_states for more information.

Block Default Value Valid Range

param empty_list() List(new String())

vg_restricted_states
List of states to be used to restrict some inputs during VG analysis. This should
accompany the parameter vg_restricted_inputs. Restricted states refers to a
particular input setting applied to the circuit (for instance, drive strength signals
fixed to a specific value). Restricted inputs refers to the list of inputs on which
these states are to be enforced.
You should not have the same input net be part of the restricted inputs as well
as restricted states. These parameters accept a list of strings as their
arguments. They must be specified together if they are to be considered during
VG analysis (either both are empty or both are non-empty). If there are multiple
restricted states specified, for the second and all subsequent states, only the
inputs listed in vg_restricted_inputs list are analyzed. If a primary input is listed
in vg_restricted_inputs and it is also part of one of the vg_restricted_states, the
input is abstracted out of the restricted state when arcs originating from it are
analyzed. For instance, if a is a restricted input and a restricted state is

932 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
param Parameters

specified a.!b.!c then the restricted state corresponding to arc analysis from a
will be taken as just !b.!c.

Block Default Value Valid Range

param empty_list() List(new String())

vg_state_selection
Specific state selection in the VG flow. For a given input pin, among all arcs,
fugues will be generated for only those arcs whose when conditions match the
supplied selected state value.

Block Default Value Valid Range

param \"0\" String()

voltage_name_map
This parameter is helpful in specifying voltage name where volatge name is not
same as pg_pin group name.

Block Default Value Valid Range

param empty_list() List(new String())

weak
Defines the characterization settings for characterizing pins with weakly driven
transitions.

Block Default Value Valid Range

param \"0\" String()

SiliconSmart ACE User Guide 933

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

whens
This parameter specifies the explicit secondary pin states for an arc when
'state_partitions' is set to 'explicit'.

Block Default Value Valid Range

param empty_list() List(new String())

workers_as_daemons
Starts characterization workers as daemons, so they are out of job
management control.

Block Default Value Valid Range

param \"off\" EnumeratedNoCase("{\

'0' : 'off', \
'off' : 'off', \
'false' : 'off', \
'no' : 'off', \
'1' : 'on', \
'on' : 'on', \
'true' : 'on', \
'yes' : 'on' }")

pintype Parameters
The following parameter are available in pintype block:
■
acquire_ccs_timing
■
acquire_retaining_arcs
■ aocv_input_slew
■
autorange_height
■
autorange_load
■ autorange_load_minmax_ratio
■ autorange_load_source

934 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

■
autorange_timeshift
■
bundle_from
■
bundle_to
■
bundle_width
■
bus_from
■
bus_to
■
bus_width
■
ccs_max_voltage_error
■
ccs_power_max_current_error
■
ccsn_dc_normalize_voltage
■
ccsn_default_load
■
ccsn_iv_voltage
■
ccsn_numsteps_voltage
■
cin_bias_capacitance
■
cin_high_threshold
■
cin_high_threshold_fall
■
cin_high_threshold_rise
■
cin_low_threshold
■
cin_low_threshold_fall
■
cin_low_threshold_rise
■
clock_active_period
■
clock_inactive_period
■ common_differential_cin_input
■
configure_delay_from_outputs
■
constraint_alternate_input
■
constraint_autorange_load
■
constraint_default_load
■
constraint_default_slew
■
constraint_dependent_margin

SiliconSmart ACE User Guide 935

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

■
constraint_explicit_points_load
■
constraint_explicit_points_slew
■
constraint_glitch_check
■
constraint_largest_load
■
constraint_largest_slew
■
constraint_monotonic_check
■
constraint_numsteps_load
■
constraint_numsteps_slew
■
constraint_resolution
■
constraint_scaled_points_load
■
constraint_scaled_points_slew
■
constraint_smallest_load
■
constraint_smallest_slew
■
current_resolution
■
cycle_time
■
decap_fall_time
■
default_bus_value_0
■
default_bus_value_1
■
default_height
■
default_load
■
default_load_index_position
■
default_load_index_position_mode
■ default_load_mode
■
default_load_pct
■
default_load_scale
■
default_pintype
■
default_slew
■
default_total_slew
■
default_total_slew_multiplier

936 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

■
default_voltage
■
default_width
■
delay_matching_cin_driver
■
delay_matching_cin_max
■
dependent_max_width
■
differential_pair_timing_duplication
■
differential_slew_mode
■
dontcare_bias
■
dontcare_value
■
downto
■
driver
■
driver_fall_time
■
driver_initial_delay
■
driver_mode
■
driver_pwl_fall
■
driver_pwl_rise
■
driver_pwls_fall
■
driver_pwls_rise
■
driver_rise_time
■
driver_waveform_limit
■
driver_waveform_min_dt
■
driver_waveform_points
■ ecsm_fixed_levels
■
ecsm_higher_threshold
■
ecsm_lower_threshold
■
ecsm_threshold_tolerance
■
ecsm_use_fixed_levels
■
ecsm_waveform_set
■
em_table_with_current_types

SiliconSmart ACE User Guide 937

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

■
emulated_driver_ratio
■
enable_clamped_predriver
■
enable_common_mode_voltage
■
enable_multi_threshold_receiver_cap
■
exclude_ecsm_start_end_points
■
explicit_points_frequency
■
explicit_points_height
■
explicit_points_load
■
explicit_points_rload
■
explicit_points_slew
■
explicit_points_timeshift
■
explicit_points_voltage
■
explicit_points_width
■
failure_threshold
■
failure_threshold_fall
■
failure_threshold_rise
■
fallback_threshold_pcts
■
force_driver_char_reuse
■
full_transition_mode
■
full_transition_fall_threshold
■
full_transition_rise_threshold
■
glitch_high_threshold
■ glitch_low_threshold
■
hyper_coeffs_three_point_method
■
ibis_above_rail_multiplier
■
ibis_acq_to_model
■
ibis_acq_to_model2
■
ibis_below_rail_multiplier
■
ibis_c_comp

938 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

■
ibis_composite_current
■
ibis_copyright
■
ibis_default_r_fixture
■
ibis_disclaimer
■
ibis_ground_clamp_supply
■
ibis_input_differential_nodes
■
ibis_input_node
■
ibis_input_pin_open
■
ibis_isso
■
ibis_iv_diff_pin_v_sum
■
ibis_manufacturer
■
ibis_max_gnd_clamp_ref
■
ibis_max_power_clamp_ref
■
ibis_max_pulldown_ref
■
ibis_max_pullup_ref
■
ibis_min_gnd_clamp_ref
■
ibis_min_power_clamp_ref
■
ibis_min_pulldown_ref
■
ibis_min_pullup_ref
■
ibis_model_to_acq
■
ibis_notes
■
ibis_numsteps_voltage
■ ibis_output_differential_nodes
■
ibis_output_node
■
ibis_power_clamp_supply
■
ibis_rail_extrapolate_linear
■
ibis_typ_gnd_clamp_ref
■
ibis_typ_power_clamp_ref
■
ibis_typ_pulldown_ref

SiliconSmart ACE User Guide 939

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

■
ibis_typ_pullup_ref
■
ibis_vt_v_fixture_differential_output
■
ibis_vt_v_fixture_falling_non_differential_output
■
ibis_vt_v_fixture_rising_non_differential_output
■
initial_common_mode_voltage
■
initial_delay
■
largest_frequency
■
input_fall_threshold
■
input_rise_threshold
■
largest_height
■
largest_load
■
largest_rload
■
largest_slew
■
largest_timeshift
■
largest_voltage
■
largest_width
■
liberty_bundle_as_pins
■
liberty_bus_as_pins
■
liberty_internal_pin
■
liberty_pin_groups
■
liberty_tmax_input
■
liberty_tmax_output
■ limit_noise_pulse_range
■
logic_high_level
■
logic_high_name
■
logic_high_param_name
■
logic_high_threshold
■
logic_high_threshold_fall
■
logic_high_threshold_rise

940 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

■
logic_low_level
■
logic_low_name
■
logic_low_param_name
■
logic_low_threshold
■
logic_low_threshold_fall
■
logic_low_threshold_rise
■
max_asynch_recovery
■
max_asynch_removal
■
max_cmpw
■
max_constraint
■
max_constraint_multiplier
■
max_hold
■
max_hold_hbm
■
max_min_period
■
max_ncmpw
■
max_recover_hbm
■
max_recovery
■
max_removal
■
max_removal_hbm
■
max_setup
■
max_setup_hbm
■
max_tout
■ max_width_factor
■
maxload_tout_resolution
■
members
■
min_adjust
■
min_asynch_recovery
■
min_asynch_removal
■
min_cmpw

SiliconSmart ACE User Guide 941

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

■
min_constraint
■
min_constraint_multiplier
■
min_hold
■
min_hold_hbm
■
min_min_period
■
min_ncmpw
■
min_recover_hbm
■
min_recovery
■
min_removal
■
min_removal_hbm
■
min_setup
■
min_setup_hbm
■
mpw_min_adjust
■
nochange_clock
■
node_activity_tolerance
■
node_stability_pruning_threshold
■
noise_immunity_current
■
noise_immunity_from_prop
■
noise_immunity_tolerance
■
num_ccs_samples
■
numsteps_frequency
■
numsteps_height
■ numsteps_load
■
numsteps_rload
■
numsteps_slew
■
numsteps_timeshift
■
numsteps_voltage
■
numsteps_width
■
opt_load_high

942 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

■
opt_load_low
■
partial_swing
■
output_fall_threshold
■
output_rise_threshold
■
partial_swing_minimum
■
passive_glitch_check
■
peak_ratio
■
phased_inputs
■
pin_category
■
pintype
■
pocv_input_slew
■
port
■
power_period
■
prop_delay_current
■
prop_delay_inp_level
■
prop_delay_inp_level_fall
■
prop_delay_inp_level_rise
■
prop_delay_level
■
prop_delay_out_level
■
prop_delay_out_level_fall
■
prop_delay_out_level_rise
■
rc_filter_capacitor
■ rc_filter_resistor
■
scaled_points_frequency
■
scaled_points_height
■
scaled_points_load
■
scaled_points_rload
■
scaled_points_slew
■
scaled_points_timeshift

SiliconSmart ACE User Guide 943

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

■
scaled_points_voltage
■
scaled_points_width
■
si_driver
■
side_pin_driver
■
skip_constraint_outputs
■
slew_based_margin
■
smallest_frequency
■
smallest_height
■
smallest_load
■
smallest_rload
■
smallest_slew
■
smallest_timeshift
■
smallest_voltage
■
smallest_width
■
smc_constraint_style
■
smc_degrade
■
smc_degrade_absolute
■
smc_degrade_check
■
smc_degrade_maximum
■
smc_degrade_pushout
■
smc_max_degrade_absolute
■
smc_slew_degrade
■ smc_slew_degrade_absolute
■
soi_transition_mode
■
stable_time
■
subtract_leakage
■
sweep_method_load
■
sweep_method_slew
■
switchpoint_default_slew

944 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

■
target_bits
■
tie_cell_load
■
total_slew_multiplier
■
trailing_delay
■
use_floating_hiz_output
■
verilog_attach_edges
■
voltage_resolution
■
voltage_resolution_threshold

acquire_ccs_timing
Allows the acquisition of CCS timing measurements to be selectively controlled
by pin. This is typically used when CCS measurements must be disabled for a
subset of pins on a cell, such as I/O pads. Setting this value to 0 disables CCS
timing measurements.

Block Default Value Valid Range

pintype 1 Flag()

acquire_retaining_arcs
If enabled for an arc, retain acquisition will be generated for that arc

Block Default Value Valid Range

pintype 0 Flag()

SiliconSmart ACE User Guide 945

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

aocv_input_slew
Input slew to be used for AOCV characterization.

Block Default Value Valid Range

pintype default_slew Float()

autorange_height
Indicates that the minimum input glitch height should be automatically
determined by a process of autoranging. The method finds the switching point
of the cells and determines the range of heights used for noise propagation
measurements. Set this parameter to 1 to enable height autoranging.
Specifying explicit_points_height suppresses autoranging even if
autorange_height is set to 1.

Block Default Value Valid Range

pintype 1 Flag()

autorange_load
Enables output load auto-ranging. Auto-ranging creates simulations named
\"capload\" which perform a modified binary search to determine the output
load necessary to achieve an output slew equal to the value specified by the
max_tout pintype parameter.
Load auto-ranging can be performed for every state (slower), or every pin
(faster). When using \"state\", the output slew tables should have a maximum
output slew value equal to max_tout. When using \"pin\", auto-ranging is only
done for one arbitrary state for each pin, the result of which is then applied to all
arcs ending at that pin. When using pin mode, you can expect to see
differences to maximum output slew as compared to the max_tout value,
especially if there is a lot of delay variance between different states.
Note that when explicit loads are specified via set_config_opt, auto-ranging will
not be used even if enabled. Typically, the import command is run with the
-use_default_loads switch, when auto-ranging is desired. Typically, pin based

946 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

auto-ranging produces sufficient accuracy. Note that setting auto-ranging to 1

or true, is the same as \"pin\".

Block Default Value Valid Range

pintype \"off\" EnumeratedNoCase("{ '0' : 'off', 'off' :

'off', 'false' : 'off', 'no' : 'off', '1' : 'pin', 'on'
: 'pin', 'true' : 'pin', 'yes' : 'pin', 'pin' : 'pin',
'state' : 'state' }")

autorange_load_minmax_ratio
Define the ratio of largest and smallest load value when largest_load is
calculated using autorange_load option. If the actual ratio is smaller than the
value defined for this parameter, a warning will be issued. This is to avoid too
close spacing of load points.

Block Default Value Valid Range

pintype 10 Float(0.0, 1e+9)

autorange_load_source
Identifies an arc as a possible source for load auto-ranging measurements. The
default is to consider all types of arcs as candidates. This parameter can be
used to selectively enable only certain types of arcs (for instance, delay arcs)
as a source of load auto-ranging measurements.

Block Default Value Valid Range

pintype 1 Flag()

autorange_timeshift
Indicates that the timeshift value for noise immunity measurements on
synchronous data pins is automatically determined by a process of
autoranging. Set this parameter to 1 to enable timeshift autoranging. Specifying

SiliconSmart ACE User Guide 947

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

explicit_points_timeshift suppresses autoranging even if autorange_timeshift is

set to 1.

Block Default Value Valid Range

pintype 1 Flag()

bundle_from
Modeling parameter controlling bundle group attributes. The index of the most
significant bit of a bundle.

Block Default Value Valid Range

pintype 0 Integer()

bundle_to
Modeling parameter controlling bundle group attributes. The index of the least
significant bit of a bundle.

Block Default Value Valid Range

pintype 0 Integer()

bundle_width
Specifies the number of bits in the bundle. The default value is 1 for pins and
must be greater than 1 for bundles.

Block Default Value Valid Range

pintype 1 Integer(1,None)

948 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

bus_from
Modeling parameter controlling bus group attributes. The index of the most
significant bit of a bus.

Block Default Value Valid Range

pintype 0 Integer()

bus_to
Modeling parameter controlling bus group attributes. The index of the least
significant bit of a bus.

Block Default Value Valid Range

pintype 0 Integer()

bus_width
Specifies the number of bits in the bus. The default value is 1 for pins and must
be greater than 1 for buses.

Block Default Value Valid Range

pintype 1 Integer(1,None)

ccs_max_voltage_error
Maximum allowed voltage error as a fraction of the total voltage range.

Block Default Value Valid Range

pintype 0.005 Float(0.0001,0.1)

SiliconSmart ACE User Guide 949

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

ccs_power_max_current_error
Maximum allowed current error as a fraction of the total current range.

Block Default Value Valid Range

pintype 0.005 Float(0.0001,0.1)

ccsn_dc_normalize_voltage

Block Default Value Valid Range

pintype 10 Integer(1,None)

ccsn_default_load
Defines a load value for output node of CCBs, which are internal nets with
respect to the cell-to-parent cell. This parameter is defined in the configure.tcl
file. The default value is 1e-15 .

Block Default Value Valid Range

pintype 1e-15 Float(0.0, 1e-9)

ccsn_iv_voltage
Multiplication factor used for multiplying voltage values in CCS-noise I-V curve.
This is typically rail to rail voltage. SiliconSmart automatically calculates this
internally.

Block Default Value Valid Range

pintype subst(\"($logic_high_param_ OneOf(new String(), new Float())

name-
$logic_low_param_name)+$l
ogic_low_param_name\")

950 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

ccsn_numsteps_voltage
Specifies the size of CCS-noise I-V table. This parameter also determines the
voltage range:
■
If ccsn_numsteps_voltage >=6 and <=16, the range is from -0.1VDD to
1.1VDD.
■
If ccsn_numsteps_voltage >=17 and <=25, the range is from -0.5VDD
to 1.5VDD.
■
If ccsn_numsteps_voltage >=26, the range is from -VDD to 2VDD.

Block Default Value Valid Range

pintype 29 Integer(6,None)

cin_bias_capacitance
During slew-matching input pin capacitance measurements a small capacitor is
added to the output of the active driver. This is to avoid accuracy issues with my
SPICE simulators when running with 0pf loads. See the Pin Capacitance
section in the Measurement and Modeling Methodology chapter.

Block Default Value Valid Range

pintype 1e-14 Float(0.0, 1e-12)

cin_high_threshold
Higher voltage threshold for pin capacitance measurement. This clips off any
ringing in the single and long tails caused by leakage currents through the input
pin.

Block Default Value Valid Range

pintype 0.95 Float(0.0,1.0)

SiliconSmart ACE User Guide 951

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

cin_high_threshold_fall
Higher voltage threshold for pin capacitance measurement of the falling
waveform.

Block Default Value Valid Range

pintype cin_high_threshold Float(0.0,1.0)

cin_high_threshold_rise
Higher voltage threshold for pin capacitance measurement of the rising
waveform.

Block Default Value Valid Range

pintype cin_high_threshold Float(0.0,1.0)

cin_low_threshold
Lower voltage threshold for pin capacitance measurement. This clips off any
ringing in the single and long tails caused by leakage currents through the input
pin.

Block Default Value Valid Range

pintype 0.05 Float(0.0,1.0)

cin_low_threshold_fall
Lower voltage threshold for pin capacitance measurement of the falling
waveform.

Block Default Value Valid Range

pintype cin_low_threshold Float(0.0,1.0)

952 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

cin_low_threshold_rise
Lower voltage threshold for pin capacitance measurement of the rising
waveform.

Block Default Value Valid Range

pintype cin_low_threshold Float(0.0,1.0)

clock_active_period

Block Default Value Valid Range

pintype 4.0*total_slew Float()

clock_inactive_period

Block Default Value Valid Range

pintype 5.0*total_slew Float()

common_differential_cin_input
When measuring input capacitance on a differential pin, drive each input with
the same stimulus to avoid including cross-coupling resistor currents.

Block Default Value Valid Range

pintype 1 Flag()

SiliconSmart ACE User Guide 953

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

configure_delay_from_outputs
Used to specify the relative input pin (which is actually an output pin) for output
to output arc

Block Default Value Valid Range

pintype empty_list() List(new String())

constraint_alternate_input
The list of internal pins to which to measure a constraint. Usually this is just one
internal node. If empty use pin itself.

Block Default Value Valid Range

pintype \"\" String()

constraint_autorange_load
Enables autoranging for constraint load.

Block Default Value Valid Range

pintype autorange_load EnumeratedNoCase("{ '0' : 'off', 'off' :

'off', 'false' : 'off', 'no' : 'off', '1' : 'pin', 'on'
: 'pin', 'true' : 'pin', 'yes' : 'pin', 'pin' : 'pin',
'state' : 'state' }")

constraint_default_load
Unswept load value used for constraints.

Block Default Value Valid Range

pintype default_load Float(0.0, 1e-9)

954 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

constraint_default_slew
Unswept slew value used with constraints.

Block Default Value Valid Range

pintype default_slew Float(1e-15, 1e-3)

constraint_dependent_margin
For dependent-setup or dependent-hold, this parameter controls the minimum
time between the selected independent edge and the limiting point. If the actual
margin is too small, the position of the dependent edge becomes unstable.
Typically this will be a multiple of constraint_resolution.

Block Default Value Valid Range

pintype 1.0*constraint_resolution Float(0.0, 1e-8)

constraint_explicit_points_load
Specific load indices to use for constraints.

Block Default Value Valid Range

pintype explicit_points_load List(new Float(0.0, 1e-9))

constraint_explicit_points_slew
Specific slew indices to use for constraints

Block Default Value Valid Range

pintype explicit_points_slew List(new Float(1e-15,1e-3))

SiliconSmart ACE User Guide 955

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

constraint_glitch_check
When true, verify that a transition on a constraint test output is not just a glitch.
Default is true.

Block Default Value Valid Range

pintype 1 Flag()

constraint_largest_load
Largest load index used for constraints (if autorange_load = off).

Block Default Value Valid Range

pintype largest_load Float(0.0, 30e-9)

constraint_largest_slew
Largest slew index for constraints.

Block Default Value Valid Range

pintype largest_slew Float(1e-15, 1e-3)

constraint_monotonic_check
When true, verify that a transition on a constraint test output is monotonic
between the transition thresholds.

Block Default Value Valid Range

pintype 0 Flag()

956 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

constraint_numsteps_load
Specifies the number of load points to be used in constraint measurements if
explicit_points_load is not set. This allows constraint tables to be different sizes
than the timing and power tables.

Block Default Value Valid Range

pintype numsteps_load Integer(1, 50)

constraint_numsteps_slew
Specifies the number of slew points to be used in constraint measurements if
explicit_points_slew is not set. This allows constraint tables to be different sizes
than the timing and power tables.

Block Default Value Valid Range

pintype numsteps_slew Integer(1, 50)

constraint_resolution
Defines the timing resolution used to perform constraint timing measurements
such as setup, hold, and MPW are determined. All constraints measurements
are acquired using a search algorithm where constraint_resolution represents
the smallest size of the search window.

Block Default Value Valid Range

pintype 10e-12 Float(1e-15, 1e-8)

SiliconSmart ACE User Guide 957

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

constraint_scaled_points_load
Set loads at intervals between smallest_load and largest_load (or autoranged).

Block Default Value Valid Range

pintype scaled_points_load List(new Float(0.0, 1.0))

constraint_scaled_points_slew
Set slews at intervals between smallest_slew and largest_slew.

Block Default Value Valid Range

pintype scaled_points_slew List(new Float(0.0, 1.0))

constraint_smallest_load
Smallest load index for constraints.

Block Default Value Valid Range

pintype smallest_load Float(0.0, 1e-9)

constraint_smallest_slew
Smallest slew index for constraints.

Block Default Value Valid Range

pintype smallest_slew Float(1e-15, 1e-3)

958 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

current_resolution
The current that can be taken as a unit to decide on the change of state

Block Default Value Valid Range

pintype 1e-9 Float(0.0, None)

cycle_time
Specifies the period for one cycle of a clock waveform used in constraint
measurements.

Block Default Value Valid Range

pintype clock_active_period+clock_in Float(1e-12,100e-3)

active_period

decap_fall_time
The time by which vdd values come down to its 90% for decapacitance
measurement.

Block Default Value Valid Range

pintype 10e-12 Float(1e-15, 1e-3)

default_bus_value_0
A string of 0's and 1's to use as the input to a bus when it's value is nominally 0,
as in the first state of a rise transition. The length of the string should match the
bus_width parameter.

Block Default Value Valid Range

pintype \"ALL_BITS_ZERO\" String()

SiliconSmart ACE User Guide 959

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

default_bus_value_1
A string of 0's and 1's to use as the input to a bus when it's value is nominally 1,
as in the second state of a rise transition. The length of the string should match
the bus_width parameter.

Block Default Value Valid Range

pintype \"ALL_BITS_ONE\" String()

default_height
Obsolete

Block Default Value Valid Range

pintype smallest_height OneOf(new Float(-50.0, 50.0),new

String())

default_load
Specifies the load associated with output and bidirectional pins that are
expected to transition during a simulation, except where the load is not being
swept.

Block Default Value Valid Range

pintype 40e-15 Float(0.0, 1e-9)

default_load_index_position
Specifies the index position of the load indices.

Block Default Value Valid Range

pintype 0 Integer(0, None)

960 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

default_load_index_position_mode
Specifies how to choose a load value, if multiple arcs exist with the same output
pin. This should be used along with the parameter default_load_index_position.

Block Default Value Valid Range

pintype \"first\" EnumeratedNoCase("min, max, first")

default_load_mode
Controls the loading on secondary outputs. If 'fixed' then the value of
'default_load' is used. If 'scaled' then a fraction of the maximum_load (which
may be autoranged) is used. If 'swept' then a fraction of the swept load is used.
See 'default_load_scale' for the fraction to use.

Block Default Value Valid Range

pintype \"fixed\" EnumeratedNoCase("fixed, scaled,

swept")

default_load_pct
Specifies the percentage of maximum output load to be applied on secondary
output pins

Block Default Value Valid Range

pintype 1 Float(0.0, 1.0)

default_load_scale
The fraction of autoranged load to use for loading secondary outputs. When
default_load_mode is set to scaled, the load used is the maximum load *

SiliconSmart ACE User Guide 961

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

default_load_scale. When default_load_mode is set to swept, the load used is

the primary swept load * default_load_scale.

Block Default Value Valid Range

pintype 1.0 Float(0.0, 2.0)

default_pintype
Specifies the name of a pintype to use for supply pins if the pintype has not
been set via the add_pin command. This simplifies the task of defining the
pintypes of the supply pins for an entire library.

Block Default Value Valid Range

pintype \"default\" String()

default_slew
Specifies the slew associated with pins that are required to transition during the
simulation, but have no specific slew value associated with them.

Block Default Value Valid Range

pintype 15e-12 Float(1e-15, 1e-3)

default_total_slew
An internally computed parameter that approximates the default rail-to-rail
transition time expected in the simulations. It is computed by extrapolating the

962 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

default_slew value to a full rail transition. This parameter is used as the basis
for the default value of many pin type parameters.

Block Default Value Valid Range

pintype default_total_slew_multiplier* Float(1e-15, 1e-3)

default_slew/
(logic_high_threshold-
logic_low_threshold)

default_total_slew_multiplier
Default value for total_slew_multiplier, which is specified to expand simulation
time.

Block Default Value Valid Range

pintype total_slew_multiplier Float(0.0, None)

default_voltage
Obsolete

Block Default Value Valid Range

pintype 0.0 Float()

default_width
Obsolete

Block Default Value Valid Range

pintype smallest_width Float(1e-15,1e-3)

SiliconSmart ACE User Guide 963

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

delay_matching_cin_driver
Specifies the cell to be used for delay matching cin. This cell is
precharacterized to generate delay-capacitance table. This table is used during
delay matching cin measurement.

Block Default Value Valid Range

pintype driver String()

delay_matching_cin_max
Specifies the upper limit for cap while doing delay matching driver
characterization.

Block Default Value Valid Range

pintype 1e-13 Float(0.0,1e-9)

dependent_max_width
Maximum data pulse width allowed for dependent setup/hold.

Block Default Value Valid Range

pintype -max_setup-max_hold Float()

differential_pair_timing_duplication
This parameter restricts SiliconSmart from automatically copying timing table
for differential output pair.

Block Default Value Valid Range

param 1 Flag()

964 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

differential_slew_mode
Controls the method for measuring slew to/from a differential pin pair. If
\"single\", treat the pin as a normal single-ended pin; if \"partial\", measure to
the slew thresholds relative to the partial swing rails; if \"crossover\", measure
relative to the crossover point; if \"legacy\", use the original method, similar to
\"partial\" but measured internally.

Block Default Value Valid Range

pintype \"partial\" Enumerated("single, partial, crossover,

legacy")

dontcare_bias
Preferred value to use for this pin if a choice exists. Used for arbitrary selection
among several possible states for a measurement.

Block Default Value Valid Range

pintype dontcare_value Enumerated("0, 1, Z")

SiliconSmart ACE User Guide 965

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

dontcare_value

Block Default Value Valid Range

pintype \"0\" Enumerated("0, 1, Z")

downto
A modeling parameter for controlling bus group attributes. If set to 1, the
number assignment for the bus_from and bus_to parameters will be from
high to low, respectively.

Block Default Value Valid Range

pintype 0 0, 1

driver
Specifies the device (cell) used to generate the input stimulus on pins.
Specifying pwl directs SiliconSmart to use an ideal, linear voltage ramp. To use
an active driver cell, set this parameter to the name of a cell imported with the
import_driver command.

Block Default Value Valid Range

pintype \"pwl\" String()

driver_fall_time
Specifies the fall transition time for the input stimulus to an active driver cell.
The time specified for this parameter corresponds to the rail-to-rail time for the
piece-wise-linear waveform applied in Spice.

Block Default Value Valid Range

pintype 10e-12 Float(1e-15, 1e-3)

966 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

driver_initial_delay
Initial delay specified for driver.

Block Default Value Valid Range

pintype 10e-12 Float(1e-12, 2.5e3)

driver_mode
Type of driver to use for stimulating each pin during characterization:
■
active — uses a driver cell driving a capacitance to produce a realistic input
waveform of the required slew.
■ active-waveform — preferred to active; it captures the active driver
waveforms and uses a pwl input so that the driver does not have to be
simulated more than once
■ active-direct — attaches the driver to the CUT; it does not allow control of
the input slew.
■
pwl — a simple ramp.
■ custom — similar to pwl but with a user supplied shape from the parameters
driver_pwl_rise and driver_pwl_fall.
■
custom-perslew — sets different waveform shapes for each slew with a tcl
list of lists and the parameters driver_pwls_rise and driver_pwls_fall.
■
emulated — the standard CCS timing waveform shape.
■ pin-active-waveform — derives the driver shape by driving each pin with the
driver cell and then using the resulting shape as a custom waveform.

Block Default Value Valid Range

pintype pwl active, active-waveform, active-direct,

pwl, custom, custom-perslew,
emulated, pin-active-waveform

SiliconSmart ACE User Guide 967

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

driver_pwl_fall
Used for custom waveform driver. This parameter controls the shape of the fall
PWL pre-driver. You must explicitly set this parameter. It is a list of floating point
values between 0 and 1 (normalized) and the lengths of the list must be
equivalent with the list for the parameter driver_pwl_rise. According to these
two list values, the SiliconSmart tool scales the rise and fall waveforms.

Block Default Value Valid Range

pintype empty list List of values between 0 and 1

driver_pwl_rise
Used for custom waveform driver. This parameter controls the shape of the rise
PWL pre-driver. You must explicitly set this parameter. It is a list of floating point
values between 0 and 1 (normalized) and the lengths of the list must be
equivalent with the list for the parameter driver_pwl_fall. According to these two
list values, the SiliconSmart tool scales the rise and fall waveforms.

Block Default Value Valid Range

pintype empty list List of values between 0 and 1

driver_pwls_fall
Used for custom waveform per slew (custom-perslew) driver. The value should
be a tcl list of lists. This represents the set of falling driver waveforms. The
voltage levels used in each waveform should be the same and normalized (and
between 1->0) and the time values should be in units of seconds. The format
should be: {{slew1} {t11 v1 t12 v2 ... t1n vn} ... {slewm} {tm1 v1 tm2 v2 ... tmn
vn}}.

Block Default Value Valid Range

pintype empty list List of values between 1 and 0

968 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

driver_pwls_rise
Used for custom waveform per slew (custom-perslew) driver. The value should
be a tcl list of lists. This represents the set of rising driver waveforms. The
voltage levels used in each waveform should be the same and normalized (and
between 0->1) and the time values should be in units of seconds. The format
should be {{slew1} {t11 v1 t12 v2 ... t1n vn} ... {slewm} {tm1 v1 tm2 v2 ... tmn
vn}}.

Block Default Value Valid Range

pintype empty list List of values between 0 and 1

driver_rise_time
Specifies the rise transition time for the input stimulus to an active driver cell.
The time specified for this parameter corresponds to the rail-to-rail time for the
piece-wise-linear waveform applied in Spice.

Block Default Value Valid Range

pintype 10e-12 Float(1e-15, 1e-3)

driver_waveform_limit
The maximum ratio between the actual rail-to-rail time and the linear rail-to-rail
time. Enforced only for pin-active-waveform at present.

Block Default Value Valid Range

pintype 3.0 Float(1.0, None)

driver_waveform_min_dt
When you provide your driver_waveform_points to be too close (many points in
the range 0-100%), then the driver_waveform_min_dt will activate. The
SiliconSmart tool will determine that two voltage points should be at least

SiliconSmart ACE User Guide 969

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

driver_waveform_min_dt interval apart to satisfy the spice engine. If voltage

point separation is too close, the second point will be moved so that the
separation is at least driver_waveform_min_dt.

Block Default Value Valid Range

pintype 1e-13 Float(1e-20, 1e-10)

driver_waveform_points
Normalized voltage values used for waveform based active driver. Must match
driver characterization. This parameter contains a list of floating point numbers
between 0 and 1.0 in ascending order. Specifying more points will cause the
waveform to be more similar to the actual driver waveform. In general, the
defaults for this parameter shows good correlation when compared to active
driver mode.

Block Default Value Valid Range

pintype list(0.02, 0.05, 0.10, 0.20, List(new Float(0.0, 1.0))

0.30, 0.40, 0.50, 0.60, 0.70,
0.80, 0.90, 0.95, 0.98)

ecsm_fixed_levels
If ecsm_use_fixed_levels=1, use these fixed sampling thresholds for ecsm
voltage waveforms.

Block Default Value Valid Range

pintype list(0.02, 0.10, 0.25, 0.50, List(new Float(0.0, 1.0), 3)

0.75, 0.90, 0.98)

970 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

ecsm_higher_threshold
Higher threshold for ecsm waveform. If the voltage waveform does not cross
this threshold, ecsm measurement will fail

Block Default Value Valid Range

pintype 0.98 Float(0.5, 0.999)

ecsm_lower_threshold
Lower threshold for ecsm waveform. If the voltage waveform does not cross this
threshold, ecsm measurement will fail

Block Default Value Valid Range

pintype 0.02 Float(0.001, 0.5)

ecsm_threshold_tolerance
ECSM waveforms must have points near the upper and lower slew threshold
and near the delay threshold. How near is configurable here, and in lc_shell.
Too near runs the risk of simultaneous times due to round-off error so 0.001 is
about the smallest reasonable value. This parameter is now expressed as a
fraction of the threshold value rather than as an absolute difference.

Block Default Value Valid Range

pintype 0.1 Float(0.0001, 0.1)

ecsm_use_fixed_levels
If true, use fixed sampling thresholds for ECSM waveforms.

Block Default Value Valid Range

pintype 0 Flag()

SiliconSmart ACE User Guide 971

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

ecsm_waveform_set
If true, use ECSM_waveform_set syntax.

Block Default Value Valid Range

pintype 0 Flag()

em_table_with_current_types
Generate separate EM toggle rate tables for different current types (average,
RMS, peak) . The default is 0.

Block Default Value Valid Range

param 0 Flag()

emulated_driver_ratio
When the driver_mode is emulated, this parameter is used to construct a
voltage waveform that is a weighted sum of a linear voltage curve and an
exponential voltage ramp.

Block Default Value Valid Range

pintype 0.5 Float(0.0,1.0)

enable_clamped_predriver
When the driver_mode is ccs-predriver (emulated), this parameter is
used to construct a voltage waveform that is a weighted sum of a clamped
linear voltage curve and an exponential voltage ramp.

Block Default Value Valid Range

pintype 0 Flag()

972 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

enable_common_mode_voltage
Start simulation with pin at initial_common_mode_voltage before
transitioning to the initial state for the measurement. This is currently ignored
for non-differential pins.

Block Default Value Valid Range

pintype 0 Flag()

enable_multi_threshold_receiver_cap
Determines whether receiver capacitance is measured/modeled at multiple
thresholds.

Block Default Value Valid Range

param 0 Flag()

exclude_ecsm_start_end_points
The rail times for ecsm are fictional and are only included since ECSM once
required them. Set this to false to eliminate them.

Block Default Value Valid Range

pintype 0 Flag()

explicit_points_frequency
This parameter can be used to specify the explicit frequency values that should
be used to find out the intrinsic capacitance value for the cell for CCS power
measurements.

Block Default Value Valid Range

pintype empty_list() List(new Float())

SiliconSmart ACE User Guide 973

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

explicit_points_height
Specifies a list of input glitch heights (in volts) to be swept when acquiring noise
measurements. When specified, SiliconSmart does not automatically generate
a range of heights and the numsteps_height, smallest_height, and
largest_height parameters are ignored.

Block Default Value Valid Range

pintype empty_list() List(new Float(-50.0, 50.0))

explicit_points_load
Specifies a list of loads to be swept when acquiring measurements. When
specified, SiliconSmart does not automatically generate a range of loads, and
the numsteps_load, smallest_load, and largest_load settings are ignored.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 3e-9))

explicit_points_rload
Specifies a list of loads for the second output pin to be swept when acquiring
measurements. When specified, SiliconSmart does not automatically generate
a range of loads, and the numsteps_rload, smallest_rload, and largest_rload
settings are ignored.

Block Default Value Valid Range

pintype empty_list() List(new Float(1e-9,None))

974 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

explicit_points_slew
Specifies a list of slews to be swept when acquiring measurements. When
specified, SiliconSmart does not automatically generate a range of slews and
numsteps_slew, smallest_slew, and largest_slew settings are ignored.

Block Default Value Valid Range

pintype empty_list() List(new Float(1e-15,1e-3))

explicit_points_timeshift
Specifies a list of times (in seconds) to be swept when acquiring time shift
acquisitions on a sequential input relative to an edge-triggered clock pin. See
Characterization and Modeling.

Block Default Value Valid Range

pintype empty_list() List(new Float())

explicit_points_voltage
If voltage must be swept at a pin for any measurement, this parameter can be
used to specify the values explicitly.

Block Default Value Valid Range

pintype empty_list() List(new Float())

explicit_points_width
Specifies a list of input glitch widths (in volts) to be swept when acquiring noise
measurements. When specified, SiliconSmart does not automatically generate

SiliconSmart ACE User Guide 975

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

a range of heights and the numsteps_width, smallest_width, and largest_width

parameters are ignored.

Block Default Value Valid Range

pintype empty_list() List(new Float(1e-15,1e-3))

failure_threshold
The maximum safe voltage change allowed on an output in response to an
input glitch. Responses greater than this value are considered a failure. If
unset, a slope matching algorithm is used as described in Characterization and
Modeling.

Block Default Value Valid Range

pintype 0.0 Float()

failure_threshold_fall
Same as failure_threshold, but only applies to falling output values. The value
must be positive as it is an absolute threshold.

Block Default Value Valid Range

pintype failure_threshold Float()

failure_threshold_rise
Same as failure_threshold, but only applies to rising output values.

Block Default Value Valid Range

pintype failure_threshold Float()

976 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

fallback_threshold_pcts
Specifies a list of desired multiple percentage threshold levels that are used to
detect failures caused by fallbacks. When this parameter is set, fallback checks
using logic_low_threshold and logic_high_threshold are not
performed.
If nothing is specified, fallback check is done at logic_low_threshold and
logic_high_threshold. If some values are specified, fallback check is
done only at thresholds specified through this parameter.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

force_driver_char_reuse
Enforce reuse of driver db and bypassing driver char job. Note that it will reuse
driver db blindly. Use with caution.

Block Default Value Valid Range

param 0 Flag()

full_transition_mode
Determines whether the cell makes a full transition or not in the delay/slew
characterization. When enabled, it conducts timeAtVoltage measurement after
delay/slew/propagating_power characterization.

Block Default Value Valid Range

pintype 0 0, 1

full_transition_fall_threshold
When the full_transition_mode parameter is set to 1, this parameter
defines the thresholds of full transition voltage for output pin (in rising arc and

SiliconSmart ACE User Guide 977

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

falling arc, respectively). They are collectively used for checking whether the
cell can reach the fraction of the supply voltage and full transition during the
delay/slew/propagating_power characterization. Each value must be between 0
and 1.0.

Block Default Value Valid Range

pintype 0.005 Float(0.0, 1.0)

full_transition_rise_threshold
When the full_transition_mode parameter is set to 1, this parameter
defines the thresholds of full transition voltage for output pin (in rising arc and
falling arc, respectively). They are collectively used for checking whether the
cell can reach the fraction of the supply voltage and full transition during the
delay/slew/propagating_power characterization. Each value must be between 0
and 1.0.

Block Default Value Valid Range

pintype 0.995 Float(0.0, 1.0)

glitch_high_threshold
The fraction of a complete transition from the high rail to the low rail which
constitutes a glitch.

Block Default Value Valid Range

pintype logic_high_threshold Float(0.0, 1.0)

978 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

glitch_low_threshold
The fraction of a complete transition from the low rail to the high rail which
constitutes a glitch.

Block Default Value Valid Range

pintype logic_low_threshold Float(0.0, 1.0)

hyper_coeffs_three_point_method
If true, use the three point error estimatation method to determine hyperbolic
noise coefficients. Otherwise use the default curve fitting method.

Block Default Value Valid Range

pintype 0 Flag()

ibis_above_rail_multiplier
A multiplier used to determine the top of the power clamp and IV curve voltage
range in the equation, ibis_above_rail_multiplier * (VDD-VSS) + VSS. The
default of 1.0 corresponds to a voltage of 2*VDD (assuming VSS is ground).

Block Default Value Valid Range

pintype 1.0 Float(0.0, 1.0)

ibis_acq_to_model
internal usage, map acq to model

Block Default Value Valid Range

param empty_list() Dict(new String())

SiliconSmart ACE User Guide 979

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_acq_to_model2
internal usage, map acq to model

Block Default Value Valid Range

param \"\" String()

ibis_below_rail_multiplier
A multiplier used to determine the bottom of the ground clamp voltage range in
the equation, VSS - ibis_below_rail_multiplier * (VDD-VSS). The default of 1.0
corresponds to a voltage of -VDD (assuming VSS is ground).

Block Default Value Valid Range

pintype 1.0 Float(0.0, 1.0)

ibis_c_comp
The size of the capacitive load to use in VT-curve measurements. The value
can also be the name of an operating condition parameter defined with the
command set_opc_parameter. This allows the capacitance value to vary
across operating conditions.

Block Default Value Valid Range

pintype 0.0 Float(0.0, 1e-9)

980 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_composite_current
This boolean parameter controls the [Composite Current] section in IBIS
models. Note [Composite Current] is supported in IBIS from version 5.0 and
above.

Block Default Value Valid Range

pintype 0 Flag()

ibis_copyright
This parameter controls ibis copyright section which would be written to the ibis
files.

Block Default Value Valid Range

param \"\" String()

ibis_default_r_fixture
The resistance used to characterize the transient data (V-T). For high speed
designs this usually equals the characteristic impedance of a transmission line
(Z0 = 50 Ohms). An exception to this rule is the USB1.1 (low speed) cell which
needs to characterized at 15K Ohms for the upstream port load version. It
becomes more complicated for the downstream port load where only one of the
pads gets connected to 1.5K and the other one is left floating.

Block Default Value Valid Range

pintype 50.0 Float()

SiliconSmart ACE User Guide 981

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_disclaimer
This parameter controls ibis disclaimer section which would be written to the
ibis files

Block Default Value Valid Range

param \"\" String()

ibis_ground_clamp_supply
Specifies an alternate supply name to be used as the reference voltage during
ground clamp measurements.

Block Default Value Valid Range

pintype logic_low_name String()

ibis_input_differential_nodes
Specify differential input nodes.

Block Default Value Valid Range

pintype empty_list() List(new String())

ibis_input_node
Specify input node for IO buffer.

Block Default Value Valid Range

pintype \"\" String()

982 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_input_pin_open
In the case LVDS, during clamping current characterization VREF pin must be
floating or attached to a small capacitance. The possible values are none and
one. When set to one, a small capacitance will be connected to VREF. Default
value is none which means connection of source/device at VREF will be
controlled by normal behavior.

Block Default Value Valid Range

pintype \"none\" Enumerated("one none")

ibis_isso
This boolean parameter controls the [ISSO_PU] and [ISSO_PD] section in IBIS
models. Note [ISSO_P?] is supported in IBIS from version 5.0 and above.

Block Default Value Valid Range

pintype 0 Flag()

ibis_iv_diff_pin_v_sum
The sum of the voltages at differential pins during I-V characterization. In case
of LVDS (one of them anyway) it turns out to be 2*VREF For USB1.1 (low
speed) the sum turns to be equal to DVDD.

Block Default Value Valid Range

pintype \"DVDD\" String()

SiliconSmart ACE User Guide 983

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_manufacturer
This parameter controls ibis manufacturer section which would be written to the
ibis files

Block Default Value Valid Range

param \"\" String()

ibis_max_gnd_clamp_ref
Specifies max corner's ground clamp voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype ibis_max_pulldown_ref Float()

ibis_max_power_clamp_ref
Specifies max corner's power clamp voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype ibis_max_pullup_ref Float()

984 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_max_pulldown_ref
Specifies max corner's pull-down voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype 0.0 Float()

ibis_max_pullup_ref
Specifies max corner's pull-up voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype 0.0 Float()

ibis_min_gnd_clamp_ref
Specifies min corner's ground clamp voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype ibis_min_pulldown_ref Float()

SiliconSmart ACE User Guide 985

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_min_power_clamp_ref
Specifies min corner's power clamp voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype ibis_min_pullup_ref Float()

ibis_min_pulldown_ref
Specifies min corner's pull-down voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype 0.0 Float()

ibis_min_pullup_ref
Specifies min corner's pull-up voltage. This is used only when the three corners
of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype 0.0 Float()

ibis_model_to_acq
internal usage, map model to acq

Block Default Value Valid Range

param empty_list() Dict(new String())

986 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_notes
This parameter controls ibis notes section which would be written to the ibis
files

Block Default Value Valid Range

param \"\" String()

ibis_numsteps_voltage
The number of voltage steps to use when capturing the IBIS IV curve data.

Block Default Value Valid Range

pintype numsteps_voltage Integer(0, 100)

ibis_output_differential_nodes
Specify differential output nodes.

Block Default Value Valid Range

pintype empty_list() List(new String())

ibis_output_node
Specify output node for IO buffer.

Block Default Value Valid Range

pintype \"\" String()

SiliconSmart ACE User Guide 987

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_power_clamp_supply
Specifies an alternate supply name to be used as the reference voltage during
power clamp measurements.

Block Default Value Valid Range

pintype logic_high_name String()

ibis_rail_extrapolate_linear
This parameter is used when the parameters ibis_below_rail_multiplier and
ibis_above_rail_multiplier take on values other than 1. Since IBIS needs data in
the entire range of [-VDD, 2VDD], this parameter gives the option of
extrapolating linearly (set this parameter to 1) or repeating the last point which
is the default option.

Block Default Value Valid Range

pintype 0 Flag()

ibis_typ_gnd_clamp_ref
Specifies typ corner's ground clamp voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype ibis_typ_pulldown_ref Float()

988 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

ibis_typ_power_clamp_ref
Specifies typ corner's power clamp voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype ibis_typ_pullup_ref Float()

ibis_typ_pulldown_ref
Specifies typ corner's pull-down voltage. This is used only when the three
corners of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype 0.0 Float()

ibis_typ_pullup_ref
Specifies typ corner's pull-up voltage. This is used only when the three corners
of IBIS are characterized separately and needs to be merged. See also
ibis_plan_for_corner_merge.

Block Default Value Valid Range

pintype 0.0 Float()

ibis_vt_v_fixture_differential_output
V_fixture for differential ended cells used in characterizing V-T curves for IBIS
models. The default implemented in the SiliconSmart code is both VDD and

SiliconSmart ACE User Guide 989

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

VSS. An important exception to this rule is LVDS (one of them anyway), where
only VREF is used.

Block Default Value Valid Range

pintype empty_list() List(new String())

ibis_vt_v_fixture_falling_non_differential_output
The voltages used to characterize falling V-T curves for IBIS models. If left
empty, then the values are set to logic_high_name (for example DVDD) and
logic_low_name (for example DVSS).

Block Default Value Valid Range

pintype logic_high_name List(new String())

logic_low_name

ibis_vt_v_fixture_rising_non_differential_output
The voltages used to characterize rising V-T curves for IBIS models. If left
empty, then the values are set to logic_high_name (for example DVDD) and
logic_low_name (for example DVSS).

Block Default Value Valid Range

pintype logic_high_name List(new String())

logic_low_name

initial_common_mode_voltage
'Common-mode' voltage for a differential pin.

Block Default Value Valid Range

pintype 0.0 Float()

990 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

initial_delay
Specifies an initial period at the beginning of each simulation during which
there is no activity for the driving stimulus.

Block Default Value Valid Range

pintype 2.5*total_slew Float(1e-12, 2.5e3)

largest_frequency
This parameter specifies the value of the largest frequency that will be used to
find out the intrinsic capacitance for the cell for CCS power measurements. The
default value of this parameter is 1GHz.

Block Default Value Valid Range

pintype 1e+9 Float()

input_fall_threshold
Defines an absolute threshold value for the delay measurement trip point (Vth),
used for intrinsic delay and constraint acquisition, as an input signal fall
transition voltage swing.

Block Default Value Valid Range

pintype 0 Float()

SiliconSmart ACE User Guide 991

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

input_rise_threshold
Defines an absolute threshold value for the delay measurement trip point (Vth),
used for intrinsic delay and constraint acquisition, as an input signal rise
transition voltage swing.

Block Default Value Valid Range

pintype 0 Float()

largest_height
Controls the upper bound on the glitch heights over which noise immunity and
noise propagation characterization is performed. The value of this parameter
needs to be larger that the switching threshold of the cell.

Block Default Value Valid Range

pintype subst(\"$logic_high_param_n OneOf(new Float(-50.0, 50.0), new

ame- String())
$logic_low_param_name\")

largest_load
Specifies the largest load in a range of values generated by SiliconSmart when
explicit_points_load is not specified or is an empty list. See also
numsteps_load and smallest_load.

Block Default Value Valid Range

pintype 90e-15 Float(0.0, 30e-9)

992 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

largest_rload
Specifies the largest load for the second output in a range of values generated
by SiliconSmart when explicit_points_rload is not specified or is an empty list.
See also numsteps_rload and smallest_rload.

Block Default Value Valid Range

pintype 10e3 Float(1e-9,None)

largest_slew
Specifies the largest slew in a range of values generated by SiliconSmart when
explicit_points_slew is not specified or is an empty list. See also
numsteps_slew and smallest_slew.

Block Default Value Valid Range

pintype 1.2e-9 Float(1e-15, 1e-3)

largest_timeshift
Specifies the latest data glitch arrival time before (or after for negative) the
clock edge. The smaller the value the later the glitch.

Block Default Value Valid Range

pintype -3.0*default_total_slew Float()

SiliconSmart ACE User Guide 993

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

largest_voltage
Specifies the maximum voltage used when characterizing the steady state IV
curves for a cell. This value must be above the largest supply rail in order to
properly characterize the IV curves.

Block Default Value Valid Range

pintype subst(\"2.0*($logic_high_par OneOf(new String(), new Float())

am_name-
$logic_low_param_name)+$l
ogic_low_param_name\")

largest_width
Specifies the maximum width of the injected glitches used for characterizing
noise immunity and noise propagation behavior.

Block Default Value Valid Range

pintype max_width_factor*total_slew Float(1e-15,30e-3)

liberty_bundle_as_pins
Specifies a subset or range of pins for use with Liberty modeling only. The
model produced need not depend on what is characterized. For instance, an
arc delay may be computed for all bits of a bundle, but the model may only have
a single number for the bundle or for a couple of sub-bundles of the bundle (0:7
8:15).
Consider the following example:
set_config_opt -pin D liberty_bundle_as_pins { 0 1 2 3}

Here, the measurement for the 4-bit bundle D must be modeled at pin-level for
each of its bits 0, 1, 2, and 3. If unspecified, the measurements are modeled
only at bundle level D.

994 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

Note: When specified along with the set_pins_to_bundle_map

command, the liberty_bundle_as_pins takes precedence.
The bits will be split out and the -unsplit option will be ignored.

Block Default Value Valid Range

pintype empty_list() List(new String())

See Also
■
set_pins_to_bundle_map

liberty_bus_as_pins
This pintype parameter specifies a subset or range of pins intended to be used
for liberty modeling only. The concept is that the model produced does not have
to strongly depend on what is characterized.
For instance, a delay for an arc may be computed for all the bits of a bus, but
the model may only have a single number for the bus or for a couple of sub-
buses of the bus(0:7 8:15) for instance.

Block Default Value Valid Range

pintype empty_list() List(new String())

liberty_internal_pin
Internal pins are not normally included in the Liberty model. Set this true for
pins which should be.

Block Default Value Valid Range

pintype 0 Flag()

liberty_pin_groups
This pintype parameter specifies the list of bits that will be used for creating pin-
groups within the bus-group for liberty modeling in create_new_model flow.

SiliconSmart ACE User Guide 995

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

For example: set_config_opt -pin Q liberty_pin_groups { 0 1 2 3 4 5 6 7} This

states that the Siliconsmart needs to create pin groups Q[0], Q[1], ... , Q[7]
inside the bus group Q. Measurements related to bus Q will be modeled inside
these pin groups depending on the arc-wise settings for parameter
'liberty_bus_as_pins'.

Block Default Value Valid Range

pintype empty_list() List(new String())

liberty_tmax_input
This parameter can be set to a floating point value and specifies a value for the
max_transition attribute on input pins. If unset, the value of the pin type
parameter largest_slew is used.

Block Default Value Valid Range

pintype 0.0 Float(0.0, 1e-3)

liberty_tmax_output
This parameter can be set to a floating point value and it specifies a value for
the max_transition attribute on output pins. If unset, the value of the pin type
parameter max_tout is used.

Block Default Value Valid Range

pintype 0.0 Float(0.0, 1e-3)

996 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

limit_noise_pulse_range
Indicates if the noise pulses should be limited to rail-to-rail values or if
undershoots/overshoots should be considered.

Block Default Value Valid Range

pintype 0 Flag()

logic_high_level
Rail level for pwl.

Block Default Value Valid Range

pintype 0.0 Float()

logic_high_name
Specifies a symbolic supply name that indicates the ceiling or floor of the
voltage swing on pins that are associated with this pin type. Differential output
pins that have partial swings must have a valid supply name for this parameter
(valid implies that the supply is defined inside an operating condition block).
SiliconSmart dynamically determines the actual value of the high voltage swing
on differential output ports, but it still requires the parameter to be specified.

Block Default Value Valid Range

pintype \"VDD\" String()

SiliconSmart ACE User Guide 997

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

logic_high_param_name
Alias of logic_high_name

Block Default Value Valid Range

pintype param_name(logic_high_na String()

me)

logic_high_threshold
Defines the thresholds for a logic-low and logic-high voltage, respectively, for
pins associated with this pin type. These are collectively used for output
transition time determination if the pin is an output and for determining the
transition times of the driving signal if the pin is an input.
Each value must be between 0 and 1.0, indicating a fraction of the full signal
swing. These values are a fraction of rail-to-rail voltage for digital pins. For
differential output ports, the values represent a fraction of the total swing
between the steady state values of a low and high where the swing is
automatically determined.

Block Default Value Valid Range

pintype 0.8 Float(0.0, 1.0)

logic_high_threshold_fall
This parameter specifies the threshold for logic-high voltage for the falling
waveform.

Block Default Value Valid Range

pintype logic_high_threshold Float(0.0, 1.0)

998 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

logic_high_threshold_rise
This parameter specifies the threshold for logic-high voltage for the rising
waveform.

Block Default Value Valid Range

pintype logic_high_threshold Float(0.0, 1.0)

logic_low_level
Rail level for pwl.

Block Default Value Valid Range

pintype 0.0 Float()

logic_low_name
Specifies a symbolic supply name that indicates the ceiling or floor of the
voltage swing on pins that are associated with this pin type. Differential output
pins that have partial swings must have a valid supply name for this parameter
(valid implies that the supply is defined inside an operating condition block).
SiliconSmart dynamically determines the actual value of the high voltage swing
on differential output ports, but it still requires the parameter to be specified.

Block Default Value Valid Range

pintype \"VSS\" String()

SiliconSmart ACE User Guide 999

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

logic_low_param_name
Alias of logic_low_name

Block Default Value Valid Range

pintype param_name(logic_low_nam String()

e)

logic_low_threshold
Defines the thresholds for a logic-low and logic-high voltage, respectively, for
pins associated with this pin type. These are collectively used for output
transition time determination if the pin is an output and for determining the
transition times of the driving signal if the pin is an input.
Each value must be between 0 and 1.0, indicating a fraction of the full signal
swing. These values are a fraction of rail-to-rail voltage for digital pins. For
differential output ports, the values represent a fraction of the total swing
between the steady state values of a low and high where the swing is
automatically determined.

Block Default Value Valid Range

pintype 0.2 Float(0.0, 1.0)

logic_low_threshold_fall
This parameter specifies the threshold for logic-low voltage for the falling
waveform.

Block Default Value Valid Range

pintype logic_low_threshold Float(0.0, 1.0)

1000 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

logic_low_threshold_rise
This parameter specifies the threshold for logic-low voltage for the rising
waveform.

Block Default Value Valid Range

pintype logic_low_threshold Float(0.0, 1.0)

max_asynch_recovery
max_constraint for asynchronous recovery.

Block Default Value Valid Range

pintype max_constraint Float()

max_asynch_removal
max_constraint for asynchronous removal.

Block Default Value Valid Range

pintype max_constraint Float()

max_cmpw
Maximum pulse width to test for active MPW search.

Block Default Value Valid Range

pintype clock_active_period Float()

SiliconSmart ACE User Guide 1001

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

max_constraint
The smallest (most optimistic) constraint value.

Block Default Value Valid Range

pintype - Float()
max_constraint_multiplier*tot
al_slew

max_constraint_multiplier
The smallest (most optimistic) constraint value.

Block Default Value Valid Range

pintype 1.2 Float()

max_hold
max_constraint for hold

Block Default Value Valid Range

pintype max_constraint Float()

max_hold_hbm
max_constraint for hold hbm

Block Default Value Valid Range

pintype max_constraint Float()

1002 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

max_min_period
Maximum period to test for min period search.

Block Default Value Valid Range

pintype clock_active_period+clock_in Float()

active_period

max_ncmpw
Maximum pulse width to test for inactive MPW search.

Block Default Value Valid Range

pintype clock_inactive_period Float()

max_recover_hbm
max_constraint for recovery hbm.

Block Default Value Valid Range

pintype max_constraint Float()

max_recovery
max_constraint for recovery.

Block Default Value Valid Range

pintype max_constraint Float()

SiliconSmart ACE User Guide 1003

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

max_removal
max_constraint for removal.

Block Default Value Valid Range

pintype max_constraint Float()

max_removal_hbm
max_constraint for removal.

Block Default Value Valid Range

pintype max_constraint Float()

max_setup
max_constraint for setup.

Block Default Value Valid Range

pintype max_constraint Float()

max_setup_hbm
max_constraint for setup hbm.

Block Default Value Valid Range

pintype max_constraint Float()

1004 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

max_tout
The maximum output transition time that is expected on the output pin.

Block Default Value Valid Range

pintype 1e-9 Float(1e-15, 1e-3)

max_width_factor
Specifies the factor to calculate the default value for largest_width (equals
max_width_factor*total_slew)

Block Default Value Valid Range

pintype 3.0 Float()

maxload_tout_resolution
Specifies the maximum difference between the desired output transition time
(max_tout) and the actual output transition time found by max load autorange
simulations. The value is in seconds.

Block Default Value Valid Range

pintype 10e-12 Float(1e-15, 1e-9)

members
Modeling parameter controlling bundle group attributes.

Block Default Value Valid Range

pintype empty_list() List(new String())

SiliconSmart ACE User Guide 1005

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

min_adjust

Block Default Value Valid Range

pintype 1.0+mpw_min_adjust Float()

min_asynch_recovery
min_constraint for asynchronous recovery.

Block Default Value Valid Range

pintype min_constraint Float()

min_asynch_removal
min_constraint for asynchronous removal

Block Default Value Valid Range

pintype min_constraint Float()

min_cmpw
Minimum pulse width to test for active MPW search.

Block Default Value Valid Range

pintype 1e-12 Float()

1006 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

min_constraint
The largest (most pessimistic) constraint value.

Block Default Value Valid Range

pintype min_constraint_multiplier*tot Float()

al_slew

min_constraint_multiplier
Default min_constraint = min_constraint_multiplier*total_slew

Block Default Value Valid Range

pintype 1.2 Float()

min_hold
min_constraint for hold.

Block Default Value Valid Range

pintype min_constraint Float()

min_hold_hbm
min_constraint for hold hbm.

Block Default Value Valid Range

pintype min_constraint Float()

SiliconSmart ACE User Guide 1007

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

min_min_period
Minimum period to test for min period search.

Block Default Value Valid Range

pintype 1e-12 Float()

min_ncmpw
Minimum pulse width to test for inactive MPW search.

Block Default Value Valid Range

pintype 1e-12 Float()

min_recover_hbm
min_constraint for recovery hbm.

Block Default Value Valid Range

pintype min_constraint Float()

min_recovery
min_constraint for recovery.

Block Default Value Valid Range

pintype min_constraint Float()

1008 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

min_removal
min_constraint for removal

Block Default Value Valid Range

pintype min_constraint Float()

min_removal_hbm
min_constraint for removal hbm

Block Default Value Valid Range

pintype min_constraint Float()

min_setup
min_constraint for setup

Block Default Value Valid Range

pintype min_constraint Float()

min_setup_hbm
min_constraint for setup hbm

Block Default Value Valid Range

pintype min_constraint Float()

SiliconSmart ACE User Guide 1009

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

mpw_min_adjust

Block Default Value Valid Range

pintype 1e-4 Float()

nochange_clock
identifies a pin as a clock for the purpose of no-change measurements.

Block Default Value Valid Range

pintype 0 Flag()

node_activity_tolerance
Maximum voltage swing which can still be counted as an inactive node. Used in
active/inactive node detection.

Block Default Value Valid Range

pintype 0.5 Float(0.001, 1.0)

node_stability_pruning_threshold
This threshold margin expressed as a percentage of supply is the voltage
range within which the nodes will be considered as an inactive node. Any node
whose final voltage value if does not fall within this voltage range will be
marged as switching even if the node had been stable (inactive) throughout the
period of the simulation. This is required to make sure that we do not prune
analog nodes.

Block Default Value Valid Range

pintype 0.2 Float(0.001, 1.0)

1010 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

noise_immunity_current
Current threshold to use when measuring noise immunity on three-state enable
or disable arcs. Expressed as a fraction of the min/max current.

Block Default Value Valid Range

pintype 0.1 Float(0.0, 1.0)

noise_immunity_from_prop
If true, use noise propagation to determinine immunity for sequential data
inputs. Otherwise use search.

Block Default Value Valid Range

pintype 0 Flag()

noise_immunity_tolerance
Specifies the tolerance to which noise immunity measurements are optimized.
This is the maximum voltage difference between the largest safe input glitch
height and the actual largest safe input glitch height.

Block Default Value Valid Range

pintype 0.05 Float(0.001, 10.0)

num_ccs_samples
Specifies the number of points generated in the CCS timing current vectors.
Decreasing the number of points reduces the size of the resulting model but at
the expense of a possible loss in accuracy.

Block Default Value Valid Range

pintype 12 Integer(8,50)

SiliconSmart ACE User Guide 1011

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

numsteps_frequency
This parameter specifies the number of frequency values to use between the
smallest frequency and largest frequency to calculate the intrinsic capacitance
value for the cell for CCS power measurements. The default value of this
parameter is 5 which means that 5 frequency values will be swept between the
smallest frequency and largest frequency to find out the intrinsic capacitance.

Block Default Value Valid Range

pintype 10 Integer(1, 50)

numsteps_height
Specifies the number of height points to use when characterizing the noise
propagation data for an input pin.

Block Default Value Valid Range

pintype 8 Integer(1,50)

numsteps_load
Specifies the number of load points for a pin at which measurements will be
acquired if explicit_points_load is not specified or is an empty list.
numsteps_load, smallest_load and largest_load are used to create a list of
loads for pins of this type.

Block Default Value Valid Range

pintype 5 Integer(1, 50)

numsteps_rload
Specifies the number of load points for a second output pin at which
measurements will be acquired if explicit_points_rload is not specified or is an

1012 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

empty list. numsteps_rload, smallest_rload and largest_rload are used to

create a list of loads for pins of this type.

Block Default Value Valid Range

pintype 5 Integer(1,50)

numsteps_slew
Specifies the number of slew points for a pin at which measurements will be
acquired if explicit_points_slew is not specified or is an empty list.
numsteps_slew, smallest_slew and largest_slew are used to create a list of
slew values for pins of this type.

Block Default Value Valid Range

pintype 5 Integer(1, 50)

numsteps_timeshift
Specifies the number of timeshift points to use between smallest_timeshift and
largest_timeshift when characterizing noise immunity on sequential data pins.
The default for this parameter is 1 because it is typically autoranged.

Block Default Value Valid Range

pintype 1 Integer(1,None)

numsteps_voltage
Specifies the number of steps simulated between smallest_voltage and
largest_voltage.

Block Default Value Valid Range

pintype 25 Integer(1,None)

SiliconSmart ACE User Guide 1013

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

numsteps_width
Specifies the number of steps taken between smallest_width and largest_width
.

Block Default Value Valid Range

pintype 5 Integer()

opt_load_high
Used for optimization to find out upper range(maximum capacitance) for active
driver characterization. The maximum capacitance used for active driver
characterization is the capacitance value which produces \"largest_slew\".
Value of this parameter should produce a slew greater than \"largest_slew\".

Block Default Value Valid Range

pintype 1e-12 Float(0.0, 1e-9)

opt_load_low
Used for active driver characterization. Lower range of the table when active
driver is characterized. This value should be low enough to produce the fastest
slew required during characterization.

Block Default Value Valid Range

pintype 0.0 Float(0.0, 1e-9)

1014 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

partial_swing
If set for a pin, thresholds will be with respect to the actual voltage swing
measured on the pin. This is used for pins where the voltage does not swing
from rail to rail.

Block Default Value Valid Range

pintype 0 Flag()

output_fall_threshold
Defines an absolute threshold value for the delay measurement trip point (Vth),
used for intrinsic delay and constraint acquisition, as an output signal fall
transition voltage swing.

Block Default Value Valid Range

pintype 0 Float()

output_rise_threshold
Defines an absolute threshold value for the delay measurement trip point (Vth),
used for intrinsic delay and constraint acquisition, as an output signal rise
transition voltage swing.

Block Default Value Valid Range

pintype 0 Float()

partial_swing_minimum
The minimum partial swing which will be accepted as a transition for this pin.

Block Default Value Valid Range

pintype 0.05 Float(0.0, (bool)0)

SiliconSmart ACE User Guide 1015

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

passive_glitch_check
If true, add checks for unexpected transitions on non-switching outputs of
energy measurements.

Block Default Value Valid Range

pintype 0 Flag()

peak_ratio
Specifies the peak_ratio for noise immunity measurements.

Block Default Value Valid Range

pintype 0.5 Float(0.0,1.0)

phased_inputs
Provides time shifting for a list of inputs expressed as a percentage of the clock
cycle time. This is typically used to support multi-phase clocking, but will phase
shift the waveform for any input.
The below example will define a four-phase clock with each clock signal offset
by 1/4 cycle:
set phased_inputs { clk0 0 clk1 0.25 clk2 0.5 clk3 0.75 }

Block Default Value Valid Range

pintype empty_list() Dict()

1016 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

pin_category
Force a pin to be considered as a clock, a data, a sync control. Used when not
enough information is available for this to be inferred from pin behavior.

Block Default Value Valid Range

pintype \"none\" Enumerated("none, data,

async_control, sync_control, clock,
retain")

pintype
The name of the pintype associated with this pin.

Block Default Value Valid Range

pintype \"\" String()

pocv_input_slew
Input slew to be used for POCV characterization.

Block Default Value Valid Range

pintype default_slew Float()

port
Port name associated with a pin. Redundant. Is it used?

Block Default Value Valid Range

pintype \"\" String()

SiliconSmart ACE User Guide 1017

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

power_period
Specifies the period for which the current is tracked on each supply specified in
the power_meas_supplies parameter. The specified time duration must be at
least twice the largest transition time on any CUT pin. This parameter defaults
to 4.4 times the largest value of the total_slew parameter in all defined pintype
blocks.

Block Default Value Valid Range

pintype 4.4*total_slew Float(1e-12,44.0e-3)

prop_delay_current
Defines the threshold (between 0 and 1.0) that is used for three-state disable
measurements. Specifically, it indicates the fraction of the maximum current
(during the output transition) at which a three-state disable is recognized.

Block Default Value Valid Range

pintype 0.1 Float(0.0, 1.0)

prop_delay_inp_level
See prop_delay_level parameter description.

Block Default Value Valid Range

pintype prop_delay_level Float(0.0, 1.0)

1018 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

prop_delay_inp_level_fall
Defines the threshold (between 0 and 1.0) that is used for three-state disable
measurements. Specifically, it indicates the fraction of the maximum current
(during the output transition) at which a three-state disable is recognized.

Block Default Value Valid Range

pintype prop_delay_inp_level Float(0.0, 1.0)

prop_delay_inp_level_rise
See prop_delay_level parameter description.

Block Default Value Valid Range

pintype prop_delay_inp_level Float(0.0, 1.0)

prop_delay_level
Defines a global value for the delay measurement trip point (Vth), used for
intrinsic delay and constraint acquisition, as a fraction of signal transition
voltage swing. For example, the default value of 0.5 indicates 50% of the
transition. This parameter is used in a pintype command.
The value of this parameter and those of its more specific override parameters
represents a fraction and must be in the range of logic_low_threshold to
logic_high_threshold. This value is used in the following general equation to
determine trigger and target values for circuit simulator measurement
statements: voltage = (logic_high_name - logic_low_name) * prop_delay_level
+ logic_low_name
The value of this parameter is assigned for all four trip conditions (input/output,
rise/fall) unless overridden using one or more of the prop_delay_*_level_*
parameters.
SiliconSmart requires some combination of the prop_delay_*_level_*
parameters that defines all four trip conditions. More specific

SiliconSmart ACE User Guide 1019

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

prop_delay_*_level_* parameters always override higher level

prop_delay_*_level_* parameters.

Block Default Value Valid Range

pintype 0.5 Float(0.0, 1.0)

prop_delay_out_level
See prop_delay_level parameter description.

Block Default Value Valid Range

pintype prop_delay_level Float(0.0, 1.0)

prop_delay_out_level_fall
See prop_delay_level parameter description.

Block Default Value Valid Range

pintype prop_delay_out_level Float(0.0, 1.0)

prop_delay_out_level_rise
See prop_delay_level parameter description.

Block Default Value Valid Range

pintype prop_delay_out_level Float(0.0, 1.0)

1020 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

rc_filter_capacitor
This parameter specifies the size of the capacitor used to filter injected glitches.
In conjunction with rc_filter_resistor, it forms a low-pass RC filter through which
injected glitches are passed.

Block Default Value Valid Range

pintype 1e-14 Float(0.0, 1e-9)

rc_filter_resistor
This parameter specifies the size of the resistor used to filter injected glitches.
In conjunction with rc_filter_capacitor, it forms a low-pass RC filter through
which injected glitches are passed.

Block Default Value Valid Range

pintype 100.0 Float(1e-6, 1e6)

scaled_points_frequency
Set frequencys at intervals between smallest_frequency and
largest_frequency.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

scaled_points_height
Set heights at intervals between smallest_height and largest_height.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

SiliconSmart ACE User Guide 1021

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

scaled_points_load
Set loads at intervals between smallest_load and largest_load (or autoranged).

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

scaled_points_rload
Set rloads at intervals between smallest_rload and largest_rload.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

scaled_points_slew
Set slews at intervals between smallest_slew and largest_slew.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

scaled_points_timeshift
Set timeshifts at intervals between smallest_timeshift and largest_timeshift.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

1022 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

scaled_points_voltage
Set voltages at intervals between smallest_voltage and largest_voltage.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

scaled_points_width
Set widths at intervals between smallest_width and largest_width.

Block Default Value Valid Range

pintype empty_list() List(new Float(0.0, 1.0))

si_driver

Block Default Value Valid Range

pintype \"rc_filter\" String()

side_pin_driver
When driver_mode is set to active-direct for the transitioning pins, the
side_pin_driver parameter can be used to specify the driver that should be
used for the side pins, as shown in the example below. The default value of this
parameter is "", which means no driver is connected to side pins and the side
pins are connected directly to ideal voltage sources.
Side pin drivers for different arcs can be defined as below:
Example 468
set_config_opt -cell NAND2_X1A_A9TR50 -type delay side_pin_driver
BUF_1
set_config_opt -cell NAND2_X1A_A9TR50 -type energy
side_pin_driver BUF_1

SiliconSmart ACE User Guide 1023

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

In the above example, the side pin driver BUF_2 is used for delay acquisitions
and the side pin driver BUF_1 is used for energy arcs.
To use this feature, it is important to import all drivers that are to be used for
transitioning, as well as side pins:
import_driver -netlist [pwd]/netlists/BUF_1.cir
-input_pin A -output_pin Y BUF_1
import_driver -netlist [pwd]/netlists/BUF_2.cir
-input_pin A -output_pin Y BUF_2

Block Default Value Valid Range

pintype \"\" String()

skip_constraint_outputs
If this parameter is set, for simulator bisection method, constraint checks will be
skipped for primary outputs and it will be performed only for internal nodes
specified through the monitor_internal_nodes parameter

Block Default Value Valid Range

param 0 0, 1

slew_based_margin
Defines the the value to be added and subtracted from the parameter
'prop_delay_level' to determine the trip points for delay measurement in case of
path based constraint.

Block Default Value Valid Range

pintype logic_high_threshold- Float(0.0, 0.49)

prop_delay_level

1024 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

smallest_frequency
This parameter specifies the value of the smallest frequency that will be used to
find out the intrinsic capacitance for the cell for CCS power measurements. The
default value of this parameter is 100MHz.

Block Default Value Valid Range

pintype 1e+07 Float()

smallest_height
Controls the lower bound on the glitch heights over which noise immunity and
noise propagation characterization is performed. This value should be smaller
than the switching threshold of the cell.

Block Default Value Valid Range

pintype subst(\"$logic_low_threshold OneOf(new Float(-50.0, 50.0),new

*($logic_high_param_name- String())
$logic_low_param_name)\")

smallest_load
Specifies the smallest load in a range of values generated by SiliconSmart
when explicit_points_load is not specified or is an empty list. See also
numsteps_load and largest_load.

Block Default Value Valid Range

pintype 10e-15 Float(0.0, 1e-9)

SiliconSmart ACE User Guide 1025

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

smallest_rload
Specifies the smallest load for the second output in a range of values
generated by SiliconSmart when explicit_points_rload is not specified or is an
empty list. See also numsteps_rload and largest_rload.

Block Default Value Valid Range

pintype 1e3 Float(0.0,None)

smallest_slew
Specifies the smallest slew in a range of values generated by SiliconSmart
when explicit_points_slew is not specified or is an empty list. See also
numsteps_slew and largest_slew.

Block Default Value Valid Range

pintype 10e-12 Float(1e-15, 1e-3)

smallest_timeshift
Specifies the earliest data glitch arrival time before before the clock edge. The
larger the value the earlier the glitch.

Block Default Value Valid Range

pintype 3.0*default_total_slew Float()

1026 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

smallest_voltage
Specifies the minimum voltage used when characterizing the steady state IV
curves for a cell. This value must be below the lowest supply rail (typically
ground) to properly characterizez the IV curves.

Block Default Value Valid Range

pintype subst(\"- OneOf(new String(), new Float())

($logic_high_param_name-
$logic_low_param_name)+$l
ogic_low_param_name\")

smallest_width
Specifies the width of the narrowest injected glitch used for characterizing
noise immunity and noise propagation behavior. This value must be greater
than 0.

Block Default Value Valid Range

pintype 10e-12 Float(1e-15, 1e-3)

smc_constraint_style
Constraint CK-Q degradation mode for a specific Q.

Block Default Value Valid Range

pintype pass-fail pass-fail, relative-degradation, slew-

degradation, pushout-degradation,
pulse-degradation, mpw-v2, delay-
reduction, relative-slew-degradation

SiliconSmart ACE User Guide 1027

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

smc_degrade
If smc_constraint_style is relative-degradation, slew-degradation, or relative-
slew-degradation, this parameter gives the relative increase in propagation
delay that indicates a constraint failure.

Block Default Value Valid Range

pintype 0.1 Float(0.0, 1.0)

smc_degrade_absolute
If smc_constraint_style is relative-degradation, slew-degradation, or relative-
slew-degradation, this parameter gives the absolute increase (in seconds) in
propagation delay that indicates a constraint failure.

Block Default Value Valid Range

pintype 10e-12 Float(0.0, 1.0e-8)

smc_degrade_check
If smc_constraint_style is relative-degradation, slew-degradation, pushout-
degradation, or relative-slew-degradation, this parameter specifies in which
direction the constraint failure check will be done.

Block Default Value Valid Range

pintype positive-side positive-side, negative-side, double-

side

1028 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

smc_degrade_maximum
Maximum increase (in seconds) of the clock-to-output delay before declaring
failure for constraint. Used for relative-degradation. Ignored unless non-zero.
Not public yet.

Block Default Value Valid Range

pintype 0.0 Float(0.0, 1.0e-8)

smc_degrade_pushout
if smc_constraint_style='pushout-degradation' and smc_degrade_pushout>0
then the constraint will be reduced past the minimum until the
constraint+output_delay increases/decreases by the specified amount (as
defined by smc_degrade_check.

Block Default Value Valid Range

pintype 0.0 Float(0.0, 1.0)

smc_max_degrade_absolute
If smc_constraint_style is relative-degradation or relative-slew-
degradation, this parameter gives the maximum absolute increase (in seconds)
in propagation delay that indicates a constraint failure. This parameter is
supported only for simulator bisection method.

Block Default Value Valid Range

pintype 1.0e-8 Float(0.0, 1.0e-8)

SiliconSmart ACE User Guide 1029

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

smc_slew_degrade
If smc_constraint_style is relative-slew-degradation or slew-degradation,
this parameter gives the relative increase in slew that indicates a constraint
failure.

Block Default Value Valid Range

pintype 0.1 Float(0.0, 1.0)

smc_slew_degrade_absolute
If smc_constraint_style is relative-slew-degradation, slew-degradation, or
relative-slew-degradation, this parameter gives the absolute increase (in
seconds) in slew that indicates a constraint failure.

Block Default Value Valid Range

pintype 0.0 Float(0.0, 1.0e-8)

soi_transition_mode
Indicates whether this is an SOI measurement and if so whether it is first switch
or second switch.

Block Default Value Valid Range

pintype \"off\" Enumerated("off, first, second")

stable_time
Controls the waveform sampling period after the last input transition for
measurements that require sampled output waveforms. This includes
differential pins, outputs with partial_swing enabled, and ECSM

1030 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

measurements. The default value is 5.0 times the largest value of total_slew
in each of the defined pin types.

Block Default Value Valid Range

pintype 5.0*total_slew Float(1e-12, 50e-3)

subtract_leakage
Controls whether leakage current though a pin is accounted for in pin
capacitance and Z-disable measurements. When set to 0, leakage current is
assumed to be negligible. When set to 1, any steady-state leakage current is
subtracted from the measurements.

Block Default Value Valid Range

pintype 0 Flag()

sweep_method_load
Specifies the sweep method for auto load indexing.

Block Default Value Valid Range

pintype \"polynomial\" EnumeratedNoCase("{\

'0' : 'polynomial', \
'1' : 'log', \
'2' : 'log2x', \
'3' : 'linear2x', \
'polynomial' : 'polynomial', \
'log' : 'log', \
'log2x' : 'log2x', \
'linear2x' : 'linear2x' }")

SiliconSmart ACE User Guide 1031

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

sweep_method_slew
Specifies the sweep method for auto slew indexing.

Block Default Value Valid Range

pintype \"polynomial\" EnumeratedNoCase("{\

'0' : 'polynomial', \
'1' : 'log', \
'2' : 'log2x', \
'3' : 'linear2x', \
'polynomial' : 'polynomial', \
'log' : 'log', \
'log2x' : 'log2x', \
'linear2x' : 'linear2x' }")

switchpoint_default_slew
Defines the duration of the voltage ramp used in switchpoint simulations.

Block Default Value Valid Range

pintype total_slew*50.0 Float()

target_bits
This optional attribute specifies a subset of the pins to be used in delay/power
measurements. This attribute recognizes the fact that for a wide bus of say 64
bits, it is not necessary to probe for measurements on all the bits; it is sufficient
to examine only a select few of those 64 bits to obtain accurate results.
Each target_bit is specified such that it is a non-negative integer between 0 and
(bus_width - 1). If target_bits is not explicitly specified, by default, all the bits will
in the range [ 0, (bus_width - 1) ] will be considered for characterization. This
parameter is used in conjunction with the bus_width parameter and therefore

1032 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
pintype Parameters

requires the SiliconSmart Memory Extensions package, a separately

purchased option.

Block Default Value Valid Range

pintype empty_list() List(new Integer())

tie_cell_load
Enable the max_capacitance determination through maximum load
autoranging. Use this parameter to calculate maximum capacitance across all
of the operating conditions and then choose the lowest value and use it for all
operating conditions.

Block Default Value Valid Range

pintype \"off\" EnumeratedNoCase("{ '0' : 'off', 'off' :

'off', 'false' : 'off', 'no' : 'off', '1' : 'pin', 'on'
: 'pin', 'true' : 'pin', 'yes' : 'pin', 'pin' : 'pin',
'state' : 'state', 'High' : 'high', 'Low' : 'low'
}")

total_slew_multiplier
Provides a scaling factor for the total_slew parameter. The default of 1.0
assumes reasonably linear transitions rail to rail. For cells that demonstrate
highly nonlinear tails on the transitions, this parameter can be increased to
compensate.

Block Default Value Valid Range

pintype 1.0 Float(0.0, None)

trailing_delay
Specifies an additional period after the last driving transition. This should be set
to a value long enough to ensure that the last output transition successfully

SiliconSmart ACE User Guide 1033

L-2016.03
Chapter 15: SiliconSmart Parameters
pintype Parameters

completes after the driving transition. The default value is 8.8 times the largest
value of total_slew in each of the defined pin types.

Block Default Value Valid Range

pintype 8.8*total_slew Float(1e-12,880e-3)

use_floating_hiz_output
If pin is an output in hi-Z state, let it float instead of assigning dontcare_bias.

Block Default Value Valid Range

pintype 0 Flag()

verilog_attach_edges
Used to specify if the Verilog model should attach posedge/negedge to arcs
originating from a pin. The addition of edges is relevant mainly for sequential
delay arcs from preset/clear pins.

Block Default Value Valid Range

pintype 0 Flag()

voltage_resolution
Minimum voltage tolerance over a analog voltage range.

Block Default Value Valid Range

pintype 0.05 Float(0.0, None)

1034 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

voltage_resolution_threshold
Minimum voltage tolerance over a analog voltage range.

Block Default Value Valid Range

pintype 0.05 Float(0.0, None)

validation Parameters
The following parameter are available in validation block:
■ absolute_tolerance
■
capacitance_absolute_tolerance
■
capacitance_product_tolerance
■ capacitance_relative_tolerance
■
ccs_absolute_tolerance
■
ccs_noise_absolute_tolerance
■ ccs_noise_product_tolerance
■
ccs_noise_relative_tolerance
■
ccs_product_tolerance
■ ccs_relative_tolerance
■
ccsn_current_absolute_tolerance
■
ccsn_current_product_tolerance
■ ccsn_current_relative_tolerance
■
ccsn_height_absolute_tolerance
■
ccsn_height_product_tolerance
■ ccsn_height_relative_tolerance
■
ccsn_output_voltage_absolute_tolerance
■ ccsn_output_voltage_product_tolerance
■
ccsn_output_voltage_relative_tolerance

SiliconSmart ACE User Guide 1035

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

■
ccsn_width_absolute_tolerance
■
ccsn_width_product_tolerance
■
ccsn_width_relative_tolerance
■
compare_library_interpolation
■
compare_library_top_failures
■
data_range_max
■
data_range_min
■
delay_absolute_tolerance
■
delay_product_tolerance
■
delay_relative_tolerance
■
delay_sensitivity_absolute_tolerance
■
delay_sensitivity_product_tolerance
■
delay_sensitivity_relative_tolerance
■
delay_variance_absolute_tolerance
■
delay_variance_product_tolerance
■
delay_variance_relative_tolerance
■
ecsm_absolute_tolerance
■
ecsm_product_tolerance
■
ecsm_relative_tolerance
■
enable_total_power_comparison
■
energy_absolute_tolerance
■
energy_product_tolerance
■ energy_relative_tolerance
■
gends_config_file
■
generate_sdf_cmd_file
■
hdl_target_simulator
■
hdl_target_simulator_path
■
hold_absolute_tolerance
■
hold_product_tolerance

1036 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

■
hold_relative_tolerance
■
hyperbolic_noise_absolute_tolerance
■
hyperbolic_noise_product_tolerance
■
hyperbolic_noise_relative_tolerance
■
index_relative_tolerance
■
input_capacitance_absolute_tolerance
■
input_capacitance_product_tolerance
■
input_capacitance_relative_tolerance
■
leakage_absolute_tolerance
■
leakage_product_tolerance
■
leakage_relative_tolerance
■
mpw_absolute_tolerance
■
mpw_product_tolerance
■
mpw_relative_tolerance
■
nochange_absolute_tolerance
■
nochange_product_tolerance
■
nochange_relative_tolerance
■
noise_immunity_absolute_tolerance
■
noise_immunity_product_tolerance
■
noise_immunity_relative_tolerance
■
noise_iv_absolute_tolerance
■
noise_iv_product_tolerance
■ noise_iv_relative_tolerance
■
noise_prop_absolute_tolerance
■
noise_prop_product_tolerance
■
noise_prop_relative_tolerance
■
product_tolerance
■
qualification_10nm_mode
■
qualification_data_range

SiliconSmart ACE User Guide 1037

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

■
qualification_correlation_lc_shell
■
qualification_lc_compensation
■
qualification_lc_shell
■
qualification_lc_suppress
■
recovery_absolute_tolerance
■
recovery_product_tolerance
■
recovery_relative_tolerance
■
relative_tolerance
■
removal_absolute_tolerance
■
removal_product_tolerance
■
removal_relative_tolerance
■
retain_slew_absolute_tolerance
■
retain_slew_product_tolerance
■
retain_slew_relative_tolerance
■
retaining_absolute_tolerance
■
retaining_product_tolerance
■
retaining_relative_tolerance
■
sdf_source_tool
■
sdf_source_tool_cmd
■
setup_absolute_tolerance
■
setup_product_tolerance
■
setup_relative_tolerance
■ slew_absolute_tolerance
■
slew_product_tolerance
■
slew_relative_tolerance
■
slew_sensitivity_absolute_tolerance
■
slew_sensitivity_product_tolerance
■
slew_sensitivity_relative_tolerance
■
slew_variance_absolute_tolerance

1038 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

■
slew_variance_product_tolerance
■
slew_variance_relative_tolerance
■
zdis_absolute_tolerance
■
zdis_product_tolerance
■
zdis_relative_tolerance
■
zen_absolute_tolerance
■
zen_product_tolerance
■
zen_relative_tolerance

absolute_tolerance
Disabled by default, tolerances are set per data type. See default validation
parameter block in configure.tcl file for type-specific defaults.

Block Default Value Valid Range

validation 0.001 Float()

capacitance_absolute_tolerance
Absolute tolerance for capacitance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

capacitance_product_tolerance
Product tolerance for capacitance, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

SiliconSmart ACE User Guide 1039

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

capacitance_relative_tolerance
Relative tolerance for capacitance. Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.01 Float()

ccs_absolute_tolerance
Absolute tolerance for ccs. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

ccs_noise_absolute_tolerance
Absolute tolerance for ccs_noise. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be

1040 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation 0.04 Float()

ccs_noise_product_tolerance
Product tolerance for delay, where product is the relative_tolerance multiplied
by the absolute_tolerance. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

ccs_noise_relative_tolerance
Relative tolerance for ccs_noise. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.015 Float()

ccs_product_tolerance
Product tolerance for ccs, where product is the relative_tolerance multiplied by
the absolute_tolerance. Reports failures in the report if error is larger than the

SiliconSmart ACE User Guide 1041

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

ccs_relative_tolerance
Relative tolerance for ccs. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

ccsn_current_absolute_tolerance
Absolute tolerance for dc_current table comparison. Reports failures in the
report if error is larger than the specified tolerance. Note that all specified
tolerances have to be exceeded for an error to be reported. A value of zero
disables the check for this tolerance.

Block Default Value Valid Range

validation 0.01 Float()

ccsn_current_product_tolerance
Product tolerance for dc_current table comparison. Here product is the
relative_tolerance multiplied by the absolute_tolerance. Reports failures in the
report if error is larger than the specified tolerance. Note that all specified

1042 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

tolerances have to be exceeded for an error to be reported. A value of zero

disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

ccsn_current_relative_tolerance
Relative tolerance for dc_current table comparison. Valid value range is
between 0 and 1. Reports failures in the report if error is larger than the
specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

ccsn_height_absolute_tolerance
Absolute tolerance for ccs noise hieght comparison in propogated_noise_high/
low groups. Reports failures in the report if error is larger than the specified
tolerance. Note that all specified tolerances have to be exceeded for an error to
be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

ccsn_height_product_tolerance
Product tolerance for ccs noise hieght comparison in propogated_noise_high/
low groups. Here product is the relative_tolerance multiplied by the
absolute_tolerance. Reports failures in the report if error is larger than the

SiliconSmart ACE User Guide 1043

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

ccsn_height_relative_tolerance
Relative tolerance for ccs noise hieght comparison in propogated_noise_high/
low groups. Valid value range is between 0 and 1. Reports failures in the report
if error is larger than the specified tolerance. Note that all specified tolerances
have to be exceeded for an error to be reported. A value of zero disables the
check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

ccsn_output_voltage_absolute_tolerance
Absolute tolerance for comparing time values in output_voltage vectors.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

ccsn_output_voltage_product_tolerance
Product tolerance for comparing time values in output_voltage vectors. Here
product is the relative_tolerance multiplied by the absolute_tolerance. Reports
failures in the report if error is larger than the specified tolerance. Note that all

1044 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

specified tolerances have to be exceeded for an error to be reported. A value of

zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

ccsn_output_voltage_relative_tolerance
Relative tolerance for comparing time values in output_voltage vectors. Valid
value range is between 0 and 1. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

ccsn_width_absolute_tolerance
Absolute tolerance for ccs noise width comparison in propogated_noise_high/
low groups for ccs_noise. Reports failures in the report if error is larger than the
specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

ccsn_width_product_tolerance
Product tolerance for ccs noise width comparison in propogated_noise_high/
low groups. Here product is the relative_tolerance multiplied by the
absolute_tolerance. Reports failures in the report if error is larger than the

SiliconSmart ACE User Guide 1045

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

ccsn_width_relative_tolerance
Relative tolerance for ccs noise width comparison in propogated_noise_high/
low groups. Valid value range is between 0 and 1. Reports failures in the report
if error is larger than the specified tolerance. Note that all specified tolerances
have to be exceeded for an error to be reported. A value of zero disables the
check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

compare_library_interpolation
Specifies the interpolation mode to be used when comparing 1-D and 2-D table
values between 2 libraries. The different modes are:
■
0: No interpolation. Table indices must be absolutely matched within
numerical precision for values to be compared.
■
1: Linear interpolation for tables with like dimensions and same number of
indices per dimension.
■ 2: Linear interpolation for tables where possible. Tables must be of like
dimensions, but may have different number of indices per dimension.
■
3: Same as 2, but no extrapolation is performed. If the test library index value
lies outside the range of the reference value, it is skipped.
For 3-D tables, the index values must match for comparison of the table values.

Block Default Value Valid Range

validation 2 0, 1, 2, 3

1046 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

compare_library_top_failures
Specifies the top number of failures to summarize in the top_failures.log output
from compare_library.

Block Default Value Valid Range

validation 0 Integer

data_range_max
data_range_max.

Block Default Value Valid Range

validation 0 Float()

data_range_min
data_range_min.

Block Default Value Valid Range

validation 0 Float()

delay_absolute_tolerance
Absolute tolerance for delay. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.005 Float()

SiliconSmart ACE User Guide 1047

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

delay_product_tolerance
Product tolerance for delay, where product is the relative_tolerance multiplied
by the absolute_tolerance. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

delay_relative_tolerance
Relative tolerance for delay. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.02 Float()

delay_sensitivity_absolute_tolerance
Absolute tolerance for delay sensitivity. A value of zero disables the check for
this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

1048 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

delay_sensitivity_product_tolerance
Product tolerance for delay sensitivity. A value of zero disables the check for
this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

delay_sensitivity_relative_tolerance
Relative tolerance for delay sensitivity. Valid value range is between 0 and 1. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

delay_variance_absolute_tolerance
Absolute tolerance for delay variance. A value of zero disables the check for
this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

delay_variance_product_tolerance
Product tolerance for delay variance. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

SiliconSmart ACE User Guide 1049

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

delay_variance_relative_tolerance
Relative tolerance for delay variance. Valid value range is between 0 and 1. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

ecsm_absolute_tolerance
Absolute tolerance for ecsm. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

ecsm_product_tolerance
Product tolerance for ecsm, where product is the relative_tolerance multiplied
by the absolute_tolerance. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

ecsm_relative_tolerance
Relative tolerance for ecsm. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all

1050 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

specified tolerances have to be exceeded for an error to be reported. A value of

zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

enable_total_power_comparison
To enable total power checks while performing comparison between a pair of
internal_power groups. When this parameter is set to true, the CV*2 term will
be added to each entry in the internal_power tables.

Block Default Value Valid Range

validation 0 Flag()

energy_absolute_tolerance
Absolute tolerance for energy. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation 5 Float()

energy_product_tolerance
Product tolerance for energy, where product is the relative_tolerance multiplied
by the absolute_tolerance. Reports failures in the report if error is larger than

SiliconSmart ACE User Guide 1051

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

energy_relative_tolerance
Relative tolerance for energy. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

gends_config_file
This specifies the path to the gends_config_file file. It defaults to charpt/reports/
gends_config.tcl.

Block Default Value Valid Range

validation \"[get_location]/reports/ String()

gends_config.tcl\"

generate_sdf_cmd_file
This specifies the path to the file which generates the SDF. It contains the file
tags for substitution. It defaults to [get_install_path]/etc/validation/validate_hdl/

1052 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

generate_sdf.tcl, where get_install_path is a SiliconSmart command that

returns path to the SiliconSmart installation location.

Block Default Value Valid Range

validation \"[get_install_path]/etc/ String()

validation/validate_hdl/
generate_sdf.tcl\"

hdl_target_simulator
Specifies the target simulator for HDL simulation when performing back-
annotation. Supported simulators include verilog-XL, NC-Verilog, VCS, and
Modelsim. Defaults to 'verilogXL'.

Block Default Value Valid Range

validation \"VCS\" Enumerated("verilogXL, NC, VCS,

Modelsim") String()

hdl_target_simulator_path
Path to the Verilog simulator executable. Defaults to 'vcs' to match VCS' default
for hdl_target_simulator.

Block Default Value Valid Range

validation \"vcs\" String()

hold_absolute_tolerance
Absolute tolerance for hold. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.015 Float()

SiliconSmart ACE User Guide 1053

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

hold_product_tolerance
Product tolerance for hold, where product is the relative_tolerance multiplied by
the absolute_tolerance. Reports failures in the report if error is larger than the
specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

hold_relative_tolerance
Relative tolerance for hold. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

hyperbolic_noise_absolute_tolerance
Absolute tolerance for hyperbolic_noise attributes(area_coeffcient,
height_coefficient, width_coefficient). Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

1054 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

hyperbolic_noise_product_tolerance
Product tolerance for hyperbolic_noise attributes(area_coeffcient,
height_coefficient, width_coefficient) , where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

hyperbolic_noise_relative_tolerance
Relative tolerance for hyperbolic_noise attributes(area_coeffcient,
height_coefficient, width_coefficient). Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

index_relative_tolerance
Tolerance used in comparing index values with compare_library. This is to
avoid very close indices being compared and included in the report. Valid value
range is between 0 and 1. Default is 1%.

Block Default Value Valid Range

validation 0.01 Float(0, 1)

SiliconSmart ACE User Guide 1055

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

input_capacitance_absolute_tolerance
Alias of capacitance_absolute_tolerance.

Block Default Value Valid Range

validation capacitance_absolute_tolera Float()

nce

input_capacitance_product_tolerance
Alias of capacitance_product_tolerance.

Block Default Value Valid Range

validation capacitance_product_toleran Float()

ce

input_capacitance_relative_tolerance
Alias of capacitance_relative_tolerance.

Block Default Value Valid Range

validation capacitance_relative_toleran Float()

ce

leakage_absolute_tolerance
Absolute tolerance for leakage. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation 5 Float()

1056 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

leakage_product_tolerance
Product tolerance for leakage, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

leakage_relative_tolerance
Relative tolerance for leakage. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

mpw_absolute_tolerance
Absolute tolerance for mpw. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.015 Float()

mpw_product_tolerance
Product tolerance for mpw, where product is the relative_tolerance multiplied by
the absolute_tolerance. Reports failures in the report if error is larger than the

SiliconSmart ACE User Guide 1057

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

mpw_relative_tolerance
Relative tolerance for mpw. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

nochange_absolute_tolerance
Absolute tolerance for nochange. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation 0.015 Float()

nochange_product_tolerance
Product tolerance for nochange, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

1058 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

nochange_relative_tolerance
Relative tolerance for nochange. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

noise_immunity_absolute_tolerance
Absolute tolerance for noise_immunity. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

noise_immunity_product_tolerance
Product tolerance for noise_immunity, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

SiliconSmart ACE User Guide 1059

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

noise_immunity_relative_tolerance
Relative tolerance for noise_immunity. Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

noise_iv_absolute_tolerance
Absolute tolerance for noise_iv. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

noise_iv_product_tolerance
Product tolerance for noise_iv, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

1060 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

noise_iv_relative_tolerance
Relative tolerance for noise_iv. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

noise_prop_absolute_tolerance
Absolute tolerance for noise_prop. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

noise_prop_product_tolerance
Product tolerance for noise_prop, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

SiliconSmart ACE User Guide 1061

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

noise_prop_relative_tolerance
Relative tolerance for noise_prop. Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

product_tolerance
Disabled by default, tolerances are set per data type. See default validation
parameter block in configure.tcl file for type-specific defaults.

Block Default Value Valid Range

validation 0 Float()

qualification_10nm_mode
Enables advanced node (10nm) checks in Library Compiler. This turns on
advanced screening checks when compiling the library. Please check version
compatibility before turning on this feature.

Block Default Value Valid Range

validation 0 1

1062 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

qualification_data_range
Specifies ranges for the data range checks of delay. The value is a simple list of
each data table type name and minimum and maximum values. Table types
supported are delay, transition, constraint, energy, current, capacitance,
dc_current, ccsn, and pg_current.

Block Default Value Valid Range

validation empty_list() List(new String())

qualification_correlation_lc_shell
Specifies full path of Library Compiler executable for correlation tasks only.
Applies only to 2014.09 or earlier releases of the common shell.

Block Default Value Valid Range

validation none String()

qualification_lc_compensation
Turns on compensation in LC shell when performing consistency checks.
Please refer to LC documentation for more information on the compensation
feature.

Block Default Value Valid Range

validation 1 0, 1

qualification_lc_shell
Specify full path of Library Compiler exectuable for qualification tasks.

Block Default Value Valid Range

validation \"\" String()

SiliconSmart ACE User Guide 1063

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

qualification_lc_suppress
Specifies a list of valid Library Compiler warnings to be suppressed during
compilation.

Block Default Value Valid Range

validation empty_list() List(new String())

recovery_absolute_tolerance
Absolute tolerance for recovery. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation 0.015 Float()

recovery_product_tolerance
Product tolerance for recovery, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

recovery_relative_tolerance
Relative tolerance for recovery. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all

1064 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

specified tolerances have to be exceeded for an error to be reported. A value of

zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

relative_tolerance
Disabled by default, tolerances are set per data type. See default validation
parameter block in configure.tcl file for type-specific defaults.

Block Default Value Valid Range

validation 0.05 Float()

removal_absolute_tolerance
Absolute tolerance for removal. Reports failures in the report if error is larger
than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation 0.015 Float()

removal_product_tolerance
Product tolerance for removal, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

SiliconSmart ACE User Guide 1065

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

removal_relative_tolerance
Relative tolerance for removal. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

retain_slew_absolute_tolerance
Absolute tolerance for retain slew arcs. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

retain_slew_product_tolerance
Product tolerance for retain slew, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

1066 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

retain_slew_relative_tolerance
Relative tolerance for retain slew arcs. Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

retaining_absolute_tolerance
Absolute tolerance for rtaining arcs. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be
exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

retaining_product_tolerance
Product tolerance for retaining arcs, where product is the relative_tolerance
multiplied by the absolute_tolerance. Reports failures in the report if error is
larger than the specified tolerance. Note that all specified tolerances have to be

SiliconSmart ACE User Guide 1067

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

exceeded for an error to be reported. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

retaining_relative_tolerance
Relative tolerance for retaining arcs. Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

sdf_source_tool
Path to the STA tool executable.

Block Default Value Valid Range

validation none String()

sdf_source_tool_cmd
This parameter specifies the command that is executed to generate an SDF file
from a source STA tool.

Block Default Value Valid Range

validation \" pt_shell [get_parameter String()

validation
generate_sdf_cmd_file]\"

1068 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

setup_absolute_tolerance
Absolute tolerance for setup. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.015 Float()

setup_product_tolerance
Product tolerance for setup, where product is the relative_tolerance multiplied
by the absolute_tolerance. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

setup_relative_tolerance
Relative tolerance for setup. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.04 Float()

SiliconSmart ACE User Guide 1069

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

slew_absolute_tolerance
Absolute tolerance for slew. Reports failures in the report if error is larger than
the specified tolerance. Note that all specified tolerances have to be exceeded
for an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.0075 Float()

slew_product_tolerance
Product tolerance for slew, where product is the relative_tolerance multiplied by
the absolute_tolerance. Reports failures in the report if error is larger than the
specified tolerance. Note that all specified tolerances have to be exceeded for
an error to be reported. A value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

slew_relative_tolerance
Relative tolerance for slew. Valid value range is between 0 and 1. Reports
failures in the report if error is larger than the specified tolerance. Note that all
specified tolerances have to be exceeded for an error to be reported. A value of
zero disables the check for this tolerance.

Block Default Value Valid Range

validation 0.03 Float()

1070 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

slew_sensitivity_absolute_tolerance
Absolute tolerance for slew sensitivity. A value of zero disables the check for
this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

slew_sensitivity_product_tolerance
Product tolerance for slew sensitivity. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

slew_sensitivity_relative_tolerance
Relative tolerance for slew sensitivity. Valid value range is between 0 and 1. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

slew_variance_absolute_tolerance
Absolute tolerance for slew variance. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

SiliconSmart ACE User Guide 1071

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

slew_variance_product_tolerance
Product tolerance for slew variance. A value of zero disables the check for this
tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

slew_variance_relative_tolerance
Relative tolerance for slew variance. Valid value range is between 0 and 1. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

zdis_absolute_tolerance
Absolute tolerance for three-state disable. Reports failures in the report if error
is larger than the specified tolerance. Note that all specified tolerances have to
be exceeded for an error to be reported. A value of zero disables the check for
this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

zdis_product_tolerance
Product tolerance for three-state disable, where product is the
relative_tolerance multiplied by the absolute_tolerance. Reports failures in the
report if error is larger than the specified tolerance. Note that all specified

1072 SiliconSmart ACE User Guide

L-2016.03
 Chapter 15: SiliconSmart Parameters
validation Parameters

tolerances have to be exceeded for an error to be reported. A value of zero

disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

zdis_relative_tolerance
Relative tolerance for three-state disable. Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

zen_absolute_tolerance
Absolute tolerance for three-state enable. Reports failures in the report if error
is larger than the specified tolerance. Note that all specified tolerances have to
be exceeded for an error to be reported. A value of zero disables the check for
this tolerance.

Block Default Value Valid Range

validation absolute_tolerance Float()

zen_product_tolerance
Product tolerance for three-state enable, where product is the
relative_tolerance multiplied by the absolute_tolerance. Reports failures in the
report if error is larger than the specified tolerance. Note that all specified

SiliconSmart ACE User Guide 1073

L-2016.03
Chapter 15: SiliconSmart Parameters
validation Parameters

tolerances have to be exceeded for an error to be reported. A value of zero

disables the check for this tolerance.

Block Default Value Valid Range

validation product_tolerance Float()

zen_relative_tolerance
Relative tolerance for three-state enable. Valid value range is between 0 and 1.
Reports failures in the report if error is larger than the specified tolerance. Note
that all specified tolerances have to be exceeded for an error to be reported. A
value of zero disables the check for this tolerance.

Block Default Value Valid Range

validation relative_tolerance Float()

1074 SiliconSmart ACE User Guide

L-2016.03
 A
Silicon-On-Insulator
A

Support and Methodology

This appendix describes support for Silicon-On-Insulator (SOI) technology.

For cells manufactured using SOI technology, characteristics may vary

depending not only on the state of secondary inputs, but also on the stimulus
applied before the transition being tested: the rising delay through an inverter,
for example, may be different depending on the existence of input transitions
immediately preceding the one being tested.
SiliconSmart supports the characterization of SOI cells by allowing you to
specify whether an input requires the transition being tested to be the first
transition or the second transition in the test.
The following sections describe SOI support:
■
Selecting the SOI Mode
■ Characterizing and Modeling for SOI

Selecting the SOI Mode

The SOI mode for each pin is specified by setting pin type parameter
soi_transition_mode. The soi_transition_mode parameter can be
set to off, first, or second. first causes the pin to never have any
transitions before the test transition. second causes the pin to have exactly
one (opposite) transition right before the test transition. off (the default value)
places no restrictions on the number of transitions for the pin.
Separate initialization (controlled via the separate_cell_initialization
parameter) must be set to ic (the default value) or nodeset in order to use the
SOI transition modes. Separate initialization is used to ensure that the

SiliconSmart ACE User Guide 1075

L-2016.03
Appendix A: Silicon-On-Insulator Support and Methodology
Characterizing and Modeling for SOI

transitions before the test are kept to the selected number, regardless of any
necessary state initialization stimulus. An error will be output if separate
initialization is disabled and SOI is selected for any input in a measurement.

Characterizing and Modeling for SOI

To characterize and model SOI cells, the SOI modes must be adjusted, then
cells must be configured, characterized and modeled for each combination of
SOI modes desired. The resulting libraries are then merged according to the
user-defined criteria. As an example, a latch with inputs D and CLK might be
characterized as follows:
1. Parameter soi_transition_mode is set as first for both D and CLK.
2. The cell is characterized and modeled, generating file d_first_clk_first.lib.
Library names are arbitrarily chosen.
3. soi_transition_mode is now set as first for D and second for CLK.
4. Once again, the cell is characterized and modeled, generating file
d_first_clk_second.lib.
5. For each SOI switch combination, there will be a separate characterization
point. Because of this, you might have three characterization points:
• cp_first_switch
• co_second_switch
• cp_third_switch
6. Specifying the switching is controlled with the parameters described above.
In the following example, the first line sets all pin measurements to be
observed on the second switch, and the second line specifies that the clock/
enable-related measurements are to be done on the first switch.

Example 469
set_config_opt -pin * soi_transition_mode second
set_config_opt -pin {CK EN} soi_transition_mode first

7. After all characterization points have been characterized, a model API

merging procedure is used to create a single model from the three
characterization points. The model API file is named libMergeSource.tcl and
can be located at soi_install_path/etc/SOI. The top of this file contains the
latest version number of the merge script

1076 SiliconSmart ACE User Guide

L-2016.03
 Appendix A: Silicon-On-Insulator Support and Methodology
Characterizing and Modeling for SOI

The merge script examines the contents of each output model and merges
the values into a final model based on the user function requested (usually
a Min or Max function). An example might be:

Example 470
mergeLibraries cells output_model list first_charpt/first.lib
second_charpt/second.lib Max

where:
• cells — the list of cells.
• output_model — name of the output model. It will have the merging
function added to the output name. In the above example, the merging
function is Max. The name of the merged model would then be:
output_model_Max.lib
• list — list of paths to libraries to merge (i.e., first, second, third switch
libraries).

• Max — the merging function to use.

SiliconSmart ACE User Guide 1077

L-2016.03
Appendix A: Silicon-On-Insulator Support and Methodology
Characterizing and Modeling for SOI

1078 SiliconSmart ACE User Guide

L-2016.03
 B
B

Tcl and SiliconSmart

This appendix describes basic Tcl usage to help in understanding the examples
presented throughout this document.

SiliconSmart is driven using commands that are available through Tcl. Tcl
provides a common set of control flow and data handling mechanisms that you
can extend on an application-specific basis to provide a common look and feel
across a wide variety of domains.
For a more detailed description of Tcl and Tk Toolkit, refer to the book "Practical
Programming in Tcl and Tk" by Brent Welch.
The following sections describe Tcl usage:
■
Introduction
■
Using Variables
■ Looping and Conditional Execution
■
Tcl Scripts

Introduction
Variables in Tcl are prefixed by the $ character. Variables can have
subcommands associated with them. A variable can be thought of as a
programmatic object while each associated subcommand can be considered a
method of the object. The terms "object" and "variable" are used
interchangeably in this chapter; likewise for the terms subcommand and
method.

SiliconSmart ACE User Guide 1079

L-2016.03
Appendix B: Tcl and SiliconSmart
Using Variables

Using Variables
All variables are defined/assigned using the set command, which requires the
name of the variable followed by the variable’s new value. Invoking the set
command without a value returns the current setting of the variable. The #
character on a line by itself precedes a comment while the characters ;# are
used for a comment on the same line with a statement.
The following statements illustrate the use of set:
Example 471
set x 23 ; # set the variable x to 23
set y $x ; # set the variable y to the current value of x
set y; # return the current value of y

Lists in Tcl are delimited by curly braces { and }. The curly braces also
suppress evaluations. Individual elements in a list can be accessed using the
lindex command. Examples of creating and manipulating lists follow:
Example 472
set mylist {1 2 3 4}; #set mylist to a sequence of numbers
set elt1 [ lindex $mylist 0]; #set elt1 to 0-th element of mylist = 1
set another_list {$elt1 3}; #suppresses evaluation of elt1
set correct_list [list $elt1 3]; #‘list’ creates the desired list
{1 3}

Evaluations in Tcl are forced using the square braces [ and ]. Several examples
of evaluations were shown in the previous examples.

1080 SiliconSmart ACE User Guide

L-2016.03
 Appendix B: Tcl and SiliconSmart
Looping and Conditional Execution

Looping and Conditional Execution

The foreach looping command allows a series of commands to be applied to
each element of a list while the if, else, and elseif commands allow for
conditional execution. These are illustrated in the following example:
Example 473
foreach element $mylist {
if {$element == 3} {
puts “I am a 3!”
} elseif {$element == 1} {
puts “I am a 1!”
} else {
puts “I have no idea!”
}
}

Tcl Scripts
SiliconSmart can be invoked in batch mode by providing the name of a Tcl
script as the an argument on the command-line. When done, SiliconSmart will
read the Tcl file and execute each of the commands. This can be used to
automate the process of configuring, characterizing, and modeling a whole
library of cells or a subset thereof. The script at the end of this section is an
example of how to automate this process.
This example makes several assumptions. First, a characterization directory
named smcdata has been created under the current directory and it has been
setup for your cell library. Additionally, one or more cells have been imported
into this characterization directory and the instance control file for each cell has
been configured.
The set of cells to be processed is stored in the variable cell_list. This example
uses the get_cells command to get all available cells, though a subset of
cells could also be specified. This example configures all of the cells and then
characterizes them. Because all of the cells are provided to a single call to the
characterize command they will be processed in parallel.
Once the characterization has completed successfully, each cell is modeled as
a separate Liberty model, one file per operating condition per cell. If all of the
cells model correctly then a full Liberty model containing all of the cells is
generated.

SiliconSmart ACE User Guide 1081

L-2016.03
Appendix B: Tcl and SiliconSmart
Tcl Scripts

Consider the following script:

Example 474
#
# This script runs SiliconSmart through the full flow from
# configuration, to characterization, and finally modeling.
#
# This script assumes there is a characterization directory named
# 'smcdata' in the current directory.

set_location ./smcdata

# The set of cells we want to process. get_cells with no arguments

returns
# all cells. Wildcard expressions can be used to select a subset
# of cells.

set cell_list [get_cells]

# Run the configure and characterize commands. These generate the

# characterization plan and then submit the simulation jobs.

if { [catch {
configure $cell_list
characterize $cell_list
} err] } {
error "Configuration and characterization failed: $err"
}

# Now run modeling and generate a separate .lib file for each cell at
# each operating condition. This code assumes we have the following
# operating conditions: SLOW_125 and FAST_0 corresponding to the
#worst-case and best-case conditions.
#
# The Liberty file names will be <cell>_<op cond>.lib

set cell_failed 0

foreach cell $cell_list {

if { [catch {
model -out $cell -liberty -operating_condition SLOW_125 \
-library_type worst $cell
model -liberty -operating_condition FAST_0 -library_type
best \
-out $cell
} err] } {
log_error "Failed while modeling cell $cell: $err"
set cell_failed 1
}

1082 SiliconSmart ACE User Guide

L-2016.03
 Appendix B: Tcl and SiliconSmart
Tcl Scripts

# If all of the cells modeled correctly, write a library with all of

# the cells in it.
#
# The Liberty file names will be full_<op cond>.lib

if { !$cell_failed } {
model -out full -liberty -operating_condition SLOW_125 \
-library_type worst $cell_list
model -liberty -operating_condition FAST_0 -library_type best \
-out full
}

SiliconSmart ACE User Guide 1083

L-2016.03
Appendix B: Tcl and SiliconSmart
Tcl Scripts

1084 SiliconSmart ACE User Guide

L-2016.03
 C
C

Model Publishing API

This appendix describes the SiliconSmart Model Publishing API and provides a
reference for commands and data format.

This API is an optional package that provides additional commands for reading
and modifying Synopsys Liberty libraries. The commands provide complete,
programmatic access to all of the data in the library and an ability to add to or
modify the data before writing out a new Liberty model.
You must have the appropriate license token to use the Model Publishing API.
Contact Synopsys support for more information.
The SiliconSmart Model Publishing API includes a low-level modeling module
that uses advanced data structures designed for today’s larger models that
include current source waveforms, transient current waveforms, and CCS-noise
information.

Note: To make previous scripts backwards-compatible, be sure to

remove any code that adds commas between the values when
setting a values or index_* attribute as this is no longer
necessary. Otherwise, this will result in double commas between
numbers and will not be syntactically correct. While these
changes do require a change to existing scripts, the changes are
usually simply a matter of deleting code and thus simplifying the
code overall.

The following sections describe the Model Publishing API:

■
Using the API
■
API Command Reference

SiliconSmart ACE User Guide 1085

L-2016.03
Appendix C: Model Publishing API
Using the API

Using the API

To start using the Model Publishing API, issue the enable_api command as
follows:
Example 475
enable_api pub

This command loads all of the publishing commands in the Tcl pub::
namespace. As a shortcut, You can import the commands into the default
namespace with the namespace import command as shown in the following
example:
Example 476
namespace import pub::*

Then, you can access the commands without the pub:: prefix.
You can read in a Liberty model using the pub::read_model command as
follows:
Example 477
pub::read_model -liberty filename

This command loads the Liberty file into an internal database that the
publishing command can access and returns a handle to the root of the library.
A Liberty model is represented as a tree of objects, with the root of the tree
being the library object. Each object has a name, a type, an optional set of
attributes in the form of key-value pairs, and zero or more child objects. For
example, the root of the tree is an object with the same name as the library, a
type of library, and possibly some attributes. The library object also has child
objects that represent each cell in the library, any table templates, and other
data.
To begin with, the following Tcl procedure can be use to recursively display the
contents of any node in a model:
proc dump_model { handle { indent "" } } {
puts "$indent Object [pub::get_obj_name $handle]: \
type=[pub::get_obj_type $handle]"
foreach child [pub::get_obj_list $handle] {
dump_model $child " $indent"
}
}

1086 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

To use this procedure, enter the following commands, which read in a simple
library and display its contents:
Example 478
set handle [pub::read_model -liberty my_library.lib]
dump_model $handle

Running these commands on a simple, one-cell library yields output that looks
similar to the following:
Example 479
Object TEST: type=library
Object TEST: type=operating_conditions
Object default: type=input_voltage
Object default: type=output_voltage
Object tmg_ntin_oload_5x5: type=lu_table_template
Object pwr_tin_oload_5x5: type=power_lut_template
Object BUFX20: type=cell
Object A: type=pin
Object Y: type=pin
Object internal_power0: type=internal_power
Object pwr_tin_oload_5x5: type=fall_power
Object pwr_tin_oload_5x5: type=rise_power
Object timing0: type=timing
Object tmg_ntin_oload_5x5: type=cell_fall
Object tmg_ntin_oload_5x5: type=cell_rise
Object tmg_ntin_oload_5x5: type=fall_transition
Object tmg_ntin_oload_5x5: type=rise_transition

The hierarchy exactly follows the hierarchy in a Liberty file. Notice that the node
types are the same as the elements names in a Liberty model.

API Command Reference

The following sections describe API commands in alphabetical order:
■
add_obj
■
copy_obj
■
del_obj
■
get_models
■
get_obj

SiliconSmart ACE User Guide 1087

L-2016.03
Appendix C: Model Publishing API
API Command Reference

■
get_obj_attr
■
get_obj_level
■
get_obj_list
■
get_obj_match
■
get_obj_name
■
get_obj_owner
■
get_obj_type
■
get_order
■
get_style
■
get_style_by_id
■
read_model
■
remove_model
■
set_obj_attr
■
set_obj_multi_attr
■
set_obj_name
■
set_order
■
set_order_by_id
■
set_style
■
set_style_by_id
■
unset_obj_attr
■
write_model

add_obj
This command adds an object to a model as a child of the specified object.
Each object has a type, a name, and an optional list of attributes. The hierarchy
of objects, the object types, and the legal attributes follow the Liberty
specification. This interface does not attempt to check the validity of the data
and allows user-defined and potentially invalid structures to be created.
Syntax
pub::add_obj objectHandle type name [attr_list]

1088 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

Returns
This command returns a handle to the new object. This handle can be used
with any of the publishing commands such as pub::get_object_name.
Arguments
attr_list
Tcl list of key-value pairs specifying the name and value of each attribute to
be added to the new object.
name
Name of the object to be created.
objectHandle
Object handle tag that specifies an object in the model. This object will be
the parent of the newly created object.
type
Type of the object to be created.
Examples
The following example adds a cell named INVX1 with pins A and Z to the library
referenced by lib_id:
Example 480
set cell_id [pub::add_obj lib_id cell INVX1]
pub::add_obj $cell_id pin A { direction input }
pub::add_obj $cell_id pin Z { direction output }

copy_obj
This command recursively copies an object to a new location in the model
hierarchy. The object will be added as a child of the target_obj.
Syntax
pub::copy_obj src_obj target_obj [attr_list]
Arguments
attr_list
Tcl list of key-value pairs specifying the name and value of each attribute to
be added to the new object.

SiliconSmart ACE User Guide 1089

L-2016.03
Appendix C: Model Publishing API
API Command Reference

src_object
Handle for an object to be copied.
target_obj
Handle of the parent to the newly copied object.

del_obj
This command deletes the specified object from the model hierarchy. The
object is deleted from the model hierarchy. All child objects are deleted as well.
Syntax
pub::del_obj id
Arguments
id
Handle of an object in the model.

get_models
This command returns a list of ids for all the model loaded in memory using the
pub::read_model command.
Syntax
pub::get_models
Returns
A Tcl list of all model ids.

get_obj
This command returns a handle to an object of the given type and name.
Syntax
pub::get_obj parent_id type name
Arguments
name
Name of the requested object.

1090 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

parent_id
Handle to an object in the model.
type
Type of the requested object.
Examples
The following example finds the cell BUFX1 in the library pointed to by lib_id:
Example 481
pub::get_obj lib_id cell BUFX1

get_obj_attr
This command retrieves the attributes from the specified object. Each object
type allows specific attributes to be associated with it.
Syntax
pub::get_obj_attr objectHandle [[key] [default_value]]
Returns
This command returns a string list of key-value pairs. If key is specified, only
the value for that data field is returned, which can be zero length. If the default
value is specified with key, this value is returned if the object does not contain
the attribute key.
Arguments
default_value
Optional argument that specifies the default return value if the specified
attribute key is not present in the object. This option must be used with the
key option.
key
Optional argument that specifies the handle of the exact attribute key from
which to retrieve the data value.
objectHandle
Object handle tag that specifies the object from which to retrieve the
attributes.

SiliconSmart ACE User Guide 1091

L-2016.03
Appendix C: Model Publishing API
API Command Reference

Examples
The following Tcl example retrieves the attributes from the specified cell and
converts the list into an array:
Example 482
array set cellAtt [ pub::get_obj_attr cellId ]

The following Tcl example retrieves a single attribute value from the specified
cell.
Example 483
set cellAtt [ pub::get_obj_attr cellId "area"]

get_obj_level
This command retrieves the level of the specified object from the database
object hierarchy. The root object returns a value of 0.
Syntax
pub::get_obj_level objectHandle
Returns
This command returns the object’s level.
Arguments
objectHandle
Object handle tag that specifies the object from which to retrieve the
attributes.
Examples
The following Tcl example retrieves the level of the object:
Example 484
puts "level : [pub::get_obj_level objId]"

See Also
get_obj_type

1092 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

get_obj_list
This command retrieves the object handles from the specified object ownership
list. Only the next level of object hierarchy is searched and listed. If the
objectType argument is specified, the list of objectHandles will contain
only that type. If filter arguments keyType and name are present, only the
object ID tags of the type or name or those that have the specified key are
returned. When the value argument is specified with keyType set to key, the
value of the key specified by the name argument is matched.
Syntax
pub::get_obj_list objectHandle keyType name [value
[objectType]]
Returns
This command returns a string list of objectHandles. A zero length list is
returned if the specified object is a leaf object.
Arguments
keyType
Optional key type argument to filter the list returned to contain only objects
of a specific type (name | type | key).
name
Name of the specified key.
objectHandle
Object handle tag which specifies the object to retrieve the list of owned
objects from.
objectType
Name of the Liberty construct to retrieve.
value
Optional value for key type key.
Examples
The following Tcl example retrieves the list of object handles from the specified
cell, loops through the list, and prints the name and type of object.
Example 485
Foreach cellObj [ pub::get_obj_lst cellId ] { puts
"[pub::get_obj_name cellObj] : [pub::get_obj_type cellObj ] }

SiliconSmart ACE User Guide 1093

L-2016.03
Appendix C: Model Publishing API
API Command Reference

The following Tcl example retrieves the list of object handles of type pin from a
cell object:
Example 486
set pinObjLst [ pub::get_obj_list cellId type pin]

The following Tcl example retrieves the object handles with name scan_in
from a cell object:
Example 487
set pinObjLst [ pub::get_obj_list cellId name "scan_in"]

See Also
get_obj_attr
get_obj_name
get_obj_type

get_obj_match
Similar to the get_obj_list command, except this command filters by
matching specified type, name, or key-value attribute pairs as the criteria for
matching an object. All of the specified criteria must hold true for the item to
match and be returned by this command.
Syntax
pub::get_obj_match id desc_list
Arguments
type
Specifies the type of the object to match. Note that wild cards are not
allowed for the type.
name
Specifies the name or list of names of the object to match. Any nam in the
list has to match to be selected for the return list.
keyValList
Specifies the object’s attribute key-value pairs that must match. All key
values must match for the object to be selected for the return list.

1094 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

keyNotList
Specifies a list of attribute names that must not be set on the object. All
specified keys must not be set on the object if it is to be selected for the
return value.
valCmpFunc
This specifies the comparison function that is used to match the name and
values in the keyValList. Valid cmp_functions are glob, regexp, and
equal (default). glob and regexp offer regular expression and wildcard-
based matching. glob is based on the TCL string match command and
regexp uses the Tcl regexp command.
Examples

Example 488
# Match by type and name using glob pattern matching for the name.
# Below matches objects of type cell with the names *BUF*
set res [get_obj_match $lib {type cell valCmpFunc glob name *BUF*}]
# Match by type and using multiple glob patterns
# Below matches objects of type cell with names that match the 3
specified patterns
set res [get_obj_match $lib {type cell valCmpFunc glob name {*BUF*
*LAT* CMPR42X2}}]
# Match by type and various key-value attributes
# Below matches cells with both dont_touch and dont_use attributes
with values true
set res [get_obj_match $lib {type cell keyValList {dont_touch
true dont_use true}}]
# Match by type and various key-value attributes using glob patters
for the attr values
# Below matches cells with both dont_touch and dont_use attributes
with any value.
set res [get_obj_match $lib {type cell valCmpFunc glob keyValList
{dont_touch * dont_use *}}]
# Similar to above call, except more readable.
array set desc {
type cell
valCmpFunc glob
keyValList {
dont_touch *
dont_use true
}
}
set res [get_obj_match lib [array get desc]]

SiliconSmart ACE User Guide 1095

L-2016.03
Appendix C: Model Publishing API
API Command Reference

See Also
get_obj
get_obj_list

get_obj_name
This command retrieves the name of the specified object from the database.
Syntax
pub::get_obj_name objectHandle
Returns
This command returns the object’s name.
Arguments
objectHandle
Object handle tag that specifies the object with the name to retrieve.
Examples
The following Tcl example retrieves the name of the object:
Example 489
if { [pub::get_obj_name objId ] == "AND2" } { #loop through pins
foreach pinObj [pub::get_obj_list objId "pin" ] { puts "Pin:
pinObj...

See Also
get_obj_list
get_obj_type

get_obj_owner
This command retrieves the object handle of the owner (parent) of the specified
object from the database.
Syntax
pub::get_obj_owner objectHandle
Returns
This command returns the object’s owner’s objectHandle.

1096 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

Arguments
objectHandle
Object handle tag that specifies the object with the name to retrieve.
Examples
The following Tcl example retrieves the object handle of the owner of a pin
object:
Example 490
set ownerId [pub::get_obj_owner pinId ]

See Also
get_obj_name
get_obj_list

get_obj_type
This command retrieves the type of the specified object from the database.
Syntax
pub::get_obj_type objectHandle
Returns
This command returns the object’s type.
Arguments
objectHandle
Object handle tag that specifies the object with the name to retrieve.
Examples
The following Tcl example retrieves the type of the object:
Example 491
if { [pub::get_obj_type objId ] == "cell" } { puts "object is a
cell }

See Also
get_obj_name

SiliconSmart ACE User Guide 1097

L-2016.03
Appendix C: Model Publishing API
API Command Reference

get_order
This is an auxiliary command that is built on top of the get_style command.
Syntax
pub::get_order id type
Description
This command returns the current order of objects. This may return an empty
list even if there are child objects present. This could happen when there is no
explicit order specified. When no styling is present, the model is written
according to the Liberty modeling style specification.

get_style
This command returns the style information for a given object.
Syntax
pub::get_style objectHandle
Returns
This command returns a list-of-lists.
Arguments
objectHandle
Object handle tag that specifies the object with the name to retrieve.
Description
Each sublist is of the following format:

Example 492
{ class type name format }

where class is one of two strings, obj or attr referring to a child object or
attribute respectively. The type field refers to the type of the attribute or object.
For attributes, type can be one of simple or complex referring to the format
options in the Liberty format.
A simple attribute in Liberty looks like this:
Example 493
pin_capacitance : 0.0246 ;

1098 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

where as a complex attribute in Liberty looks like this:

Example 494
values(“0.00, 0.23, 1.08”);

The type of an object is just the type returned by the pub::getObjType

command, such as pin, cell, or timing.
The name field is the name of the object or attribute. The format field specifies
how the object name or attribute value is formatted in the model.
Valid values for attribute (attr) formats are:

Example 495
double, int, boolean, simple, complex, string, name, name_list,
comment

Valid values for groups (obj) formats are:

Example 496
string, name, name_list

A string is a quoted string, e.g. (“MY BUF”).

A name is an unquoted string, e.g. (MY BUF)
A name_list is an unquoted string with words separated by commas, e.g.
(MY, BUF).
For example, for a latch group, a name, name_list and string format
would produce:

Example 497
{obj latch {IQ IQN} name} -> latch(IQ IQN) { … }
{obj latch {IQ IQN} name_list} -> latch(IQ, IQN) { … }
{obj latch {IQ IQN} string} -> latch(“IQ IQN”) { … }

SiliconSmart ACE User Guide 1099

L-2016.03
Appendix C: Model Publishing API
API Command Reference

Examples
Consider the following example of a Liberty cell definition:
Example 498
cell(BUFD1) {
area : 9.87 ;
cell_leakage_power : 3.1415 ;
pin(A) {
direction : input ;
pin_capacitance : 0.0246;
}
pin(Z) {
direction : output ;
…
}
}

Calling the pub::get_style command on the object handle for this cell
would yield the following return value:
Example 499
pub::get_style $cellId
{{attr simple area double}
{attr simple cell_leakage_power double}
{obj pin A name}
{obj pin Z name}}

get_style_by_id
This command is the same as the get_style command, except that an object
handle id is returned instead of a name in the style_list return value.
Syntax
pub::get_style_by_id objectHandle
Returns
This command returns a list-of-lists in the format: { class type
objectHandle format }
Arguments
objectHandle
Object handle tag of the parent object.

1100 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

See Also
get_style

read_model
This command reads a Liberty model into the internal database and returns a
handle to the root of the data model. It parses the specified Liberty file and
reads it into the internal database. This database represents the contents of the
model as a hierarchical collection of data objects that can be accessed via the
Model Publishing API. The return value of this command is the handle of the
root object, which is the library node.
Syntax
pub::read_model -liberty filename
Arguments
-liberty
Selects the Synopsys Liberty modeling format.
filename
Name of the Liberty model to be read.
Examples
The following commands read in a Liberty model and write it back out to
another file:
Example 500
set lib_id [pub::read_model -liberty my_library.lib]
pub::write_model lib_id new_library.lib

remove_model
This command removes a model from memory. An ID that was returned by the
pub::read_model command must be supplied as an argument. If you do not
have the ID to the model, you can use the pub::get_models command to get
a list of all model IDs currently loaded.
Syntax
pub::remove_model id

SiliconSmart ACE User Guide 1101

L-2016.03
Appendix C: Model Publishing API
API Command Reference

Arguments
id
ID to a library object returned by the read_model command.
Examples
The following example reads in a Liberty model and then removes it:
Example 501
set lib_id [pub::read_model -library my_library.lib]
pub::remove_model lib

See Also
get_models

set_obj_attr
This command sets an attribute on an object. This command does not require
commas between the numbers when setting these value attributes.
Syntax
pub::set_obj_attr id attr_list
Arguments
attr_list
Tcl list of key-value pairs specifying one or more attributes to be set on the
object.
id
Handle to an object in the model.

1102 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

Examples
For example, to scale the max_transition attribute value on each input pin
of each cell:
enable_api pub
set lib [pub::read_model -liberty $filename]
foreach cell [pub::get_obj_list $lib type cell] {
foreach pin [get_obj_list $cell key direction input] {
set oldmaxtran [get_obj_attr $pin max_transition NOMAXTRAN]
if {![string match NOMAXTRAN $oldmaxtran]} {
set newmaxtran [expr $oldmaxtran * 1.2]
unset_obj_attr $pin max_transition
set_obj_attr $pin [list max_transition $newmaxtran]
}
}
}

set_obj_multi_attr
This command sets an attribute on an object which can have multiple entries in
the Liberty library structure. The syntax does not require commas between the
numbers when setting the value attributes.
Syntax
pub::set_obj_multi_attr id name attribute_list
Arguments
id_name
Construct name.
attribute_list
A single liberty attribute which may have multiple definitions in the liberty file,
such as the voltage_map attribute.
Examples
If the original library has the voltage_map definitions as:
Example 502
voltage_map(vdd33, 2.85);
voltage_map(vss33, 0);
voltage_map(vdd, 1.08);
voltage_map(vss, 0);

SiliconSmart ACE User Guide 1103

L-2016.03
Appendix C: Model Publishing API
API Command Reference

and the user wants to change the supply name vdd to vddin and vss to
vssin, then set_obj_multi_attr can be used as below:
Example 503
set lib_id [pub::read_model -liberty my.lib]

#rename_supply lib_id
set vm [pub::get_obj_attr lib_id voltage_map]
pub::unset_obj_attr lib_id voltage_map
#replace_attribute lib_id voltage_map $vm

foreach v $vm {
set vname [lindex $v 0]
set val [lindex $v 1]
if { $vname == "vdd" || $vname == "vss" } {
log_info "modifying voltage map : $v"
append vname "in"
}
set v "$vname $val"
pub::set_obj_multi_attr lib_id voltage_map [list $v]
}

set_obj_name
This command changes an object's name.
Syntax
pub::set_obj_name id name
Arguments
id
Handle to an object in the model.
name
New name of the object.

set_order
This command provides a high-level interface for specifying the order of child
objects, such as pins under a cell.
Syntax
set_order objHandle type nameList [format]

1104 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

Arguments
objectHandle
Handle of the parent object.
type
Type of the objects to be ordered, such as pin or cell.
nameList
List of the names of the objects to be ordered. The order of the list is the
order in which the objects will appear in the published Liberty mode.
Description
This is an auxiliary command that is built on top of the pub::set_style
command. It provides a higher-level interface for common ordering tasks, such
as orders the pins under a cell. This command accepts the object handle of the
container object (a library contains cells, a cell contains pins) and the type of
the objects to be ordered. The nameList argument then specifies the order of
all of the objects of that type by name. If a complete list of objects is not
specified, then the omitted objects will appear last and in an arbitrary order.
Examples
To order the cells in a library, the following command would be used:
Example 504
set_order libId cell {DFFX1 BUFX1 XOR1}

Similarly, the pins in cell DFFX1 and the timing arcs under pin Q could be
ordered using the following commands:
Example 505
set_order cellId pin {QN Q D CK}
set_order pinId timing {timing3 timing1 timing2 timing0}

To order timing groups or internal_power groups that have no name, use

the set_order_by_id command, which allows you to specify order by using
object handles instead of object names.

set_order_by_id
Same as the set_order command except that instead of a list of names, this
command expects a list of object handles (IDs). This command must be used

SiliconSmart ACE User Guide 1105

L-2016.03
Appendix C: Model Publishing API
API Command Reference

when ordering groups that either have duplicate names, or no names at all (as
is the case of timing groups).
Syntax
pub::set_order_by_id objectHandle type objectHandleList
[format]
Arguments
objectHandle
Handle of the parent object.
type
Type of the objects to be ordered, such as pin or cell.
objectHandleList
List of the object handles to be ordered. The order of the list is the order in
which the objects will appear in the published Liberty model.
Description
This is an auxiliary command that is built on top of the set_style_by_id
command. It provides a higher-level interface for common ordering tasks, such
as orders the pins under a cell. This command accepts the object handle of the
container object (a library contains cells, a cell contains pins) and the type of
the objects to be ordered. The objectHandleList argument then specifies
the order of all of the objects of that type by object handle. If a complete list of
object handles is not specified, then the omitted objects will appear last and in
an arbitrary order.
Examples
To order the cells in a library, use the following command:
Example 506
set_order libId cell {cellObj1 cellObj2 cellObj3}

Similarly, you can order the pins in cell DFFX1 and the timing arcs under pin Q
using the following commands:
Example 507
set_order cellId pin {pinObj1 pinObj2 pinObj3}
set_order pinId timing {timingObj1 timingObj2 timingObj3}

See Also
set_order

1106 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

set_style
This command sets the style of its attributes and child objects.
Syntax
pub::set_style objectHandle styleList
Arguments
objectHandle
Name of the object to have the style set.
styleList
Tcl list specifying the style ordering of objects and attributes.
Description
The styleList argument specifies the formatting of the attributes of an object
and the order of the attributes and child objects. For instance, it could be used
to specify the order of the attributes and pins of a cell.
styleList is formatted as a list of lists, where each sublist is of the following
format:
Example 508
{class type name format}

where class is one of two strings, obj or attr referring to a child object or
attribute respectively. The type field refers to the type of the attribute or object.
For attributes, type can be one of ‘simple’ or ‘complex’ referring to the format
options in the Liberty format. A simple attribute in Liberty looks like this:

Example 509
pin_capacitance : 0.0246 ;

where as a complex attribute in Liberty looks like this:

values(“0.00, 0.23, 1.08”);

The type of an object is just the type returned by the pub::getObjType

command, such as pin, cell, or timing.
The name field is the name of the object or attribute. The format field specifies
how the object name or attribute value is formatted in the model.
Valid values for attribute (attr) formats are:
double, int, boolean, simple, complex, string, name, name_list

SiliconSmart ACE User Guide 1107

L-2016.03
Appendix C: Model Publishing API
API Command Reference

Valid values for groups (obj) formats are:

Example 510
string, name, name_list

where:
■
string is a quoted string, e.g., (“MY BUF”).
■
name is an unquoted string, e.g., (MY BUF).
■
name_list is an unquoted string with words separated by commas, e.g.,
(MY, BUF).
For example, for a latch group, a name, name_list and string format
would produce:
Example 511
{obj latch {IQ IQN} name} -> latch(IQ IQN) { … }
{obj latch {IQ IQN} name_list -> latch(IQ, IQN) { … }
{obj latch {IQ IQN} string} -> latch(“IQ IQN”) { … }

The order in which the objects and attributes are specified determines the order
in which they appear in the generated Liberty model. Any objects or attributes
not specified are added to the end of the group in an arbitrary order.
Examples
Consider the following example of a Liberty cell definition:
Example 512
cell(BUFD1) {
area : 9.87 ;
cell_leakage_power : 3.1415 ;
pin(A) {
direction : input ;
pin_capacitance : 0.0246;
}
pin(Z) {
direction : output ;
...
}
}

1108 SiliconSmart ACE User Guide

L-2016.03
 Appendix C: Model Publishing API
API Command Reference

To ensure the ordering and style of the data appears as shown above the style
command would be called like this:
Example 513
pub::set_style cellId {
{attr simple area double}
{attr simple cell_leakage_power double}
{obj pin A name}
{obj pin Z name}
}

set_style_by_id
Same as the set_style command except that an object handle (id) is
specified instead of the object name within the style_list argument.
Syntax
pub::set_style_by_id objectHandle styleList
Arguments
objectHandle
Name of the object to have the style set.
styleList
Tcl list specifying the style ordering of objects and attributes.
Description
The styleList argument specifies the formatting of the attributes of an object
and the order of the attributes and child objects. For instance, it could be used
to specify the order of the attributes and pins of a cell.
styleList is formatted as a list of lists, where each sublist is of the following
format:
{ class type objectHandle format }

See Also
set_style

unset_obj_attr
This command unsets one or more attributes on an object. Use this command
carefully.

SiliconSmart ACE User Guide 1109

L-2016.03
Appendix C: Model Publishing API
API Command Reference

Syntax
pub::unset_obj_attr id attr_list
Arguments
attr_list
Tcl list of attribute names to be unset.
id
Handle of an object in the model.

write_model
This command writes out the internal modeling database to a Liberty model.
The database is populated via the read_model command.
Syntax
pub::write_model handle filename
Arguments
handle
Handle of a library object returned by the read_model command.
filename
Name of the file to be written.
Examples
The following example reads in a Liberty model and writes it back out to a
second file:
Example 514
set lib_id [pub::read_model -liberty my_library.lib]
pub::write_model $lib_id new_library.lib

See Also
read_model
remove_model
get_models

1110 SiliconSmart ACE User Guide

L-2016.03
 D
D

Third Party Software

This appendix describes licensing and proprietary information for third-party

software products used with the SiliconSmart tool.

This information has been included in this file as requested by the applicable
third party software licensor.
Questions or comments regarding the information printed here should be
directed to the third party licensor in accordance with the contact information
included with the applicable license.
The following third-party products are described in this chapter:
■ Signal Extensions for Tcl/Tk
■
Python 2.2.1
■
libjpeg
■ Tcl/Tk
■
TclPro
■
CUDD
■
elmer
■
zlib
■
itcl
■ BLT
■
SWIG
■
Berkeley DB
■ libedit

SiliconSmart ACE User Guide 1111

L-2016.03
Appendix D: Third Party Software
Signal Extensions for Tcl/Tk

■
Graphviz
■
Gnuplot
■
GNU Lesser General Public License v2.1

Signal Extensions for Tcl/Tk

Copyright © 1996 Schwartz Computer Consulting Services
Permission to use, copy, modify, distribute, and sell this
software and its documentation for any purpose is hereby
granted without fee, provided that the above copyright
notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting
documentation, and that the name of SCCS not be used in
advertising or publicity pertaining to distribution of
the software without specific, written prior permission.
SCCS makes no representations about the suitability of
this software for any purpose. It is provided "as is"
without express or implied warranty.

Python 2.2.1
Copyright (c) 2001, 2002 Python Software Foundation; All
Rights Reserved

PSF LICENSE AGREEMENT FOR PYTHON 2.2.1

--------------------------------------

1. This LICENSE AGREEMENT is between the Python Software

Foundation ("PSF"), and the Individual or Organization
("Licensee") accessing and otherwise using Python 2.2.1
software in source or binary form and its associated
documentation.

2. Subject to the terms and conditions of this License

Agreement, PSF hereby grants Licensee a nonexclusive,
royalty-free, world-wide license to reproduce, analyze,
test, perform and/or display publicly, prepare derivative
works, distribute, and otherwise use Python 2.2.1 alone

1112 SiliconSmart ACE User Guide

L-2016.03
 Appendix D: Third Party Software
Python 2.2.1

or in any derivative version, provided, however, that

PSF's License Agreement and PSF's notice of copyright,
i.e., "Copyright (c) 2001, 2002 Python Software
Foundation; All Rights Reserved" are retained in Python
2.2.1 alone or in any derivative version prepared by
Licensee.

3. In the event Licensee prepares a derivative work that is

based on or incorporates Python 2.2.1 or any part thereof,
and wants to make the derivative work available to others
as provided herein, then Licensee hereby agrees to include
in any such work a brief summary of the changes made to
Python 2.2.1.

4. PSF is making Python 2.2.1 available to Licensee on an

"AS IS" basis. PSF MAKES NO REPRESENTATIONS OR
WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT
NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY
REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 2.2.1
WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.

5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS

OF PYTHON 2.2.1 FOR ANY INCIDENTAL, SPECIAL, OR
CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING,
DISTRIBUTING, OR OTHERWISE USING PYTHON 2.2.1, OR ANY
DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY
THEREOF.

6. This License Agreement will automatically terminate upon

a material breach of its terms and conditions.

7. Nothing in this License Agreement shall be deemed to

create any relationship of agency, partnership, or joint
venture between PSF and Licensee. This License Agreement
does not grant permission to use PSF trademarks or trade
name in a trademark sense to endorse or promote products
or services of Licensee, or any third party.

8. By copying, installing or otherwise using Python 2.2.1,

Licensee agrees to be bound by the terms and conditions
of this License Agreement.

SiliconSmart ACE User Guide 1113

L-2016.03
Appendix D: Third Party Software
libjpeg

libjpeg
"this software is based in part on the work of the Independent
JPEG Group"

* Copyright (C) 1991-1998, Thomas G. Lane.

* This file is part of the Independent JPEG Group's software.
* For conditions of distribution and use, see the
accompanying README file.

The authors make NO WARRANTY or representation, either

express or implied, with respect to this software, its
quality, accuracy, merchantability, or fitness for a
particular purpose. This software is provided "AS IS",
and you, its user, assume the entire risk as to its quality
and accuracy.

This software is copyright (C) 1991-1998, Thomas G. Lane.

All Rights Reserved except as specified below.

Permission is hereby granted to use, copy, modify, and

distribute this software (or portions thereof) for any
purpose, without fee, subject to these
conditions:
(1) If any part of the source code for this software is
distributed, then this README file must be included, with
this copyright and no-warranty notice unaltered; and any
additions, deletions, or changes to the original files
must be clearly indicated in accompanying documentation.
(2) If only executable code is distributed, then the
accompanying documentation must state that "this software
is based in part on the work of the Independent JPEG
Group".
(3) Permission for use of this software is granted only if
the user accepts full responsibility for any undesirable
consequences; the authors accept NO LIABILITY for damages
of any kind.

These conditions apply to any software derived from or based

on the IJG code, not just to the unmodified library. If
you use our work, you ought to acknowledge us.

1114 SiliconSmart ACE User Guide

L-2016.03
 Appendix D: Third Party Software
Tcl/Tk

Permission is NOT granted for the use of any IJG author's

name or company name in advertising or publicity relating
to this software or products derived from it. This
software may be referred to only as "the Independent JPEG
Group's software".

We specifically permit and encourage the use of this software

as the basis of commercial products, provided that all
warranty or liability claims are assumed by the product
vendor.

Tcl/Tk
This software is copyrighted by the Regents of the University
of California, Sun Microsystems, Inc., Scriptics
Corporation, ActiveState This software is copyrighted by
the Regents of the University of California, Sun
Microsystems, Inc., Scriptics Corporation, ActiveState
Corporation and other parties. The following terms apply
to all files associated with the software unless
explicitly disclaimed in individual files.

The authors hereby grant permission to use, copy, modify,

distribute, and license this software and its
documentation for any purpose, provided that existing
copyright notices are retained in all copies and that
this notice is included verbatim in any distributions.
No written agreement, license, or royalty fee is required
for any of the authorized uses. Modifications to this
software may be copyrighted by their authors and need not
follow the licensing terms described here, provided that
the new terms are clearly indicated on the first page of
each file where they apply.

IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO

ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS
SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF,
EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.

SiliconSmart ACE User Guide 1115

L-2016.03
Appendix D: Third Party Software
TclPro

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY

WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED
ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS
HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

GOVERNMENT USE: If you are acquiring this software on behalf

of the U.S. government, the Government shall have only
"Restricted Rights" in the software and related
documentation as defined in the Federal
Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2).
If you are acquiring the software on behalf of the
Department of Defense, the software shall be classified
as "Commercial Computer Software" and the Government shall
have only "Restricted Rights" as defined in Clause
252.227-7013 (c) (1) of DFARs. Notwithstanding the
foregoing, the authors grant the U.S. Government and
others acting in its behalf permission to use and
distribute the software in accordance with the terms
specified in this license.

TclPro
Copyright (c) 1998-2000 Ajuba Solutions
All rights reserved.

This software is copyrighted by the Scriptics Corporation

(also known as Ajuba Solutions). The following terms apply
to all files associated with the software unless
explicitly disclaimed in individual files.

The authors hereby grant permission to use, copy, modify,

distribute, and license this software and its
documentation for any purpose, provided that existing
copyright notices are retained in all copies and that
this notice is included verbatim in any distributions.
No written agreement, license, or royalty fee is required
for any of the authorized uses. Modifications to this
software may be copyrighted by their authors and need not

1116 SiliconSmart ACE User Guide

L-2016.03
 Appendix D: Third Party Software
CUDD

follow the licensing terms described here, provided that

the new terms are clearly indicated on the first page of
each file where they apply.

IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO

ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS
SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF,
EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY

WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED
ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS
HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

GOVERNMENT USE: If you are acquiring this software on behalf

of the U.S. government, the Government shall have only
"Restricted Rights" in the software and related
documentation as defined in the Federal
Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2).
If you are acquiring the software on behalf of the
Department of Defense, the software shall be classified
as "Commercial Computer Software" and the Government shall
have only "Restricted Rights" as defined in Clause
252.227-7013 (c) (1) of DFARs. Notwithstanding the
foregoing, the authors grant the U.S. Government and
others acting in its behalf permission to use and
distribute the software in accordance with the terms
specified in this license.

CUDD
Copyright [Copyright (c) 1994-1996 The Univ. of Colorado.
All rights reserved.

Permission is hereby granted, without written agreement and

without license or royalty fees, to use, copy, modify,
and distribute this software and its documentation for

SiliconSmart ACE User Guide 1117

L-2016.03
Appendix D: Third Party Software
elmer

any purpose, provided that the above copyright notice and

the following two paragraphs appear in all copies of this
software.

IN NO EVENT SHALL THE UNIVERSITY OF COLORADO BE LIABLE TO

ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS
SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY
OF COLORADO HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
THE UNIVERSITY OF COLORADO SPECIFICALLY DISCLAIMS ANY
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS
IS" BASIS, AND THE UNIVERSITY OF COLORADO HAS NO
OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES,
ENHANCEMENTS, OR MODIFICATIONS.]

elmer
Copyright (c) 2001-2003 Richard L. Ratzel

Permission is hereby granted, free of charge, to any person

obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the
Software without restriction, including without
limitation the rights to use, copy, modify, merge,
publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software
is furnished to do so, subject to the following
conditions:

The above copyright notice and this permission notice shall

be included in all copies or substantial portions of the
Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY

KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF

1118 SiliconSmart ACE User Guide

L-2016.03
 Appendix D: Third Party Software
zlib

CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN

CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.

zlib
(C) 1995-1996 Jean-loup Gailly and Mark Adler

This software is provided 'as-is', without any express or

implied
warranty. In no event will the authors be held liable for
any damages
arising from the use of this software.

Permission is granted to anyone to use this software for

any purpose,
including commercial applications, and to alter it and
redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented;

you must not
claim that you wrote the original software. If you use
this software
in a product, an acknowledgment in the product
documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such,
and must not
be misrepresented as being the original software.
3. This notice may not be removed or altered from any source
distribution.

Jean-loup Gailly Mark Adler

gzip@prep.ai.mit.edu madler@alumni.caltech.edu

itcl
AUTHOR: Michael J. McLennan
Bell Labs Innovations for Lucent Technologies

SiliconSmart ACE User Guide 1119

L-2016.03
Appendix D: Third Party Software
BLT

mmclennan@lucent.com
http://www.tcltk.com/itcl
=======================================================
=================
Copyright (c) 1993-1996 Lucent Technologies
=======================================================
=================
Permission to use, copy, modify, and distribute this software
and its documentation for any purpose and without fee is
hereby granted, provided that the above copyright notice
appear in all copies and that both that the copyright
notice and warranty disclaimer appear in supporting
documentation, and that the names of Lucent Technologies
any of their entities not be used in advertising or
publicity pertaining to distribution of the software
without specific, written prior permission.

Lucent Technologies disclaims all warranties with regard to

this software, including all implied warranties of
merchantability and fitness. In no event shall Lucent
be liable for any special, indirect or consequential
damages or any damages whatsoever resulting from loss of
use, data or profits, whether in an action of contract,
negligence or other tortuous action, arising out of or
in connection with the use or performance of this
software.
=======================================================
=================

BLT
Copyright 1991-1998 by Bell Labs Innovations for Lucent
Technologies.

Permission to use, copy, modify, and distribute this

software and its documentation for any purpose and
without fee is hereby granted, provided that the above
copyright notice appear in all copies and that both that
the copyright notice and warranty disclaimer appear in
supporting documentation, and that the names of Lucent

1120 SiliconSmart ACE User Guide

L-2016.03
 Appendix D: Third Party Software
SWIG

Technologies any of their entities not be used in

advertising or publicity pertaining to distribution of
the software without specific, written prior permission.

Lucent Technologies disclaims all warranties with regard

to this software, including all implied warranties of
merchantability and fitness. In no event shall Lucent
Technologies be liable for any special, indirect or
consequential damages or any damages whatsoever resulting
from loss of use, data or profits, whether in an action
of contract, negligence or other tortuous action, arising
out of or in connection with the use or performance of
this software.

SWIG
I.

This software includes contributions that are Copyright (c)

1998-2002 University of Chicago. All rights reserved.

Redistribution and use in source and binary forms, with or

without modification, are permitted provided that the
following conditions are
met:

Redistributions of source code must retain the above

copyright notice, this list of conditions and the
following disclaimer. Redistributions in binary form
must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution. Neither the name of the University of
Chicago nor the names of its contributors may be used to
endorse or promote products derived from this software
without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY OF CHICAGO AND

CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY

SiliconSmart ACE User Guide 1121

L-2016.03
Appendix D: Third Party Software
SWIG

OF CHICAGO OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.

II.
Copyright (c) 1995-1998
The University of Utah and the Regents of the University of
California All Rights Reserved

Permission is hereby granted, without written agreement and

without license or royalty fees, to use, copy, modify,
and distribute this software and its documentation for
any purpose, provided that
(1) The above copyright notice and the following two
paragraphs appear in all copies of the source code and
(2) redistributions including binaries reproduces these
notices in the supporting
documentation. Substantial modifications to this software
may be
copyrighted by their authors and need not follow the
licensing terms described here, provided that the new
terms are clearly indicated in all files where they apply.

IN NO EVENT SHALL THE AUTHOR, THE UNIVERSITY OF CALIFORNIA,

THE
UNIVERSITY OF UTAH OR DISTRIBUTORS OF THIS SOFTWARE BE LIABLE
TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS
SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE AUTHORS OR
ANY OF THE ABOVE PARTIES HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE AUTHOR, THE UNIVERSITY OF CALIFORNIA, AND THE UNIVERSITY

OF UTAH SPECIFICALLY DISCLAIM ANY WARRANTIES,INCLUDING,
BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
ON AN "AS IS" BASIS, AND

1122 SiliconSmart ACE User Guide

L-2016.03
 Appendix D: Third Party Software
Berkeley DB

THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE

MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
MODIFICATIONS.

Berkeley DB
Copyright (c) 1990, 1993, 1994
The Regents of the University of California. All rights
reserved.

Redistribution and use in source and binary forms, with or

without modification, are permitted provided that the
following conditions are met: 1. Redistributions of
source code must retain the above copyright
notice, this list of conditions and the following
disclaimer. 2. Redistributions in binary form must
reproduce the above copyright
notice, this list of conditions and the following
disclaimer in the
documentation and/or other materials provided with the
distribution. 3. All advertising materials mentioning
features or use of this software
must display the following acknowledgement:
This product includes software developed by the
University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its
contributors
may be used to endorse or promote products derived from
this software
without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS

``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY

SiliconSmart ACE User Guide 1123

L-2016.03
Appendix D: Third Party Software
libedit

OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR

TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.

libedit
Copyright (c) 1992, 1993
The Regents of the University of California. All
rights reserved.

This code is derived from software contributed to Berkeley

by Christos Zoulas of Cornell University.

Redistribution and use in source and binary forms, with or

without modification, are permitted provided that the
following conditions are met:
1. Redistributions of source code must retain the above
copyright
notice, this list of conditions and the following
disclaimer.
2. Redistributions in binary form must reproduce the above
copyright
notice, this list of conditions and the following
disclaimer in the
documentation and/or other materials provided with the
distribution.
3. All advertising materials mentioning features or use of
this software
must display the following acknowledgement:
This product includes software developed by the
University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its
contributors
may be used to endorse or promote products derived from
this software
without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS

``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES

1124 SiliconSmart ACE User Guide

L-2016.03
 Appendix D: Third Party Software
Graphviz

OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.

Graphviz

Eclipse Public License - v 1.0.

THE ACCOMPANYING GRAPHIZ (GRAPH VISULATION SOFTWARE) (THE
\"PROGRAM\") IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE
PUBLIC LICENSE (\"AGREEMENT\") and not Synopsys’s Software
License Agreement with you. ANY USE, REPRODUCTION OR
DISTRIBUTION OF THE PROGRAM CONSTITUTES YOUR ACCEPTANCE OF
THIS AGREEMENT.
The terms of the Agreement may be found here - http://
www.graphviz.org/License.php - or if the link is broken,
please contact Synopsys support.Source Code for the
Program may be accessed here - http://graphviz.org/
Download.php - or if the link is broken, please contact
Synopsys support.

Gnuplot
Copyright 1986 - 1993, 1998, 2004 Thomas Williams, Colin
Kelley
Permission to use, copy, and distribute this software and
its documentation for any purpose with or without fee is
hereby granted, provided that the above copyright notice

SiliconSmart ACE User Guide 1125

L-2016.03
Appendix D: Third Party Software
GNU Lesser General Public License v2.1

appear in all copies and that both that copyright notice

and this permission notice appear in supporting
documentation.
Permission to modify the software is granted, but not the
right to distribute the complete modified source code.
Modifications are to be distributed as patches to the
released version. Permission to distribute binaries
produced by compiling modified sources is granted,
provided you:
1. distribute the corresponding source modifications from
the released version in the form of a patch file along with
the binaries.
2. add special version identification to distinguish your
version in addition to the base release version number.
3. provide your name and address as the primary contact for
the support of your modified version.
4. retain our contact information in regard to use of the
base software.
Permission to distribute the released version of the
source code along with corresponding source modifications
in the form of a patch file is granted with same provisions
2 through 4 for binary distributions.
This software is provided "as is" without express or
implied warranty to the extent permitted by applicable
law.
http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright?view=markup

GNU Lesser General Public License v2.1

This Synopsys software is based in part on the work of the Qwt project (http://
qwt.sf.net).

1126 SiliconSmart ACE User Guide

L-2016.03
 Index

A command groups
processing commands 669
add model attributes 223
query commands 652
add_channel_length_variation 561
setup commands 555
add_channel_width_variation 561 commands
add_harness_elements command 567 add_harness_element 567
add_process_parameter_variation 582 characterize 38, 669
add_transistor 588 clear_liberty_attribute 593
add_user_stimulus 588 configure 596
API commands create 42, 599
pub::add_obj 1088 create_harness 599
pub::get_obj 1090 define_parameters 604
pub::get_obj_attr 1091 enable_api 605, 1086
pub::get_obj_level 1092 generate_datasheet 382, 673
pub::get_obj_list 1093 get_cells 652
pub::get_obj_name 1096 get_location 655
pub::get_obj_owner 1096 get_parameter 656
pub::get_obj_type 1097 get_version_info 657
pub::read_model 1101 help 658
pub::set_obj_name 1104 import 5, 76, 674
pub::unset_obj_attr 1109 import_driver 680
pub::write_model 1101, 1110 list_parameters 659
arc selection 211 model 682
architecture 2 pintype 613
report_sim_results 662
set_cell_type 617
B set_liberty_attribute 623
backwards-compatibility 1085 set_location 45, 628
Boolean operations 110 set_log_file 6, 629
set_log_level 7, 629
C set_log_stdout_level 7, 630
set_measurement_node 631
cell_families_by_name 592 set_opc_default_voltage 638
cell-level model attributes 224 set_opc_parameter 633
characterization set_opc_process 636
electromigration 535 set_opc_temperature 637
EM 535 set_parameter 640
characterization directory structure 43 set_pintype_parameter 642
characterization engine 2 set_stimulus_node 643
characterize command 38, 669 set_sweep_parameter 645
clear_liberty_attribute command 593 complementary inputs 94
clear_liberty_group 595 configure command 596

1127
Index
D
configure.tcl 70
create command 42, 599
create_harness command 599
ctin parameter type 397
Current Source Models 435
custom scripts 7
customize
data sheet content 399
data sheet format 399
data sheets 393
D G
data sheet content
banner 388
dynamic energy 391
function 389
headers 388
input pin capacitance 390
leakage power 392
setup and conditions 393
transition time 390
data sheets
add parameters 395
column headers 403
customize 393
customize content 399
customize format 399
load pin parameters 396
modify parameters 395
prolog parameters 403
prototype parameters 403
report parameters 399
report settings 399
set transition time 396
table captions 402
table parameters 402
variable substitution 404
default arc selection 211
define_cell_ccb 601
define_parameters command 604
E job
ECSM 2
editing
configure.tcl 70
Electromigration 535
1128
EM 535
EM characterization 535
enable_api command 605, 1086
entering commands 4
explicit_points_load 73
explicit_points_slew 72
F
foreach Tcl command 1081
generate_datasheet command 382, 673
get_cells command 652
get_config_opt 653
get_location command 655
get_parameter command 656
get_version_info command 657
Grid Engine 2
binaries 12
wrapper scripts 12
H
help 5
help command 658
hosts
IDs and names 25
I
import command 5, 76, 674
import_driver command 680
introduction 1
io_shell 2
io_shell command options 4
io_shell syntax 4
io_shell.log 6
J
JMS 2
definition 10
job management system (JMS) 2
Job Scheduler
RTDA NC 12
job scheduler
 Index
L

Grid Engine 11 log file 6

LSF 10 log files 6
setting 10 logging 6
stand-alone 10 logic_high_name 71
job scheduling logic_low_name 71
Grid Engine 2
LSF 2, 10
LSF 2
LSF status 11
stand-alone 2
job_scheduler 12
M
L man 610
managing licenses 25
largest_slew 72
Liberty attributes map files 211
capacitive_load_unit 224 merge 610
current_unit 224 model attributes 223
default_fanout_load 223 cell-level 224
leakage_power_unit 224 library-level 223
pulling_resistance_unit 224 pin-level 225
time_unit 224 user-defined 225
voltage_unit 224 model command 682
Liberty constructs model files 211
capacitance 216 model formats
cell_fall 216 ECSM 2
cell_leakage_power 216 Liberty 2
cell_rise 216 model publishing API
fall_constraint 216 overview 1086
fall_power 216 model_negative_constraints 217
fall_transition 216 model_negative_delays 217
min_pulse_width_high 216 model_significant_digits 217
min_pulse_width_low 216 modeling engine 2
rise_constraint 216
Modeling Three-State Pin Capacitance 446
rise_power 216
rise_transition 216
Liberty models 2, 216 N
constructs 216 NC 12
liberty_cap_unit 217 –nocompact 612
liberty_increasing_delay_with_load 217 numsteps_slew 72
liberty_increasing_delay_with_slew 217
liberty_time_unit 217 O
library-level model attributes 223
oload parameter type 397
license
operating conditions 74
managing 25
obtaining new 25 option switches 5
upgrading 25
list_parameters command 659 P
load sharing 9 parameter types
facility 10 ctin 397

1129
Index
R
oload 397
rload 397
rtin 397
tin 397
parameters
pin type 73
Pin Capacitance 446
pin type definitions 71
pin type parameters 73
pin-level model attributes 225
pintype command 613
Platform Computing Corporation 10
PrimeTime 2
pub::add_obj command 1088
pub::get_obj command 1090
pub::get_obj_attr command 1091
pub::get_obj_level command 1092
pub::get_obj_list command 1093
pub::get_obj_name command 1096
pub::get_obj_owner command 1096
pub::get_obj_type command 1097
pub::read_model command 1101
pub::set_obj_name command 1104
pub::unset_obj_attr command 1109
pub::write_model command 1101, 1110
R log files 6
remove_parameter_block 615
report parameters 399
report_sim_results command 662
rload parameter type 397
RTDA NC 12
rtin parameter type 397
run_char_managers 615
run_list_maxsize 10
S submit_list_maxsize 10
scripts 1081
set
directory location 45
simulator options 31
set Tcl command 1080
set_boundary_distance 615
set_cell_type command 617
set_config_opt
1130
binning 151
constraint 149
noise 151
timing 148
set_harness_parent 622
set_length_unit 622
set_liberty_attribute command 623
set_location command 45, 628
set_log_file command 6, 629
set_log_level command 7, 629
set_log_stdout_level command 7, 630
set_maskable_enable_control_output 630
set_measurement_node command 631
set_opc_default_voltage command 638
set_opc_parameter command 633
set_opc_process command 636
set_opc_temperature command 637
set_parameter command 640
set_pintype_parameter command 642
set_points_boundary_distance 642
set_stimulus_node command 643
set_sweep_parameter command 645
SignalStorm 2
SiliconSmart IO
architecture 2
command help 5
entering commands 4
simulator options 31
slew 72
smallest_slew 72
specify
cells 6
stand-alone 10
stand-alone mode 2
status 647
styling options 216
T
Tcl 4, 1079
conditional execution 1081
looping 1081
variables 1080
Tcl commands
foreach 1081
 Index
U

set 1080 usage

Tcl scripts 1081 specifying cells 6
third-party software 1111 user-defined model attributes 225
Three-State Disable 443
Three-State Enable 442 V
tin parameter type 397 validate_hdl 649
transition times 72
Tri-State 440
W
U wildcards 6
upgrading licenses 25

1131
Index
W

1132