RedHawk
User Manual
Software Release 18.0
Manual Version: Production
Copyright © May 12, 2017
ANSYS, Inc.
RedHawk User Manual
Copyright © 2002, 2003, 2004 Apache Design Solutions, Inc.
Copyright Notice and Proprietary Information
No part of this document may be reproduced or transmitted in any form or by any means, electronic, or
mechanical, for any purpose, without the express written permission of ANSYS INC (Apache Design
Business Unit). This manual and the program described in it are owned by ANSYS INC and may be
used only as authorized in the license agreement controlling such use, and may not be copied except
in accordance with the terms of this agreement.
Copyright © 2013, 2014, 2015, 2016; ANSYS INC (Apache Design Business Unit). All rights reserved.
Disclaimer
ANSYS INC makes no warranty of any kind, expressed or implied, with respect to software or
documentation, its quality, or performance. The information in this document is subject to change
without notice and does not represent a commitment on the part of ANSYS INC.
Trademarks
ANSYS and any and all ANSYS INC brand, product, service and feature names, logos and slogans
are registered trademarks or trademarks of ANSYS, INC. or its subsidiaries in the United States or
other countries. All other trademarks referred to are the property of their registered owners.
ANSYS, Inc.
2645 Zanker Road
San Jose, CA 95134
Tel:(408) 457-2000
Fax: (408) 428-9569
apache_sales@apache-da.com
support_center@apache-da.com
www.apache-da.com
RedHawk User Manual
Copyright © 2002, 2003, 2004 Apache Design Solutions, Inc.
RedHawk User Manual | i
Table of Contents
TABLE OF CONTENTS
Chapter 1 - Introduction
Full-chip Static and Dynamic Power Integrity ......................................................................... 1-1
Using RedHawk in the Design Flow ........................................................................................ 1-2
Design Planning ............................................................................................................... 1-2
Design Development ....................................................................................................... 1-2
Design Verification ........................................................................................................... 1-3
Summary ................................................................................................................................. 1-4
Chapter 2 - RedHawk Flow
Introduction ............................................................................................................................. 2-5
Static Voltage Drop Analysis Flow .......................................................................................... 2-5
Dynamic Voltage Drop Analysis Flow ..................................................................................... 2-6
Chapter 3 - User Interface and Data Preparation
Introduction ............................................................................................................................. 3-9
TCL Command User Interface ................................................................................................ 3-9
TCL Command Summary ................................................................................................ 3-9
Graphical User Interface ....................................................................................................... 3-10
Elements of the GUI ...................................................................................................... 3-10
Menu Bar ................................................................................................................ 3-11
Primary Display Area .............................................................................................. 3-12
Log Display Area .................................................................................................... 3-12
Control Buttons ....................................................................................................... 3-12
Design View Area ................................................................................................... 3-13
TCL Command Line ............................................................................................... 3-13
Using the GUI ................................................................................................................ 3-13
Exporting and Importing a GUI Configuration ......................................................... 3-13
RedHawk Data Preparation - Static and Dynamic Analysis .................................................. 3-13
RedHawk Program Files ................................................................................................ 3-13
Multiple Vdd/Vss Analysis .............................................................................................. 3-16
Summary of Differences in Input Data Files ........................................................... 3-17
Liberty Library Syntax Differences for Multiple Vdd/Vss Domains ......................... 3-18
P/G Arc Definitions in Custom LIB Files ................................................................. 3-20
GSR Keywords for Multi-Vdd Domain Designs ...................................................... 3-21
APL Requirements for Multi-Vdd Designs .............................................................. 3-22
AVM Configuration File ........................................................................................... 3-22
Data Prep and Using the Automated ‘rh_setup.pl’ Script .............................................. 3-22
Recommended RedHawk Directory Structure ........................................................ 3-22
Automated Script rh_setup.pl ................................................................................. 3-24
GDS2DEF Setup with the ‘gds_setup.pl’ Script ............................................................. 3-27
Using the gds_setup Utility ..................................................................................... 3-27
Outputs ................................................................................................................... 3-28
Manually Importing Design Data .................................................................................... 3-28
ANSYS, Inc.
Table of Contents
RedHawk User Manual | ii
Command Line Data Import ................................................................................... 3-28
GUI Data Loading ................................................................................................... 3-30
RedHawk Configuration Files ........................................................................................ 3-31
Distributed Machine Processing (DMP) ......................................................................... 3-31
DMP-supported Flows ............................................................................................ 3-32
Chapter 4 - Power Calculation, Static IR Drop and EM Analysis
Introduction ........................................................................................................................... 4-34
Power Calculation ................................................................................................................. 4-35
Setup for Vectorless Power Calculation ........................................................................ 4-36
Setting Frequency and Clock Parameters .............................................................. 4-37
Setting the Switching State of Instances and Blocks .............................................. 4-38
Setting the Toggle Rate .......................................................................................... 4-38
Setting Toggle Rate Scaling Parameters ............................................................... 4-40
Using both clock and signal toggle rates in power calculation ............................... 4-42
Setting Extraction Parameters ................................................................................ 4-42
Selecting Power Calculation Methodology ............................................................. 4-43
Specifying Supply Nets ........................................................................................... 4-44
Setting Bus and Hierarchy Delimiter Keywords ...................................................... 4-45
Setting up for Event-Driven (VCD File) Power Calculation ............................................ 4-45
Setting GSR Keywords for Event-driven (VCD) Power Calculation ....................... 4-46
Power Calculation Procedure and Results Evaluation .................................................. 4-49
Power Grid Resistance Extraction ........................................................................................ 4-52
Metal Density Calculation .............................................................................................. 4-52
TCL Command R Extraction .......................................................................................... 4-52
GUI Extraction ............................................................................................................... 4-53
Examining Power/Ground Grid Weakness ........................................................................... 4-53
Defining Pad and Package Parameters ................................................................................ 4-56
Command Line Procedure for Package Modeling ......................................................... 4-56
GUI Procedure for Package Modeling ........................................................................... 4-57
Package Compiler Utility ................................................................................................ 4-57
Running RedHawk-S (Static IR/EM Analysis) ....................................................................... 4-57
Exporting and Importing Results to the Design Database ............................................. 4-59
Exporting a Database ............................................................................................. 4-59
Database Compatibility ........................................................................................... 4-59
Importing a Database ............................................................................................. 4-59
Flexible Memory Caching for Database Reloading ................................................ 4-60
Early Analysis Methodology .................................................................................................. 4-60
Overview ........................................................................................................................ 4-60
Input Data Required ....................................................................................................... 4-61
Early Analysis Flow ........................................................................................................ 4-61
Block Power and Current Assignment .................................................................... 4-61
Creating Decap Cells During BPA .......................................................................... 4-67
Early Stage Decap Estimation ................................................................................ 4-68
Reports Created ............................................................................................................ 4-69
Example Analyses ......................................................................................................... 4-69
ANSYS, Inc.
Table of Contents
RedHawk User Manual | iii
Evaluating Results of Static IR Voltage Drop Analysis ......................................................... 4-71
Example Procedure to Fix IR Drop Problems ....................................................................... 4-74
Example IR Drop Case .................................................................................................. 4-74
Modifying Power Pads ................................................................................................... 4-75
Adding Metal6 Straps .................................................................................................... 4-77
Resistivity Sensitivity ..................................................................................................... 4-79
Chapter 5 - Dynamic Voltage Drop Analysis
Introduction ........................................................................................................................... 5-80
Preparing for Dynamic Voltage Drop Analysis ...................................................................... 5-80
Perform Cell Characterization ........................................................................................ 5-80
Calculate Power ............................................................................................................. 5-80
Network Extraction ......................................................................................................... 5-81
Pad and Package Parameter Setup .............................................................................. 5-81
Methods of Dynamic Voltage Drop Analysis ......................................................................... 5-81
Vectorless Dynamic Analysis ......................................................................................... 5-83
Overview ................................................................................................................. 5-83
Input Data and Assumptions .................................................................................. 5-83
Standard Vectorless Analysis Procedure ............................................................... 5-83
Unified Clock Gate Handling and Analysis .................................................................... 5-84
Automatic Clock Gate Handling (default) ............................................................... 5-84
RTL VCD-Driven Vectorless Dynamic Analysis ............................................................. 5-87
Data Requirements for State Propagation .............................................................. 5-87
GSR Keywords to Support RTL VCD Flow ............................................................ 5-88
RTL VCD Reports ................................................................................................... 5-89
Gate Level VCD-Driven Vectorless Dynamic Analysis .................................................. 5-89
Input Data and Assumptions .................................................................................. 5-89
Analysis Procedure ................................................................................................. 5-90
VCD Dynamic Analysis .................................................................................................. 5-91
Input Data and Assumptions .................................................................................. 5-91
VCD Critical Cycle Selection .................................................................................. 5-91
Multi-Bit Sequential Cell Handling in VCD Analysis ............................................... 5-92
Mixed Mode VCD and Vectorless Analysis ............................................................ 5-92
Analysis Procedure ................................................................................................. 5-93
Gated Clock Dynamic Analysis ...................................................................................... 5-94
Input Data ............................................................................................................... 5-94
GSR Keywords for Clock Domain Gating ............................................................... 5-94
Troubleshooting Files and Tips .............................................................................. 5-97
Scan Mode Dynamic Analysis ....................................................................................... 5-97
Early design vectorless scan mode analysis .......................................................... 5-97
Gate-level VCD scan mode analysis .................................................................... 5-100
Evaluating DvD Analysis Results ........................................................................................ 5-100
Types of DvD Results .................................................................................................. 5-100
Filtering Minimum DvD Results ................................................................................... 5-101
Replaying a Previous RedHawk Session ............................................................................ 5-102
TCL Commands to Run Dynamic Voltage Drop Analysis) .................................................. 5-102
ANSYS, Inc.
Table of Contents
RedHawk User Manual | iv
Chapter 6 - Reports
Introduction ......................................................................................................................... 6-103
RedHawk Log Files ............................................................................................................. 6-103
Command Files ............................................................................................................ 6-103
Log and Error Files ...................................................................................................... 6-103
Links to Latest Log and Message Files ....................................................................... 6-104
GUI Log Message Viewer ............................................................................................ 6-104
Reviewing Shorts in the Design ................................................................................... 6-106
Tech File Viewer .......................................................................................................... 6-107
DEF Import Summary .................................................................................................. 6-107
Summary Files for Power .................................................................................................... 6-108
power_summary.rpt File .............................................................................................. 6-108
<top_level_block>.power.rpt File ................................................................................. 6-109
apache.power.info File ................................................................................................. 6-109
Results for Static and Dynamic Voltage and Current Analyses .......................................... 6-109
EM, Static IR and DvD Colormap Displays .................................................................. 6-109
Static EM and IR Drop Results Files ........................................................................... 6-110
Static and Dynamic Voltage Drop Results Files .......................................................... 6-111
<design>.ir.worst File ........................................................................................... 6-111
<design>.dvd File ................................................................................................. 6-111
Static and Dynamic Results for Vias ............................................................................ 6-111
Current Report Files .................................................................................................... 6-112
<design>.ignd File ................................................................................................ 6-112
<design>.ipwr File ................................................................................................ 6-112
<design>.ivdd File ................................................................................................ 6-112
<design>.ivdd.vsrc File ......................................................................................... 6-113
<design>.ipwr.domain File .................................................................................... 6-113
<design>.ignd.domain File ................................................................................... 6-113
switch_dynamic.rpt File ........................................................................................ 6-113
decaps.rpt File ...................................................................................................... 6-114
freqd_ipwr.out File ................................................................................................ 6-114
Pad Current File ........................................................................................................... 6-114
CMM Constraint Violation Reports ...................................................................................... 6-115
Constraint Violation Summary ..................................................................................... 6-115
Dynamic Analysis Constraint Summary ....................................................................... 6-115
Static Analysis Constraint Summary ............................................................................ 6-116
Debugging Using Summary Files in the GUI ...................................................................... 6-117
Output Files from Multiple Vdd/Vss Analysis ...................................................................... 6-117
Other Files .......................................................................................................................... 6-118
Miscellaneous ....................................................................................................... 6-118
Debugging ............................................................................................................ 6-120
Dynamic Simulation Preparation .......................................................................... 6-120
Low Power Ramp Up Analysis ............................................................................. 6-121
Chapter 7 - Fixing and Optimizing Grid and Power Performance
Introduction ......................................................................................................................... 7-122
ANSYS, Inc.
Table of Contents
RedHawk User Manual | v
Manual Power Grid Modification ......................................................................................... 7-123
Changing a Metal Layer or Via Resistivity ................................................................... 7-123
Adding a Single Power/Ground Pad ............................................................................ 7-123
Adding a Set of Power/Ground Pads over a Specified Area ....................................... 7-123
Deleting a Power/Ground Pad ..................................................................................... 7-124
Adding a Via ................................................................................................................ 7-124
Deleting a Via .............................................................................................................. 7-124
Adding One or Multiple Power Straps .......................................................................... 7-124
GUI option for ‘eco add strap’ ...................................................................................... 7-126
Editing/Deleting a Power Strap .................................................................................... 7-127
Adding a Decap Cell .................................................................................................... 7-128
Adding Metal Layers and Vias or Via Arrays ............................................................... 7-130
Undo and Redo ............................................................................................................ 7-131
Automated Grid Optimization and Fixing Procedures ......................................................... 7-131
Fixing and Optimization Flow for Static IR Drop Improvement .................................... 7-131
FAO Procedure for Multiple Vdd Designs .................................................................... 7-132
Grid Optimization ......................................................................................................... 7-132
Mesh Commands ................................................................................................. 7-132
GSR Keywords for Region-based Grid Width Sizing (mesh optimize) ................. 7-133
GSR Keywords for Hot-spot Based Grid Width Fixing (mesh fix) ......................... 7-133
Examples of Grid Optimization .................................................................................... 7-134
Example A - Full Chip Optimization - Relaxing Static IR Drop ............................. 7-134
Example B - Full Chip Grid Fixing - Reducing Static IR Drop ............................... 7-135
Example C - Partial Chip Optimization, Relaxing Static IR Drop .......................... 7-136
Example D - Partial Chip Fixing, Reducing Static IR Drop ................................... 7-138
Example E - Mesh Optimize, -taper option, to reduce regional static IR drop ...... 7-140
Example F - Mesh Fix, -taper option, to reduce hot spot static IR drop ............... 7-141
Automated Fixing and Optimization (FAO) for DvD and Timing ......................................... 7-141
Overview ...................................................................................................................... 7-141
Preparation for Decap FAO ......................................................................................... 7-143
Decap Modification Operations .................................................................................... 7-143
Decoupling Capacitance Modification Commands ............................................... 7-144
Decap Modification Constraints and Interfaces with Other Programs .................. 7-144
GSR Keywords Controlling Decap Modification ................................................... 7-144
Additional Tools for Fixing High Voltage Drop Areas ................................................... 7-145
Supplemental Power Routing with ‘route fix’ ........................................................ 7-145
Cell Moving or Cell Swapping of “Hot Instances” ................................................. 7-145
Examples of FAO for DvD ........................................................................................... 7-148
Example G - Full Chip DvD Reduction - Non-overlap Decap and Grid Fix .......... 7-148
Example H - Full Chip DvD Reduction - Decap Overlap ...................................... 7-150
Saving Design Changes with the ECO Command .............................................................. 7-151
Writing an ECO File ..................................................................................................... 7-151
Reading an ECO File ................................................................................................... 7-151
ECO File Format Definition .......................................................................................... 7-151
ECO File Translation for Use by Place and Route Tools ............................................. 7-152
Fixing and Optimization Command Reference ................................................................... 7-153
Descriptions of Mesh Optimization Commands ........................................................... 7-153
ANSYS, Inc.
Table of Contents
RedHawk User Manual | vi
Descriptions of Decap Modification Commands .......................................................... 7-159
Supplementary Voltage Drop Fixing Commands ......................................................... 7-169
GSR Keywords Supporting FAO Functionality ............................................................ 7-169
Command and GSR Keyword Syntax Conventions .................................................... 7-169
Chapter 8 - Analysis of DvD and Cross-coupling Noise Impacts
on Timing
Introduction ......................................................................................................................... 8-170
Impacts on Timing ....................................................................................................... 8-170
Overview ...................................................................................................................... 8-171
PJX Clock Tree Jitter Analysis ............................................................................. 8-172
Analysis Modes ............................................................................................................ 8-173
Timing Analysis Applications ....................................................................................... 8-173
False Violation Filter ............................................................................................. 8-173
Design Margin Adjustment ................................................................................... 8-173
Methodology Calibration ....................................................................................... 8-173
Case Analysis for Stress Test .............................................................................. 8-174
Silicon Correlation ................................................................................................ 8-174
LEF-SPICE Pin Mapping ...................................................................................... 8-174
PJX Fullchip Clock Tree Jitter Analysis .............................................................................. 8-174
Overview ...................................................................................................................... 8-174
Flow and Interface Description .................................................................................... 8-174
Input Data Preparation and Setup ............................................................................... 8-175
Running PJX Fullchip Jitter Analysis ........................................................................... 8-175
Analyzing Results ........................................................................................................ 8-175
PJX Clock Tree Jitter Sign-Off Analysis .............................................................................. 8-176
Overview ...................................................................................................................... 8-176
Required Inputs for Clock Tree Jitter Sign-Off Analysis .............................................. 8-176
Input Data Preparation ................................................................................................. 8-177
Spice Cell Netlist (.CIR) File ................................................................................. 8-177
SPICE Technology Library Data ........................................................................... 8-177
Additional Timing Constraints ............................................................................... 8-177
Clock Tree Jitter Analysis Setup Procedure ................................................................ 8-178
Edge-to-Edge DDR Clock Jitter Measurements .......................................................... 8-182
Write Mode ........................................................................................................... 8-182
Read Mode ........................................................................................................... 8-183
Running Clock Tree Jitter Sign-Off Analysis from the RedHawk GUI ......................... 8-184
Tools -> Clock Jitter -> Clock Network Summary ............................................ 8-184
Dynamic -> Power -> Calculate/ Import ............................................................ 8-184
Running Clock Tree Jitter Sign-off Analysis in Batch Mode ........................................ 8-184
Setup for Batch Mode Invocation ......................................................................... 8-184
Jitter Analysis Command Line Invocation ............................................................. 8-184
Specifying clock instances .................................................................................... 8-185
Clock Tree Jitter Results .............................................................................................. 8-186
Clock Tree Jitter Report ........................................................................................ 8-186
Clock Tree Browser Display ................................................................................. 8-187
ANSYS, Inc.
Table of Contents
RedHawk User Manual | vii
Clock Tree Jitter Details Report ............................................................................ 8-189
Edge-to-edge DDR Clock Tree Jitter Reports ...................................................... 8-190
Waveform Plots .................................................................................................... 8-191
Clock Jitter Bottleneck Report .............................................................................. 8-192
Jitter Color Map .................................................................................................... 8-194
Text Reports ......................................................................................................... 8-196
Clock Tree Skew Analysis .................................................................................................. 8-197
Overview ...................................................................................................................... 8-197
Required Inputs and Data Preparation ........................................................................ 8-197
Procedure for Clock Tree Skew Analysis .................................................................... 8-197
Running Clock Tree Skew Analysis from the RedHawk GUI ............................... 8-197
Running Clock Tree Skew Analysis in Batch Mode .............................................. 8-197
Clock Tree Skew Analysis Results .............................................................................. 8-198
Clock Tree Skew Summary Report ...................................................................... 8-198
Clock Tree Analysis Configuration File Reference ............................................................. 8-200
Clock Tree Analysis Keywords .................................................................................... 8-200
Input Data Settings ............................................................................................... 8-201
Jitter Analysis ....................................................................................................... 8-202
Signal Waveforms ................................................................................................ 8-203
Simulation Controls .............................................................................................. 8-204
Spice Elements ..................................................................................................... 8-205
Multi-task Controls ................................................................................................ 8-206
Constraint Settings ............................................................................................... 8-208
Application Type Selection ................................................................................... 8-208
RedHawk Data Usage .......................................................................................... 8-209
Report Formats ..................................................................................................... 8-210
Sample Timing Configuration File ................................................................................ 8-210
Chapter 9 - Characterization Using Apache Power Library
Introduction ......................................................................................................................... 9-212
Overview of APL Characterization ..................................................................................... 9-213
Types of Cell Checking and Characterization .............................................................. 9-213
Pre-run Sample Integrity Checking ....................................................................... 9-213
Fast Library Checking ........................................................................................... 9-213
Library (APL-DI) and Design-dependent (APL-DD) Characterization .................. 9-213
Simulator Support ........................................................................................................ 9-214
Characterization Functions .......................................................................................... 9-214
Multiple Machine Batch Management .......................................................................... 9-215
Platforms Supported .................................................................................................... 9-216
APL Working Directory ................................................................................................ 9-216
Cell Characterization Data Preparation .............................................................................. 9-216
Data Requirements ...................................................................................................... 9-216
APL Configuration File Description .............................................................................. 9-217
Required APL Configuration File Keywords ......................................................... 9-218
Required for Library APL (Design-independent) Configuration File Only ............. 9-221
Optional APL Configuration File Keywords .......................................................... 9-224
ANSYS, Inc.
Table of Contents
RedHawk User Manual | viii
Parallel Run Keywords ......................................................................................... 9-238
Custom Cell Characterization Data Preparation ................................................................. 9-240
Input Vector Files ......................................................................................................... 9-241
Running Cell Characterization ............................................................................................ 9-244
Setup for a Design-independent (Library-based) APL Run ......................................... 9-244
Setup for a Design-dependent APL Run ..................................................................... 9-244
Setup for Enhanced Design-Independent Characterization ........................................ 9-245
Running APL Characterization from a UNIX Shell ....................................................... 9-245
Sample APL Invocations .............................................................................................. 9-247
Low Power Design Characterization ............................................................................ 9-248
Characterization for Low Power Designs ............................................................. 9-248
Switch Characterization with aplsw ...................................................................... 9-249
Multi-Job Management in APL ............................................................................................ 9-249
Output Files ......................................................................................................................... 9-250
Overall Process Files ................................................................................................... 9-250
Process Log Files ................................................................................................. 9-250
Error and Warning Files ........................................................................................ 9-250
Status Log File ...................................................................................................... 9-250
Results Files ......................................................................................................... 9-251
Individual Cell Characterization Files ........................................................................... 9-251
Characterization Results ...................................................................................... 9-251
Cell Log Files ........................................................................................................ 9-252
APL Results Checking and Processing ....................................................................... 9-252
Keywords for Checking Limits .............................................................................. 9-253
Resistance, Capacitance, and Leakage Histogram .............................................. 9-255
Reports of Cells with no APL Data or samples ............................................................ 9-255
Importing and Merging Characterization Data Files in RedHawk ....................................... 9-256
Importing APL Files ..................................................................................................... 9-256
Merging APL Result Files ............................................................................................ 9-257
aplccs (CCS2APL) Library Characterization ....................................................................... 9-258
Introduction and Syntax ............................................................................................... 9-258
APLCCS Configuration File ......................................................................................... 9-259
Importing the CCS Lib Directly .................................................................................... 9-259
I/O Cell Characterization ..................................................................................................... 9-259
I/O Cell Characterization Procedure ............................................................................ 9-259
Additional Keywords for I/O Cells (Optional) ............................................................... 9-261
Characterization of I/O Cells ........................................................................................ 9-262
Memory and IP Characterization ........................................................................................ 9-262
Sim2iprof Switching Current Characterization ............................................................. 9-262
ACE Decap and ESR Characterization ....................................................................... 9-262
Identifying tied-off devices as decaps ................................................................... 9-263
Identifying special pins for PWCap characterization ............................................ 9-263
ACE Configuration File ......................................................................................... 9-263
Running ACE Characterization ............................................................................. 9-270
Output Result Files ............................................................................................... 9-270
AVM Datasheet Characterization ................................................................................ 9-270
Running AVM standalone ..................................................................................... 9-271
ANSYS, Inc.
Table of Contents
RedHawk User Manual | ix
AVM Configuration File ......................................................................................... 9-271
Running AVM ....................................................................................................... 9-278
AVM Outputs ........................................................................................................ 9-278
Troubleshooting APL Problems .......................................................................................... 9-278
Checking the Configuration File ................................................................................... 9-278
Common Problems ...................................................................................................... 9-278
Debugging Command Line APL Errors ....................................................................... 9-279
Sample APL Configuration File ........................................................................................... 9-279
Chapter 10 - Memory and I/O Modeling
Introduction ....................................................................................................................... 10-282
Memory and I/O Modeling Methodology ........................................................................... 10-284
Black-box Modeling ................................................................................................... 10-284
Pin and Grid-Based Abstractions ............................................................................... 10-284
Detailed Memory Block Modeling ..................................................................................... 10-285
Extraction ................................................................................................................... 10-285
GDS2DEF/ GDS2RH Configuration File for Memories .............................................. 10-288
Required GDS2DEF/ GDS2RH keywords .......................................................... 10-288
Optional GDS2DEF/GDS2RH keywords: ........................................................... 10-288
gds2def -m/ gds2rh -m Configuration File Syntax .............................................. 10-289
Current Profile Generation ......................................................................................... 10-290
Static Analysis .................................................................................................... 10-290
Dynamic Analysis ............................................................................................... 10-290
Detailed I/O Cell Modeling ................................................................................................ 10-291
Extraction ................................................................................................................... 10-291
GDS2DEF/GDS2RH Configuration File for I/Os ........................................................ 10-291
Required GDS2DEF/GDS2RH Keywords .......................................................... 10-292
Optional GDS2DEF/GDS2RH Keywords for I/Os ............................................... 10-292
Current Profile Generation ......................................................................................... 10-292
Static Analysis .................................................................................................... 10-292
Dynamic Analysis ............................................................................................... 10-292
Results and Analysis Including I/Os .......................................................................... 10-293
Chapter 11 - Hierarchical Cell Modeling
Introduction ....................................................................................................................... 11-296
Extracted Reusable View (ERV) Models .......................................................................... 11-296
Overview .................................................................................................................... 11-296
Input Files .................................................................................................................. 11-297
Chapter 12 - Package and Board Analysis
Introduction ....................................................................................................................... 12-299
Package and Board Models .............................................................................................. 12-299
Simple Package RLC Model ...................................................................................... 12-299
Distributed RLCK Package and Board Subcircuit Model ........................................... 12-300
Support for Package K-parameters .................................................................... 12-302
ANSYS, Inc.
Table of Contents
RedHawk User Manual | x
Linear Current- and Voltage-Controlled Source Models ............................................ 12-303
Linear Voltage-Controlled Voltage Source (E ) .................................................. 12-304
Linear Current-Controlled Current Source (F) .................................................... 12-304
Linear Voltage-Controlled Current Source (G ) .................................................. 12-304
Linear Current-Controlled Voltage Source (H) ................................................... 12-304
S-Parameter Package and Board Modeling for Static Analysis ................................. 12-305
S-Parameter Package and Board Modeling for Dynamic Analysis ............................ 12-305
Modeling Methodology ....................................................................................... 12-305
Connecting S-parameter models in the REDHAWK_PKG subcircuit ................. 12-306
Specifying S-parameter models in RedHawk ..................................................... 12-308
Saving/reuse of rational approximation and passivity enforcement results ........ 12-309
Recommendations and limitations in using S-parameter models ....................... 12-309
Usage summary and example ............................................................................ 12-310
Recommendations for best S-parameter model extraction ................................ 12-312
Analysis of the Simulation Results ..................................................................... 12-312
Mapping Package Port Names to Die Pad Names in the PLOC File ................................ 12-313
Chip-Die Mapping Using Package Compiler ..................................................................... 12-313
Overview ............................................................................................................. 12-313
Inputs .................................................................................................................. 12-314
Command Syntax ............................................................................................... 12-315
Outputs ............................................................................................................... 12-316
Known Restrictions ........................................................................................................... 12-317
Chapter 13 - Low Power Design Analysis
Introduction ....................................................................................................................... 13-318
Analysis of Multiple Vdd/Vss Domain Designs ................................................................. 13-318
Analysis of Power Gating Designs .................................................................................... 13-321
Types of Power Switches .......................................................................................... 13-322
Low Power Analysis Switch Modeling ....................................................................... 13-322
ON State ............................................................................................................. 13-323
OFF State ........................................................................................................... 13-324
PowerUp and PowerDown States ...................................................................... 13-325
Control of Power Gating Switches ............................................................................. 13-326
Checking Switches with Two Enable Pins .......................................................... 13-326
Characterization and Implementation ....................................................................... 13-327
Switch Configuration Files .................................................................................. 13-327
Switch Model Generation .................................................................................. 13-331
Defining Block Switching Status with the GSC File ................................................... 13-332
Obtaining STA Timing Window Data ......................................................................... 13-332
Importing Switches into RedHawk ............................................................................. 13-332
Adding and Deleting Power Switches ................................................................. 13-333
Reporting on Switches in the Design .................................................................. 13-333
Design Characterization for Power-up Conditions ..................................................... 13-333
Running RedHawk Low Power Analysis .................................................................... 13-334
ON State Analysis .............................................................................................. 13-334
Ramp-up Analysis .............................................................................................. 13-334
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xi
Running in Mixed Mode ............................................................................................. 13-335
Power Gating Results ................................................................................................ 13-335
switch_static. rpt File .......................................................................................... 13-335
switch_dynamic.rpt File ...................................................................................... 13-335
charge_switch.rpt File ......................................................................................... 13-335
Analysis of IP Block Designs with Switched Power .......................................................... 13-336
Introduction ................................................................................................................ 13-336
Data Requirements ............................................................................................. 13-337
Flow Overview .................................................................................................... 13-337
GDS2DEF Processing ............................................................................................... 13-339
Domain Text Labels Available ............................................................................ 13-339
No Domain Text Labels Available ...................................................................... 13-339
Switch Subcircuit Extraction ...................................................................................... 13-341
IP Switch Characterization with the aplsw Utility ................................................ 13-342
ACE Characterization ......................................................................................... 13-342
Running RedHawk with Switch IP models .......................................................... 13-342
Analysis of Switched RAM Designs .................................................................................. 13-343
Introduction ................................................................................................................ 13-343
Types of Switched RAM Supported ........................................................................... 13-343
Overview of Switched RAM Analysis ......................................................................... 13-344
Model Generation ...................................................................................................... 13-346
GDS Data Preparation ........................................................................................ 13-346
APLSW Data Preparation .......................................................................................... 13-352
On-state Analysis - Static IR and DvD Conditions ..................................................... 13-352
GSR Keyword Settings - Static IR Analysis ........................................................ 13-353
GSR Keyword Settings - DvD Analysis .............................................................. 13-354
Ramp-up Analysis ...................................................................................................... 13-355
GSR Keyword Settings - Ramp-up Analysis ...................................................... 13-356
Switched RAM Analysis Timing Control Settings ............................................... 13-358
Analysis of LDO Low Power Designs ............................................................................... 13-360
Overview .................................................................................................................... 13-360
LDO design modeling ................................................................................................ 13-360
Controlling LDO switching state using GSC file ......................................................... 13-362
Outputs generated in LDO-based analysis ................................................................ 13-363
LDO Modeling with APLDO ....................................................................................... 13-363
LDO DC model example configuration file ......................................................... 13-364
APLDO example configuration file for load regulation dynamic model ............... 13-365
Generating the DC LDO model .................................................................................. 13-367
Testing LDO models .................................................................................................. 13-367
Other practical LDO applications ............................................................................... 13-368
Analysis of Gated Clock Designs ...................................................................................... 13-368
Chapter 14 - Chip Power Modeling (CPM)
Introduction ....................................................................................................................... 14-369
Design Flow ...................................................................................................................... 14-370
RedHawk Modeling of Chip Power Delivery Network ...................................................... 14-371
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xii
Modeling Choices Based on Number of Pads ........................................................... 14-371
CPM for Flip Chip Designs ................................................................................. 14-371
CPM for Wirebond Designs ................................................................................ 14-372
3DIC CPM Generation ........................................................................................ 14-372
Modeling Choices Based on Analysis Speed and Accuracy ..................................... 14-373
High speed modeling .......................................................................................... 14-373
High Accuracy Modeling ..................................................................................... 14-373
ESD- aware CPM Models ................................................................................... 14-374
CPM Simulation Procedures ............................................................................................. 14-375
Initial Setup and Preparation ..................................................................................... 14-375
Running CPM ............................................................................................................ 14-375
Basic power integrity analysis ............................................................................ 14-379
EMI modeling ...................................................................................................... 14-380
User-specified Grouping for Port Creation ......................................................... 14-380
Modeling leakage resistance using arbitrary partitioning .................................... 14-381
iCPM- Internal Node Probing .............................................................................. 14-382
Resonance frequency-aware mode .................................................................... 14-382
Power Transient Mode (variable power) ............................................................. 14-383
User-configurable mode ..................................................................................... 14-385
CPM LDO analysis support ................................................................................ 14-387
CPM Outputs ............................................................................................................. 14-388
CPM Model Files ................................................................................................ 14-389
get_cdie.sp File .................................................................................................. 14-389
*.cdie File ............................................................................................................ 14-390
Using the Chip Power Model ..................................................................................... 14-391
Differential Voltage Waveforms .......................................................................... 14-392
Validating the Model ......................................................................................................... 14-392
Chapter 15 - Reliability and EM Analysis
Introduction ....................................................................................................................... 15-394
Temperature Setting for Power EM Calculation ................................................................ 15-395
RedHawk Methodology for Static Power EM Analysis ...................................................... 15-396
Setting Up EM Limits ................................................................................................. 15-396
Running Power EM Analysis ..................................................................................... 15-398
Analyzing Static EM Analysis Results ....................................................................... 15-398
Methodology for Dynamic Power EM Analysis ................................................................. 15-399
Setting Up EM Limits ................................................................................................. 15-399
Analyzing Dynamic Power EM Violations .................................................................. 15-400
Current direction and EM violations .................................................................... 15-402
Fixing Power EM Violations ....................................................................................... 15-403
Methodology for Signal EM Analysis ................................................................................ 15-403
Input Data Requirements ........................................................................................... 15-404
Setup for Signal EM Analysis .................................................................................... 15-404
Waveform Specifications .................................................................................... 15-404
Wire Merging ...................................................................................................... 15-405
EM Limits ............................................................................................................ 15-405
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xiii
Custom Current File ........................................................................................... 15-406
Hierarchical analysis ........................................................................................... 15-406
Running Signal EM Analysis ...................................................................................... 15-407
Using the RedHawk GUI in Signal EM ...................................................................... 15-408
Defining Equipotential Regions .................................................................................. 15-408
Analyzing Results ...................................................................................................... 15-408
Debugging Tips .......................................................................................................... 15-409
Chapter 16 - Pathfinder™ ESD Analysis
Introduction - The ESD Problem ....................................................................................... 16-410
ESD Analysis .................................................................................................................... 16-411
Overview .................................................................................................................... 16-411
Clamp Cell Definition ................................................................................................. 16-412
Clamp Files ......................................................................................................... 16-412
Clamp DB Creation ............................................................................................. 16-417
SPT tracing from clamp nodes ........................................................................... 16-417
ESD Rules Files ......................................................................................................... 16-418
Defining Groups of Nets ..................................................................................... 16-418
Reducing Design Size for Improved ESD Analysis ................................................... 16-418
Topology and Connectivity Checking of Bumps and Clamps ........................................... 16-419
Layout Resistance Checking of Bumps and Clamps ........................................................ 16-420
Overview .................................................................................................................... 16-420
Bump-to-Bump (BUMP2BUMP, or B2B) ............................................................ 16-420
Bump-to-Clamp (BUMP2CLAMP, or B2C) ......................................................... 16-421
Bump-to-Instance (B2I) ...................................................................................... 16-421
Clamp-to-Clamp (CLAMP2CLAMP, or C2C) ...................................................... 16-421
Clamp-to-Inst (CLAMP2INST or C2I) ................................................................. 16-421
Clamp-to-Macro (CLAMP2MACRO or C2M) ...................................................... 16-422
Cross-domain DRIVER2RECEIVER (D2R)-to-Bump ......................................... 16-422
Including Package Resistance ................................................................................... 16-422
Data Flow ................................................................................................................... 16-422
Description of Inputs .................................................................................................. 16-423
Inputs for 3D-IC Designs .................................................................................... 16-424
Resistance Checking for B2B, B2C, and C2C Rules ................................................. 16-425
Rules File Syntax for Types B2B, B2C, and C2C ............................................... 16-426
Sample Rules File .............................................................................................. 16-432
Resistance Rule Checking Results .................................................................... 16-433
Resistance Checking for CLAMP2INST (C2I) and CLAMP2MACRO (C2M) Rules .. 16-433
Rules File Syntax for Types C2I and C2M ......................................................... 16-433
Examples of Rule Checking ............................................................................... 16-436
Connectivity Checking ........................................................................................ 16-438
Combined Rules and Clamp Cell Pin Location File ............................................ 16-440
Node creation on Clamp Pins ............................................................................ 16-440
Sample Invocation .............................................................................................. 16-440
Resistance Checking for BUMP2INSTANCE Rules .................................................. 16-441
Rule File Syntax for Types B2I ........................................................................... 16-441
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xiv
Resistance Checking from Bumps to Cross-domain Driver-Receivers ..................... 16-443
Introduction ......................................................................................................... 16-443
Cross-domain Resistance Check Rule Keywords .............................................. 16-444
Multiple-clamp Zap R Checks ............................................................................. 16-445
ESD Resistance Checking Reports ........................................................................... 16-446
Report esdcheck command ................................................................................ 16-446
Resistance Checking Output Reports ................................................................ 16-447
B2I results reports .............................................................................................. 16-447
Clamp Info Reports ............................................................................................. 16-448
Pass/Fail Reports ............................................................................................... 16-449
ESD Info Reports ................................................................................................ 16-453
ESD Summary Reports ...................................................................................... 16-454
Displaying Resistance Checking Results in the GUI ................................................. 16-454
Special Resistance Calculations for ESD Analysis .................................................... 16-462
Current Density Checking ................................................................................................. 16-464
Mode 1 Rules Files - all clamp paths ......................................................................... 16-464
Rules Files - Specified clamp paths ........................................................................... 16-468
Bump-to-Clamp and Clamp-to-Clamp Current Density Checking ..................................... 16-469
Rules File ................................................................................................................... 16-470
CD and arc-based resistance checks include clamp resistance ................................ 16-471
Point-to-point current density checks ......................................................................... 16-472
Viewing Current Density Checking Results ...................................................................... 16-473
ESD CD Report Command ........................................................................................ 16-473
Results in compressed mode ............................................................................. 16-475
ESD-CD report esd_summary.rpt .............................................................................. 16-475
ESD Current Density Reports for Pads ..................................................................... 16-476
ESD EM Report for ESD-CD ..................................................................................... 16-476
Displaying Current Density Checking Results in the GUI .......................................... 16-477
Peak and Differential Voltage Maps ................................................................... 16-477
Current Maps ...................................................................................................... 16-478
Wire and Via Voltage Maps from Current Density Checks ................................. 16-479
General Rule File Inclusions and Exclusions .................................................................... 16-480
Clamp Element Exclusions ........................................................................................ 16-480
Chapter 17 - Memory and Mixed Signal
Design Analysis
Introduction ....................................................................................................................... 17-481
Chapter 18 - Chip Thermal Modeling and Analysis
Introduction ....................................................................................................................... 18-482
CTM-Based Thermal Analysis Flow Overview .................................................................. 18-484
Data Preparation for CTM Generation .............................................................................. 18-485
APL Library Characterization ..................................................................................... 18-485
GSR Keyword Settings .............................................................................................. 18-487
CTM Generation ............................................................................................................... 18-488
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xv
Chapter 19 - Timing File Creation Using Apache Timing Engine
(ATE)
Introduction ....................................................................................................................... 19-490
Overview ........................................................................................................................... 19-490
PJX - Fast Fullchip Clock Jitter Analysis ............................................................ 19-491
Setting up ATE .................................................................................................................. 19-491
Configuration File ....................................................................................................... 19-492
Command File ........................................................................................................... 19-493
PJX flow uses STA voltage as nominal and control on threshold voltage ................. 19-494
Handling Ideal Clocks ................................................................................................ 19-494
Multi-threading ........................................................................................................... 19-495
Special ATE Variables ............................................................................................... 19-495
getSTA Command Options ........................................................................................ 19-496
Invoking ATE ..................................................................................................................... 19-497
ATE Command Line Options ..................................................................................... 19-497
Output Files ....................................................................................................................... 19-497
Specifying the STA file in RedHawk ................................................................................. 19-498
ATE Validation .................................................................................................................. 19-498
Ensuring Correct Creation and Use of the Timing File .............................................. 19-498
Is the setup OK? ................................................................................................. 19-499
Did ATE run properly? ........................................................................................ 19-499
Is the STA file good? .......................................................................................... 19-500
Contacting Apache Support ................................................................................ 19-501
Chapter 20 - Chip-Package Analysis (CPA)
Introduction ....................................................................................................................... 20-502
Co-simulation Flows .................................................................................................. 20-503
Integrated Chip Package Analysis and Chip Thermal Modeling ....................................... 20-503
CTM Viewer ............................................................................................................... 20-505
Temperature-Aware CTM .......................................................................................... 20-505
Configuration for Thermal Analysis ............................................................................ 20-506
Configuration and Results .................................................................................. 20-506
View Result buttons ............................................................................................ 20-506
Visible option for Vias, Bumps and Balls ............................................................ 20-506
Zoom to a pin ...................................................................................................... 20-507
Integrated Chip and Package GUI ............................................................................. 20-507
Chip and Pkg Auto-Connection and Pin Grouping .................................................... 20-508
DC IR Co-simulation ......................................................................................................... 20-508
AC Hotspot Co-simulation ................................................................................................. 20-510
HTML-based Reporting ..................................................................................................... 20-514
Appendix A - Installation Procedure
Introduction .........................................................................................................................A-515
Downloading RedHawk Software .......................................................................................A-515
Program Installation ............................................................................................................A-515
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xvi
RedHawk Operating System/Platform Support ...........................................................A-516
Setting Up the Apache License ...........................................................................................A-516
Setting Up the RedHawk Environment ...............................................................................A-517
License File and Library Directory Setup .....................................................................A-517
Binary Setup ................................................................................................................A-517
Platform-Specific Binaries ....................................................................................A-518
Platform-Independent Binaries .............................................................................A-518
Invocation ....................................................................................................................A-518
Appendix C - File Definitions
Introduction ........................................................................................................................ C-520
RedHawk Input Files ................................................................................................... C-520
RedHawk Output Files ................................................................................................ C-520
Keyword Syntax Conventions ..................................................................................... C-520
Apache Technology File (*.tech) ....................................................................................... C-521
Encrypting and Decrypting a Tech File ....................................................................... C-521
Full File Encryption .............................................................................................. C-521
Partial File Encryption .......................................................................................... C-522
Technology File Keywords .......................................................................................... C-522
Global Switching Configuration (GSC) File ........................................................................ C-548
Global System Requirements File (*.gsr) .......................................................................... C-550
GSR File Keywords .................................................................................................... C-550
Input Data Keywords ........................................................................................... C-550
Parameter Keywords ........................................................................................... C-587
Custom Cell Modeling Keywords ......................................................................... C-596
Power calculation keywords ................................................................................ C-599
Electromigration Keywords .................................................................................. C-630
Extraction and Netlisting Keywords ..................................................................... C-648
Characterization Keywords .................................................................................. C-665
Timing Keywords ................................................................................................. C-668
Simulation Keywords ........................................................................................... C-672
FAO General Keywords ....................................................................................... C-684
Grid Fixing and Optimization Keywords .............................................................. C-687
Decap Optimization Keywords ............................................................................ C-691
Low Power Design Keywords .............................................................................. C-695
ESD Keywords .................................................................................................... C-701
Name Mapping Keywords ................................................................................... C-705
Warning and Error Message Keywords ............................................................... C-706
Ignore Function Keywords ................................................................................... C-707
GSR Macro Keywords ......................................................................................... C-714
Pad, Power/Ground and I/O Definition Files ...................................................................... C-714
Unified Pad Input File Format ..................................................................................... C-714
Individual Pad File Specification ................................................................................. C-718
Pad Cellname File (*.pcell) .................................................................................. C-718
Pad Instance Name File (*.pad) .......................................................................... C-718
Pad Location File (*.ploc) .................................................................................... C-719
Pad PSS File ....................................................................................................... C-720
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xvii
Library Technology Files .................................................................................................... C-721
Design Netlist (DEF) Files .................................................................................................. C-721
Synopsys Library Files ....................................................................................................... C-721
Custom LIB File Syntax ....................................................................................... C-721
Timing Data File ................................................................................................................. C-724
STA Compact Format Timing File ....................................................................... C-724
Legacy Format Timing File .................................................................................. C-726
Result Files ........................................................................................................................ C-727
Appendix D - Command and GUI Reference
Introduction ........................................................................................................................ D-728
Invoking RedHawk ............................................................................................................. D-728
Terminating Processes ............................................................................................... D-729
TCL / Script Commands ..................................................................................................... D-729
TCL Syntax Conventions ............................................................................................ D-729
TCL Command Summary ........................................................................................... D-729
Running RedHawk in the TCL Script Mode ................................................................ D-790
Starting the GUI at a designated step in batch mode .......................................... D-790
TCL Script Execution Examples ................................................................................. D-791
Sample TCL Scripts .................................................................................................... D-792
Static IR Drop Analysis Example ......................................................................... D-792
.................................................................................................. perform extraction -power D-792
Dynamic Voltage Drop Analysis Example ........................................................... D-793
Automated Color Map Generation ....................................................................... D-793
RedHawk Graphic User Interface Description ................................................................... D-794
Mouse Function .......................................................................................................... D-794
Left Mouse Button Object Selection, Highlighting and Query .............................. D-795
Right Mouse Button Zoom ................................................................................... D-795
Mouse Wheel Zooming ........................................................................................ D-796
Using GUI Dialog Box Settings in RedHawk .............................................................. D-796
GUI Control Buttons .................................................................................................... D-796
‘View’ buttons ...................................................................................................... D-796
Configuration’ buttons .......................................................................................... D-797
‘View Results’ buttons ......................................................................................... D-799
‘Query’ buttons .................................................................................................... D-801
Coordinates readout area .................................................................................... D-803
Full design view area ........................................................................................... D-803
User-defined Shortcuts for GUI Buttons .............................................................. D-803
GUI Menu ................................................................................................................... D-804
File Menu ............................................................................................................. D-804
File -> Import Design Data ................................................................................ D-804
File -> Import Database ..................................................................................... D-804
File -> Export Database ..................................................................................... D-804
File -> Import ESD DB ....................................................................................... D-804
File -> Export ESD DB ....................................................................................... D-804
File -> Import ECO ............................................................................................. D-804
File -> Export ECO ............................................................................................. D-804
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xviii
File -> Import GUI Config .................................................................................. D-804
File -> Export GUI Config .................................................................................. D-804
File -> Playback ................................................................................................. D-804
File -> Exit .......................................................................................................... D-805
Edit Menu ............................................................................................................ D-805
Edit -> Undo ....................................................................................................... D-805
Edit -> Redo ....................................................................................................... D-805
Edit -> Add Pad .................................................................................................. D-805
Edit -> Delete Pad .............................................................................................. D-805
Edit -> Add Power Strap ................................................................................... D-805
Edit -> Edit Power Strap .................................................................................... D-805
Edit -> Add Via ................................................................................................... D-805
Edit -> Delete Via ............................................................................................... D-805
Edit -> Add Decap Cell ...................................................................................... D-805
Edit -> Delete Decap Cell .................................................................................. D-806
Edit -> Edit Probe .............................................................................................. D-806
Edit -> ESD Clamp ECO .................................................................................... D-806
Edit -> Chip Partition ......................................................................................... D-806
Edit -> Ruler -> ................................................................................................... D-806
Edit -> Single Key .............................................................................................. D-806
View Menu ........................................................................................................... D-806
View -> Chip Layout Map .................................................................................. D-806
View -> Nets ....................................................................................................... D-807
View -> Connectivity -> ..................................................................................... D-807
View -> Technology Layers ............................................................................... D-809
View -> Hierarchy Level .................................................................................... D-809
View -> EM Mode ............................................................................................... D-809
View -> Map Configuration -> ........................................................................... D-809
View -> Power Maps -> ...................................................................................... D-812
View -> Resistance Maps .................................................................................. D-812
View -> Voltage Drop Maps -> ........................................................................... D-814
View -> Current Maps -> .................................................................................... D-815
View -> Electromigration Maps ........................................................................ D-816
View -> Transistor Pin Maps -> ......................................................................... D-816
View -> Dynamic Instance DvD -> .................................................................... D-817
View -> Decap Maps -> ...................................................................................... D-818
View -> ESD Resistance Lists -> ...................................................................... D-819
View -> ESD Clamp Lists .................................................................................. D-820
View -> ESD Resistance Maps -> ..................................................................... D-820
View -> ESD Current Density-> ........................................................................ D-821
View -> Impact on Timing Maps -> ................................................................... D-823
View -> Clock Jitter Maps (PJX) ....................................................................... D-823
View -> Clock Jitter Maps -> ............................................................................. D-824
View -> STA Critical Path .................................................................................. D-824
Tools Menu .......................................................................................................... D-824
Tools -> Lowpower -> ........................................................................................ D-824
Tools -> Signal EM -> ........................................................................................ D-825
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xix
Tools -> Chip Power Model -> .......................................................................... D-825
Tools -> PJX Timing Paths ( was Fullchip Critical Paths PPX ) .................... D-826
Tools -> Clock Jitter -> ...................................................................................... D-826
Tools -> PathFinder SOC .................................................................................. D-827
Tools -> Effective Resistance Computation .................................................... D-830
Static Menu .......................................................................................................... D-830
Static -> Power -> .............................................................................................. D-830
Static -> Network Extraction ............................................................................. D-831
Static -> Pad Wirebond Package Constraints ................................................. D-831
Static -> Static Voltage Drop Analysis ............................................................. D-831
Static -> EM Check ............................................................................................ D-831
Dynamic Menu ..................................................................................................... D-831
Dynamic -> Power -> ......................................................................................... D-832
Dynamic -> Network Extraction ....................................................................... D-832
Dynamic -> Pad Wirebond Package Constraints ............................................ D-832
Dynamic -> Dynamic Voltage Drop Analysis .................................................. D-832
Dynamic -> Vectorless Only Analysis ............................................................. D-832
Dynamic -> VCD Only Analysis ........................................................................ D-832
Dynamic -> EM Check ....................................................................................... D-832
Timing Menu ........................................................................................................ D-832
Timing -> Sign-off Clock Tree -> ...................................................................... D-832
Timing -> Sign-off Critical Path -> .................................................................... D-832
Timing -> Generate MSDF ................................................................................. D-833
Results Menu ....................................................................................................... D-833
Results -> Log Message Viewer ....................................................................... D-833
Results -> List of Effective Grid Resistances ................................................. D-834
Results -> List of Effective Instance Resistances .......................................... D-834
Results -> List of Worst EM .............................................................................. D-834
Results -> List of Worst IR for Wires and Vias ................................................ D-834
Results -> List of Highest Power Instances .................................................... D-834
Results -> List of Metal-Via EM Ratio ............................................................... D-834
Results -> List of Worst IR Instances (Static) ................................................. D-834
Results -> List of Worst Instance DVD ............................................................ D-834
Results -> List of Worst Transistor Pin Voltages ............................................ D-835
Results -> Analysis Histograms ....................................................................... D-835
Results -> Movie -> ............................................................................................ D-835
Explorer Menu ..................................................................................................... D-836
Explorer -> Generate ......................................................................................... D-836
Explorer -> View Results ................................................................................... D-836
Windows Menu .................................................................................................... D-836
Windows -> Multiple Pages .............................................................................. D-836
Windows -> Preferences ................................................................................... D-838
Windows -> Detach View Bar ........................................................................... D-840
Windows -> Detach Message Window ............................................................. D-840
Help Menu ........................................................................................................... D-840
Help -> About ..................................................................................................... D-840
Help -> Manual ................................................................................................... D-840
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xx
Defining Bindkey Functions ........................................................................................ D-840
Multiple-key Functions ......................................................................................... D-840
Direct Keybinding ................................................................................................ D-841
Single-key Functions ........................................................................................... D-841
Appendix E - Utility Programs
Introduction .........................................................................................................................E-843
vcdtrans ..............................................................................................................................E-843
vcdscan ...............................................................................................................................E-844
fsdbtrans .............................................................................................................................E-845
ircx2tech ..............................................................................................................................E-845
rhtech ..................................................................................................................................E-845
gds2rh/gds2def ...................................................................................................................E-848
Comparison of GDS2DEF and GDS2RH Use .............................................................E-849
Distributed Processing of GDS2RH Runs ...................................................................E-850
Creating the GDS2RH/GDS2DEF Configuration File .....................................................E-851
GDS2RH Sub-configuration Files .........................................................................E-852
GDSII Files Keywords ..........................................................................................E-852
Top Cell Definition Keywords ...............................................................................E-853
Nets Definition Keywords .....................................................................................E-855
Layer Map Definition Keywords ............................................................................E-860
Input LEF Keywords .............................................................................................E-861
Geometry Extraction Keywords ............................................................................E-863
Selective Cell Hierarchy Handling Keywords .......................................................E-866
Auto Pad Location Generation Keywords .............................................................E-869
DSPF/SPEF-based standard cell flow Keywords .................................................E-871
Automated Switch Cell Handling Keywords .........................................................E-872
Other Keywords ....................................................................................................E-875
Running gds2rh or gds2def .........................................................................................E-880
Special Applications .....................................................................................................E-880
Boundary Layer Definition ....................................................................................E-880
Specific metal resistor support using the marker layer .........................................E-881
Modeling through-via support ...............................................................................E-881
Bump Via Support ................................................................................................E-881
DSPF/SPEF file-based GDS2DEF Standard Cell Flow ........................................E-882
Select Cell Hierarchy Modeling ............................................................................E-886
Clamp Cell identification based on marker layer ..................................................E-887
gds2rh -m and gds2def -m ..................................................................................................E-888
Pin-based Memory Modeling .......................................................................................E-888
Creating the gds2rh -m/ gds2def -m Characterization Configuration File ....................E-889
gds2rh -m/ gds2def -m Characterization Configuration File Keywords ................E-889
Spice Netlist with X,Y Locations ...........................................................................E-891
Spice Netlist without X,Y Locations ......................................................................E-892
Defining Memories in RedHawk ..................................................................................E-893
Running gds2rh -m and gds2def -m ............................................................................E-894
pt2timing .............................................................................................................................E-894
sim2iprof .............................................................................................................................E-895
ANSYS, Inc.
Table of Contents
RedHawk User Manual | xxi
Running sim2iprof ........................................................................................................E-896
Configuration File Example ..................................................................................E-907
Output ..........................................................................................................................E-909
aplreader .............................................................................................................................E-909
Running aplreader .......................................................................................................E-909
aplreader Output ..........................................................................................................E-909
Current Outputs ....................................................................................................E-909
Equivalent Device Capacitance and Resistance Outputs ....................................E-911
Piecewise Linear Capacitance and Resistance Outputs ......................................E-911
aplcdev2pwc .......................................................................................................................E-912
aplcdev2pwc Configuration File ...................................................................................E-913
aplchk ..................................................................................................................................E-913
clampviewer ........................................................................................................................E-913
Appendix F - Third-Party Software Licenses
Introduction .........................................................................................................................F-915
gnuplot and gnuplot_x11 .....................................................................................................F-915
xgraph .................................................................................................................................F-916
mpiexec ...............................................................................................................................F-916
Tcl/Tk 8.4 and tclline ...........................................................................................................F-918
strftime.c .............................................................................................................................F-919
compat, dlfcn.h, unix/tclLoadAix.c .......................................................................................F-920
itcl3.2 ...................................................................................................................................F-920
gifsicle, rlfe, libreadline ........................................................................................................F-921
UMFPACK ..........................................................................................................................F-925
libQt3Support, libQtCore, libQtGui, libQtNetwork, libQtScript, libQtSql, libQtTest, libQtXml, libart_lgpl, ld-linux, lg2c, libgd, libgdk-1.2, libgdk_imlib, libgdk_pixbuf, libglib-1.2, libgmodule-1.2,
libgnome, libgnomesupport, libgnomeui, libgtk-1.2, libpixbufloader-gif, libpixbufloader-xpm F-926
libstdc++ ..............................................................................................................................F-933
GNU .............................................................................................................................F-933
GCC Runtime Library Exception ..................................................................................F-942
Miscellaneous .....................................................................................................................F-943
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxiii
ALPHABETIC LIST OF GSR KEYWORDS
ACCURATE_METAL_DENSITY ...................................................................... C-645
ADD_PLOC_FROM_DEF ................................................................................ C-553
ADD_PLOC_FROM_TOP_DEF ...................................................................... C-554
ALLOW_SEPARATED_METAL_PSEUDO_VIAS ........................................... C-645
ANALYZE_NETS ............................................................................................. C-628
ANALYZE_NETS_FILE ................................................................................... C-628
APACHE_DB_OVERWRITE ........................................................................... C-588
APACHE_FILES .............................................................................................. C-588
APL_FILES ...................................................................................................... C-662
APL_INTERPOLATION_METHOD................................................................... C-662
APL_MODE ..................................................................................................... C-601
ATE_CONSTRAINT_FILES ............................................................................. C-664
ATE_USE_REDHAWK_DB ............................................................................. C-665
AUTO_INTERNAL_NET_EXTRACT ............................................................... C-645
AUTO_PAD_CONNECTION_LAYERS ........................................................... C-554
BIASPIN_CONFIG_FILE ................................................................................. C-601
BLOCK_INSTANCE_POWER_FILE ........................................................... C-668
BLOCK_PAR ................................................................................................... C-668
BLOCK_POWER_ASSIGNMENT ................................................................... C-555
BLOCK_POWER_ASSIGNMENT_FILE .......................................................... C-560
BLOCK_POWER_FOR_SCALING .................................................................. C-601
BLOCK_POWER_FOR_SCALING_FILES ...................................................... C-603
BLOCK_POWER_MASTER_CELL ................................................................. C-561
BLOCK_POWERUP_FILES ............................................................................ C-691
BLOCK_SAIF_FILES ....................................................................................... C-605
BLOCK_STA_FILES ........................................................................................ C-562
BLOCK_TOGGLE_FILES ................................................................................ C-603
BLOCK_TOGGLE_RATE ................................................................................ C-604
BLOCK_TOGGLE_RATE_FILES .................................................................... C-604
BLOCK_VCD_FILES ....................................................................................... C-563
BOUND_SLEW_TO_MAX_TRANSITION ....................................................... C-665
BPA_BY_CURRENT ....................................................................................... C-564
BPA_BY_LAYER ............................................................................................. C-565
BPA_CONN_DISTANCE ................................................................................. C-565
BPA_CONN_MARGIN ..................................................................................... C-565
BPA_CURRENT_DENSITY ............................................................................. C-565
BRIDGE_WIRE_CONNECTION....................................................................... C-638
BUS_DELIMITER ............................................................................................ C-700
BUS_DELIMITER_STA ................................................................................... C-701
CACHE_DIRECTORY ..................................................................................... C-588
CACHE_MODE ................................................................................................ C-588
CAP_LIMIT ...................................................................................................... C-687
CELL_CURRENT_DIST_FILE ......................................................................... C-646
CELL_GEOMETRIES_AS_MFILL ................................................................... C-565
CELL_PIN_FILE .............................................................................................. C-566
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxiv
CELL_PIN_FILE .............................................................................................. C-646
CELL_RC_FILES ............................................................................................. C-605
CELL_TOGGLE_RATE ................................................................................... C-606
CELL_TOGGLE_RATE_FILE .......................................................................... C-606
CELL_TYPE_FILE ........................................................................................... C-566
CELL_WELL_CAP_FILE ................................................................................. C-567
CEXTRACTION_SPEF_LAYER_MAP ............................................................ C-646
CEXTRACTION_USE_SPEF............................................................................ C-646
CHARGE_SWITCH ......................................................................................... C-691
CHECK_SWITCH_POWERON ....................................................................... C-691
CLEAN_VIAS_AFTER_WIRES ....................................................................... C-646
CLOCK_DOMAIN_TOGGLE_RATE ................................................................ C-606
CLOCK_DOMAIN_TOGGLE_RATE_FILE ...................................................... C-606
CLOCK_ROOTS .............................................................................................. C-665
CMM_CELLS ................................................................................................... C-596
CMM_EXCLUDE_FILES ................................................................................. C-597
CMM_EXPAND_PINS_AT_TOP ..................................................................... C-597
CMM_INSTANCES .......................................................................................... C-598
CMM_LAYER_MAP_FILES ............................................................................. C-598
CMM_RIVETED_CONN .................................................................................. C-647
CONFIGURABLE_REPORT_FILE .................................................................. C-629
CONNECT_SWITCH_PINS ............................................................................. C-647
CONNECTIVITY_RES_THRESHOLD ............................................................. C-668
CONSISTENT_SCENARIO ............................................................................. C-668
COUPLEC ........................................................................................................ C-647
CPA_FILES ...................................................................................................... C-567
CYCLE_SELECTION_GRID_SIZE................................................................... C-567
DECAP_CELL .................................................................................................. C-687
DECAP_CELL_FILES ...................................................................................... C-687
DECAP_DENSITY ........................................................................................... C-688
DECAP_TILE_MAX ......................................................................................... C-688
DECOUPLE_LDO_GROUND .......................................................................... C-692
DEF_FILES ...................................................................................................... C-567
DEF_HONOR_HALF_NODE_SCALE_FACTOR ............................................ C-568
DEF_IGNORE_LAYERS ................................................................................. C-568
DEF_IGNORE_NETS_WIDTH ........................................................................ C-568
DEF_IGNORE_PIN_LAYERS ......................................................................... C-568
DEF_IGNORE_SNET_SHIELD ....................................................................... C-647
DEF_IGNORE_SPECIFIC_LAYERS ............................................................... C-569
DEF_PG_NETS_FILE ..................................................................................... C-589
DEF_READ_ALL_IO_NETS ............................................................................ C-569
DEF_READ_CLOCK_ONLY ............................................................................ C-569
DEF_SCALING_FACTOR ............................................................................... C-589
DEF_TRUE_PATH_EXTENSION .................................................................... C-569
DEFER_VIA_CREATION ................................................................................ C-700
DEFINE ............................................................................................................ C-709
DELTA_T_RMS_EM ........................................................................................ C-629
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxv
DETAILED_CONN_ISSUE_RPT ..................................................................... C-629
DIELECTRIC .................................................................................................... C-525
DMP_DYNAMIC_POWER_MODEL ................................................................ C-669
DMP_EP_FAST_MODE .................................................................................. C-607
DMP_SP_FAST_MODE .................................................................................. C-607
DO_PININST_INTERNAL_CONN ................................................................... C-647
DVD_GLITCH_FILTER .................................................................................... C-669
DYNAMIC_64BIT_SOLVER ............................................................................ C-670
DYNAMIC_ADAPTIVE_RON ........................................................................... C-692
DYNAMIC_ARC_LOW_POWER ..................................................................... C-670
DYNAMIC_BYPASS_SHORT ......................................................................... C-670
DYNAMIC_CELL_CROSS_CHECK ................................................................ C-670
DYNAMIC_CLOCK_SCALE ............................................................................ C-670
DYNAMIC_DETACHED_POSTPROCESS ..................................................... C-671
DYNAMIC_DISABLE_NEW_WFEXTRACT .................................................... C-671
DYNAMIC_EXTEND_VCD .............................................................................. C-671
DYNAMIC_FF_ADJUST_NTRIG ..................................................................... C-671
DYNAMIC_FRAME_SIZE ................................................................................ C-671
DYNAMIC_FREQUENCY_AWARE ................................................................. C-672
DYNAMIC_GROUP_WIRECAP ...................................................................... C-672
DYNAMIC_GSC_CHECK ................................................................................ C-692
DYNAMIC_MCYC_TW .................................................................................... C-672
DYNAMIC_MIXED_CONSISTENT_SCENARIO ............................................. C-672
DYNAMIC_MSTATE_FILTER ......................................................................... C-672
DYNAMIC_PEAK_CURRENT_AWARE .......................................................... C-672
DYNAMIC_PGARC_REPORT_BASE ............................................................. C-673
DYNAMIC_POST_BATCH .............................................................................. C-673
DYNAMIC_PRECHECK .................................................................................. C-673
DYNAMIC_PRESIM_DCINIT_SCALE ............................................................. C-671
DYNAMIC_PRESIM_TIME .............................................................................. C-673
DYNAMIC_RELAX_CONTROL_PIN_CONSTRAINT ...................................... C-674
DYNAMIC_REPORT_CLOCK_EVDD ............................................................. C-674
DYNAMIC_REPORT_DECAP ......................................................................... C-674
DYNAMIC_REPORT_DVD .............................................................................. C-674
DYNAMIC_SAVE_WAVEFORM ...................................................................... C-675
DYNAMIC_SELECTIVE_SAVE ....................................................................... C-675
DYNAMIC_SIMULATION_TIME ...................................................................... C-675
DYNAMIC_SOLVER_MODE ........................................................................... C-675
DYNAMIC_SORT_BY_PERCENTAGE ........................................................... C-675
DYNAMIC_TIME_STEP .................................................................................. C-676
DYNAMIC_VOLTAGE_CHECK ....................................................................... C-676
EFFECTIVE_VDD_WINDOW .......................................................................... C-676
EM_CCF_ONLY .............................................................................................. C-630
EM_CHECK_2D .............................................................................................. C-630
EM_CUSTOM_CURRENT_FILE ..................................................................... C-630
EM_DENSITY_ANALYSIS_LAYERS .............................................................. C-630
EM_DUMP_PERCENTAGE ............................................................................ C-630
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxvi
EM_LENGTH_USE_MAX_LENGTH ............................................................... C-631
EM_MISSION_PROFILE ................................................................................. C-631
EM_MODE ....................................................................................................... C-632
EM_NET_INFO ................................................................................................ C-632
EM_PEAK_EQUATION_SOURCE_TECHFILE ............................................... C-532
EM_REPORT_<mode>_PERCENTAGE ......................................................... C-634
EM_REPORT_LINE_NUMBER ....................................................................... C-634
EM_REPORT_MINWIDTH .............................................................................. C-633
EM_REPORT_MODE_ONLY .......................................................................... C-633
EM_REPORT_PERCENTAGE ........................................................................ C-633
EM_REPORT_PERCENTAGE_BY_LAYER ................................................... C-634
EM_RULE_SET ............................................................................................... C-526
EM_SCALE_DC ............................................................................................... C-634
EM_SCALE_PEAK .......................................................................................... C-634
EM_SCALE_RMS ............................................................................................ C-634
EM_SLEW_NO_STA ....................................................................................... C-635
EM_TECH_DC ................................................................................................. C-635
EM_TECH_FILE .............................................................................................. C-527
EM_TECH_FILE .............................................................................................. C-635
EM_TECH_PEAK ............................................................................................ C-635
EM_TECH_RMS .............................................................................................. C-635
EM_TOPOLOGY_USE_ELECTRON_FLOW .................................................. C-636
ENABLE_ATE .................................................................................................. C-666
ENABLE_AUTO_EM ....................................................................................... C-636
ENABLE_BLECH ............................................................................................. C-636
ENABLE_POLYNOMIAL_EM .......................................................................... C-636
ERROR_COUNTS ........................................................................................... C-702
ERROR_LOG_COUNTS ................................................................................. C-702
ESD_CLAMP_FILE .......................................................................................... C-696
ESD_CLAMP_PIN_FILE .................................................................................. C-697
ESD_CLAMP_PIN_NODE_DISTANCE ........................................................... C-698
ESD_DEF_IGNORE_LAYER .......................................................................... C-698
ESD_EXTRACT_CLAMP_NET ....................................................................... C-698
ESD_GSR_OPTIMIZE ..................................................................................... C-698
ESD_LOCAL_NETS ........................................................................................ C-699
ESD_RULE_FILE ............................................................................................ C-699
ESD_SHORT_CLAMP_PIN ............................................................................. C-699
ESD_SIGNAL_NET_FILE ................................................................................ C-700
ESD_SIGNAL_NETS ....................................................................................... C-699
EVA_PG_AWARE ........................................................................................... C-590
EXCLUDE_REGION ........................................................................................ C-570
EXPAND_CELL_PIN_FILE .............................................................................. C-648
EXTRACT_INTERNAL_NET ........................................................................... C-692
EXTRACT_PIN_VOL_INSTS .......................................................................... C-649
EXTRACTION_INC .......................................................................................... C-648
EZ_MERGE_NON_RECT_WIRE .................................................................... C-649
EZ_MERGE_NON_RECT_WIRE_MAX_LENGTH .......................................... C-649
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxvii
FAO_ACCURATE_VOLTAGE ......................................................................... C-680
FAO_ADD_STACK_VIA .................................................................................. C-680
FAO_BYPASS_CUTSIZE_CHECK ................................................................. C-681
FAO_DECAP_FILL_ALG ................................................................................. C-688
FAO_DECAP_FILL_NEW_FLOW ................................................................... C-688
FAO_DECAP_OVERLAP ................................................................................ C-689
FAO_DRC_DROP_RATIO .............................................................................. C-683
FAO_DRC_OBS .............................................................................................. C-689
FAO_DRC_PL_OBS ........................................................................................ C-689
FAO_DVD_TYPE ............................................................................................. C-683
FAO_DYNAMIC_MODE .................................................................................. C-683
FAO_ECO_NAME ........................................................................................... C-689
FAO_HOLD_LIC .............................................................................................. C-681
FAO_IGNORE_COMPRESS_VIAS ................................................................. C-681
FAO_LAYERS ................................................................................................. C-684
FAO_MAX_SHIFT ........................................................................................... C-689
FAO_MISVIA_DISTANCE ............................................................................... C-684
FAO_MISVIA_ONE_FILE ................................................................................ C-681
FAO_MISVIA_RPT_SHORT ............................................................................ C-684
FAO_NETS ...................................................................................................... C-684
FAO_OBJ ......................................................................................................... C-681
FAO_PLACE_GRID ......................................................................................... C-689
FAO_PRECISE_VOLTAGE ............................................................................. C-685
FAO_RANGE ................................................................................................... C-685
FAO_REGION ................................................................................................. C-682
FAO_ROW_SITE ............................................................................................. C-690
FAO_ROW_VDD_SITE ................................................................................... C-685
FAO_SUB_GRID_NETS .................................................................................. C-685
FAO_SUB_GRID_SPEC ................................................................................. C-686
FAO_TURBO_MODE ...................................................................................... C-682
FAO_WIDTH_CNSTR ..................................................................................... C-686
FAO_WIRE_WIDTH_LOW_LIMIT ................................................................... C-690
FAST_DEF_READ ........................................................................................... C-570
FAST_IMPORT_APL_MODE .......................................................................... C-662
FIND_ABUTTED_NONSTD_INSTS_PININSTS ............................................. C-650
FIX_WINDOW .................................................................................................. C-682
FREQUENCY .................................................................................................. C-590
GDS_CELLS .................................................................................................... C-570
GDS_CELLS_FILE .......................................................................................... C-571
GENERATE_CPM ........................................................................................... C-590
GND_NETS ..................................................................................................... C-590
GROUND_CURRENT_DISTRIBUTION .......................................................... C-677
GSC_FILES ..................................................................................................... C-571
GSC_OVERRIDE_IPF ..................................................................................... C-607
HALF_NODE_SCALE_FACTOR ..................................................................... C-527
HIER_DIVIDER ................................................................................................ C-701
HIER_DIVIDER_STA ....................................................................................... C-701
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxviii
HIERARCHY_CONSISTENT_SCENARIO ...................................................... C-677
HONOR_LEF_PIN_TYPE ................................................................................ C-572
HOOK_INTERNAL_PIN_POWER_EXTERNAL .............................................. C-572
IGNORE_APL_CHECK ................................................................................... C-663
IGNORE_APL_CHECK_SWITCH ................................................................... C-663
IGNORE_APL_PROCESS_CORNER ............................................................. C-663
IGNORE_CELLS ............................................................................................. C-703
IGNORE_CELLS_FILES ................................................................................. C-703
IGNORE_DEF_ERROR ................................................................................... C-703
IGNORE_DUMMY_PGNET ............................................................................. C-650
IGNORE_DUPLICATE_PGNET ...................................................................... C-703
IGNORE_ERROR_POPUP ............................................................................. C-703
IGNORE_ESCAPE_CHAR .............................................................................. C-704
IGNORE_FILE_PREPARSE ............................................................................ C-704
IGNORE_FILLER_DECAP_CELL_REPORT .................................................. C-704
IGNORE_FLOATING_INSTANCE_MISSING_TW_CHECK ........................... C-704
IGNORE_GDS2DEF_UNCONNECTS ............................................................ C-704
IGNORE_GDSMEM_ERROR .......................................................................... C-704
IGNORE_HALF_NODE_SCALE_FOR_EM .................................................... C-637
IGNORE_INST_POSTPROCESS ................................................................... C-637
IGNORE_INST_WITH_NO_MASTER ............................................................. C-572
IGNORE_INSTANCES .................................................................................... C-705
IGNORE_INSTANCES_FILES ........................................................................ C-705
IGNORE_INSTANCES_ON_TOP_DEF_REGIONS ........................................ C-572
IGNORE_IO_POWER ..................................................................................... C-706
IGNORE_LEF_DEF_MISMATCH .................................................................... C-705
IGNORE_LEF_DEF_SCALE_FOR_EM .......................................................... C-637
IGNORE_LEF_MACRO ................................................................................... C-706
IGNORE_LEF_PIN_DIRECTION .................................................................... C-705
IGNORE_LIB_CHECK ..................................................................................... C-706
IGNORE_MACROEEQ .................................................................................... C-650
IGNORE_NETS ............................................................................................... C-706
IGNORE_NETS_FILES ................................................................................... C-707
IGNORE_OPC_METAL ................................................................................... C-650
IGNORE_PLOC_INTERNALNETS .................................................................. C-573
IGNORE_PRECHECK_ERROR ...................................................................... C-707
IGNORE_PRIMARY_LOAD_DECAP .............................................................. C-707
IGNORE_ROUTE ............................................................................................ C-707
IGNORE_SHORT ............................................................................................ C-708
IGNORE_SIMTIME_CHECK ........................................................................... C-708
IGNORE_TECH_ERROR ................................................................................ C-708
IGNORE_THICKNESS_VARIATION ............................................................... C-650
IGNORE_UNDEFINED_LAYER ...................................................................... C-708
IGNORE_UNPLACED_INSTANCE ................................................................. C-708
IGNORE_UPF_PGARC ................................................................................... C-708
IGNORE_VP_CONTROL_ERROR ................................................................. C-709
IMPORT_NETS ............................................................................................... C-573
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxix
IMPORT_NETS_FILE ...................................................................................... C-573
IMPORT_REGION ........................................................................................... C-573
IMPORT_REGION_CELL_OVERLAP ............................................................. C-573
INACTIVE_NETS ............................................................................................. C-666
INCLUDE ......................................................................................................... C-709
INPUT_TRANSITION ...................................................................................... C-666
INST_CURRENT_DIST_MODE ...................................................................... C-650
INSTANCE_POWER_FILES ........................................................................... C-607
INSTANCE_TOGGLE_RATE .......................................................................... C-608
INSTANCE_TOGGLE_RATE_FILES .............................................................. C-608
INTERCONNECT_GATE_CAP_RATIO .......................................................... C-609
INTERNAL_CONNECT_PIN_CELLS_FILES .................................................. C-651
IP_MODEL_CELL_MAP .................................................................................. C-663
IP_MODEL_INST_MAP ................................................................................... C-663
IP_MODELS .................................................................................................... C-664
IPF_ERROR_THRESHOLD ............................................................................ C-609
IR_REPORT_STACKVIA_METAL ................................................................... C-651
ITERATIVE_SOLVER ...................................................................................... C-677
ITR_OVERRIDE_BPFS ................................................................................... C-609
JITTER_ENABLE ............................................................................................. C-666
KEEP_POWER_DATA .................................................................................... C-574
LEAKAGE_LIMIT ............................................................................................. C-690
LEF_CELL_IGNORE_PIN_LAYERS ............................................................... C-574
LEF_CELL_IGNORE_PIN_LAYERS ............................................................... C-651
LEF_FILES ...................................................................................................... C-574
LEF_IGNORE_PIN_LAYERS .......................................................................... C-575
LEF_SCALING_FACTOR ................................................................................ C-591
LEF_USE_DEFAULT_PIN_CAP ..................................................................... C-579
LEFDEF_TECH_LAYER_MAP_FILE .............................................................. C-574
LIB_FILES ........................................................................................................ C-575
LIB_HONOR_OUT_SIGNAL_SWING .............................................................. C-575
LIB_IGNORE_CELL_LEAKAGE ...................................................................... C-576
LIB_IGNORE_IO_VOLTAGE ........................................................................... C-576
LIB_IGNORE_POWER_THRESHOLD ............................................................ C-576
LIB_PIN_CAP .................................................................................................. C-577
LIB2AVM .......................................................................................................... C-664
LIB2AVM_MSTATE ......................................................................................... C-609
LIBERTY_DB ................................................................................................... C-575
LICENSE_WAIT ............................................................................................... C-592
LONG_WIRE_RES_CALC .............................................................................. C-652
LOWEST_METAL ............................................................................................ C-652
MACRO_POWER_FILES ................................................................................ C-577
MACRO_IRDROP ............................................................................................ C-652
MEM_RC_MODEL ........................................................................................... C-652
MERGE_ABUTTED_ASYM_CUTS ................................................................. C-653
MERGE_ABUTTED_CUTS ............................................................................. C-637
MERGE_WIRE ................................................................................................ C-653
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxx
MESH_VIAS_FILE ........................................................................................... C-653
METAL ............................................................................................................. C-527
METAL_DENSITY_BOUNDS .......................................................................... C-653
MIN_WIRE_DIMENSION ................................................................................. C-654
MINWIDTH_FROM_LEF ................................................................................. C-653
MISSING_VIA_CHECK_IGNORE_CELLS ...................................................... C-708
MMX_ADAPTIVE_SAMPLING ........................................................................ C-677
MMX_RES_MAP_LIMIT .................................................................................. C-592
MPR_MODE .................................................................................................... C-654
MPR_PARTITION_REDUCTION .................................................................... C-654
MPR_POWER_LIMIT_FOR_RED ................................................................... C-655
MULTI_CYCLE_SCENARIO ........................................................................... C-677
MULTI_GND_PACKAGE_MODEL .................................................................. C-592
MULTI_THREADS ........................................................................................... C-592
NAME_CASE_SENSITIVE .............................................................................. C-700
NET_LOAD_FILE ............................................................................................ C-610
NET_TOGGLE_RATE ..................................................................................... C-610
NET_TOGGLE_RATE_FILE ............................................................................ C-610
NEW_MERGE_WIRE ...................................................................................... C-637
NODE_REDUCTION_MODE .......................................................................... C-655
NOISE_LIMIT ................................................................................................... C-682
NOISE_REDUCTION ...................................................................................... C-683
NUM_HOTINST ............................................................................................... C-690
NUM_HOTSPOT ............................................................................................. C-686
NX_SIM ............................................................................................................ C-678
NX_VECTORLESS .......................................................................................... C-678
PACKAGE_SPICE_SUBCKT_INFO ................................................................ C-578
PAD_FILES ...................................................................................................... C-578
PARA_CALC_POWER .................................................................................... C-611
PARTIAL_FLAT_SPEF .................................................................................... C-579
PGNET_HONOR_DEF_TYPE ......................................................................... C-579
PGPLOC_DEBUG ........................................................................................... C-592
PIECEWISE_CAP_FILES ................................................................................ C-692
PIECEWISE_SWITCH_INPUT ........................................................................ C-679
PIN_DELIMITER .............................................................................................. C-701
PIN_DELIMITER_STA ..................................................................................... C-701
PIN_SLICE_CELL_LIST_FILE ........................................................................ C-655
PIN_SLICE_LIMIT ........................................................................................... C-655
PLOC_SHORT_INTERNAL_NET .................................................................... C-679
POWER_ALLOW_MULTIPLE_STATE ............................................................ C-611
POWER_ALLOW_PER_PIN_IPF .................................................................... C-611
POWER_ANALYSIS_MODE ........................................................................... C-612
POWER_CYCLE_SELECT_BLACK_BOX ...................................................... C-612
POWER_CYCLE_SELECT_MODE ................................................................. C-612
POWER_CYCLE_SELECT_POWER_NETS .................................................. C-612
POWER_CYCLE_SELECT_REPORT_VDD ................................................... C-613
POWER_CYCLE_SELECT_WHITE_BOX ...................................................... C-613
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxxi
POWER_DISABLE_SWITCH .......................................................................... C-613
POWER_DOMAIN_TOGGLE_RATE .............................................................. C-613
POWER_DOMAIN_TOGGLE_RATE_FILE ..................................................... C-613
POWER_DRIVER_TOGGLE_RATE ............................................................... C-613
POWER_HIER_REPORT_LEVEL ................................................................... C-613
POWER_HONOR_LIB_K_FACTOR ............................................................... C-614
POWER_IGNORE_ASYNCH_PIN .................................................................. C-614
POWER_LEAKAGE_SCALING_FACTOR ...................................................... C-614
POWER_LEAKAGE_SCALING_FILE ............................................................. C-614
POWER_MCF_MULTI_CLOCK ...................................................................... C-615
POWER_MISSING_IPF_LEAK ....................................................................... C-615
POWER_MISSING_IPF_POWER ................................................................... C-615
POWER_MODE ............................................................................................... C-615
POWER_REPORT_BIAS_PIN ........................................................................ C-616
POWER_STATE_DEPENDENT_LEAKAGE ................................................... C-616
POWER_TRANSIENT_ANALYSIS ................................................................. C-616
POWER_USE_CCS ........................................................................................ C-616
POWER_VCD_COVERED_THRESHOLD ...................................................... C-616
POWER_VCD_EVENT_SEQUENCE .............................................................. C-616
POWER_VCD_HONOR_GLITCH_EVENT ...................................................... C-616
POWER_VCD_IGNORE_ERROR ................................................................... C-617
POWER_VCD_LIMIT_TR ................................................................................ C-617
POWER_VCD_NUM_PROCESS .................................................................... C-617
POWER_VCD_OVERRIDE_IPF ..................................................................... C-617
POWER_VCD_REUSE_EVENT ..................................................................... C-617
POWER_VCD_TO_FSDB ............................................................................... C-617
POWER_WORST_IO_PAD ............................................................................. C-617
POWER_WORST_LEAKAGE ......................................................................... C-618
POWER_WORST_MBFF ................................................................................ C-618
POWERUP_OUTPUT_HIGH_PROB .............................................................. C-693
POWERUP_RANDOM_TOGGLE ................................................................... C-680
POWERUP_SAVE ........................................................................................... C-693
PPI_CELL_EDGE_MAX_NM_THRESHOLD .................................................. C-656
PPI_CELL_EDGE_THRESHOLD_PERCENT ................................................. C-656
PPI_STD_IGNORE_TOUCH_VIA_MET .......................................................... C-655
PRIMARY_OUTPUT_LOAD_CAPS ................................................................ C-618
PRIMARY_OUTPUT_LOAD_RC_MODEL ...................................................... C-656
PRINT_EM_VIA_BOX ..................................................................................... C-593
PRINT_EM_VIA_INFO .................................................................................... C-593
PRINT_ONE_PLOC_PER_PADINST .............................................................. C-579
PROBE_NODE_FILE ...................................................................................... C-680
PS_DMP_PERFORMANCE_MODE ............................................................... C-619
PS_GENERATE_MCYC_SCENARIO ............................................................. C-619
PS_GENERATE_VLESS_SCENARIO ............................................................ C-619
PS_GLITCH_POWER_MODELING ................................................................ C-619
PS_IN_FLOW_APL ......................................................................................... C-664
PS_LIB_EXTRACT_CCS ................................................................................ C-619
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxxii
PS_LIB_EXTRACT_CCS ................................................................................ C-637
PS_RTL_EP_MODE ........................................................................................ C-619
PS_RTL_EP_REPORT .................................................................................... C-619
PS_SP_GATED_CLOCK_LOGIC ................................................................... C-620
PS_VLSG_POWER_DOMAIN_HANDLING ..................................................... C-620
PSI_SPICE_CELL_NETLIST_FILE ................................................................. C-667
PUSH_PG_PININST ........................................................................................ C-657
PUSH_PININST_CELLS_FILES ..................................................................... C-656
PUSH_SIGNAL_PININST ................................................................................ C-657
QUICK_MESH_WIRE_MERGE ....................................................................... C-658
RAMPUP_OFFSTATE_VOLTAGE .................................................................. C-693
RAMPUP_SW_REPORT.................................................................................. C-693
RDL_CELL(S) .................................................................................................. C-579
READ_LEF_OBS ............................................................................................. C-581
REMOVE_PARENTLEF_GEOS ...................................................................... C-581
REPORT_ALL_UNCONNECT_PORTS .......................................................... C-658
REPORT_DISCONN_MIN_LENGTH .............................................................. C-593
REPORT_FLATTEN_LOG .............................................................................. C-593
REPORT_MAXCAP_VIOLATION .................................................................... C-620
REPORT_PEAK_MEMORY ............................................................................ C-593
REPORT_PEAK_MEMORY ............................................................................ C-594
REPORT_REDUCTION ................................................................................... C-593
REVERSE_DEF_READ_ORDER .................................................................... C-581
RTL_NAME_MAPPING ................................................................................... C-620
SAIF_FILE ....................................................................................................... C-620
SAVE_CONSOLIDATED_R .............................................................................. C-664
SCALE_CLOCK_POWER ............................................................................... C-621
SCAN_CLK_DUTY_CYCLE ............................................................................ C-621
SCAN_CONSTRAINT_FILES .......................................................................... C-621
SCAN_LAUNCH_CAPTURE_MODE .............................................................. C-680
SCAN_PI_CONSTRAINT_FILE ....................................................................... C-622
SCANLINE_MERGE_LAYERS ........................................................................ C-658
SCANMODE .................................................................................................... C-622
SCAN_SHIFTIN_LSB ...................................................................................... C-632
SEM_ACCURACY ........................................................................................... C-637
SEM_ANALYZE_NET_ONLY .......................................................................... C-638
SEM_CONNECT_NETS' ................................................................................. C-638
SEM_DEFAULT_PARAMETERS .................................................................... C-638
SEM_DRV_CURRENT_FILE .......................................................................... C-639
SEM_DUTY_RATIO_ROOT ............................................................................ C-639
SEM_ENABLE_SHORTS_REPORT ............................................................... C-640
SEM_EXTRACT_LONG_WIRE ....................................................................... C-640
SEM_HIERARCHICAL_MODE ........................................................................ C-640
SEM_IGNORE_DISCONNECT ....................................................................... C-640
SEM_IGNORE_NETS_MISSING_DATA ......................................................... C-640
SEM_IMPORT_CONNECTED_NETS.............................................................. C-640
SEM_INOUT_PIN_AUTO_SELECTION........................................................... C-640
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxxiii
SEM_KEEP_EMPTY_REPORT ...................................................................... C-641
SEM_NET_CHECK_SHORT ........................................................................... C-641
SEM_NET_FILTER_DRIVERS_FILE .............................................................. C-641
SEM_NET_FILTER_MAX_PEAK .................................................................... C-641
SEM_NET_FREQ ............................................................................................ C-641
SEM_NET_INFO ............................................................................................. C-642
SEM_NET_REPORT ....................................................................................... C-642
SEM_NEW_SIGEM_INFO_RPT ..................................................................... C-642
SEM_RECOVERY_FACTOR .......................................................................... C-642
SEM_SLEW_OPTIMIZATION ......................................................................... C-643
SEM_SPLIT_LONG_WIRE .............................................................................. C-643
SEM_TURBO_CLEAN_WIRE ......................................................................... C-643
SEM_VECTORLESS_TIME_STEP ................................................................. C-643
SHORT_CLAMP_NODES ............................................................................... C-700
SIMULATION_CACHE_DIRECTORY ............................................................. C-680
SINGLE_CUT_SLICE_LAYERS ...................................................................... C-658
SIZE_BASED_PININST_CURRENT_DISTRIBUTION .................................... C-659
SKIP_CONNECTIVITY_CHECK ..................................................................... C-659
SKIP_LAYERS_FILE ....................................................................................... C-659
SLEW_MIN_TRANSITION | SLEW_MAX_TRANSITION ................................ C-667
SP_CG_CONSTRAINT_FILE .......................................................................... C-623
SP_CLOCK_GATING_ERROR_OUT_RATE .................................................. C-623
SP_CLOCK_GATING_RATIO ......................................................................... C-623
SP_LIMIT_TR .................................................................................................. C-623
SPARAM_CHECK_LOWEST_FREQ .............................................................. C-667
SPARAM_CHECK_REFERENCE_R .............................................................. C-667
SPARAM_EXACT_DC ..................................................................................... C-667
SPARAM_HANDLING ..................................................................................... C-668
SPECIAL_SML ................................................................................................. C-659
SPLIT_SPARSE_VIA_ARRAY ........................................................................ C-659
SPLIT_VDD_EXTRACT_LP ............................................................................ C-594
SPLIT_VDD_EXTRACT_LP_FSIZE ................................................................ C-594
SPLIT_VIA_ARRAY ......................................................................................... C-659
SPLIT_VIA_ARRAY_CELL .............................................................................. C-660
STA_CRITICAL_PATH_FILE .......................................................................... C-581
STA_FILES ...................................................................................................... C-582
STA_SLEW_SCALING ..................................................................................... C-677
STANDARD_CELL_HEIGHT ........................................................................... C-583
STATE_PROPAGATION ................................................................................. C-623
STATIC_CONNECT_INST_FLOAT_GND ....................................................... C-595
STATIC_IR_HIDE_DISCON_INST .................................................................. C-660
STATIC_REDUCTION ..................................................................................... C-660
STD_CELL_SINGLE_NOMINAL_VOLTAGE_ONLY ...................................... C-595
STEINER_TREE_CAP .................................................................................... C-625
SUBSTRATE ................................................................................................... C-544
SWITCH_MODEL_FILES ................................................................................ C-693
SWITCH_MODEL_XTR_FILES ....................................................................... C-694
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxxiv
SWITCH_RES_FILES ..................................................................................... C-694
TECH_CONNECTIVITY_FILE ......................................................................... C-583
TECH_FILES ................................................................................................... C-583
TEMPERATURE .............................................................................................. C-583
TEMPERATURE_DEVICE .............................................................................. C-595
TEMPERATURE_EM ...................................................................................... C-643
TEMPERATURE_REPORT_LINE_NUMBER ................................................. C-644
TEMPERATURES ........................................................................................... C-584
TEMPERATURES_EM .................................................................................... C-644
THERMAL_ANALYSIS .................................................................................... C-625
THERMAL_COUPLING_PITCH ....................................................................... C-654
THERMAL_MODEL ......................................................................................... C-625
THERMAL_PROFILE ...................................................................................... C-584
THERMAL_TEMP_RANGE ............................................................................. C-595
TOGGLE_RATE .............................................................................................. C-626
TOGGLE_RATE_RATIO_COMB_FF .............................................................. C-626
TSV_MODEL_FILE .......................................................................................... C-660
UNITS .............................................................................................................. C-544
USE_CCS_PIN_CAPS ..................................................................................... C-677
USE_DEF_ROW_HEIGHT .............................................................................. C-585
USE_DEF_VIARULE ....................................................................................... C-585
USE_DRAWN_WIDTH_FOR_EM ................................................................... C-644
USE_DRAWN_WIDTH_FOR_EM_LOOKUP .................................................. C-644
USE_FAST_DECAP_ALG ............................................................................... C-626
USE_INTERP_ETCH_FOR_R ........................................................................ C-660
USE_LEF_FOR_LOGICAL_CONNECTION .................................................... C-585
USE_LIB_MAX_CAP ....................................................................................... C-627
USE_MF_SWITCH_MODEL ........................................................................... C-695
USE_MVM_PIN_MODEL ................................................................................ C-661
USE_SIGNAL_LOAD_FROM_STA ................................................................. C-586
USER_MCF_FILE ............................................................................................ C-627
USER_STA_FILE ............................................................................................ C-585
VCD_CONSISTENT_SCENARIO_FILTER ..................................................... C-592
VCD_FILE ........................................................................................................ C-586
VCD_PREPARE_SCENARIO ......................................................................... C-627
VCD_SCENARIO_COMPRESS ...................................................................... C-627
VCD_TIME_ALIGNMENT ................................................................................ C-627
VCD_X_LOGIC_STATE .................................................................................. C-628
VDD_NETS ...................................................................................................... C-595
VECTORLESS_BLOCK ................................................................................... C-628
VIA <via_name> .............................................................................................. C-545
VIA_COMPRESS ............................................................................................. C-645
VIA_IR_REPORT ............................................................................................. C-596
VIA_MAX_SPACE_FOR_COMP ..................................................................... C-661
VIAMODEL ...................................................................................................... C-550
VIAMODEL_NAME_CHECK ........................................................................... C-661
VP_CONTROL ................................................................................................. C-695
ANSYS, Inc.
Alphabetic List of GSR Keywords
RedHawk User Manual | xxxv
WARNING_COUNTS ...................................................................................... C-701
WARNING_LOG_COUNTS ............................................................................. C-702
WIRE_R_COMPENSATION ............................................................................ C-661
WIRE_SLICE_MIN_DIM .................................................................................. C-661
WIRE_SLICE_WIDTH ..................................................................................... C-661
ANSYS, Inc.
CHAPTER 1 — Introduction
Full-chip Static and Dynamic Power Integrity
RedHawk User Manual
| 1
Chapter 1
Introduction
Full-chip Static and Dynamic Power Integrity
Apache’s RedHawk™ power integrity solution is a full-chip cell-based power/ground
design and verification product with integrated SPICE, addressing static and dynamic
power integrity from early in the design flow through verification and sign-off. Static IR
drop, which determines the IR-drop based on the average value of the power distribution,
is merely the DC component of the solution. The more significant components are the AC
effects involving temporal relationships between switching events (of cells, clocks,
memories, IP, and I/O buffers) and the impact that capacitance and inductance have on
full-chip power integrity.
The RedHawk product suite consists of two core applications, RedHawk-S (static) and
RedHawk-EV (static and dynamic). RedHawk-S supports full-chip static power, IR drop,
and EM (electro-migration) analysis. RedHawk-EV supports full-chip Vectorless
Dynamic™ power and voltage analysis, including the effects of on-chip inductance,
package RLC models, and decoupling capacitance analysis and optimization. In addition,
RedHawk support accurate analysis of advanced low power designs using techniques
such as MTCMOS (power gating), clock gating, multiple Vdd/Vss, and substrate biasing.
The name RedHawk is used interchangeably to refer to either RedHawk-S or RedHawkEV, depending on the product bundle you have licensed.
The comprehensive physical power integrity solution offered by RedHawk encompasses
several breakthrough technologies, including transistor-level analysis accuracy in a cellbased power solution. One of the underlying technologies is RedHawk's Vectorless
Dynamic statistical analysis engine, which computes realistic worst-case switching
scenarios on a full chip without requiring functional vectors. The Vectorless Dynamic
technique, driven by the static timing analysis (STA) timing window and current
waveforms in SPICE-characterized Apache Power Libraries (APL), yield accurate voltage
waveforms for each instance on a power-grid. Severe peak voltage drop areas are
identified as hotspot regions, which can be fixed using new decap placement, grid
resizing, supplementary power routing, and/or swapping key cell instances at power
hotspots. Upon identifying these hotspots in the power networks, RedHawk helps
determine how to modify the grid or the decap placement, or swap a cell instance at
needed locations, to reduce the voltage drop.
RedHawk is fully interoperable with industry standard file formats for technology, design,
and library descriptions. To support the requirements of complex SoC designs, RedHawk
accepts hybrid input formats such as LEF/DEF for standard cell and GDSII for memories,
flip-chip bumps, I/Os, cover macros, and IP blocks. In addition, RedHawk supports
SPICE-characterized waveform data in Apache Power Libraries to augment the static
data in Synopsys .lib, thereby ensuring “true” dynamic accuracy.
While accuracy is one of the primary goals of RedHawk’s physical power flow, an equally
important mission is to provide designers with full-chip capacity and an easy-to-use
product. RedHawk enables full-chip RLC power-ground extraction, transient simulation,
electro-migration analysis, static and dynamic power and voltage drop analysis, voltage
drop impact on key timing parameters such as clock jitter and delay, and power integrity
design fixing and optimization in a single product. This enables designers to quickly
examine the power and timing impacts on an SoC caused by physical implementation
decisions throughout the design flow and insure accurate power performance and signoff.
ANSYS, Inc.
CHAPTER 1 — Introduction
Using RedHawk in the Design Flow
RedHawk User Manual
| 2
Using RedHawk in the Design Flow
RedHawk is fully compatible with industry standard formats and easily drops into existing
ASIC vendor and COT flows. RedHawk’s physical power methodology, illustrated in
Figure 1-1, is easily integrated into all three primary stages of chip design: Design
Planning, Design Development, and Design Verification. The use of RedHawk in these
design phases is described in the following sections.
RedHawk supports two methodologies for dynamic analysis, depending on where you are
in the design flow. The first method is based on .lib file data, which provides early
feedback on dynamic hotspots. The second method is Apache Power Library (APL)
based dynamic analysis, which provides transistor-level accuracy during verification,
based on cell current waveforms in the characterized APL.
Design Planning
RedHawk enables early design analysis of static IR drop, and dynamic hotspot estimation
using .lib-based analysis. At this stage, RedHawk considers wire load models, such as
net-to-gate capacitance ratios, to calculate the power distribution. Typically, graphic
presentation of IR drop and EM maps can reveal weaknesses of the power/ground mesh
structures or the shortage of power/ground pads. Power-grid distribution issues can be
easily remedied by wire-sizing or adding more straps or vias. At this point, switching to a
flip-chip package may alleviate the static IR power distribution problems. In addition, by
black-box consideration of memories and other content which is not yet available,
dynamic hotspots due to simultaneous switching can be flagged in individual blocks or on
the entire design.
Design Development
In the design development stage, after detailed cell placement, the design is represented
by hybrid of input formats, such as LEF/DEF for logic core and GDSII for memories and
flip-chip power bumps. If the SPEF or DSPF of the signal nets is unavailable, RedHawk
uses Steiner tree wire estimates to compute power distribution. The use of slew
information from the static timing analyzer (STA) further increases the accuracy of power
analysis. Potential EM problems can be identified. Once the full-chip dynamic hotspot
regions are identified, a rapid “what-if” analysis can be performed to assess the impact of
package model inductance and intentional decap. Early analysis of the decaps ensure
that proper area and location are allocated during placement, rather than after routing.
Decap must be placed as close as possible to the victim to ensure proper protection from
current spikes.
ANSYS, Inc.
CHAPTER 1 — Introduction
Using RedHawk in the Design Flow
Design Flow
Initial Placement and
Power Grid Design
RedHawk User Manual
| 3
Design Planning
• Evaluate static IR distribution and EM
problems
• Estimate dynamic hotspots
• Evaluate and fix power grid design and
current demand imbalances
REDHAWK
• Power analysis using *.libs
Design Development
Detailed Placement
and Optimization
• Perform LIB-based analysis of dynamic
hotspots and repair
• Explore and modify decoupling
capacitance
REDHAWK
• Assess and fix package and clock power
problems
Design Verification
Detailed Routing,
Extraction, LVS/DRC
• Perform precise APL-based analysis of
dynamic hotspots and repair
• Optimize decap usage and protection
REDHAWK
• Analyze dynamic voltage and its impact
on timing
• Evaluate and fix remaining power-related
design issues
• Verify design with Spice sign-off accuracy
Figure 1-1
Using RedHawk throughout the design process
Design Verification
During the design verification stage, RedHawk uses the detailed resistive and capacitive
loading of the signal nets from the extracted DSPF or SPEF file, as well as the final slew
and delay information from the STA. The critical information that is required at the
verification stage is the transient current waveform data for each cell library instance. The
current waveforms are characterized in the Apache Power Libraries (APL), enabling
transistor-level accuracy during cell-level verification. APL should be used during the final
verification to fully benefit from RedHawk’s transistor-level accuracy. This provides the
assurance that the decap is optimally placed to protect dynamic hotspots. A final
verification of dynamic voltage-induced delays to clock skew and timing is performed
before tapeout.
ANSYS, Inc.
CHAPTER 1 — Introduction
Summary
RedHawk User Manual
| 4
Summary
Due to large power densities, smaller voltage supplies, and higher frequencies, full-chip
dynamic and static power integrity is one of the key challenges for designs in 65nm
technology processes and beyond. Dynamic power and peak voltage drop is difficult to
analyze and correct, being a transient phenomena, and its impact on chip timing and yield
is a growing concern.
Major ASIC and IC semiconductor houses and COT companies will benefit by using
Apache’s RedHawk tools to design and verify the dynamic power integrity of very large
designs. At the 65nm process node and lower, dynamic power integrity is a design signoff requirement.
A comprehensive cell-based methodology for full-chip power integrity analysis must
address:
• Vectorless Dynamic voltage drop analysis and verification, including impacts on timing
and clock trees
• Analysis and optimization of decoupling capacitance
• Waveform-based dynamic power libraries for cells and macros
• Power grid weakness analysis, optimization and fixing
• On-chip and off-chip inductive noise evaluation
• Multiple Vdd and Vss per instance
RedHawk’s physical power solution delivers all of these capabilities in a dramatically
faster, high-capacity, and easy-to-use design environment. Design teams can confidently
deploy RedHawk's full-chip physical power methodology throughout their design flows,
taping out on-schedule, and with power integrity insured to silicon.
ANSYS, Inc.
CHAPTER 2 — RedHawk Flow
Introduction
RedHawk User Manual
| 5
Chapter 2
RedHawk Flow
Introduction
RedHawk performs several types of power analysis on a circuit:
• static (IR) voltage drop with average cycle currents
• dynamic voltage drop with worst-case switching currents
• electromigration analysis
• critical path and clock tree impacts
Each type of analysis can be run in different ways, depending on the input data available
and the desired speed of analysis and accuracy of results. An overview of the data flow
for static IR and dynamic voltage drop analyses is presented in the following sections.
Static Voltage Drop Analysis Flow
Figure 2-1 shows the design flow for running RedHawk-S, the static IR drop solution.
The following are the key steps in the static voltage drop analysis flow.
1.
Prepare the design data and input files (see Chapter 3).
- Prepare the RedHawk technology file data on the IC process (tutorial.tech).
- Prepare the pad cell name, pad instance name, or pad location file. (tutorial.pcell,
tutorial.pad, and/or tutorial.ploc file).
- Generate the STA output file for slews, timing windows, and clock instances
(tutorial.sta). See Chapter 19, "Timing File Creation Using Apache Timing Engine
(ATE)".
- Prepare the Global System Requirements (GSR) file (including references to .tech
file, pad files, STA file, LEF files, DEF files, and LIB files) for static IR/EM and/or
dynamic voltage drop analysis (tutorial.gsr).
- Import design data using GSR file (tutorial.gsr).
ANSYS, Inc.
2.
Perform power calculation from .lib cell data, or import power data if previously
calculated (see Chapter 4).
3.
Extract power grid (R network).
4.
Perform static IR/EM analysis (see Chapter 4).
5.
Generate and review maps and text reports of IR/EM results (see Chapter 6).
6.
Perform “what-if” analysis and grid modification and optimization to fix areas of
critical static IR drop (see Chapter 7).
CHAPTER 2 — RedHawk Flow
Dynamic Voltage Drop Analysis Flow
RedHawk User Manual
Library and
Technology-specific
Inputs
| 6
Outputs
Physical Library
LEF / LIB files
Technology
RedHawk-S
Apache Tech file
Power Calculation
Static pwr / volt / EM
Contour Maps
Physical Design
Design-specific
DEF / GDS files
Power Grid R
Extraction
Design & Analysis Spec
GSR file
Static IR/EM
Analysis
Static pwr / volt / EM
Text Reports
Package Specs
.pcell / .ploc / .pad files
Warnings/ Violations
Parasitic Loading *
SPEF / DSPF files
Instance Slews *
STA file
* Optional for more accuracy
Figure 2-1
RedHawk-S static IR power analysis flow
RedHawk-S outputs include:
• IR voltage drop contour maps
• Electro-migration (EM) analysis
• Power density and average current maps
• Text report files of detailed static power, voltage, and current data
• Warnings and violations reports
Dynamic Voltage Drop Analysis Flow
Figure 2-2 shows the design flow for running RedHawk-EV, the dynamic voltage drop
solution.
ANSYS, Inc.
CHAPTER 2 — RedHawk Flow
Dynamic Voltage Drop Analysis Flow
RedHawk User Manual
Apache Power Library
Library and
Technology-specific
Inputs
Physical Library
Current Profiles
Instance Power Resistance
Intrinsic Decap
| 7
Outputs
LEF / LIB files
Technology
Apache Tech file
Physical Design
RedHawk-EV
Power Calculation
Dynamic Pwr / Volt
Contour Maps
Power Grid RLC
Extraction
DEF / GDS files
Design-specific
Design & Analysis Spec
GSR file
Package Specs
.pcell / .ploc / .pad files
Dynamic Voltage
Hotspot Analysis
and Fixing
Dynamic Pwr / Volt
Text Reports
Vectorless
Dynamic Sim
Decap Maps
Package Parasitics
Impact on Timing
Parasitic Loading
SPEF / DSPF files
Warnings/ Violations
Instance Slew/Timing
STA file
Figure 2-2
RedHawk-EV dynamic power analysis flow
The following are the key steps in the dynamic analysis flow.
1.
Prepare the design data and input files (see Chapter 3).
Note: If RedHawk static IR drop analysis has been run, this step does not need to be
repeated, except to set specific dynamic run parameters in the GSR file.
- Prepare the RedHawk technology file data on the IC process (tutorial.tech).
- Prepare the pad cell name, pad instance name, or pad location file. (tutorial.pcell,
tutorial.pad, and/or tutorial.ploc file).
- Generate the STA output file for slews, timing windows, and clock instances. See
Chapter 19, "Timing File Creation Using Apache Timing Engine (ATE)".
- Prepare the Global System Requirements (GSR) file (including references to .tech
file, pad files, STA file, LEF files, DEF files, and LIB files) for dynamic voltage drop
ANSYS, Inc.
CHAPTER 2 — RedHawk Flow
Dynamic Voltage Drop Analysis Flow
RedHawk User Manual
| 8
analysis (tutorial.gsr) (see file definitions in Appendix C, "File Definitions").
- Import design data using GSR file (tutorial.gsr).
2.
Prepare additional inputs required to run RedHawk-EV, in addition to those needed
for static analysis (see Chapter 3, "User Interface and Data Preparation"):
- Timing windows and slews from STA (recommended)
- Extracted parasitics from SPEF or DSPF (recommended)
- Pad, wirebond/bump, and package R, L, C, K information
- Technology data - conductor thicknesses, dielectric thicknesses and dielectric
constants (seesection "Apache Technology File (*.tech)", page C-521.
- SPICE model cards and library subcircuits. This is required to characterize the
current waveforms in the Apache Power Libraries
- SPICE subcircuits for all memories, I/Os, and IP blocks (optional)
3.
Calculate detailed power distribution from .lib cell data, or import power data if
previously calculated (see Chapter 4).
4.
Extract power grid (RLC network).
5.
Run APL (Apache Power Library) characterization, to obtain current profiles under
typical corner conditions, Effective Series Resistance (ESR) for the power circuit
and as well as decoupling capacitance and leakage current (see Chapter 9,
"Characterization Using Apache Power Library").
6.
Perform dynamic voltage drop and peak current analysis (see Chapter 5, "Dynamic
Voltage Drop Analysis").
7.
Generate and review maps and text reports of dynamic analysis results (see
Chapter 6, "Reports").
8.
Perform “what-if” analysis and optimize decap placement, make grid modifications
and perform instance swapping to fix “hotspots” -- areas of highest dynamic
voltage drop (see Chapter 7, "Fixing and Optimizing Grid and Power
Performance") .
RedHawk-EV outputs include:
• Dynamic voltage drop color maps and power density color maps (see Chapter 5,
"Dynamic Voltage Drop Analysis")
• Capacitance maps, including decap effects (see Chapter 5, "Dynamic Voltage Drop
Analysis")
• Report files (see Chapter 6, "Reports")
• ECO script to place and route environment (see Chapter 7, "Fixing and Optimizing
Grid and Power Performance")
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
Introduction
RedHawk User Manual
| 9
Chapter 3
User Interface and Data Preparation
Introduction
This chapter describes both the TCL command line user interface and the graphical user
interface (GUI) available for controlling RedHawk, the proper directory organization for
managing input and output data, as well as the input data files and preparation required
before starting RedHawk analysis. See Appendix A for instructions on installing the
software.
TCL Command User Interface
TCL Command Summary
The RedHawk program can be invoked and controlled using the TCL command line
interface and a set of commands described in this section.
The basic RedHawk invocation is:
redhawk
Following is a summary of the TCL commands available for running RedHawk. Details on
the TCL commands and their options and syntax are found in section "TCL / Script
Commands", page D-729.
cell swap - allows high power cells to be moved to a location that has lower
voltage drop
characterize - runs Apache Power Library (APL) characterization to generate
dynamic Vdd/Vss current waveforms and intrinsic/intentional decap values
condition - sets, displays and unsets various conditions for post-DvD analysis
(such as plot and print)
config - sets GUI options for reviewing, analyzing and debugging of RedHawk
results
decap - allows various types of modifications to decoupling capacitance to reduce
dynamic voltage drop
dump - writes out colormaps in GIF format
eco - defines changes to the design database (GUI-based operation only), which
is equivalent to GUI ‘what-if’ operation
export - exports data from RedHawk engine for use by other tools
fao - allows modification of the physical design
generate - generates specified files for review and/or future use
get - allows querying the database to find cell or instance names based on
pattern matching to search and find design elements, execute scripts, or
allow more detailed access to the design
gsr - retrieves GSR variable values, sets GSR values, displays the contents, or
sends the GSR contents to a file
history - displays all previous commands typed on the command line during the
session
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
Graphical User Interface
RedHawk User Manual
| 10
import - imports specified files for use in RedHawk analysis, such as APL, AVM,
DB, DEF, ECO, GSR, guiconf, LEF, LIB, PAD, POWER, or TECH
ircx2tech - converts an input iRCX file to an appropriate Apache tech file
marker - adds or removes design marker(s) specified either as an x,y position or
as an instance name.
mesh - performs various types of modifications to power grids, including adding,
deleting, and modifying widths and spacing, to reduce voltage drop
message - displays Error, Info and Warning message information
movie - sets up or plays an instance-based “movie” of Dynamic Voltage Drop
history
perform - runs selected RedHawk analyses, such as extraction, power
calculation, static analysis, dynamic analysis, and timing slew
pfs - executes various ESD analysis functions
plot - generates graphical plots based on specified conditions
print - prints text-based reports for specified conditions
probe - selects and de-selects particular nodes prior to extraction
psiwinder - performs various clock and timing analyses on a design
query - displays information and analysis parameters on selected objects in the
design
report - creates reports on RedHawk analyses
ring - adds or deletes power rings
route fix - routes new power/ground wires and adds associated vias to reduce
excessive voltage drop
save - saves the design database for later use
select - selects and highlights objects in the GUI
setup - sets up data and conditions required for performing RedHawk analysis
show - displays a colormap of specified RedHawk results in the GUI
window - changes the GUI window geometry so that the “dump gif” command
can produce a higher resolution color map
zoom - zooms design view in and out
The RedHawk graphical user interface and its features are summarized in the following
section.
Graphical User Interface
Elements of the GUI
The graphical user interface allows convenient viewing of design elements and the results
of RedHawk analysis. Whenever RedHawk is invoked from the command line the GUI is
automatically displayed.
The RedHawk GUI includes a number of panels with different functions, as shown in
Figure 3-1. The functional areas of the GUI are:
• Menu bar
• Primary display area
• Multiple page view tabs
• Text display area
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
Graphical User Interface
RedHawk User Manual
| 11
• Control buttons
• Design view area
• Cursor location readout
• TCL command line
The functionality of these GUI elements is summarized in the following sections. For
details on the GUI commands and functions, see appendix section "RedHawk Graphic
User Interface Description", page D-794.
Page View tabs
Menu bar
Primary display area
Control
Buttons
View
Config
View
Results
Query
Full Design
View Area
TCL command line
Log display area
Figure 3-1
Primary view readout
RedHawk graphical user interface
Menu Bar
The RedHawk functions available from the menu bar are as follows:
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
Graphical User Interface
RedHawk User Manual
| 12
• File - allows you to import and export design data, databases, ECO information, and
configuration information
• Edit - allows you to edit information in the GSR and Tech files, as well as modify
elements of the power grid such as pads, straps, and vias.
• View - allows you to display and change the color map for viewing design elements
(such as nets, layers, instances, capacitance, and general object properties) and
analysis results (such as IR and dynamic voltage drop, power and current density, EM
problems, slack and delay).
• Tools - allows you to invoke RedHawk tools, such as those for fixing and optimizing
power grid and decoupling capacitance, low power circuit design analysis, and PJX
critical path and clock tree analysis.
• Static - allows you to perform various functions associated with static voltage drop
analysis, such as power calculation, network R extraction, pad and package
constraints, and IR drop and EM analyses
• Dynamic - allows you to perform functions associated with dynamic voltage drop
analysis, such as power calculation, network RLC extraction, pad and package
constraints, and vectorless or VCD-based dynamic voltage drop analysis.
• Timing - allows you to perform functions associated with circuit timing analysis, such
as instance slew, slack, K-factor, delay, clock networks, modified SDF data, and
impact of voltage drop on timing
• Results - allows you to set up and generate results information on RedHawk
analyses, such as histograms, log messages, and ordered lists of instances or nodes
with worst- case IR drop, dynamic voltage drop, electromigration, power/ground
design weakness. Also allows creation and display of “movies” of voltage drop by time
steps.
• Explorer - controls the generation and display of analysis results
• Windows - allows you to set up and create multiple-page simultaneous displays, as
well as set preferences for the windows display.
• Help - displays information about the RedHawk software version and provides access
to the latest “RedHawk Users’ Manual” in PDF format.
Primary Display Area
The primary display area allows the full design or segments of the design to be displayed
along with selected characteristics, highlights and analysis metrics.
Log Display Area
The log display area in the lower left corner of the GUI shows RedHawk text inputs,
progress status, error messages, and results.
Control Buttons
The sets of control buttons down the right side of the GUI window invoke changes in the
display or activate RedHawk commands. The function of the button is identified when the
cursor is placed over it. The control buttons include the following functions:
• ‘View’ buttons - modify the size and center of the view in the primary display
• ‘Configuration’ buttons - view layers, set color range, and view power pads
• ‘View Results’ buttons - displays “maps” of various parameters superimposed on the
design, such as power density, decap density, voltage drop, and current.
• ‘Query’ buttons - allows querying properties of selected design objects
• ‘Coordinates’ readout - indicates the x,y location of the cursor, and the bounding box
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 13
of the primary display area, in microns.
Design View Area
The min-view area always displays the ‘Show All’ view of the primary display selection, to
shown the context and orientation of the primary view.
TCL Command Line
At the bottom of the interface is a TCL command line for entering text commands. See
section "TCL / Script Commands", page D-729, for syntax conventions and a complete list
of TCL commands.
Using the GUI
Exporting and Importing a GUI Configuration
All of the settings that you can modify with the two ‘Configuration’ button dialog boxes can
be saved for future use in a configuration file, either by using the menu command File>Export GUI Config or by using the TCL command:
export guiconf <GUI-config-filename>
Then to restore the GUI configuration to a saved version, there are three ways to import it:
1.
Select from the menu File->Import GUI Config, and choose the saved
configuration file you want.
2.
Use the TCL command:
import guiconf <GUI-config-filename>
3.
Set the environment variable ‘APACHE_CONF_FILE’ from the command line:
setenv APACHE_CONF_FILE <GUI-config-filename>
This method has the lowest priority; methods 1 and 2 override method 3.
The TCL command ‘config’ may be used to change viewlayers, viewnets and colormaps
if you do not want to export/import the GUI configuration. The ‘config’ command can
change the GUI configuration at any time from the command line.
For example, the ‘config colormap’ command can configure the maximum and
minimum voltage drops displayed in either absolute drop or percentage, as in the
following example:
config colormap -percent -min 10 -max 24 -instance
This sets the minimum instance voltage drop displayed to 10% of nominal Vdd and the
maximum voltage drop percentage displayed to 24%.
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk Program Files
Data files required for RedHawk analysis come from three types of sources:
Des - standard files needed for or generated by the chip design process
Cr - Apache files that you need to create for RedHawk analysis
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 14
The input files may be required for either static or dynamic voltage drop analysis, as
shown in Table 3-1, or they may be optional; files not strictly required usually provide
more accurate analysis if provided. Files not required, but strongly recommended, are
designated “Dyn-Rec”.
Table 3-1
File
Data Files for RedHawk Analysis.
Description
Req’d
DEF (*.def)
design files
Physical description of instances, power and ground
network, and other circuit elements. The currently
supported version of DEF is lefdef 5.7. If there are
multiple .def files, you must specify each .def file on
Des
a line with its absolute or relative path from the
RedHawk run directory in the ‘DEF_FILES’ GSR
keyword (see section "DEF_FILES", page C-564),
and the option “top” or “block” to indicate the toplevel or block-level DEF file.
Stat/Dyn
LEF (*.lef)
library files
Library Exchange Format file. Physical description of
library cells. The currently supported version of LEF
is lefdef 5.7. If there are multiple LEF files, you must
specify each .lef file on a line with its absolute or
relative path from the RedHawk run directory in the
Des
‘LEF_FILES’ GSR keyword (see section
"LEF_FILES", page C-573). Also, all of the following
four keywords must be in the technology file,
although they can be commented out, for RedHawk
to recognize it as the technology LEF file: LAYER,
TYPE, WIDTH, ROUTING
Stat/Dyn
Synopsys-format library files contain logical
descriptions of library cells, with power and timing
tables, and are used for power calculation. As an
LIB file (*.lib) alternative, the entire set of LIB file data can be
included under the ‘LIB_FILES’ keyword in the GSR
file. Also, up to five string variable parameters per
operating condition can be handled.
Des
Stat/Dyn
Device
models
Des
Dyn
Des
Dyn
BSIM device models for simulation.
Spice netlists of standard cells and decoupling
Standard cell
capacitor cells. SPICE model cards and library
SPICE
subcircuits. This is required to create the current
netlists
profiles in the Apache Power Library.
ANSYS, Inc.
Source
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
ANSYS, Inc.
RedHawk User Manual
STA file
Static Timing Analysis file. Produces instancespecific minimum/maximum transition times and
defines the timing windows and clock network data.
Required for signoff accuracy.
The STA output file must be defined by the keyword
‘STA_FILE’ in the .gsr file.
Also improves the accuracy of static IR power and
Des
voltage drop analysis. If the timing window
information is missing for an instance, the power of
the instance is assumed to be zero unless the
information is specified in the .gsr file with the
BLOCK_POWER_FOR_SCALING keyword, or is
available in the VCD_FILE. See Chapter 19, "Timing
File Creation Using Apache Timing Engine (ATE)" for
details on generating this file.
DynRec
SPEF file
Standard Parasitic Exchange File. Instance-specifc
signal wire parasitic data. Req’d for signoff accuracy.
Note that when you have a hierarchical design, the
following cases are acceptable:
(1) Hierarchical DEF with hierarchical SPEF: every
Des
SPEF must be associated with a DEF block.
(2) Hierarchical DEF with flattened SPEF
(3) Flattened DEF with flattened SPEF.
To perform PJX timing analysis in signal integrity
mode, coupling capacitance data must be provided.
DynRec
VCD file
Value Change Dump file for determining net toggling
activity and peak power. Required by vcdtrans/
vcdscan utilities for VCD-based analysis. If VCD files
are available, then the ‘VCD_FILE’ keyword can be
Des
used to read the net toggling information from the
VCD files. If VCD files are not available, you can
specify the default toggle rate and running
frequencies in the .gsr file. See Figure 3-2 for a
sample VCD plot of power use by cycle.
DynRec
GDSII file
Physical description of circuit elements to create
DEF views. Used by gds2def/gds2rh utilities.
Required for accurate analysis of memories, flip-chip
bump layer descriptions and analog blocks, which
may only be available in GDSII format, and is
converted using RedHawk’s GDSII data preparation
utilities, gds2def/ gds2rh, gds2def -m/gds2rh -m.
Des
For details, see section "gds2rh/gds2def", page E848.
The GDS cells can be imported using the GSR file
keyword GDS_CELLS, which lists the cells and the
path to where the gds2def/gds2rh utility was run.
See section "GDS_CELLS", page C-568, for the
proper GSR syntax. Refer to Appendix E, Utilities, for
details on the RedHawk GDS conversion utilities.
DynRec
| 15
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 16
Technology
file (*.tech)
Design-specific file containing metal layer and
package information for each process corner. Refer
to Appendix C for a detailed description of the
technology file contents and format.
Cr
Stat/Dyn
GDS layer
map file
To enable GDS layer number to LEF layer name
mapping.
Cr
Sat/Dyn
Design-specific information for operating conditions
and analysis parameters such as global specs for
VDD nets, clock roots and their respective
frequencies, default logic toggle rate, and switching
conditions of special nets such as reset nets, I/O
Global
nets, and I/O pin output loadings.
System
Cr
Requirement The GSR also contains specifications for other input
files. Make sure that the GSR file contains file paths
file (*.gsr)
and names for all needed files, such as TECH, pad,
STA, DEF, LEF, LIB, VCD, GDS, SPEF, and
package. Refer to Appendix C for a description of the
contents of the .gsr file.
Stat/Dyn
Pad files
(.ploc, .pad,
or .pcell)
NOTE:
Figure 3-2
Power and ground pad descriptions, cell names,
instance names, and X,Y locations. Refer to
Appendix C for descriptions of the pad files, including
the pad cell names (.pcell) and pad instance name
(.pad) files.
Cr
Stat/Dyn
RedHawk can read LEF, DEF, STA, SPEF, VCD, FSDB, SAIF and GDS
files in *.gz (gzip) format.
vcdscan plot of power by cycle
Multiple Vdd/Vss Analysis
Redhawk is natively aware of multiple power and ground domains. As such it accurately
handles not only designs with multiple Vdd supplies, but also individual cells with multiple
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 17
power and ground domains, and always looks for data supporting multiple domains per
cell. Common examples of multiple Vdd design elements are:
• level shifters
• flip-flops and latches with primary and retention power
• isolation logic used to ring blocks at different potentials
• memory/register file blocks with independent voltages for the array and peripheral
sections
• I/O cells with both external and internal power and ground supplies
The data required to determine the proper modeling of multiple power domain cells for
both static and dynamic analysis are listed in the following paragraphs.
For cells with single VDD and VSS supply pins, there may be changes required in
RedHawk configuration files, but no input data changes are needed. In most cases,
designs using single power/ground domain cells only require that any gds2def -m/gds2rh
-m modeled cells are rebuilt. This is not the result of mVDD support, but rather an
updated modeling construct for non-uniform current distribution in gds2def -m/gds2rh -m
modeled IP.
For cells with multiple VDD pins and one or many VSS pins, additional data is required by
RedHawk, both in terms of user data and also in configuration files.
Summary of Differences in Input Data Files
The following table summarizes the data file changes for multiple Vdd analysis. Those
marked ‘GEN’ are related to a general change in RedHawk data handling and not related
to multi-Vdd.
Table 3-2
Type of File
Type of cells
requiring changes
Changes required: GEN/MVdd
LIB
Multi-domain only
MVdd. Certain attributes needed in the
library, cell, and pin level definitions. Liberty
format does not accept a cell with multiple
ground pins, in which case a custom LIB file
must be created.
LEF
Multi-domain
Single-domain
GEN. All power and ground pins must have
‘USE < >’ and ‘DIRECTION < >’ attributes
defined correctly.
User instance
power file
Multi-domain only
APL data
Multi-domain only
MVdd. Rerun APL characterization to create
separate instance current profiles for each
Vdd and Vss arc, and Cdev per pin.
Multi-domain
Single-domain
GEN. Memory models created using
‘gds2def –m’ /’gds2rh -m’ should be reextracted to use the enhanced memory
handling capability.
If using ‘gds2def/gds2rh’ no changes are
needed.
Memory models
ANSYS, Inc.
Input data changes needed
MVdd. Specify pin-based power.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 18
Table 3-3 summarizes the changes needed to RedHawk configuration files to perform
multiple Vdd/Vss domain analysis. Further descriptions of the changes needed are
provided following the table.
Table 3-3
Type of File
Configuration file changes needed - Multi Vdd
Type of cells
requiring changes
Changes required: GEN/MVdd
GEN. Use GSR-based specification for all
input files.
Use ‘GDS_CELLS’ keyword to use new
memory models when using GDS2RH -m.
GSR
Multi-domain
Single-domain
Custom LIB
Multi-domain with
multiple GND pins
MVdd. Specify the power-ground arc pairs.
APL configuration
Multi-domain
MVdd. Specify LEF files for APL-DI.
Multi-domain
AVM configuration
Single-domain
GSC
Multi-domain
Single-domain
MVDD. Specify VDD and GND pin names in
the configuration file, as follows:
VDD_PIN <net names>
GND_PIN <net names>
GEN. ‘OFF’ state is for power-gated blocks
only. To turn regular cells ‘Off’, use
‘DISABLE’.
Liberty Library Syntax Differences for Multiple Vdd/Vss Domains
The following section describes the requirements in multi-Vdd/Vss domain designs for LIB
files.
‘power_supply’ group at library level
The ‘power_supply’ group captures all nominal information on voltage variation. It defines
the default power supply name and the nominal voltage values of the supplies. An
example of the new syntax follows:
Syntax:
power_supply () {
default_power_rail : <domain_name> ;
power_rail (<domain_name>, <voltage>) ;
...
}
Example:
power_supply () {
default_power_rail : VDD ;
power_rail(VDDNW,0.81);
power_rail(VDDC,0.81);
power_rail(VDD,0.81);
power_rail(VDDIN,0.95);
}
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 19
‘rail_connection’ statement in the cell section
The ‘rail_connection’ attribute must define all multiple power supply and ground domain
pins used in a cell. It maps the library power supply name to the cell LEF power pin name
to which it is connected. An example of the new syntax follows:
Syntax:
rail_connection ( <power_pin_name>, <power_domain_name>) ;
rail_connection ( <grnd_pin_name>, <grnd_domain_name> ) ;
...
Example:
rail_connection (VDDS, VDD1) ;
rail_connection (VDD_RET, VDD2);
rail_connection (VSS_A, VSS ;
‘leakage_power’ statement
The ‘leakage_power’ statement defines rail-specific power values for internal/leakage
power. An example of the new syntax follows:
leakage_power () {
value : 2.500000E+00;
power_level : "VDDNW";
}
leakage_power () {
value : 6.740750E+03;
power_level : "VDD";
}
‘input_signal_level’ attribute
The input_signal_level attribute defines the voltage level that should be applied to the
input or inout pin/bus/bundle.
Syntax:
input_signal_level : <domain_name> ;
‘output_signal_level’ attribute
The output_signal_level attribute defines the voltage level that should be applied to the
inout or output pin/bus/bundle.
Syntax:
output_signal_level : <domain_name> ;
internal_power
The internal_power attribute table defines short-circuit energy values during switching for
all power arcs.
power_level
The ‘power_level’ attribute specifies the power supply used to characterize the internal
power of a pin.
Syntax:
power_level : "<domain_name>" ;
Example:
pin ( Z ) {
direction : input ;
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 20
output_signal_level : VDD1;
internal_power() {
power_level : VDD1 ;
power (power_template) {
values ("1, 2, 3, 4");
}
}
} /* end pin */
P/G Arc Definitions in Custom LIB Files
To support cells with multiple Vdd and multiple Vss pins, the P/G arcs must be specified,
which define the current path between each VDD node to the associated GND node pair.
When there are multiple power domains and multiple ground domains, defining the power
domain arcs is required to provide the static and dynamic simulators with the current node
pairs necessary to correctly assign currents.
If a UPF LIB is available, P/G arc info can be obtained from the 'related_power_pin' and
'related_ground_pin' values in LIB. Otherwise, for multiple Vdd/Vss cells P/G arc data
must be provided in a custom LIB.
The 'pgarc' object can be defined at the design level in a custom LIB as follows:
pgarc {
<vdd_pin_name> <vss_pin_name>
...
}
In this case the definition applies to all multiple power supply cells in the design. A pgarc
can also be defined within a cell, in which case it is only applicable to that cell, as follows:
cell <cell_name> {
pgarc {
<vdd_pin_name> <vss_pin_name>
...
}
}
P/G arc definitions in a custom library are not needed for:
• 1 power and N ground pins (N = 1 or more). If one power goes to multiple grounds, the
current for the power pin is assumed to split evenly between the ground arcs. Note
that APL captures the VDD currents, not the VSS currents.
• N power and 1 ground when all N power pins have a profile in the current file (or power
in LIB)
P/G arc definitions in a custom library are needed for:
• N power and M ground pins (N > 1, M > 1)
• N power and 1 ground pin, very common in memory IP, with some power pins that
have no profile in the current file (or missing power in LIB), so that VDD current can be
assigned realistically
For example, assume that you have a library in which most cells have three power
domains, VDD, VDD2 and VDDL, and one ground domain, VSS. However, one cell,
ram_mvdd, has three power domains, VDD, VDD2 and VDDL, and two ground domains,
VSS and VSS2. In the ram_mvdd cell both VDD and VDDL use VSS as ground, while
VDD2 has VSS2 as ground. The primary design pgarc relationships do not require a
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 21
custom LIB file, since there is only one ground domain, but the pgarc relationships must
be defined in a custom LIB file since the ram_mvdd cell also has two grounds as well as
three power domains. See the example custom file format following:
pgarc {
VDD VSS
VDD2 VSS
VDDL VSS
}
cell ram_mvdd {
pgarc {
VDD VSS
VDD2 VSS2
VDDL VSS
}
}
Note that If there is a cell with p/g arcs that are not defined completely in a custom lib,
RedHawk ignores the rest of the p/g arcs for this cell in LEF/LIB. If there are no arcs
defined for this cell in a custom lib, RedHawk can read this information from LEF/LIB
implicitly. However, implicit p/g arcs may not be correct due to the pin types in LEF or
incomplete p/g arc information in LIB. So you must ensure that the p/g arcs defined in
custom libs are complete and correct, since they have the highest priority and override the
p/g arc information from LEF/ LIB. Moreover, custom libs also give you the flexibility to
distribute current only to the power/ground pin(s) in which you are interested.
In the GSR file, the LIB_FILES keyword is required to specify the custom LIB filename
(only one custom *.lib file may be specified):
LIB_FILES {
<lib_filename> CUSTOM
...
}
If you are unsure as to which cells need to be specified in a custom library, then run the
design through ‘setup design’ and look at the data in the file adsRpt/
apache.refCell.noPGArc. Redhawk detects cells with multiple ground pins that have no
custom LIB file and reports them in the report adsRpt/apache.refCell.noPGArc, along with
all power and ground pins for each cell.
Example:
#<cell_name> <vdd_pin_names> <gnd_pin_names>
<SC_ANALOG> <VDD1A VDD2A> <VSS1A VSS2A>
GSR Keywords for Multi-Vdd Domain Designs
P/G arc errors
P/G arc errors can be suppressed using the IGNORE_PGARC_ERROR 1 keyword.
Block_Power_For_Scaling & Block_Power_For Scaling_File keywords
The following keyword syntax should be used for handling cells with either single or
multiple Vdd/Vss supplies in a Block_Power_for_Scaling definition file. However, in
release 6.1 and before the ‘fullchip <full_mVdd_inst_path>’ option cannot be used in a
GSR Block_Power_For_Scaling entry. See section "BLOCK_POWER_FOR_SCALING",
page C-600, for use of this keyword.
Syntax of BLOCK_POWER_FOR_SCALING file:
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 22
{ CELLTYPE <cell_name> <cell_power_Watts> ? <Vdd_pin>?
? <cell_current_A> <Vss_pin> ?
...
[FULLCHIP |<top_block_name>] <full_block_instance_path> <pwr_Watts>
...
fullchip <full_mVdd_inst_path> <power_Watts> ?<VDD_pin>?
? <current_A> <Vss_pin> ?
...
}
APL Requirements for Multi-Vdd Designs
Key elements of APL characterization for multiple Vdd/Vss domain cells are:
• No APL configuration file changes are required for Design Dependent
characterization. RedHawk automatically generates the required files for mVdd
characterization if the LEF/LIB files provided to RedHawk are complete.
• APL-DI requires a new keyword in re-characterization, LEF_FILES. For APL-DI, in the
APL configuration file you must list the LEF files that cover all the multiple Vdd cells to
be characterized, using the syntax:
LEF_FILES {<fileA> ... <fileN> }
• RedHawk uses the LEF files for deriving the P/G arc information. Current profiles and
decap values are computed for the defined power/ground pin arcs in each cell.
Note: The *.current and *.cdev files are in binary format,
• Importing and merging mixed RedHawk release 5.x APL files are supported with some
restrictions. The APL_FILES keyword structure in the GSR file is:
APL_FILES {
<APL_binary_filename>
current
<APL_binary_filename>
cdev
<Avm.conf_filename>
avm
<AVM_binary_filename> current_avm
<AVM_binary_filename> cap_avm
<APL binary filename> pwcap
...
}
Note: In release 7.x <cell>.current files from releases 5.x and 6.x can be mixed on
APL import and merge.
See section "Importing APL Files", page 9-256, for more information.
AVM Configuration File
Specify the power/gnd pins for single or multiple-Vdd/Vss designs using the syntax
described in detail in section "AVM Configuration File", page 9-271.
Data Prep and Using the Automated ‘rh_setup.pl’ Script
This section describes how to specify the necessary input design files, create
configuration and run-time command files to run RedHawk using the automated setup
script, and also describes the recommended directory structure for input and working
files.
Recommended RedHawk Directory Structure
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 23
For each design the following RedHawk directory structure is suggested:
design_data
<design_name>
<RH_run1>
<RH_run2>
<RH_runN>
The contents of the directories for each design are as follows:
design_data/: directory for all user-provided input data
def/: all DEF files for the design, with the extension *.def
Note: *.gz compressed files are also acceptable and are handled by RedHawk
lef/: all LEF files for the design, with the extension *.lef
lib/: all LIB files for the design, with the extension *.lib
tech/: RedHawk technology file
ploc/: voltage location, or pad cell file
The following design_data/ sub-directories are optional:
timing/: timing data files (required for dynamic analysis)
spf/: full-chip or block-level SPEF/DSPF information
vcd/: VCD file
power/: instance-level power data
gds/: GDS file for all memory/macros in the design
gds2def/ or gds2rh/: directory for all GDS translation results files
apl/: directory containing APL/characterization data directories
memory/: directory for HSIM/Spice waveforms
avm/: directory for AVM results
<RH_runX>/: working directory
static/: static analysis results directory
setupApl/: directory in which to create APL data files
dynamic-dvd/: dynamic analysis results for vectorless method
dynamic-vcd/: dynamic analysis results for VCD input method
adsPower/: created by RedHawk for power calculation data
adsRpt/: created by RedHawk for Cmd, Error, Warn, and Log files in
separate folders, as well as links to the latest file of each type
.apache/: created by RedHawk for holding working files for the run
Note: Working files in the .apache directory for any previous RedHawk run are
deleted before starting a new run in the same run directory.
For best operation of the automated setup script the design_data/ directory should have
the structure shown above, but it is not mandatory. The setup script finds the needed files
if the paths are specified.
The working directories static/, dynamic-dvd/, and dynamic-vcd/ can be named as you
prefer, but they should be at the same directory level as those in the design_data/
directory.
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 24
Copy the required input files into the design_data/directory in preparation for setting up
and running RedHawk.
Note: If you have a file named .redhawkrc in your home directory or in the current
working directory that has one or more standard RedHawk TCL commands in it,
RedHawk executes that file before it executes any other RedHawk command.
Automated Script rh_setup.pl
Setting up the Automated TCL Setup Script
In order to run Redhawk you must prepare an appropriate Global System Requirements
(GSR) file. It is convenient to compile a command script to run each step desired. To
automate these tasks, RedHawk provides the rh_setup.pl utility to assist in checking for
the needed files, setting up the GSR file, and preparing a command file for running
RedHawk the first time. The main features of using the setup script are:
• rh_setup.pl creates all the files needed to launch RedHawk simulation, either static,
dynamic, or special evaluations, as follows:
•
<design>.gsr - Global System Requirements keyword settings
•
run_static.tcl - static run script
•
run_dynamic.tcl - dynamic run script
•
run_signalEM.tcl - run script for signal EM analysis
•
run _lowpower.tcl - ramp-up run script for low power analysis
• Parameter values used in the generated GSR file can come from four sources, in the
following priority, highest to lowest:
a. from rh_setup.pl command line parameters
b. from parameters of previous invocation of rh_setup.pl saved in rh_setup.init
file
c. from template GSR file pointed by variable $APACHEDA_TEMPLATE_GSR,
if this file exists
d. from default values preset by RedHawk
• You don’t need to remember the exact syntax of the GSR keywords. The GSR
keywords generated with rh_setup will be syntactically correct.
• The script locates files automatically if the data directory structure used is as
recommended (as described in the previous section). For example, if DEF files are
found in the ../../data/def/*.def directory, they are all included in the generated GSR.
• The script supports UNIX wildcards in searching for required files in non-standard
locations. For example, in using the file search pattern -def *.def */*.def */*/
*.def, all DEF files in any directory up to two levels below will be found. If a required
file is found with the same name in more than one directory, the file in the first directory
specified is used.
• A central CAD engineering group can provide default values for specific RedHawk
parameters (for example, the value of the desired dynamic simulation step) by means
of a “template GSR” file. Use the global environmental variable
$APACHEDA_TEMPLATE_GSR to point to the template GSR file before running the
setup script.
• Input to the script can be done incrementally. You can invoke the script with one or
more command line arguments, and the script will prompt you if any of the required
arguments are missing (for example, the power net name). You can re-invoke the
script and add or change arguments, until all required information is complete. Then
rh_setup.pl checks that all input files exist and creates the necessary files as listed
above.
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 25
Using the rh_setup Utility
The procedure for using the setup script is as follows:
1.
The script rh_setup.pl has the UNIX command line format:
rh_setup.pl <command_options> [<values>]
...
2.
When you execute the script command with no options
rh_setup.pl
definitions of the required options, parameter values and files are displayed, as
well as those that are optional. These options are:
-top_cell - Required - name of the top cell in the design as specified in the
corresponding DEF file (see DESIGN section of the DEF file).
-mode - the analysis mode, either ‘early_analysis’ or ‘sign_off_analysis’. By
default - ‘sign_off_analysis’.
-analysis - the analysis type, ‘static’, ‘dynamic’, ‘low_power’, or ‘signalEM’. By
default, TCL files for static and dynamic are created.
-vdd_nets - Required. Specifies Vdd net names and nominal voltage values
-vss_nets - Vss net names (no voltage specification). Optional input for static or
signalEM runs, but required for dynamic or lowpower runs.
-frequency - Required. Defines the dominant operating frequency of the design
(Hz), that is, the frequency that consumes a majority of the power in the
design. If there is more than one dominant frequency, specify the lower
frequency. See the GSR keyword description, section "FREQUENCY", page
C-590.
-tech_file - Required. Defines dielectrics, metal layer parameters and vias in the
tech/ directory. If not specified, the default path in rh_setup.defaults is
searched.
-def_files - Optional if required files are in the def/ directory. Specifies DEF files
for top module, hierarchical and IP blocks.
-lef_files - Optional if required files are in the lef/ directory. Specifies files for
technology, library cells, hierarchical and IP blocks.
-lib_files - Optional if required files are in the lib/ directory. Specifies Synopsys
Liberty format (.lib) timing libraries. Files not needed for an early analysis or
static runs, but required for dynamic, lowpower and sign-off runs.
-pad_files - Required. The automated flow picks files up from ploc/ directory, or
you can specify the option ‘def_pins’ to use DEF pins as power pads for block
level analysis, which forces RedHawk to place one pad in the center of every
Vdd/Vss pin described in top-level DEF file. The RedHawk PLOC file
provides x,y coordinates for ideal voltage sources. One of the pad files is
required.
-sta_files - Optional if required files are in the timing/ directory. Specifies timing
files from STA, described in Chapter 19, "Timing File Creation Using Apache
Timing Engine (ATE)". Files are required input for a sign_off_analysis run.
-spf_files - Optional if required files are in the spf/ directory. Specifies hierarchical
SPEF or DSPF files of post-layout parasitics.
-apl_files - RedHawk cell.current files containing current profiles from APL
characterization. Required if the mode is ‘sign_off’ and the analysis type is
‘dynamic’ or ‘lowpower’.
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 26
-aplcap_files - RedHawk cell.cdev device capacitance file from APL
characterization. Required if the mode is ‘sign_off’ and the analysis type is
‘dynamic’ or ‘lowpower’.
-aplpwcap_files - RedHawk cell.pwcap PWL decap file from APL power up
characterization. Required if the mode is ‘sign_off’ and the analysis type is
‘lowpower’.
-gds_dirs - Optional if required files are in the gds2def/ gds2rh/ directory.
Specifies all LEF, DEF, and PRATION files created by gds2def or gds2rh in
specified directories.
-toggle - Optional. The automated flow assigns a default value.
-input_transition - Optional. The automated flow assigns a default value.
Note: You may abbreviate command options, as long as they are unambiguous. For
example, you may use the option ‘-top’ as an abbreviation for ‘-top_cell’.
3.
Once the input data has been set up in the design_data/ directory, the rh_setup
command can be run anywhere, specifying the required values, such as the
following example of input syntax:
rh_setup.pl -top_cell <name of the design>
-vdd_nets <name of VDD net> <value>
-vss_nets <names of VSS nets>
-pad_files <name of pad/pcell file in ploc/ dir,
OR specify def_pins for DEF pin-based analysis>
-def_files <path and filenames>
-lef_files <path and filenames>
-lib_files <path and filenames>
-tech_file <path and filenames>
Assuming all input information is found, this invocation creates the necessary run
files:
4.
The rh_setup.pl utility preserves all input values in a text file called rh_setup.init in
the same directory in which the utility is invoked, so you can invoke the utility
multiple times, each time providing one or more of the required arguments, until all
the required data requirements are satisfied. At that point the run files are created.
Also, you can edit the text file rh_setup.init file directly.
5.
To execute the command scripts generated by rh_setup.pl, use the TCL command
option -f, such as:
redhawk -f [ run_static.tcl | run_dynamic.tcl ]
Special GSR Keywords
Default values are maintained for some important GSR keywords:
• DYNAMIC_SIMULATION_TIME 2.56e9
• DYNAMIC_TIME_STEP 50ps - for an early_analysis run, and
DYNAMIC_TIME_STEP 20ps - for sign_off run.
• INPUT_TRANSITION 200ps
• TOGGLE_RATE 0.3 (non-clock)
The following GSR keywords are taken into account only based on the analysis mode or
kept commented in the GSR file.
• BLOCK_POWER_ASSIGNMENT - turned on during prototype analysis and prompts
the user to edit their requirements
• SWITCH_MODEL_FILE - a file automatically generated by aplsw utility and added to
the GSR section during a low power analysis run.
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 27
GDS2DEF Setup with the ‘gds_setup.pl’ Script
The RedHawk gds_setup.pl script helps automate the generation of necessary
configuration files and running the gds2def extraction utility for multiple cells, in serial or
parallel. The script accepts user data from two sources:
• the \$cwd/gds_setup.init file
• command line arguments, which are saved in gds_setup.init by the script
As with rh_setup, input to the script is incremental. First, the script examines LEF and
GDS files to ensure that cells being extracted have both GDS and LEF descriptions.
To create the proper setup data you may invoke the script with one or more options, then
re-invoke the script to add or change information at any time, until all required gds2def
setup information is complete.
Using the gds_setup Utility
The procedure for using the setup script is as follows:
1.
The script gds_setup.pl has the UNIX command line format:
gds_setup.pl <command_options> [<values>]
...
2.
When you execute the script command with no options
gds_setup.pl
definitions of the required options, parameter values and files are displayed, as
well as those that are optional. These options are:
-vdd_nets - Required. Specifies names of Vdd nets.
Example: -vdd_nets VDD vdda vddb, VDD_SOC
Segments labeled in GDS with 'vdda' and 'vddb' appear as 'VDD' in
generated DEF file. 'VDD_SOC' is not renamed.
-vss_nets - Required. Specifies names of Vss nets.
Example: -vss_nets VSS vssa vssb, VSS_SOC
Segments labeled in GDS with 'vssa' and 'vssb' appear as 'VSS' in generated
DEF file. 'VSS_SOC' is not renamed.
-cell_names - specifies cell names to be processed. When not specified, gds2def
runs for cells for which the LEF and GDS data are provided.
-map_file - Required. Specifies the location of layer map file.
-lef_files - Required. Specifies individual LEF files, or specify *.lef to take in all
LEF files.
Example: -lef_files ../lef/hdsg1_10240x32cm16.lef ../lef/
hdsg1_2048x40cm8bw.lef
-lef_files ../*.lef
-gds_files - Required. Specifies individual GDS files, or specify *.gds to take in all
GDS files.
Example: -gds_files ../gds/hdsg1_10240x32cm16.gds ../gds/
hdsg1_2048x40cm8bw.gds
Example: -gds_files ../gds/*.gds
-mem [ on | off ] - If set to 'on' indicates gds2def run is for a memory. Off by
default.
-start_layer - specifies starting layer for extraction.
Example: -start_layer m1
- core_start_layer - specifies starting layer for core extraction.
Example: -core_start_layer m3
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 28
-options_file - specifies an input file containing a list of additional gds2def options
to use.
-norun [ on | off ] - If set to 'On' creates only the config files and does not run
gds2def. Off by default.
-bsub_run [ on | off ] - If set to ‘on’, submits the jobs to LSF farms for parallel
execution on multiple machines. Off by default.
- bsub_command_file - specifies a file containing the ‘bsub’ command with
additional options defining multiple machine execution requirements. If not
specified, ‘bsub’ alone is used as the command.
3.
Edit and update the values of the setup file options as required (see Figure 3-3,
below), then run gds2def.
gds_setup.pl -vdd_nets VDD vdd vddx vddy, VDD_SOC \\
-vss_nets VSS gnd vss \\
-map_file gds_layer.map \\
-cell_names MEM22x64 MEM22x32 \\
-lef_files lef_dir/*.lef \\
-gds_files gds_dir/*.gds \\
-mem on \\
-norun on
-bsub_run on
-bsub_command_file bsub_options.txt
Figure 3-3
Sample gds_setup.pl file
Outputs
The 'OUTPUT' directory contains the DEF, LEF and PRATIO files generated from the
gds2def runs, and the ‘LOG’ directory contains cell-specific log directories, which in turn
contain the log files.
The ‘top_report’ file contains information on whether the cells have passed gds2def
processing or not, as shown the example output in Figure 3-4:
------------------------------------------------------------------hdsg1_10240x32cm16 Done
rfsg1_256x32cm4
Done
rfsg2_44x128cm2bw
Fail
...
-------------------------------------------------------------------
Figure 3-4
Sample ‘top_report’ file of gds2def results
Manually Importing Design Data
The previous section describes how to use scripts to prepare the input files to run
RedHawk. If you do not want to use the scripts, design data and configuration files can be
prepared manually using either the TCL command line or the GUI. These commands and
procedures are described in the following sections.
Command Line Data Import
TCL commands for loading design data are shown in Table 3-4. Note that putting all
design data into the GSR file and then importing the GSR is the recommended method for
performing all design data input. See section "Global System Requirements File (*.gsr)",
page C-550, for more information about the contents and syntax of the GSR file.
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
Table 3-4
RedHawk User Manual
| 29
Commands for Loading Design Data
TCL
Purpose
import gsr
<InputFileName>
Imports design information in the .gsr file.
import tech
<InputFileName>
Imports .tech file. (Recommend using
TECH_FILE keyword in GSR file.)
import lef
<InputFileName>
Imports .lef file. (Recommend using LEF_FILES
keyword in GSR file.)
import lib
<InputFileName>
Imports .libs file. (Recommend using LIB_FILES
keyword in GSR file.)
import def
<InputFileName>
Imports .def file. (Recommend using
DEF_FILES keyword in GSR file.)
import pad
<InputFileName>
Imports pad cell .pcell, pad instance .pad, or pad
location .ploc file. (Recommend using
PAD_FILES keyword in GSR file.)
import guiconf
<InputFileName>
Imports GUI configuration file (optional)
import eco
<InputFileName>
Imports previous eco file (optional)
setup design
Sets up database after importing design data.
import apl
<InputFileName>
Imports <cell>.current file generated by APL
(dynamic).
import apl -c
<InputFileName>
Imports <cell>.cdev file generated by APL
(dynamic).
import avm
<configFileName>
Generates and imports memory model,
vmemory.current and vmemory.cdev file from
the config file.
import db
<InputFileName>
Imports the previously generated results after
setup, extraction, or simulation.
You are now ready to load the technology and design information and run the RedHawk
static IR drop analysis.
1.
See Appendix A, "Setting Up the RedHawk Environment", for procedures for
setting up license, environment and path variables for accessing the RedHawk
binaries.
2.
Type the following command in a UNIX shell:
redhawk
This command sends execution messages on the screen, while the following
saves execution messages to apache.log:
redhawk >& apache.log&
The RedHawk GUI is displayed.
ANSYS, Inc.
3.
To prepare the design data using the command line, compile the required input
files as described in the previous section and in Appendix C, "File Definitions".
4.
If all needed input files are referenced in or included in the GSR file, then use:
import gsr <filename>
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 30
5.
If all needed files are not referenced in the GSR, then use the TCL commands in
the table above to import the required files, such as LEF, DEF, LIB, and *.tech.
6.
After files are imported, to set up the design database, type:
setup design
The following data integrity checks insure RedHawk data are appropriate:
a. Frequency not over 50GHz.
b. Transition times not over 5ns.
c. Simulation time or frame-size not over 200ns for dynamic voltage drop
analysis, and not over 2us for power-up analysis.
d. Pre-parsing of SPICE subcircuits makes sure there are no syntax or include
errors, and no un-matched nodes with .ploc.
e. Pre-parsing of switch models makes sure there are no syntax errors and
values are reasonable.
GUI Data Loading
1.
See Appendix A, "Setting Up the RedHawk Environment", for procedures for
setting up license, environment and path variables for accessing the RedHawk
binaries.
2.
To prepare the design data using the GUI, first bring up the display by starting
RedHawk from the command line:
redhawk
The GUI will be displayed.
3.
Select the menu command File -> Import Design Data.
The ‘Import Design Data’ dialog box is displayed.
4.
Click on Select Filename button for each input file required, and enter the path
and filename in the dialog box that is displayed.
If all input files have the same path as the *.gsr file, you can click on the Use
Same Prefix button at the bottom of the form to automatically enter the same path
for all input files.
5.
Complete the paths and filenames for all input files.
6.
Make sure that the Database setup button is depressed.
7.
Click on OK to load all files and set up the design database.
When loading the DEF files you can use either the VDD or VSS DEFs for faster
VDD-only or VSS-only analysis.
8.
After all files have been loaded, take a look at the layout view that appears.
- Zoom in using the right mouse button. Change other view aspects with the ‘View’
buttons on the right side of the display.
- Navigate using the Mini-view panel on the lower right side.
- Turn layer view On/Off by using the View Layers button in the ‘Configuration’
panel on the right side.
- Select design objects using the left mouse button. After selection, the object is
highlighted in yellow.
To continue the analysis procedure, see Chapter 4, "Power Calculation, Static IR Drop
and EM Analysis".
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 31
RedHawk Configuration Files
In addition to input data files, some RedHawk functions and utilities have required
configuration files that must be prepared, as listed in Table 3-5.
Table 3-5
RedHawk Configuration Files
Filename
Purpose
apl_config_file
Used by Apache Power Library (APL) program
to characterize cells, decaps, I/Os, and
memories for dynamic voltage drop analysis.
See Chapter 9, APL Characterization.
switch_config_file
Used by aplsw utility to characterize header/
footer switches and/or generate piecewise linear
current models for switches used in low power
designs. See Chapter 13, Low Power Analysis.
avm_config_file
Used by avm (import avm) utility to generate
switching current profile for memories.
sim2iprof_config_file
Used by the sim2iprof utility to extract Read/
Write/Standby signals from third-party simulation
output and to generate current profile
waveforms. See Appendix E.
gds2rh_config_file/
Used by gds2rh utility to convert GDSII file to
DEF format. See Appendix E.
Used by gds2rh -m utility to generate detailed
view of memory and other IP. See Appendix E.
psi.ctl
The PJX configuration and control file supports
the PJX timing and clock tree analysis program.
See Chapter 8.
Distributed Machine Processing (DMP)
At launch, DMP splits the design into several partitions based on user specifications.
RedHawk then performs all analysis steps (setup design / extraction / simulation) for
different partitions on different machines. A “Master” job is also launched to monitor and
communicate with the partitions/slaves. The number of jobs launched = Number of
partitions (slaves) + 1 Master.
Every partition communicates with other partitions and creates a reduced view for the rest
of the design-- thus accuracy is maintained. This technology leverages multiple
computing resources to achieve performance and capacity improvements. Key features
are:
• DMP supported over LSF/SSH/SGE/RTDA grid types.
• DMP is targeted for aggressive RedHawk performance improvement and memory
reduction, such as 3~5X in top level runs, depending on design styles and machines
used.
• Voltage drop and EM results are the same as in the traditional flow.
• DMP demonstrates benefits in:
• Designs with many instances and very high node counts.
• Designs in which RedHawk simulation performance is a bottleneck.
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
RedHawk User Manual
| 32
• No additional GSR keywords or TCL commands are required to launch DMP.
The diagram below illustrates how DMP methodology is designed.
Optional related GSR keywords that can be used are
FAST_DEF_READ <number>
Provides parallel DEF read-in Default – none
Example: FAST_DEF_READ 10
REPORT_REDUCTION [ off / normal / max ]
Value ‘max’ helps reduce disk space consumption.
Default: off
Optional TCL commands for generating reports are described following. DMP-DB does
not generate power reports by default. To generate power reports use:
report power –all
To report instance-based DvD (these reports are NOT generated when
REPORT_REDUCTION max is set), use:
report dvd –instance ?-o <output_file> ?
DMP-supported Flows
The following types of flows are supported by DMP:
• Static and Dynamic - Gridcheck/res_calc/SPT, Vectorless IR/DvD, Global Toggle Rate,
Block Power For Scaling, Block Toggle Rate, State Propagation, Vectorless Scan,
Fullchip, Block RTL/Gate VCD (Event and State Propagation), True Mixed Mode
(Gate+RTL VCD+ Vectorless), EM (Power and Signal)
• Package - WBS, Spice model, CPA, S-Param package
• FAO - Missing Via checks
• CPM
• CTM
• SAIF Input
• MBFF support
ANSYS, Inc.
CHAPTER 3 — User Interface and Data Preparation
RedHawk Data Preparation - Static and Dynamic Analysis
• CMM
• Pin-based MMX BPA from CMM
• Explorer
ANSYS, Inc.
RedHawk User Manual
| 33
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Introduction
RedHawk User Manual
| 34
Chapter 4
Power Calculation, Static IR Drop
and EM Analysis
Introduction
This chapter describes how to run power calculation, static IR voltage drop and
electromigration (EM) analyses in RedHawk-S, following the data preparation steps
described in the Chapter 3.
An outline of the static IR drop and EM analysis flow is shown in Figure 4-1.
Library
Technology
Design Specific
LEF files
.LIB files
DEF files
MW db
Tech
File
Pad cell
Pin Loc
RedHawk-S
DSPF or
SPEF
GSR
File
RedHawk: Single Kernel Engine
• Power Calculation
• Power Grid Extraction
• Static Analysis
ASCII Reports
Contour Maps
Voltage
Report
Voltage
Map
EM
Report
EM
Map
Power
Report
Power
Map
Figure 4-1
STA
File
RedHawk-S (static) IR drop flow
The following are the key steps in the static IR drop and EM analysis flow.
ANSYS, Inc.
1.
Prepare design data files (see Chapter 3, "User Interface and Data Preparation").
2.
Import design data using the automated setup script or the GSR file (see Chapter
3)
3.
Perform power calculation (see following section).
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 35
4.
Perform power grid extraction for R network (see section "Power Grid Resistance
Extraction", page 4-52).
5.
Evaluate power/ground grid weakness (see section "Examining Power/Ground
Grid Weakness", page 4-53)
6.
Define pad and package constraints (see section "Defining Pad and Package
Parameters", page 4-56).
7.
Perform static IR voltage drop and EM analysis (see section "Running RedHawk-S
(Static IR/EM Analysis)", page 4-57).
8.
Review static IR/EM summary reports and evaluate what other information is
needed from the analysis.
9.
Explore solutions to reduce excessive static IR drop with the RedHawk power grid
Fixing and Optimization tools (see Chapter 7, "Fixing and Optimizing Grid and
Power Performance").
Steps 3 through 8 are described in the following sections. After importing all design data,
the full chip view should be displayed. Continue with the analysis procedure in the
following sections.
Power Calculation
Power calculation uses information from a number of design files to evaluate the average
cycle power consumption of all cell instances for both flat and hierarchical designs. The
calculated power is used for both static and dynamic analysis. It then displays the power
distribution results in a graphical “map” of the design. Power calculation is typically
performed once for each design, and the results are summarized in several power
reports. The power reported by power calculation is “ideal” power, based on the supply
voltage specified in the VDD_NETS keyword in the GSR, or otherwise the nominal
voltage specified in the LIB file. RedHawk honors .lib negative internal energy values for
power calculation. The computed total power also includes power due to instances not
connected to power nets or instance power pins connected to non-Vdd nets, hence the
actual power may be different due to instances not connected in the design.
The setup procedure for power calculation involves providing the best design information
available to RedHawk, in order to get the most accurate results. Three methods are
available for modeling chip activity and setting up power calculation:
• vectorless, when no VCD file is available, and toggle-based state propagation
methods are used.
• event-propagation, using full chip VCD file data
Power calculation is propagated through flip-flops in both State Propagation and Event
Propagation methodology, which is enabled in both vectorless and RTL-VCD flows.
An outline of how to select the power calculation method based on the input data
available is presented in Figure 4-2. The two primary propagation flows are shown in
Figure 4-3.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
Figure 4-2
Selection of power calculation method
Figure 4-3
Event propagation and State propagation flows
The setup procedures and information needed by RedHawk for the different types of
activity modeling are described in the following sections.
Setup for Vectorless Power Calculation
When no VCD file is available, an estimate of the toggle rate should be made, using
values from a group of GSR keywords, as described in the following paragraphs.
ANSYS, Inc.
| 36
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 37
Setting Frequency and Clock Parameters
Use the following GSR keywords to specify the primary design frequency and clocks.
• STA_FILE
If this keyword is defined, the power for each net is calculated from the transition
times (“slew”) of each instance’s input/output pins, using the clock frequency
domain for all the instances that are specified in the STA output file, instead of
deriving its value from the CLOCK_ROOTS keyword.
For instances not defined in the STA output file or VCD file, the frequency of the
instance is set to zero. Use the frequency specified by the
FREQ_OF_MISSING_INSTANCES option in STA_FILE keyword for those
instances that are not covered in the STA file. FREQ_OF_MISSING_INSTANCES
is not required to be specified unless you know that STA does not cover the design
well. If the EXTRACT_CLOCK_NETWORK option is specified as 1 (default 0),
clockroots defined in the clock section of the STA output file are used for clockroot
tracing, instead of the STA-identified clock instances.
See Chapter 19, "Timing File Creation Using Apache Timing Engine (ATE)" for
details on how to generate the STA output file. Required for dynamic analysis;
Optional for static analysis.
Syntax:
STA_FILE
{
FREQ_OF_MISSING_INSTANCES <frequency in hertz>
EXTRACT_CLOCK_NETWORK [ 0 |1 ]
<top_level_block_name> <sta_output_file>
}
where
FREQ_OF_MISSING_INSTANCES <frequency in hertz> : specifies the operating
frequency for instances not in the STA file but in the design. Default: 0.
EXTRACT_CLOCK_NETWORK : when set to 1, specifies that the clock network
is extracted from clock roots defined in STA
<top_level_block_name>: the top level block name of the chip
<sta_output_file> : the file generated from STA analysis. See Chapter 19, "Timing
File Creation Using Apache Timing Engine (ATE)"
• CLOCK_ROOTS
Traces the nets from a specified clock root and finds the respective clock domain
for all the nets and instances. Specifies the names of the clock roots (either net
name or pin name) and the frequency. No wildcard matching is supported for this
keyword. If STA_FILE is specified, CLOCK_ROOTS is not used. Optional. Default:
None.
Syntax:
CLOCK_ROOTS
{
<clock_root_name> <freq in Hz>
...
}
• FREQUENCY
Defines the dominant operating frequency on the chip, or the lowest frequency that
includes a majority of the power consumption on the chip. More specifically, for a
design in which there are several frequencies that consume significant power, the
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 38
frequency to be specified is the frequency for which less than 10% of the chip
power is consumed at lower frequencies. For example, assume that there are three
significant frequencies on the chip, and they consume the following power: 100
MHz (5mw), 200 MHz (20mw), and 400 Mz (70mw). The FREQUENCY value to be
specified in this case would be 200 MHz, even though a majority of the power is
consumed at 400 MHz. Required. Default: none.
Syntax:
FREQUENCY <value in Hertz>
Setting the Switching State of Instances and Blocks
Using the Global Switching Configuration (GSC) file, appropriate switching states for
instances and blocks can be set, such as HIGH, LOW, STANDBY, DISABLE and OFF, to
achieve more controlled power calculation. Using the GSC_FILE to establish switching
states for power calculation is described below.
The GSC filename is specified using the GSR keyword ‘GSC_FILE <gsc_filename>’.
The syntax of the GSC file is:
[<blockName> | <instanceName> ] ? <domain_name>?
[ UNDECIDED | TOGGLE |HIGH | LOW | POWERUP | POWERDOWN |
STANDBY | DISABLE | OFF | <custom_state_name> ]
...
Refer to section "Global Switching Configuration (GSC) File", page C-548, for details on
the syntax and use of the GSC file.
Note that only HIGH, LOW, TOGGLE, STANDBY, DISABLE, and OFF states affect power
calculation results.
If an instance has a power specified using the GSR keywords INSTANCE_POWER_FILE
or BLOCK_POWER_FOR_SCALING, RedHawk uses these power values, even if it has
been assigned a switching mode in GSC_FILE. This can be overridden by setting
‘GSC_OVERRIDE_IPF 1’ in the GSR (the default value is 0).
Setting the Toggle Rate
The toggle rate for an instance is defined as the average sum of the state changes from 0
->1 and 1 ->0 within a clock cycle, with respect to the net's clock domain. For the most
accurate power analysis you must compile and input the best toggle rate information
available to indicate the average switching performance of the instances in the design.
The general priorities for setting toggle rates are listed below, from highest to lowest.
However, because there are interactions between values chosen for each keyword in a
specific design, see the individual keyword descriptions following, or in Appendix C, for
more information about toggle rate specification and instance toggle rate estimation. The
priorities for toggle rate setting are (GSR keywords, unless otherwise noted; see section
"Global System Requirements File (*.gsr)", page C-550, for full keyword syntax):
1.
INSTANCE_POWER_FILE
2.
BLOCK_POWER_FOR_SCALING or BLOCK_POWER_FOR_SCALING_FILE
3.
GSC_FILE
If the GSR keyword GSC_OVERRIDE_IPF is set to 1 and there is no VCD setting,
the GSC_FILE has priority over IPF and BPFS settings. Also, if a VCD file setting
exists, the GSC value overrides the VCD for any instances specified.
4.
INSTANCE_TOGGLE_RATE or INSTANCE_TOGGLE_RATE_FILE
With the GSR key word ITR_OVERRIDE_BPFS set to 1,
INSTANCE_TOGGLE_RATE will have higher priority than
BLOCK_POWER_FOR_SCALING.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
5.
NET_TOGGLE_RATE or NET_TOGGLE_RATE_FILE or SAIF_FILE
6.
VCD_FILE
| 39
With the GSR key word POWER_VCD_OVERRIDE_IPF set to 1, VCD will have
higher priority than INSTANCE_POWER_FILE.
7.
BLOCK_TOGGLE_RATE, BLOCK_TOGGLE_RATE_FILE, or
CELL_TOGGLE_RATE
8.
STATE_PROPAGATION
a. VCD-based STATE_PROPAGATION starts from the toggle rate derived from
the VCD file.
b. Vectorless state propagation uses the toggle rate derived from evaluating
parameters in items 3-7 and 9-11.
c. For details on use of the STATE_PROPAGATION keyword, see section
"STATE_PROPAGATION", page C-625.
9.
A signal specified as 'CONST <pin>' in the STA_FILE has a toggle rate of 0.
10. CLOCK_DOMAIN_TOGGLE_RATE
11. POWER_DOMAIN_TOGGLE_RATE
12. TOGGLE_RATE_RATIO_COMB_FF <ratio>
13. TOGGLE_RATE
In general the highest priority keyword that has a toggle rate value for an instance is used
in power calculation, and all other values are ignored.
Note that any of the keyword-estimated toggle rate values are ignored when they are
specified in a VCD file, as described in the next section on setting up for VCD power
calculation.
• INSTANCE_TOGGLE_RATE_FILE
Specifies the instance toggle rate file, which provides toggle rates for instances on
the chip. The format of the file is as described in the INSTANCE_TOGGLE_RATE
keyword syntax. Optional. Default: None.
Syntax:
INSTANCE_TOGGLE_RATE_FILE
{
<instance_toggle_rate_file>
}
• INSTANCE_TOGGLE_RATE
Specifies average toggle rates for instances in the design. If there are a lot of
instances in the chip, using this keyword is recommended, rather than using
BLOCK_TOGGLE_RATE or BLOCK_TOGGLE_RATE_FILE keywords. No
wildcard (*) is supported. Whether a clock network instance or not, the first TR entry
applies to the network toggle rate, and the second, if present, applies to the clock
buffer and clock pin toggle rate. If only one TR value is specified, it is used for the
output/signal toggle rates associated with the instance. Optional. Default: None.
Syntax:
INSTANCE_TOGGLE_RATE
{
<non-clock_inst_name> <output_TR> ?<clock_pin_TR>?
<clock_network_inst_name> <output_TR> ?<clock_pin_TR>?
...
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 40
}
• BLOCK_TOGGLE_RATE_FILE
Specifies the file containing toggle rates for blocks/instances that are defined in the
DEF file. The format of the file is as described in the BLOCK_TOGGLE_RATE
keyword syntax. Optional. Default: None.
Syntax:
BLOCK_TOGGLE_RATE_FILE
{
<toggle_rate_filename>
}
• BLOCK_TOGGLE_RATE
Defines the default toggle rate for nets in a user-specified block, or instances that
are not otherwise specified. The block or instances should be defined in the DEF
files. The <block-instance_name> specification can take a wildcard ‘*’. For
example, ABC* matches all block/instance names starting with ABC. The
<clock_network_TR> entry for a block applies to clock pins and clock buffer
outputs. For an instance, whether a clock network instance or not, the first TR entry
applies to the network toggle rate, and the second, if present, applies to the clock
buffer and clock pin toggle rate. Optional. Default: None.
Syntax:
BLOCK_TOGGLE_RATE
{
<block-instance_name> <non-clock_TR> ?<clock_network_TR>?
<non-clock_inst_name> <output_TR> ?<clock_pin_TR>?
<clock_network_inst_name> <output_TR> ?<clock_pin_TR>?
...
}
• TOGGLE_RATE
Specifies the default toggle rate for nets in the design that are not otherwise
specified. The rate is the product of the probability that the nets will toggle times the
actual clock toggle rate. Toggle rate is defined as the average sum of the state
changes from 0->1 and 1->0 within a clock cycle with respect to the net's clock
domain. For example, a clock net has a toggle rate of 2.0 with respect to its clock
domain, since the net switches once from 0->1 and once 1->0 within a clock cycle.
Note that if there is no power consumption table in .lib the toggle rate is taken from
TOGGLE_RATE, and charge is scaled to meet power. Optional. Default: 0.3.
Syntax:
TOGGLE_RATE <non_clock_TR> ?<clock_network_TR>?
where
<non_clock_TR> : defines the probability for nets switching during a clock cycle
<clock_network_TR>: applies to both clock pins and to clock buffer outputs-- the
actual network clock toggle rate (Default: 2.0)
Setting Toggle Rate Scaling Parameters
Since the power consumption of any part of the design is a linear function of the average
toggle rate, scaling parameters allow RedHawk to adjust the effective toggle rates based
on known and calculated power values. For example, if a block has known power
consumption PK, and the calculated power based on an estimated toggle rate TRE1 is
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 41
PC1, then the program can scale the estimated toggle rate to TRe2 and recalculate power
PC2 so that it is equivalent to the known power consumption, as shown in the following
equations:
TRE2 /TRE1 = PC2/PC1
(EQ 1)
we want PC2 =PK
(EQ 2)
therefore, set TRE2 = TRE1*PK/PC1
(EQ 3)
So by providing known power consumption values for individual blocks and instances
RedHawk can scale their toggle rates accordingly for analysis and make a much more
accurate power calculation.
The power scaling keywords are described in the following paragraphs.
• BLOCK_POWER_FOR_SCALING_FILE (GSR Keyword)
Specifies the absolute or relative path from RedHawk run directory that contains the
power specification, as in BLOCK_POWER_FOR_SCALING keyword. Optional;
default: None
Syntax:
BLOCK_POWER_FOR_SCALING_FILE
{
<Block_Power_FilePathName >
}
• BLOCK_POWER_FOR_SCALING (GSR Keyword)
Performs scaling of the estimated toggle rate for the block, instance, cell, or
celltype, based on user-supplied known power data. Top-level block is specified for
a flat design. Note that to avoid confusion a top cell name should not be the same
as an included cell name. Pin-specific Vdd power and Vss current can be specified
for multiple Vdd/Vss designs. Optional. Default: none.
Syntax:
BLOCK_POWER_FOR_SCALING {
CELLTYPE <cell_name> [<pwr_W> ?<Vdd_pin>? |
<cell_current_A> ?<Vss_pin> ? ]
...
[FULLCHIP |<top_block_name>] <full_leaf_inst_path> <pwr_W>
[FULLCHIP |<top_block_name>] <full_block_path> <pwr_W>
? <domain> ?
...
[FULLCHIP |<top_block_name>] <full_mVdd_inst_path>
[<pwr_W> ?<VDD_pin>? | <current_A> ?<Vss_pin>?]
...
CELLS [ comb | ff_latch | mem | clockinst | io ] <pwr_W>
...
BLOCK [<full_block_path> <pwr_W> ?<domain>? |
<full_leaf_inst_path> <pwr_W> ? <pin> ? ]
...
}
See section "BLOCK_POWER_FOR_SCALING", page C-600, for more detailed
information on using this keyword.
• SCALE_CLOCK_POWER (GSR Keyword)
Selects scaling of toggle rate for clock network components. If set to zero, clock
nets are not scaled. Optional. Default: 1.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 42
Syntax:
SCALE_CLOCK_POWER [0|1]
• INSTANCE_POWER_FILE (GSR Keyword)
Defines absolute or relative path from RedHawk run directory to the power file,
which contains a list of instances and their power consumption, in the following
format: <instance_name> <power in Watts>. For instances not specified in the
power file, the power is assumed to be zero. Therefore all significant power
consumers should be specified, or none. Optional; default: None.
Syntax:
INSTANCE_POWER_FILE
{
<instance_power_file_path-name>
}
• GSC_OVERRIDE_IPF (GSR Keyword)
When set to 1, overrides settings of BLOCK_POWER_FOR_SCALING and
BLOCK_POWER_FOR_SCALING_FILE, INSTANCE_TOGGLE_RATE,
BLOCK_TOGGLE_RATE, and TOGGLE_RATE, and the toggle rate value set in the
GSC is honored. Optional. Default: 0.
Syntax:
GSC_OVERRIDE_IPF [ 0 | 1 ]
• Global Switching Configuration (GSC) File
Instances that have states defined in the GSC file are handled by power calculation
in the following ways:
High – considers power when the instance switches from 0 to 1
Low – considers power when the instance switches from 1 to 0
Standby – averages power when a clock pin switches from 0 to 1 or 1 to 0
Disable – considers leakage power only
Off – sets all power to zero
Using both clock and signal toggle rates in power calculation
By default both the signal toggle rate and clock toggle rate are scaled uniformly to reach
specified total power consumption; if you want to meet power targets by scaling the signal
toggle rate only, set SCALE_CLOCK_POWER to 0 in the GSR. (Clock power includes
both clock network power and clock pin power.) However, the power is not scaled to a
value below specified leakage power.
If the specified block power is smaller than the RedHawk computed block leakage power,
and SCALE_CLOCK_POWER is set to 1 (default), the power values are scaled uniformly
to meet the specified block power.
Setting Extraction Parameters
The following keywords set parameters for extraction.
• CELL_RC_FILE
Defines the SPEF/DSPF interconnect parasitics file for a flat or hierarchical design.
For extraction of detailed RC used in dynamic voltage drop analysis, set the
suboption EXTRACT_RC to 1, which is its default. Otherwise, for static IR-drop
analysis, optionally set EXTRACT_RC to 0. The CONDITION keyword allows
selection of one of the capacitance value types from a three-value SPEF file.
Optional. Defaults: EXTRACT_RC: 1; CONDITION: typical.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 43
Syntax:
CELL_RC_FILE
{
EXTRACT_RC [ 0 | 1 ];
CONDITION [best | typical | worst ]
<cell_name> <path to DSPF-SPEF_file>
...
}
• INTERCONNECT_GATE_CAP_RATIO
Defines the ratio of the total interconnect capacitance of the nets relative to the total
gate capacitance of the input pin fanouts. If none of the following keywords,
INTERCONNECT_GATE_CAP_RATIO, CELL_RC_FILE, or
STEINER_TREE_CAP have specified values, power calculation uses the default
value of INTERCONNECT_GATE_CAP_RATIO. Optional. Default: 1.
Syntax:
INTERCONNECT_GATE_CAP_RATIO <value>
Example:
INTERCONNECT_GATE_CAP_RATIO 1.5
• STEINER_TREE_CAP
When specified, a Steiner Tree routing is performed and the resulting length is
multiplied by the cap value specified in pF per um. Optional. Default: none.
Syntax:
STEINER_TREE_CAP <cap in pF per um>
Selecting Power Calculation Methodology
The following GSR keywords set parameters for power calculation.
• SCANMODE
Specifies whether scan pin power is included in vectorless power calculation or not.
Optional. Default: 0 .
Syntax:
SCANMODE[ 0 | 1 ]
• POWER_MODE
Specifies the primary data source for internal/switching power and leakage power
calculation analysis. Optional. Default: Mixed.
Syntax:
POWER_MODE [ APL | LIB | MIXED | APL_PEAK | APL_PEAK1 ]
where
APL : specifies primary use of APL power data for internal/switching (cell.ifprof)
and leakage power (<cell>.cdev). Where APL data are not available, .lib
data are used.
LIB : specifies use of .lib power consumption data; cells without power data in .lib
have no internal power consumption data, but have switching power
information from RedHawk.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 44
MIXED : specifies primary use of .lib power data; for cells without power
components (internal power consumption or leakage power) in .lib, APL data
are used.
APL_PEAK: uses the peak charge from APL to calculate the power for every cell
in the design, and the current is derived from the charge.
APL_PEAK1: uses the peak current from APL for every cell in the design to
calculate power. Peak current leads to a very pessimistic power calculation if
that type of model is desired.
• INPUT TRANSITION
Defines the input transition time for input pins of all instances not specified in an
STA file. Optional. Default: 10% of the value of the inverse of the frequency defined
by the “FREQ” keyword.
Syntax:
INPUT_TRANSITION <value in second>
Example:
INPUT_TRANSITION 0.2e-9 (or 0.2ns)
• NAME_CASE_SENSITIVE
Defines the name case sensitivity. If the value is set to 1, all .lib, lef/def, spef/dspf,
vcd, and STA filenames are assumed to be case-sensitive. Optional. Default: 1.
Syntax:
NAME_CASE_SENSITIVE [ 0 | 1 ]
Example:
NAME_CASE_SENSITIVE 0
Specifying Supply Nets
The following keywords define the power supply nets and their voltages.
• VDD_NETS
Specifies the voltage for Vdd nets. The power domain names are defined in the
DEF file using the SPECIALNETS keyword. Required. Default: none.
Syntax:
VDD_NETS
{
<Vdd net_name in DEF> <value in Volt>
...
}
where
<Vdd net_name in def> : specifies the name for a power net, such as VDD for the
core power domain, and VDDQ for the I/O power ring.
• GND_NETS
Specifies the voltage for Vss nets. The power/ground domain names are defined in
the DEF file using the SPECIALNETS keyword. Optional. Default: all
SPECIALNETS are designated as USE GROUND and set to 0 volts.
Syntax:
GND_NETS
{
<Gnd net_name_in_DEF> <Volts>
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 45
...
}
Setting Bus and Hierarchy Delimiter Keywords
The following keywords provide name mapping functions by defining delimiter characters
for busses and design hierarchy.
• BUS_DELIMITER
Defines the character used to delimit bus bits in the RedHawk database and GSR.
Optional. Default: [ ]
Syntax:
BUS_DELIMITER <delim>
• PIN_DELIMITER
Defines a special character to separate net or instance names from pin names in
RedHawk working files. Any character can be used that is not reserved in LEF or
used in pin names. Optional. Default: :
Syntax:
PIN_DELIMITER <delim>
• HIER_DIVIDER
Defines the character used to specify the hierarchy in the RedHawk database and
GSR. Optional. Default: /
Syntax:
HIER_DIVIDER <divider>
• BUS_DELIMITER_STA
Defines the character used to delimit the bus bits in STA files. Optional. Default: [ ]
Syntax:
BUS_DELIMITER_STA <delim>
• PIN_DELIMITER_STA
Defines the character between instance and pin names in STA files. Optional.
Default: /
Syntax:
PIN_DELIMITER_STA <delim>
• HIER_DIVIDER_STA
Defines the character used to specify the hierarchy in STA files. Optional. Default: /
Syntax:
HIER_DIVIDER_STA <divider>
Setting up for Event-Driven (VCD File) Power Calculation
If you have a VCD file for the design it is strongly recommended that you perform power
calculation based on VCD data, as described in this section.
The following GSR keywords described in the previous section for vectorless power
calculation also need to be defined when using a VCD file. All keywords are used the
same for both vectorless and event-driven calculation, so their descriptions are not
repeated in this section:
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 46
• STA_FILE
• CLOCK_ROOTS
• BLOCK_POWER_FOR_SCALING_FILE
• BLOCK_POWER_FOR_SCALING
• SCALE_CLOCK_POWER
• CELL_RC_FILE
• INTERCONNECT_GATE_CAP_RATIO
• STEINER_TREE_CAP
• SCANMODE
• POWER_MODE
• INPUT_TRANSITION
• NAME_CASE_SENSITIVE
• VDD_NETS
• GND_NETS
• Bus and Hierarchy Delimiter Keywords
Setting GSR Keywords for Event-driven (VCD) Power Calculation
General Setup
The following keyword is used to specify VCD-based power calculation. See section
"vcdscan", page E-844 and section "fsdbtrans", page E-845, for information on VCDbased utilities.
• VCD_FILE
The VCD_FILE keyword reads in original VCD files directly for power calculation
purpose. Note that instance switching specified in the GSC file overrides the VCD
file. See section "VCD_FILE", page C-585 for more details on this keyword.
Optional. Default: None.
Syntax:
VCD_FILE
{
<top_block_name> <VCD filepath>
FILE_TYPE [ VCD | FSDB ]
FRONT_PATH <“string”>
SUBSTITUTE_PATH <“string”>
FRAME_SIZE <integer value in ps>
START_TIME <integer value in ps>
END_TIME <integer value in ps>
TRUE_TIME [0|1]
MAPPING_RULE_FILE <file_name>
}
where
<top_block_name> <VCD file>
FILE_TYPE [ VCD | FSDB ]
FRONT_PATH <“string”>: specifies the string that needs to be replaced by
SUBSTITUTE_PATH <“string”> to match the DEF hierarchy.
FRAME_SIZE <value_ps> : specifies the duration per frame for cycle-by-cycle
power calculation.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 47
START_TIME and END_TIME <value_ps> : optional, specifies the start and end
times in the VCD for power calculation.
TRUE_TIME : if =0, uses STA timing data and assumes no glitches; if =1, uses
VCD switching and timing data; default=0.
MAPPING_RULE_FILE : points to file that contain list of rules for name mapping
between VCD and DEF names. This is used in RTL VCD based analysis
where there will be unfamiliar changes between vcd/netlist names. (see
following section)
Name Mapping using MAPPING_RULE_FILE
The following are various rules used in MAPPING_RULE_FILE for name mapping
between VCD and DEF names:
• change_gate_name <string1> <string2>
‘string1’ is replaced with ‘string2’ for def (gate level) names when attempting to
map as in the below example:
change_gate_name ricc icc
if you want to remove a particular string (say, 'extra') fully from a name, you can
specify as:
change_gate_name extra ""
• change_rtl_name <string1> <string2>
‘string1’ is replaced with ‘string2’ for vcd (rtl level) names when attempting to map
Example is:
change_rtl_name gen_pqr_i(%d) pqr_ixx%dx/
• define_bus_rule <rtl_bus> <gate_transform> generally buses defined in rtl of form string[%d] (say, cnt[13]) appear in gate
netlist as string_reg_%d (cnt_reg_13), which is what the algorithm looks to
map,by default. But there can be situations when the synthesis tool uses some
other bus rule conventions to given names corresponding to each bus in the gate
netlist. Here define_bus_rule can help. Please note that the output pin name also
has to be specified along with gate name. Example is:
define_bus_rule [%d] %d__regxx_/Q
• skip_gate_element <string>
This option is used when one knows that a particular name in GATE level netlist/
DEF will never appear in RTL VCD, and doesn’t need to be mapped. It is aimed at
improving the runtime for the algorithm. Example is:
skip_gate_element top/block_name
Please note that only names that start with the string are skipped.
• generate_label <string> :
There are generate constructs in rtl which get synthesized in a very specific way
when the netlist is generated. For example :
rtl name : top/label[2]/block/cnt[2]
gate name : top/block2/cnt[2]
Notice how the string 'label' is gone and the number along with it moves to the
next hierarchy. Using the rule generate_label, we can give this particular string
(label) and RedHawk will take care of the rest of mapping part. So, here,
specifying 'generate_label label' will ensure proper mapping.
Wildcards ‘%d’ are also supported in rules ‘change_gate_name’ and
‘change_rtl_name’ where %d denotes a number.
Example for wildcard usage:
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 48
If RTL and GATE names are as follows :
RTL : blockA/case_move_gen[0]/abc_move/rise_edge
GATE : blockA/case_movexx0x/rise_edge_reg
RTL : level_three_6/abc/abc_ip/gen_pqr_i(1)/pqr_i/gen_xyz_i(1)/xyz_i/
xyz_defg_ctrl_reg[14]
GATE : level_three_6/abc/abc_ip/pqr_ixx1x/xyz_ixx1x/
xyz_defg_ctrl_reg_regx14x
RTL : level_three_6/abc/abc_ip/gen_pqr_i(2)/pqr_i/gen_xyz_i(2)/xyz_i/
xyz_defg_ctrl_reg[14]
GATE : level_three_6/abc/abc_ip/pqr_ixx2x/xyz_ixx2x/
xyz_defg_ctrl_reg_regx14x
These can be mapped easily by using the following rule:
change_rtl_name case_move_gen[%d]/abc_move/ case_movexx%dx/
change_rtl_name gen_pqr_i(%d)/pqr_i/ pqr_ixx%dx/
change_rtl_name gen_xyz_i(%d)/xyz_i/ xyz_ixx%dx/
MBFF Name Mapping using MAPPING_RULE_FILE
In RTL-VCD based analysis, the presence of Multi Bit Flip Flops in the design can cause
limitations in mapping RTL-VCD names to gate level names. Multi Bit Flip Flops have
multiple inputs/outputs and are used to instantiate multiple bits of a register. Typically
there are 20-30 D pins and Q pins in an MBFF. Generally the name of MBFF instance
has all the individual register names concatenated. Mostly, there are delimiters/prefix
names that identify MBFFs. Mapping of flip-flops with pin name o, o1, o2.. etc is
supported. In scan mode, user can shift the input values among all output pins (Q0->Q1>Q2->Q3).
RedHawk internal mapping can take care of Multi Bit Flip Flops (MBFF) naming issues if
the MBFFs are specified in a GSR mapping rule file option.
For example, for a 2-bit MBFF:
inst: xxx/MBIT__cp15_st_reg_1_MB_cp15_st_reg_2_
pin:Q0, mapped to RTL Name : xxx/cp15_st[1]
pin:Q1, mapped to RTL Name : xxx/cp15_st[2]
Note that here “MBIT_” is the prefix and “MB_” is the delimiter.
For a 4-bit MBFF:
MBIT_cp_addr_reg_reg_4_MB_cp_addr_reg_reg_5_MB_cp_addr_reg_reg_6_MB_cp_addr
_reg_reg_7_
pin:Q0, mapped to xxx/cp_addr_reg[4]
pin:Q1, mapped to xxx/cp_addr_reg[5]
pin:Q2, mapped to xxx/cp_addr_reg[6]
pin:Q3, mapped to xxx/cp_addr_reg[7]
To map MBFFs, the following VCD_FILE GSR option can be used:
VCD_FILE {
...
MAPPING_RULE_FILE <file_name>
}
The MAPPING_RULE_FILE provides the common rules needed for mapping RTL names
to gates. For describing MBFFs, the available rules are as follows:
• define_mbit_prefix <prefix_name>
where Mbit_prefix denotes the string that comes before the concatenated register
names in an MBFF. In the example below,
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 49
XXX/MBIT__cp_addr_reg_reg_0_MB_cp_addr_reg_reg_1_
MBIT__ is the prefix. This can be provided in MAPPING_RULE_FILE as
define_mbit_prefix MBIT__
• define_mbit_delim <delimiter_name>
where mbit_delim denotes the string that separates the two register names. In
the example below:
XXX/cp_addr_reg_reg_0_MB_cp_addr_reg_reg_1_
MB_ is the delimiter. This can be provided in MAPPING_RULE_FILE as
define_mbit_delim MB_
• define_mbit_lsb <0/1> (default value is 0)
where mbit_lsb denotes the least significant bit in the MBFF array.
MBFF Name Mapping can support Bus Style Outputs: RedHawk can map register names
in RTL VCD to corresponding gate level names in netlist (def), even if these have been
synthesized with Multi Bit Flip Flop (MBFF) in gate level. Certain specifics regarding
MBFF names have to be specified via a rule file to enable this. This particular MBFF
mapping flow has been further enhanced to map bus-style output pin names for MBFF.
Pin names of style Q[0], Q[1] etc are supported.
Power Calculation Procedure and Results Evaluation
With all design data imported and the appropriate GSR keyword values set, you can
perform power calculation from the TCL command line or using the GUI. The TCL
command is:
perform pwrcalc
If you have already run power calculation on the design and have made no changes, you
can import the calculated power directory data from your previous calculation by using the
menu command Static > Power > Import, and select the previous power directory, such
as adsPower. Figure 4-4 shows the form for importing power information.
Or perform the import using the TCL command:
import power <Power_Dir_Name>
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
Figure 4-4
RedHawk User Manual
| 50
Importing adsPower directory information
Or, to perform power calculation using the GUI and then evaluate the results, follow the
GUI-based steps below.
1.
Calculate the power using the Static > Power > Calculate or Dynamic > Power >
Calculate command.
2.
Review the power summary in the file power_summary.rpt in the adsRpt directory,
as shown in Figure 4-5 example. The Power Summary Report recommends the
simulation time needed to capture a majority of power events, and lists the
calculated total_pwr, leakage_pwr, internal_pwr, switching_pwr and percentage of
total power consumption by frequency domain, by power domain, and by cell type.
Note that imported power values are scaled during power calculation to meet
instance-specific power consumption numbers.
3.
Generate a power density distribution map, using commands such as:
• View > Power Maps > Power Density Map
• View > Power Maps > Power Map of Instances
• View > Power Maps > Power Map of Clock Instances
or use the corresponding control buttons on the right side of the GUI.
------------------------------- Power Summary Report ----------------------------------------------------Recommended dynamic simulation time, 5000psec, to include 100%
of total power for DYNAMIC_SIMULATION_TIME in GSR.
INFO: Importing user specified power file: demo.inst.power
INFO: Instances not specified in this file will have zero power.
INFO: 100% of instances specified in instance_power_file have corresponding
instances in the design.
0 out of 4142 instances do not have corresponding instance in the design.
INFO: For complete list of PWR-121 and PWR-122 WARNINGS, please see adsRpt/
apache.inst_pwr_file.mismatch.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Calculation
RedHawk User Manual
| 51
The power is based on the INSTANCE_POWER FILE: demo.inst.power
Redhawk honors instance-by-instance power as specified in the above file.
Individual components of power, like switching power, internal power,
however, are calculated by RedHawk and may have been scaled to
meet the total instance-specific power number.
Power of different frequency (MHz) domain in Watts:
Frequency
4.000e+02
2.000e+02
0.000e+00
total_pwr leakage_pwr internal_pwr switching_pwr %_total_pwr
1.729e-02 1.704e-04
1.107e-02
6.052e-03
8.333e+01%
3.4595e-03 2.1869e-05 3.1000e-03
3.3758e-04
1.666e+01%
0.000e+00 0.000e+00
0.000e+00
0.000e+00
0.000e+00%
Power of different Vdd domain in Watts:
Vdd_domain total_pwr leakage_pwr internal_pwr switching_pwr %_total_pwr
VDD (1.1V) 2.075e-02 1.922e-04 1.417e-02
6.389e-03
1.000e+02%
Power of different cell types in Watts:
cell_type
total_pwr leakage_pwr internal_pwr switching_pwr %_total_pwr
combinational 7.111e-03 1.221e-04 1.754e-03
5.235e-03 3.426e+01
latch_and_FF 4.292e-03 3.890e-05 3.323e-03
9.301e-04 2.067e+01
memory
0.000e+00 0.000e+00 0.000e+00
0.000e+00 0.000e+00
I/O
0.000e+00 0.000e+00 0.000e+00
0.000e+00 0.000e+00
clocked_inst 9.352e-03 3.119e-05 9.096e-03
2.246e-04 4.505e+01
decap
0.000e+00 0.000e+00 0.000e+00
0.000e+00 0.000e+00
where clocked_inst are instances that cannot be classified as latch_and_FF,
memory, or I/O, but have clock pin(s).
Total chip power, 0.020757 Watt including core power and other domain power.
Total clock network only power, 0.003225 Watt. Total clock power, including
clock network and FF/latch clock pin power, 0.005992 Watt.
---------------------------------------------------------------------------------------------------------------
Figure 4-5
Example Power Summary Report
Some of the information that can be checked in the power summary report is:
• Does the total power consumption make sense?
• Are clock network and the clock power values reasonable?
• Is the power reported by clock frequency what would be expected?
Having several elements that consume a lot of power close to several elements that
consumes little power may not create a voltage drop problem. But having an area where
many elements consume a lot of power can create a voltage drop problem if the area is
not well supplied. The power consumption maps give important feedback regarding the
power distribution, i.e., the quality of the placement/floorplanning vs. power consumption.
Some aspects of the power calculation results to investigate:
• What is the total power consumption in the design?
• Is the overall power demand well distributed?
• Will the power pads handle this load safely?
• How is the power balanced between the different frequency domains?
• How much power is used in the clock network?
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Power Grid Resistance Extraction
RedHawk User Manual
| 52
You can click on any instance to see a text report of its power consumption, as well as its
associated capacitance and applied voltage.
Power Grid Resistance Extraction
After power calculation, the next step is to perform network resistance extraction, using
either TCL or GUI commands. At technology nodes now being used for design, very
precise estimates of wire resistance, and therefore wire thickness, is necessary. This
effect of metal density on resistance calculation is described in the following section.
Metal Density Calculation
To obtain very accurate resistance values for wire segments, both width and thickness
values must be accurately determined. To achieve an accurate estimate of wire thickness,
an accurate assessment of the metal density for all metal geometries in the region of the
wire is needed, because of the effects of CMP on wire thickness. The procedure for
estimating metal density around wire segment is as follows.
1.
Read geometries from DEF/LEF, or from GDS2RH/DB. Include all geometries from
LEF/DEF (NETS, SPECIALNETS, PINS, MFILL), as well as all geometries from
GDS2DB (including MFILL).
2.
Merge and flatten all metal geometries per layer, which eliminates redundant
geometries from different hierarchies or from GDS.
3.
Calculate the metal density over the whole design in small gridded regions that
contain wires.
4.
Perform extraction. Calculate the density of segments based on average density of
regions around each segment.
5.
By default each uniform wire geometry uses the density from an average of all
regions that the wire passes through.
6.
When you require the most accurate resistance calculation, such as for long wires
that go through multiple regions of varying metal density, set the GSR keyword
LONG_WIRE_RES_CALC 1. In this case, the metal density of every region that
contains the long wire geometry is used in the calculation.
7.
Then calculate the final wire thickness based on the calculated metal density-- for
example, using the POLYNOMIAL_BASED_THICKNESS_VARIATION Tech file
keyword setting.
TCL Command R Extraction
.To run static resistance extraction for IR drop analysis using the TCL command, execute:
perform extraction [-power | -ground]
To run RLC extraction for dynamic voltage drop analysis using the TCL command,
execute:
perform extraction [-power | -ground] -l -c.
The ‘perform extraction’ command builds connectivity and performs extraction for
the selected elements of the selected power/ground nets.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Examining Power/Ground Grid Weakness
RedHawk User Manual
| 53
GUI Extraction
To use the GUI commands to perform extraction on both VDD and VSS, use the following
steps:
1.
For static IR analysis, use the extraction command Static -> Network Extraction.
From the extraction form displayed, select resistance (R), and both VDD and VSS.
2.
For faster static analysis of either the power or the ground network, either VDD or
VSS can be selected. However, both VDD and VSS must be selected for dynamic
analysis.
The key information you can get from the extraction step is:
• Are all power and ground nets connected to a source? If not, the a warning message
is displayed: “Net VDD in cell not driven by any pad”.
• Are there any missing connections? (reported in the file adsRpt/apache.*.unconnect).
Examining Power/Ground Grid Weakness
Excessive voltage drop can occur due to weak power/ground grid structures. RedHawk
can identify problems in P/G structures early in the design cycle after placement and CTS
is completed, even without STA and SPEF files. P/G weakness analysis can report two
different measures of grid weakness:
• perform gridcheck - an estimate of the upper bound on grid resistance for all instances
in the design, normalized to the highest instance grid resistance
• perform res_calc - the calculated effective grid resistance for a specified number of
instances in the design
For gridcheck, an instance that has a weakly connected Power or Ground network shows
up as high impedance in the generated report. Using the GUI you can also review power
grid resistance maps showing the distribution of power and ground resistance across the
design. Also, pins not connected to VDD or VSS are listed as “floating” in the PG
Weakness report, and are listed together at the end of the report.
Note that you do not need to run power calculation or static analysis prior to doing this
assessment. Once the design is imported and P/G extraction is performed, the design
environment can generate the resistance report using the TCL interface. This can be
done early in the design cycle when detailed routing or timing information is not available.
The procedure for generating and evaluating a P/G grid weakness report is as follows:
1.
Normalized resistance estimation. On the TCL command line execute:
perform gridcheck -o <output_file_name> ? -limit <line_limit>?
The format of the resistance report displays RVDD and RVSS for each instance or
arc as percentages of the total P/G resistance distribution, as shown in the
example report below (Figure 4-6). For multiple P/G arc designs, adsRpt/
apache.gridcheck is constructed as follows:
a. The arc that has the highest relative R value is displayed first and continues
up to the specified line limit.
b. The rest of the arcs are displayed up to the specified line limit, or until the
relative R becomes smaller than the last displayed relative R in the previous
arc that reached the line limit.
--------------------------------------------------------------------# Power/Grnd arcs listed separately, there are 2 P/G arcs w/ non-zero R.
#
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Examining Power/Ground Grid Weakness
RedHawk User Manual
| 54
# Max. Resistances (%) of Power/Ground Arcs:
# Arc1 ( VDD_INT VSS) 100.0000
# Arc2 ( VDD VSS) 93.7410
{ Power/Ground Arc1:
# Total VDD_INT(%) VSS(%) Location (x y) ArcID Instance_name
100.000 49.5167 50.4833 3316.37 3950.55 Arc1 inst_129973/inst_366358
99.6966 50.8138 49.1862 3318.21 3965.32 Arc1 inst_129973/inst_366355
99.5191 50.4213 49.5787 3316.83 3961.62 Arc1 inst_129973/inst_366346
...
}
{ Power/Ground Arc2:
# Total VDD(%) VSS(%) Location (x y) ArcID Instance_name
93.7410 50.0202 49.9798 2099.90 3888.64 Arc2 inst_129228/inst_465808
92.9774 50.7174 49.2826 2131.64 3903.41 Arc2 inst_129228/inst_412486
92.9138 50.8630 49.1370 2131.18 3903.41 Arc2 inst_129228/inst_412485
92.8791 50.0223 49.9777 2131.64 3896.03 Arc2 inst_129228/inst_466552
...
}
# Floating Instances: Location (x y)
Name
floating
0
977.5 io/pad/VSSC/extra/left/4/adsU1
floating
10000 2956.24 io/pad/VDDC/extra/right/23/adsU1
floating
5435.09 191
io/pad/extra/VDDC/11/adsU1
floating
3935.09 191
io/pad/mpi/VDDC/2/inst/adsU1
floating
7300.05 0
io/pad/extra/VSSC/15/adsU1
...
---------------------------------------------------------------------
Figure 4-6
Sample P/G Weakness Report
The instance P/G resistance, Rinst, is normalized such that the instance or arc with
the highest total effective resistance is assigned a value of 100 and the instance or
arc with the lowest total effective resistance has a normalized value of 0, using the
following equation:
(Rinst - Rmin)/(Rmax, - Rmin )*100
(EQ 4)
where, Rinst is the total effective P/G resistance for an instance (RVDD + RVSS),
Rmin is the minimum value of all Rinst and Rmax is the maximum value of all Rinst.
The first column of the report, Total, lists the normalized resistance for every cell as
a percentage of the maximum Rinst. The second column lists the percentage of
RVDD grid resistance to the total effective resistance for that instance. For multiple
P/G arcs, the % resistance numbers are normalized to the highest resistance of all
the domains.
The third column provides a similar number for RVSS. The report values are sorted
based on the highest total relative resistance percentage. The sum of ‘VDD(%)’
and ‘VSS(%)’ entries is always 100.
A very large imbalance between RVDD and RVSS (in percentage terms) indicates a
significant weakness in the P/G grid at that instance, particularly for instances that
have large values of total R.
The list of P/G weakness instances also can be viewed without the TCL 'perform
gridcheck' command by using the GUI pulldown menu Results -> List of Weak
PG Instances, which brings up an ordered list of high total resistance instances.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Examining Power/Ground Grid Weakness
RedHawk User Manual
| 55
Clicking on any entry and on 'Go To Location' zooms to and highlights the weak P/
G instance. The list can be sorted based on Total resistance, VDD(%) or VSS(%).
2.
View Resistance Maps
The resistance maps can be displayed using the GUI menu option View ->
Resistance maps
The Resistance maps display either Total Resistance, RVDD , or RVSS, which are
the relative effective resistances for all instances in the design. To see the meaning
of each color, click on the 'Set Color Range' Configuration button at the right side of
the GUI. A 'Resistance Color Map' dialog is displayed, indicating the resistance
“gradient” (normalized resistance) for each color. The display and the resistance
ranges can be changed using the dialog.
3.
The View -> Nets menu option can be used to select the resistance maps to be
displayed by net.
4.
To view a grid problem area, you can highlight the weak instances in GUI using the
resistance report described above. Use the following TCL command to highlight
weak P/G instance:
select addfile high_VDD_res_instance
to highlights instances with weak VDD structures, or
select addfile high_VSS_res_instance
to highlight instances with weak VSS structures.
5.
Effective Grid Resistance Calculation. Reviewing the highlighted high
impedance instances, you can now start debugging the causes of weak P/G
structures in more detail. An important tool in finding out more about weak grid
areas is the ‘perform res_calc’ TCL command (see section "perform", page D-757,
for command syntax description).
The ‘perform res_calc’ command calculates the effective P/G grid resistance from
all pads to selected instances or locations, and provides absolute resistance
values. The default invocation, without any options, creates a resistance report of
the worst instances, as indicated by an initial quick estimation. Using the options
‘-instance’, ‘-inst_file’, or ‘-box’ allow the effective resistance of particular
instances or identified weak areas of the grid to be investigated in more detail. The
-cell_file <CellFile> option specifies a text file that contains the cell names, one per
line, for res_calc to compute the equivalent grid resistances. A sample ‘perform
res_calc’ output file is shown below.
# Ohm
Location(x y)
Layer
Net
Instance
4.54617 1005.4 8755.2 MET3
VSS
inst_1234
4.39744 1055.6 8855.3 MET5
VDD
inst_4134
3.32929 1855.7 8455.6 MET3
VDD
inst_2324
...
6.
Special Node Resistance Reports. Two other options allow you to select the type
of node resistance reports, for standard cells or macro blocks, as follows:
perform gridcheck ?-stdcell [ ave| min| max| all| none ]?
?-macro [ ave| min| max| all| none ]?
The option ‘ave’ is the average resistance for all nodes in each instance selected,
and is the default. For the 'min' and 'max' options, the node with the minimum or
the maximum resistance value for the instance is reported, instead of the average
of all nodes in the instance. The 'none' option is used to eliminate reporting on all
standard cell or macro instances. For 'all', the largest 5000 (default) node
resistances in the design are reported.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Defining Pad and Package Parameters
RedHawk User Manual
| 56
The report format is like 'perform res_calc', where VDD/VSS values are listed
point-by- point, without pairing up. An example report follows:
Example all-point gridcheck resistance listing for instances:
Resistance(%) Location( x y) Layer Net
Instance
87.4927 4459.77 443.855 METAL3 VDD
inst_129747/adsU1
87.3918 2839.76 443.855 METAL3 VDD
inst_129747/adsU1
42.4231 3741.59 609.345 METAL3 VDD
inst_129747/adsU1
33.1267 1874.49 119.18 METAL3 VDD
inst_129747/adsU1
Defining Pad and Package Parameters
Before performing static IR drop and EM analysis, the pad, package wirebond or flip-chip
bumps and associated electrical package parameters must be defined.
Command Line Procedure for Package Modeling
The pad, wirebond or flip-chip bump, and package parasitics are typically specified in the
RedHawk .tech file. The units used for the package TCL commands are: R in Ohms, C in
picoFarads, and L in picoHenrys.
The following three TCL commands define simplified lump models for all pad RC, wirebond/bump RLC, and package RLC circuits, respectively.
setup pad [-power | -ground] [-r <R_Ohms> | -c <C_pF>]
setup wirebond [-power | -ground ]
[-r <R_Ohms> | -l <L_pH> | -c <C_pF>]
setup package -r <R_Ohms> -l <L_pH> -c <C_pF>]
where
-power -ground : selects which P/G net to define
-r <R_Ohms> : specifies equivalent resistance value in Ohms
-c <C_pF> : specifies equivalent capacitance value in picoFarads
-l <L_pH> : specifies equivalent inductance value in picoHenrys
To specify individual bump/pad RLC values, see the PLOC file specifications in section
"Pad Location File (*.ploc)", page C-719. If you need a more accurate Spice package
subcircuit for your design, see Chapter 12, "Package and Board Analysis", for more
information about package subcircuit modeling.
To set up your package parameters such that you can easily look at the effects of different
package designs on power integrity, after extraction you can use the TCL command
‘setup pss’, which defines PLOC and package subcircuit files to be used in simulation,
using the follow syntax:
setup pss -pad_file <filename> -subckt <pss_ckt_name>
where
-pad_file <filename> : specifies a PLOC pad definition file that must have a .ploc
extension and be in PSS PLOC format.
-subckt <pss_ckt_name> : specifies the Spice package subcircuit file
After running RedHawk with one set of PLOC and package subcircuit files, you can then
modify one or both of the files, rerun the ‘setup pss’ command, and then rerun RedHawk
to see the effects of the new package data.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Running RedHawk-S (Static IR/EM Analysis)
RedHawk User Manual
| 57
GUI Procedure for Package Modeling
1.
Set the package and pad constraints by selecting the Static -> Pad, Wire_bond/
Bump and Package Constraint command. The data form is displayed, as shown
in Figure 4-7.
2.
Enter appropriate RLC pad and package values for your design.
The package model RLC values are needed to include the impact of package parameters
on the circuit analysis. The package can have a significant impact on voltage drop. If you
do not have accurate RLC values from testing or Spice models, you can provide
reasonable default values to see the effects on the voltage drop results.
Note: For static analysis only, R values are sufficient. However, for dynamic analysis
good L and C values are necessary for accurate results.
Figure 4-7
Pad, Wire-bond/Bump, and Package constraints form
Package Compiler Utility
The RedHawk Package Compiler is a versatile utility that checks the die-package
interface, as follows:
• checks package Spice syntax
• checks package RLCK passivity
• calculates effective package Inductance for each voltage domain
• matches die and package pins and creates an annotated PLOC
RedHawk Package Compiler makes use of the Chip Package Protocol (CPP) header
information to determine the following:
• identifies package and die pins
• identifies which nodes belong to the die side and which belong to the PCB side
• uses CPP header data to differentiate between power nets and ground nets
For details on using Package Compiler, see section "Chip-Die Mapping Using Package
Compiler", page 12-313.
Running RedHawk-S (Static IR/EM Analysis)
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Running RedHawk-S (Static IR/EM Analysis)
RedHawk User Manual
| 58
If all of the previous steps have been performed properly, you are now ready to run static
IR drop and EM analysis, as follows:
1.
Use the command Static > Static IR-drop & EM Analysis. The execution of this
command typically takes a few minutes on a Linux machine.
You can also run static analysis from the TCL command line, using the command
perform analysis -static
2.
When the analysis is complete, in the Log window the five worst Voltage drops for
each Power/ground net are listed.
3.
Evaluate the overall static voltage drop by clicking on the IR button, as shown in an
example VDD plot in Figure 4-8 and VSS plot in Figure 4-9.
The following are some important issues that can be identified by the static voltage drop
maps:
• number and location of hot spots (expected or not)
• unexpected color jumps may indicate missing straps or connections
• any unexpected black areas (which could mean a black box element, missing data, a
missing logical connection, or a missing physical connection)
• if a color change from source to hot spot make sense
ANSYS, Inc.
Figure 4-8
VDD static IR drop map
Figure 4-9
VSS static IR drop map
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Running RedHawk-S (Static IR/EM Analysis)
RedHawk User Manual
| 59
Exporting and Importing Results to the Design Database
The results of intermediate RedHawk operations and final results can be exported to the
design database from the command line using
export db <Output_filename>
or from the GUI using the File -> Export DB menu command. The exported DB is
platform-independent among Linux, Solaris, and AMD 64-bit Linux systems.
The results can be imported back into RedHawk as needed using the command
import db <DB_filename>
or the File -> Import DB command in subsequent runs.
Exporting a Database
The following procedure describes how to use the export db command:
1.
Select the Export DB menu item. A dialog window is displayed.
2.
Type in the design directory name and click on the OK button.
3.
A snapshot directory is created, containing binary files with the following names:
• general (general information such as .gsr, .tech, etc.)
• library.0, library.1, ... (library information)
• design.0, design.1, design.2, ... (design netlist, hierarchy, data, etc.)
Some text files, such as apache.gsr, which are needed for power calculation and
simulation, are also included in Export DB.
Database Compatibility
The compatibility of RedHawk databases from different releases is as follows:
• If the database version and RedHawk version are of the same major release, but from
different minor releases or patches:
a. A database generated by an older version of RedHawk can be loaded with a
newer version of RedHawk, but new features in the newer versions of
RedHawk are not available.
b. A database generated by a newer version of RedHawk cannot be loaded by
an older version of RedHawk.
• If the database version and RedHawk version are from different major releases (for
example, 2007.x and 2008.x), the database cannot be loaded across these versions.
Apache recommends that the database version and the RedHawk version used to load
the DB be the same. The “database version” is the version of the tool used to generate
the database.
Importing a Database
The following procedure describes how to use the import db command:
ANSYS, Inc.
1.
Select the Import DB menu item, a dialog window is displayed.
2.
Select the design directory name and click on the OK button.
3.
If the entry field of Selection: ... is empty, as may happen on AMD64-bit and
Enterprise 3.0 platforms, type in the directory name in the selection field. For
example, enter /home/design/MY_DB, where MY_DB is the DB directory that
needs to be imported.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
NOTE:
RedHawk User Manual
| 60
You may only load the design into the snapshot directory. No editing or
updates are allowed in any of the binary files. No query operations are
supported.
For version control purposes, a label is encoded into the binary file general. Therefore,
DB snapshots can only be reloaded using the same version of RedHawk that was used to
run ‘export db’. If there is a mismatch between DB and RedHawk versions, an Error
message is displayed and the RedHawk session terminates, with the following type of
error message:
Data/File version is not RedHawk2004100-BINARY!
Flexible Memory Caching for Database Reloading
To accommodate the physical memory size of different machines that are used to run
RedHawk, use the -cache_mode option when importing a database, particularly when
the design size is larger than the available physical memory. This allows smart caching of
the part of the database that does not fit into the memory. So regardless of the memory
size of the machine from which the DB was exported, to efficiently import a saved
database dynamic_run1.db into a machine with limited physical memory, use the
command
import db dynamic_run1.db -cache_mode 1
Note that setting the GSR keyword ‘CACHE_MODE 1’ also invokes RedHawk adaptive
memory caching. Setting a zero value turns caching off in both types of invocations.
Early Analysis Methodology
Overview
For designs that are in early stages of design and do not have complete placement and
routing information, RedHawk allows you to perform power grid verification early in the
design process to ensure that the grid meets initial design guidelines. This can verify, at
an early stage, the placement of power pads and check electromigration issues at the pad
connections or at other key locations on the grid. The usage model is extremely flexible
and allows you to run the analysis with different types of design abstraction. The following
levels of design abstraction and power grid completion are supported:
1.
Design has power and ground (P/G) routing only, with no block placement
information. Power consumption numbers are available for either the entire chip or
for the entire chip along with information on power consumption in specific regions.
2.
Design has P/G routing and macro placements only. Macros do not have any port
views (LEF pins) or detailed views (P/G routing).
3.
Design has P/G routing and macro placements. Macros have port views (LEF pins)
but do not have detailed views (P/G routing).
4.
Design has P/G routing and macro placements. Macros can have either port views
(LEF pins) or detailed views (P/G routing).
RedHawk can help analyze designs at any of the stages listed above. Based on the data
provided and the constraints specified, RedHawk creates realistic current sinks in the
design and assigns user-specified current at the current sink locations. Several examples
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 61
of different early analysis scenarios, with different levels of block information, are shown
in Figure 4-10.
Blk a
Sub-blk
cc
Blk c
Blk b
Region E
Case: LEF pin
view only and no
details.
Case: LEF pin
view only, and no
details.
Method: Assign
power from top
level grid
distributed to block
area.
Method: Assign
power from top
level grid
distributed based
on connectivity
available to block
pins.
Figure 4-10
Case: Hierarchical
block c and subblock cc have
routing.
Method: Assign
power to block and
sub-block based
on layer
specification.
Case: Userspecified region E
only.
Method: Assign
power equally at
grid intersections
in the defined
region.
Early block analysis scenarios
Input Data Required
The data requirements for executing early design static analysis are as follows:
1.
RedHawk technology file
2.
LEF file that describes the macros placed in the design. If current sinks have to be
created at the ports of the macros, the LEF file must contain the PIN definitions.
3.
DEF file for the macros for which detailed routing must be considered
4.
top level DEF file for the design
5.
voltage source location definitions
6.
GSR file
Early Analysis Flow
Block Power and Current Assignment
For performing power analysis on early stage designs RedHawk uses information
specified using the GSR keyword BLOCK_POWER_ASSIGNMENT, which defines power
parameters for particular blocks, pins, regions and the top level in early stages of design.
RedHawk creates current sinks in the design based on the constraints specified with
BLOCK_POWER_ASSIGNMENT and distributes power among these current sinks
based on user-defined power and/or current numbers. Particular regions and blocks can
also be excluded from power assignment, if desired, and power calculation data then can
be used for those excluded.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 62
Because of the large number of options for different types of applications, the
syntax is broken down into different types of applications in the following syntax
section.
Syntax:
BLOCK_POWER_ASSIGNMENT {
•
To assign power to existing instances from LEF/DEF:
<instName> [BLOCK|PIN] <layerSpec> <netName> [<powerW>|<currentA>]
where
<layerSpec> specifies either the layer name, or ALL to include all layers, or TOP
or BOTTOM to include either the highest or the lowest mask layers
overlapping the BPA instance.
[<powerW>|<currentA>] : specifies either the power in Watts for power nets, the
ground current in Amps for ground nets, or '-1' to allow power calculation to
decide the power.
ANSYS, Inc.
•
To create a new instance and assign power:
<BPA_instName> REGION <layerSpec> <netName> [<powerW>|<currentA>]
<llx> <lly> <urx> <ury>
•
To create a new instance for cells declared in DECAP_CELL or
BLOCK_POWER_MASTER_CELL keywords:
<BPA_instName> <cellName> <layerSpec> <netName>
[<powerW>|<currentA>] <llx> <lly> <orientation>
•
To assign power in a region the size of the entire design:
<BPA_instName> FULLCHIP <layerSpec> <netName>
[<powerW>|<currentA>]
•
To define sub-regions inside an existing BPA instance (multiple declarations on
the same instance is allowed) for power assignment:
<BPA_instName> BLOCK AREA <llx> <lly> <urx> <ury>
<BPA_instName> BLOCK RECTILINEAR <x1 y1 x2 y3 x4 y5 ..>
•
To exclude a region from BPA power assignment:
<regionName> REGION EXCLUDE <llx> <lly> <urx> <ury>
•
To exclude an overlapping instance in the design from BPA power assignment:
<instName> BLOCK EXCLUDE
•
To modify an area defined by 'EXCLUDE' to form rectilinear regions:
<regionName> REGION INCLUDE <llx> <lly> <urx> <ury>
•
To use the boundary box of an existing instance to do the same as above:
<instName> BLOCK INCLUDE
•
To exclude macro instances overlapping an BPA instance for power
assignment:
<BPA_instName> BLOCK EXCLUDE_MACRO
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 63
•
To exclude instances defined in the BLOCK_POWER_FOR_SCALING
keyword and which overlap the BPA instance for power assignment:
<instName> BLOCK EXCLUDE_BPFS
•
To exclude an area occupied by all instances overlapping the BPA instance:
<BPA_instName> BLOCK OVERLAP_OK
Using the BLOCK_POWER_ASSIGNMENT (BPA) keyword you can specify VDD power
and/or VSS current for any block or region for multiple metal /via layers on which current
sinks are created. Or if “-1” is specified, power calculation determines the appropriate
power/current based on other information available, such as toggle rate, BPFS and APL
characterization. If metal layers are specified, all top and bottom vias for those layers that
satisfy other criteria act as current sinks, and the assigned power or current is distributed
equally among these current sinks. If a via layer is specified, the current sinks are created
in the lower metal layer, if possible. Otherwise, the current sink is created in the upper
metal layer of the via. Current sinks can be created for different power and ground nets in
the design. All current sinks are analyzed in a single run. The keyword ‘ALL’ can be used
to include all layers in the power/current analysis.
The total current drawn by the current sinks in a power net depends on the power (Watts)
assigned to that net for a specific region, block or full-chip. The total current drawn by the
current sinks in a ground net, on the other hand, depend on the current (Amps) assigned
to that ground net for a specific region, block, or full-chip. Negative currents may be
assigned as needed for particular design methodologies.
BLOCK_POWER_ASSIGNMENT supports MMX pin-based region power assignment for
MMX instances that have many P/G pins inside to represent transistors using the
MMX_PIN and MMX_REGION keywords. See section "Power Assignment to MMX Pinbased Regions", page 4-66.
The INCLUDE and EXCLUDE capabilities make it easier for you to define areas that are
not complete rectangles to be specified for power assignment. The EXCLUDE option
allows you to define rectangular regions to be excluded from areas occupied by BPA
blocks/regions, and the INCLUDE option then can add back areas to be included within
EXCLUDE areas.
The power calculation engine can estimate power and current for early stage blocks by
setting their BLOCK_POWER_ASSIGNMENT values to -1. This can be used for either
cell instances (blocks) or regions. You must provide correct and complete power
calculation data so that power for the block can be calculated accurately. See section
"Power Calculation", page 4-35, for details.
Use one line in the BPA specification for every domain (net) in the block, such as:
regionA REGION met3 vdd1 -1 100 200 300 400
regionA REGION met4 vdd2 -1 100 200 300 400
regionA REGION met3 vss -1 100 200 300 400
Note that if one net in the block is assigned -1 for power/current in BPA, power/current for
all domains in the block is determined by the power calculation engine.
All other areas and elements of the design not specified in the Block_Power_Assignment
statement are treated as in a normal RedHawk analysis. So early stage blocks that have
power assigned in BLOCK_POWER_ASSIGNMENT (BPA) can be simulated together
with other “regular” blocks (fully designed and specified), including those specified using
the keyword BLOCK_POWER_FOR_SCALING (BPFS). For this mixed process any BPA
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 64
declaration overrides a BPFS declaration for the same instance. Power assignment for
FULLCHIP must be defined in BPFS, not in BPA.
So a general guideline is to use BPFS for “ready” completed instances, and BPA for
“early” blocks (such as regions, or macro (LEF) cell instances inside “early” design
blocks). If you need to assign power with FULLCHIP, using BPFS is highly recommended.
This generally applies to “mixed” early designs (that is, when the design has some blocks
that are completed, mixed with some early blocks).
You can also use the following GSR keywords to refine current sink assignment for
instances defined in BLOCK_POWER_ASSIGNMENT (see page C-552):
BPA_BY_LAYER
BPA_CONN_DISTANCE
BPA_CONN_MARGIN
BPA_CURRENT_DENSITY
Block Power Assignment On-the-fly
Early analysis can also support interactive block power assignment and re-definition,
allowing you to experiment, using the TCL command
gsr set BLOCK_POWER_ASSIGNMENT_FILE <BPA_filename>
anytime before and after 'setup design' to initialize and re-initialize the BPA settings.
Some example cases follow:
To display the current BPA settings in RedHawk:
gsr get BLOCK_POWER_ASSIGNMENT
To display the block power master cells defined:
gsr get BLOCK_POWER_MASTER_CELL
When using interactive changes to BPA, RedHawk compares any newly-loaded BPA
statements to what is already in RedHawk, and proceeds as follows:
• If there are errors in the newly-loaded set, such that the BPA statement cannot be
understood, RedHawk does not change that BPA setting.
• If a new BPA statement is not in RedHawk, it is added.
• If a BPA statement is in RedHawk, but not in the new set, it is deleted.
• For BPA statements in both versions, the new BPA parameters are used.
Hierarchical Power/Current Assignment
For power/current assigned to hierarchical elements in a design, power/current assigned
to child elements are included in the parent‘s assignment. So a parent’s power
assignment is the sum of the power assigned specifically to its children and also the
power assigned to areas that are outside of its children. See the hierarchical assignment
example below:
CHIP FULLCHIP m1 vdd 10
A BLOCK m1 vdd 8
A/B BLOCK m1 vdd 5
A/B/C BLOCK m1 vdd 2
So for this case BLOCK 'A/B/C' is assigned 2W, 'A/B outside of ‘C' is assigned 5 - 2 = 3W
(a total for ‘A/B’ of 3+2=5W), and the parent BLOCK 'A' outside of ‘B’ has the remainder of
3W (a total of 3+5=8W for ‘A’). For nodes in CHIP that are not in 'A', 10-8 = 2W is
assigned, and the whole chip has 10W.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 65
The ‘REGION’ specs in Block_Power_Assignment are designed as “place holders” for
design elements that are not available yet, so a warning is displayed if the coordinates of
two different REGIONS overlap, except for “sub-regions”. That is, for “regionA” and
“regionA/sub1”, “regionA/sub1” is expected to be inside “regionA”. Also, if a BPA region
overlaps all or part of a regular instance, the instance is considered “inactive”, and is
ignored in the analysis.
Every region declared in BLOCK_POWER_ASSIGNMENT can be referenced as an
instance in the design using the region name as the instance name. The cell name
associated with the instance is then the region name for most cases, except for regions
that have a hierarchical name. For example, in the cell name “U10/I5”, the “/” is replaced
by a “_” character in the cell name, “U10_I5”.
Optionally rectilinear areas inside BPA REGIONs or in LEF/DEF blocks, that share a
common master cell can be defined. Rectilinear area definitions enable you to distribute
power to specified sub-areas within a rectilinear block. Power/current assigned to
REGIONs/blocks is hooked up within the user-defined rectilinear areas. You must define
the common master cells and the rectilinear regions within it using a
BLOCK_POWER_MASTER_CELL definition and the BLOCK_POWER_ASSIGNMENT
keyword. Different regions can share the same master cell. You can use the GSR
keyword BLOCK_POWER_MASTER_CELL to achieve this, with the following syntax:
BLOCK_POWER_MASTER_CELL {
<master_cell_name1> <BB_llx> <BB_lly> <BB_urx> <BB_ury>
...
?<master_cell_name2> <bbox> {
<sub-area bbox>
...
}?
}
Multiple regions can share a common master cell using BLOCK_POWER_ASSIGNMENT
by referencing a cell name declared in BLOCK_POWER_MASTER_CELL, as follows:
BLOCK_POWER_ASSIGNMENT {
<region> <master_cell_name> <layer> <net_name>
[<power_W>|<gnd_I>] <BB_llx> <BB_lly> <orientation_code>
...
}
A typical example of using the Block_Power_Assignment keyword follows:
RegionABC FULLCHIP
via7
VDD
2.0
# in Watts
RegionABC FULLCHIP
via5
VDDC
0.4
# in Watts
BlckA
BLOCK
MET6
GND
1.0
# in Amps
BlckB
PIN
MET6
VDD
0.2
# in Watts
BlckC
BLOCK
via2
VDD
0.4
# in Watts
Region1
REGION
via3
VDDC
0.3 30.0 65.0 60.0 95.0
IOL
REGION
MET5 VDD_L 0.005 100 1050 1000 9900
IOL
REGION
MET6 VDD_L 0.010 100 1050 1000 9900
regionA
REGION
ALL VSS 0.1 10.0 20.0 30.0 4.0
To specify power in regions inside an MMX instance, you can use region names with the
prefix “adsU1/”-- for example, “adsU1/regionA”. In this way RedHawk knows that “adsU1/
regionA” is a sub-region inside 'adsU1' and the BLOCK_POWER_ASSIGNMENT
specifications can be interpreted correctly.
The steps for executing an early design static analysis flow are summarized in the
following TCL commands:
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 66
setup design <GSR_NAME>.gsr
perform pwrcalc
perform extraction -power -ground
perform analysis -static
Power Assignment to MMX Pin-based Regions
BLOCK_POWER_ASSIGNMENT supports MMX pin-based region power assignment for
MMX instances that have many P/G pins inside to represent transistors using the
MMX_PIN and MMX_REGION keywords. So the power is only distributed to P/G pins,
while regular region-based BPA assigns power to nodes on the given layer within the
region. This feature is used to change the power distribution inside a MMX instance for
static analysis only.
You can assign power :
• to transistor pins inside MMX instances using the MMX_PIN keyword in BPA.
• to regions inside MMX instances using MMX_REGION keyword and a “/” character to
indicate hierarchy in the first column.
• hierarchically by defining a region inside another region using the MMX_REGION
keyword. Use “/” character to indicate hierarchy.
For example:
BLOCK_POWER_ASSIGNMENT {
BlockABC/ram64/adsU1 MMX_PIN all VDD 0.18
BlockABC/ram64/adsU1 MMX_PIN all VSS 0.1
BlockABC/ram64/adsU1/R1 MMX_REGION all VDD 0.04 1789 980 1822 1031
BlockABC/ram64/adsU1/R1 MMX_REGION all VSS 0.01 1789 980 1822 1031
BlockABC/ram64/adsU1/R10 MMX_REGION all VSS 0.03 1842 934 1888 966
BlockABC/ram64/adsU1/R10/R11 MMX_REGION all VSS 0.02 1843 935 1863 965
BlockABC/ram64/adsU1/RR REGION all VDD 0.09 0 0 40 40
BlockABC/ram64/adsU1/RR REGION all VSS 0.05 0 0 40 40
}
In general, block power is assigned hierarchically, so power of a child block of the same
type as the parent is considered part of the parent’s power assignment.
In the above example, the final power for this instance is 0.18W for VDD and 0.1A for
VSS. Power/current in region R1 is 0.04W for VDD and 0.01A for VSS. Current in region
R10 is 0.03A for VSS. Current in region R10/R11 is 0.02A for VSS.
The last two lines in this BPA example are regular metal/via region-based BPA settings.
Instance BlockABC/ram64/adsU1/RR is created and is assigned 0.09W for VDD and
0.05A for VSS. However, since the */RR region is not type MMX, its power is not included
in the MMX region assignments.
Note that unlike metal/via region-based BPA, pin-based region BPA does not create
instance hierarchy for the given region, but it redistributes and adjusts the transistor pin
power/current inside the MMX instance, while keeping the total power/current of the MMX
instance unchanged.
Also, pin-based region BPA and metal/via-based region BPA can be used in the same
design at the same time, as follows:
ANSYS, Inc.
1.
You can apply pin-based BPA to MMX instance while assigning metal/via based
BPA to place outside MMX instance.
2.
It is possible to assign pin-based region BPA and metal/via based region BPA to
the same MMX instance. But the metal/via based region BPA cannot cover any
MMX transistor pins, or it would conflict with the assumption. Use MMX_REGION
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 67
to handle such case. So in the above example, pin-based region BPA is used while
assigning power/current to “BlockABC/ram64/adsU1/RR” with metal/via existing,
but the metal/via region BPA does not include any MMX transistor pins.
MMX BPA Restrictions
The following restrictions on MMX pin-based region BPA use are checked to avoid
analysis errors:
1.
An MMX instance cannot be inside an MMX_REGION.
2.
An MMX_REGION must be defined inside an MMX instance.
3.
An MMX_REGION can only be within another MMX_REGION if they belong to the
same instance.
4.
Regions cannot overlap.
Power Assignment to OBS Regions in LEF Macros
Early stage analysis allows assignment of power to ‘OBS’ regions in LEF blocks. The
regions are defined in the OBS section in LEF for cell macros. There are two elements to
this methodology:
• RedHawk reads the specified parts of the OBS section in LEF to get the regions to be
assigned power, when a new GSR keyword is turned on (default off, 0):
READ_LEF_OBS 1
The only parts of the OBS data read in are LAYERs defined as OVERLAP and shapes
defined as RECT. All other items defined in the LEF OBS section are ignored. For
example, the following OBS section items in LEF would be included in power
assignment:
OBS
LAYER OVERLAP ;
RECT 0.0 0.0 800.0 400.0 ;
RECT 0.0 400.0 400.0 600.0 ;
END
• Also, in the BLOCK_POWER_ASSIGNMENT (BPA) GSR keyword, a block type
keyword ‘OBS’ is used. So LEF/DEF instances are categorized as BLOCK, PIN, or
OBS. User-defined regions are specified by two GSR keywords:
• REGION in BPA
• <cellName> in BLOCK_POWER_MASTER_CELL
Areas defined in the specified LEF OBS sections are used to assign power to a block
only when the block type is also OBS in the BPA statement. The OBS type keyword is
a block-level attribute by implementation, not a net-level attribute; BPA syntax is “per
net” by definition. So if a user specifies the following:
U1 BLOCK metal1 VDD 0.2
U1 OBS metal2 VSS 0.15
it would be interpreted as applying OBS to ALL nets specified in BPA for U1.
So it should be noted that the new OBS syntax assigns power/current to the whole
specified OBS area, and if one net is assigned to OBS for a block, all nets in the block are
assigned to OBS.
Creating Decap Cells During BPA
You can use the GSR keyword DECAP_CELL and BPA to create new decap cells/blocks
and assign decap values,. These decap blocks are also considered by the 'print decap'
command. Decap cells can either come from LEF or be created in the flow. BPA
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 68
instantiates the existing decap cells to put decap instances in the design, using the
syntax:
APL_FILES {
# optional
mydecap.cdev cap
...
}
BLOCK_POWER_ASSIGNMENT {
DecapABC_10 DecapABC METAL1 VDD 0.0 3800 4200 N
DecapABC_10 DecapABC METAL1 VSS 0.0 3800 4200 N
DecapABC_20 LEF_decap1 METAL1 VDD 0.0 3900 4300 N
DecapABC_20 LEF_decap1 METAL1 VSS 0.0 3900 4300 N
}
DECAP_CELL {
# decap cells defined in LEF
LEF_decap1
...
# decap cells to be created, use the syntax:
# <decap_cell> <width> <height> <C_pF> <R_ohm> <layer> <leakage_A>
DecapABC 100 100 0.1 10 METAL1 0.001
}
In this example RedHawk creates a decap cell (instead of a regular leaf cell) for
‘DecapABC’, and ‘DecapABC_10’ and ‘DecapABC_20’ are decap instances.
When a decap instance is selected in the GUI, the instance name, the cell name and the
decap value assigned to it are all displayed in the log window.
Early Stage Decap Estimation
Early stage decap estimation can be performed to help meet your global dynamic voltage
drop (DvD) requirements, using the following estimation procedure:
1.
Run DvD analysis on the design that has rough placement or CTS completed.
Look at DvD values.
2.
Place user-specified decap cells uniformly over all standard cell rows to fill a
desired percentage of rows (may result in overlaps with existing standard cells),
using the 'decap fill' command for uniform coverage:
decap fill -uniform <percentage> -pattern {<list decap masters>}
3.
Rerun DvD analysis to get new DvD values. Delete the placed decaps if the global
DvD target is not met (ignore local hot spots).
4.
Repeat steps 2 and 3 with different combinations of percentage coverage values
and decap master cells until the global DvD target is met.
5.
Feed back the amount of decap required (and optionally, placement info) to the
place and route tool for the pre-placement design database.
6.
Continue with regular placement and routing steps.
The command creates a report of results in a tabular format, with the number and amount
of decaps added for each decap master. A sample output report is shown below:
DECAP_MASTER_NAME Number_of_Instance
Amount_of_Decap_Added
cell_698
333548
457.397700 pF
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 69
cell_200
333548
93.843726 pF
------------------------------------------------------Total_Amount
667096
551.241426 pF
Reports Created
The reports created from early analysis are very similar to those available from a standard
RedHawk static analysis, including:
• wire-based voltage drops
• pad currents
• potential EM problem areas
Example Analyses
The following cases describe how you can simulate early designs for different design
phase scenarios.
Case 1
Conditions: Design has power and ground (P/G) routing only, with no block placement
information available. Power consumption numbers are available for either the entire chip
or for the entire chip along with information on power consumption in specific regions.
For this case you can specify top (FULLCHIP) level power and define region specific
power. He or she can also define the metal or via layer on which the current sinks can be
inserted and these definitions can be unique for each region and for the full-chip.
The Block_Power_Assignment keyword syntax is as follows:
BLOCK_POWER_ASSIGNMENT {
[ <DEF_inst_name> [ BLOCK | PIN ] |
<regionName> [ FULLCHIP | REGION ] ]
[ <layer_name> | ALL | TOP | BOTTOM |
<via_name> ] <pwr_domain_name>
[ <domain_power-W> | <gnd_net_current-A> | -1 ]
?<Bounding box- x1 y1 x2 y2 - req’d for REGION, same line>?
}
So for this case current sinks in top level metal6 consume 1.0W of power in the VDD_X
domain:
RegionXYZ FULLCHIP
metal6 VDD_X 1.0
...
For current sinks in via4 in a region bounded by opposite corner locations 100,100 and
200,200, and draw 0.35 Amps in the GND_X net, the entry is:
RegionA
REGION via4
GND_X 0.35 100.0 100.0 200.0 200.0
....
}
RedHawk inserts current sinks in all via4 shapes that fall inside “RegionA”. These current
sinks draw a total of 0.35Amps in the GND_X net. Specifying a metal layer name for this
region means that all top and bottom vias for the specific layer that falls inside “RegionA”
would have current sink locations. Or, if you specify a via layer name for this region, all
vias of that layer type that fall inside “RegionA” would have current sink locations.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Early Analysis Methodology
RedHawk User Manual
| 70
Case 2
Conditions: Design has P/G routing and macro placements only. Macros do not have port
views (LEF pins) or detailed views (P/G routing).
For this case, you can specify top (FULLCHIP) level power and define block-specific
power. You also can define the metal or via layer on which the current sinks can be
inserted; these definitions can be unique for each block and for the full-chip.
Using the Block_power_assignment syntax described above, for this case the current
sinks at top level metal6 consume 1.0W of power in VDD_X domain would be specified:
RegionMNOP
...
FULLCHIP metal6 VDD_X 1.0
And for current sinks in via4 in a block that consumes 0.35Amps in the GND_X net:
BlockA BLOCK via4
GND_X 0.35
BlockA BLOCK via4
VDD_X 0.42
...
For current sinks in metal3 in a block that consumes 0.72W in the VDD_X net:
BlockB BLOCK metal3 VDD_X 0.72
...
}
RedHawk inserts current sinks in all top and bottom vias that intersect the specified layer
at the top level. In this case all via5 and via6 shapes in the top level outside “BlockA” and
“BlockB” have 1.0W assigned (since in both of these two blocks, VDD_X net is covered,
which is the same one specified in the top level). The power assigned to the FULLCHIP
current sinks is 1.0W, so the power for the top level should be specific to the top level
current sinks exclusively.
RedHawk inserts current sinks in all via4 shapes that fall inside “BlockA”. These current
sinks draw a total of 0.35Amps in the GND_X net.
All current sinks on metal3 geometries inside “BlockB” are designated as current sinks
specific to “BlockB”. Power of 0.72W is assigned to the current sinks in the VDD_X net.
Case 3
Conditions: Design has P/G routing and macro placements. Macros have port views (LEF
pins) but do not have detailed views (P/G routing).
For this case, you can specify top (FULLCHIP) level power and define block-specific
power. You also can define the metal or via layer on which the current sinks are inserted,
and these definitions can be unique for each block and for the full-chip.
The same GSR keyword syntax is used:
BLOCK_POWER_ASSIGNMENT {
[ <DEF_inst_name> [ BLOCK | PIN ] |
<regionName> [ FULLCHIP | REGION ] ]
[ <layer_name> | ALL | TOP | BOTTOM |
<via_name> ] <pwr_domain_name>
[ <domain_power-W> | <gnd_net_current-A> | -1 ]
?<Bounding box x1 y1 x2 y2 - req’d for REGION, same line>?
...
}
So for current sinks in top level metal6 that consume 1.0W of power in the VDD_X
domain:
RegionCDEF FULLCHIP
metal6 VDD_X 1.0
...
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Evaluating Results of Static IR Voltage Drop Analysis
RedHawk User Manual
| 71
For current sinks in via4 in a block that consumes 0.35Amps in the GND_X net:
BlockA PIN
via4
GND_X 0.35
BlockA PIN
via4
VDD_X 0.42
...
For current sinks in metal3 in a block that consumes 0.72W in the VDD_X net:
BlockB PIN
metal3 VDD_X 0.72
...
}
RedHawk inserts current sinks in all top and bottom vias that intersect the specified layer
at the top level -- in this case all via5 and via6 shapes in the top level outside “BlockA”.
“BlockB” has 1.0W power assigned. The power assigned to the FULLCHIP current sinks
is 1.0W, so the power for the top level should be specific to the top level current sinks
exclusively.
RedHawk inserts current sinks in all via4 shapes that fall inside “BlockA” and that
intersect with all the PIN geometries defined in the LEF view of “BlockA”. These current
sinks draw a total of 0.35Amps in the GND_X net.
All via2 and via3 shapes that intersect with metal3 geometries inside “BlockB” that
intersect with all the PIN geometries defined in the LEF view of “BlockB” are designated
as current sinks specific to “BlockB”. A power of 0.72W is assigned to the current sinks in
the VDD_X net.
Evaluating Results of Static IR Voltage Drop Analysis
A number of useful analysis techniques are available for viewing the results of voltage
analysis, which are discussed in the following steps.
1.
View IR voltage drop by layer by selecting View -> Map Configuration -> IR Drop
Color Map.
2.
Zoom in so that individual instance voltages can be seen, as shown in Figure 4-11.
Figure 4-11
3.
ANSYS, Inc.
View individual instance IR drop values with View -> Map
Configuration -> IR Drop Color Map
You can change the range of IR drop violations displayed and the display colors by
using the ‘Set Color Range’ button in the ‘Configuration’ panel (middle button) on
the right hand side. Figure 4-12 shows the form for setting the IR voltage drop color
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Evaluating Results of Static IR Voltage Drop Analysis
RedHawk User Manual
| 72
range, which enables you to change either the percentage of the voltage drop to
VDD or the absolute value of the voltage drop. You can also click on any of the
color buttons to customize the color display and the range of voltage drops each
color represents. The colors show the varying levels of voltage drop, from the
highest in red to the lowest in blue and magenta.
Figure 4-12
settings for the voltage drop color map
4.
Zoom in on the voltage drop color map and see more detail, as shown in Figure 413.
5.
Observe the instances with the highest power usage using the IPM button on the
‘View Results’ panel. Click on a key hot instance, as shown in Figure 4-14.
6.
Observe the power density distribution of the design using the PD button on the
‘View Results’ panel.
7.
Observe the electromigration profile and possible EM violations using the EM
button on the ‘View Results’ panel.
Once the static results are acceptable (analysis runs without a problem, results are well
understood, no obvious power grid/layout issues), and once you have done all the
needed modifications, it is time to proceed to the voltage drop analysis in dynamic mode.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Evaluating Results of Static IR Voltage Drop Analysis
Figure 4-13
ANSYS, Inc.
RedHawk User Manual
Zoom in to view the worst voltage drop violation area
| 73
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Example Procedure to Fix IR Drop Problems
Figure 4-14
RedHawk User Manual
| 74
Click on a hot instance for more information
Example Procedure to Fix IR Drop Problems
This brief example section uses an example design to illustrate how to fix IR drop
problems discovered during static analysis. The example demonstrates how the addition
of three power pads, two metal straps and a metal layer resistivity change can reduce
static IR drop. This example assumes that you are familiar with procedures for running IR
drop and EM analysis, described previously in this chapter. If you want more details on
the power grid modification commands used in this example, see Chapter 7, "Fixing and
Optimizing Grid and Power Performance".
Example IR Drop Case
The original IR drop map of the example design is shown in Figure 4-15. The results show
a worst-case Vdd - Vss voltage differential of 1.1073V in the upper left corner of the chip,
which contains several high-power instances. The RedHawk screen displays the following
message highlighting the worst-case IR drop.
The worst IR drop of the top cover cell
voltage = 1.1073 at node (2679.182500,2737.390000)
The existing metal4 straps extending from the top and the metal6 strap extending from
the left side do not supply adequate power to the high-power instances.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Example Procedure to Fix IR Drop Problems
RedHawk User Manual
| 75
Metal4 straps
Metal6 strap
Worst IR = 1.1073V
Figure 4-15
Original IR drop map
Modifying Power Pads
Adding new power pads and straps is described, and then analyzing the impact on IR
drop.
1.
ANSYS, Inc.
Add two power pads on the two metal4 straps by using Edit > Add Pad, as shown
in Figure 4-16.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Example Procedure to Fix IR Drop Problems
RedHawk User Manual
| 76
Add power pads
Metal4 straps
Figure 4-16
2.
ANSYS, Inc.
Adding two power pads on two metal4 straps
Then add one power pad on the metal6 strap using the command Edit > Add Pad,
as shown in Figure 4-17.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Example Procedure to Fix IR Drop Problems
RedHawk User Manual
| 77
Add power pad
Metal6 strap
Figure 4-17
Adding a power pad on the metal6 strap
Adding Metal6 Straps
3.
ANSYS, Inc.
Add two metal6 straps on top of the two metal4 straps by using Edit > Add Power
Strap, as shown in Figure 4-18. This reduces the resistance of the grid segment
supplying the hotspot. Make the following selections in the pop-up menu when
adding the metal6 straps.
• Deselect Add strap by text input to use drawing input method.
• Select a Vertical power strap.
• Input the strap width as 20um.
• Select metal6 for the stack via top metal layer.
• Select metal4 for the stack via bottom metal layer.
• Select metal6 for the strap metal layer.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Example Procedure to Fix IR Drop Problems
RedHawk User Manual
| 78
Add metal6 straps
Metal4 straps
Figure 4-18
Adding two metal6 power straps to two existing metal4 power
straps
4.
Draw two metal6 power straps that cover the length of the metal4 power straps.
This is indicated by a red rectangular box that covers the width and length of the
metal4 straps.
5.
Click on Commit Adding to add the power straps to the design.
6.
Now rerun Static->Network Extraction and Static->Static IR-drop & EM
analysis.
The results show that the worst Vdd - Vss differential is now 1.1076V, showing very
little improvement from the initial IR drop run.
ANSYS, Inc.
CHAPTER 4 — Power calculation, Static IR Drop, EM Analysis
Example Procedure to Fix IR Drop Problems
RedHawk User Manual
| 79
Resistivity Sensitivity
1.
As a way of evaluating its impact on voltage drop, reduce the metal6 resistivity
from 0.027 to 0.014 in the RedHawk technology file.
2.
Now rerun Static->Network Extraction, Static->Power->Import, and Static->
Static IR-drop & EM analysis, using the modified technology file.
The worst Vdd - Vss differential is now 1.109V. This shows slightly more
improvement from the previous IR drop analysis.
3.
This would indicate that further improvement in IR drop could be obtained by
adding an extra layer of metal on top of metal6, or by changing the wire-bond
package to a flip-chip package.
If you feel there are additional IR drop problems that need to be resolved before
proceeding to Dynamic Analysis, see Chapter 7, "Fixing and Optimizing Grid and Power
Performance".
When you have finished evaluating and fixing IR drop performance, proceed to Chapter 5,
"Dynamic Voltage Drop Analysis".
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Introduction
RedHawk User Manual
| 80
Chapter 5
Dynamic Voltage Drop Analysis
Introduction
This chapter describes how to run dynamic voltage drop analysis using RedHawk-EV.
As described in Chapter 3, "User Interface and Data Preparation", the key required inputs
for running dynamic voltage drop analysis are:
• LEF files for cell library, including standard cells, memories, and I/Os
• Flat or hierarchical DEF files
• Synopsys .lib library files
• RedHawk .tech technology file - conductor and via resistance, dielectric thicknesses
and dielectric constants, EM current density limits
• Pad instance, pad cell, or pad location files
• RedHawk Global System Requirements (GSR) file, containing information on toggle
rates, frequency, clock roots, default slews, and block power
• Timing windows and slews from STA (recommended).
• Extracted parasitics from SPEF or DSPF (recommended)
• Pad, wirebond/bump, or package RLC information (recommended)
• VCD vector file (recommended if available)
• SPICE subcircuits for all memories, I/Os, and IP blocks (optional)
• GDSII for memories, I/Os, and IP blocks (optional)
It is assumed that input data has been prepared as described in Chapter 3, and static IR
voltage drop analysis has been performed, as described in Chapter 4.
The following sections describe the dynamic voltage drop analysis methodology and
procedures.
Preparing for Dynamic Voltage Drop Analysis
Perform Cell Characterization
1.
To create the dynamic current profiles, effective power resistance, and decoupling
capacitance for cells in your design, use the APL tool to perform characterization,
as described in Chapter 9, "Characterization Using Apache Power Library".
2.
In the GUI, import the dynamic current profiles (<cell>.current) generated from
APL characterization using the APL-> Import command. The decoupling
capacitance data (<cell>.cdev) is imported using the same form.
Calculate Power
3.
ANSYS, Inc.
If you have already performed power calculation, for example before performing
static analysis, you can import the results using the command Dynamic-> Power> Import.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
4.
RedHawk User Manual
| 81
If you have not already performed power calculation, refer to Chapter 4, "Power
Calculation, Static IR Drop and EM Analysis", which describes the procedure for
setting up the proper GSR keywords and running power calculation.
Network Extraction
5.
Perform network RLC extraction using the Dynamic -> Network Extraction
command. Any combination of R, L and C extraction can be selected, but use all
three for best accuracy.
If ECO changes have been made to decaps, vias, or pins and extraction must be
performed again, with the GSR keyword EXTRACTION_INC set to 1 (default), an
incremental extraction is performed only in the areas of ECO changes. Full design
extraction is always performed for changes to wires.
Pad and Package Parameter Setup
6.
Set up pad and package parameters by selecting Dynamic-> Pad, Wirebond and
Package Constraints.
See Chapter 12, "Package and Board Analysis", for more information about
package and board modeling.
Methods of Dynamic Voltage Drop Analysis
There are several methods of vectorless and VCD-driven dynamic voltage drop analysis
available in RedHawk. The chosen method of performing dynamic voltage drop analysis
depends primarily on whether a VCD file is available, and if so, the quality of the VCD
information. The goal is to use the best switching information available to construct a
realistic switching scenario with the information available. Available methods for
performing dynamic analysis are summarized in the Figure 5-1 diagram following.
RedHawk Dynamic Analysis
Vectorless Analysis
VCD-driven
Vectorless Analysis
RTL VCD-driven
Vectorless Analysis
Figure 5-1
VCD Analysis
Gate Level VCD-driven
Vectorless Analysis
Types of RedHawk Dynamic Analysis
Use the diagram, which shows key characteristics of vectorless, VCD-driven vectorless,
and VCD dynamic analysis, to help decide what type of dynamic analysis to perform.
Characteristics of vectorless dynamic analysis
• No VCD file available for design.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 82
• Covers realistic worst case switching scenario.
• Uses GSR keywords and the timing file to define realistic toggle rate and switching
times. See section "Setup for Vectorless Power Calculation", page 4-36, for methods
of defining the toggle rate accurately.
• Switching scenario is derived statistically and depends on several design-aware
factors, such as:
• areas with structural weaknesses
• instance timing windows
• logic/power/toggle rate of instances
• If Boolean function multi-states are defined in either SIM2IPROF or AVM, the state
names should be specified in the GSC file per instance. RedHawk power calculation
and dynamic analysis then automatically use those state definitions in the analysis.
If a GSC file definition is not provided:
• power calculation uses the average charge of all states
• simulation randomly selects one customer state to toggle, unless the toggle
rate is very low
Characteristics of VCD-driven vectorless dynamic analysis
• VCD file is available, but may not represent the worst case.
• Helps drive vectorless switching scenario creation.
• Two types of VCD files are available.
- RTL VCD
• Available in early design stages.
• Requires mapping RTL names to DEF. Using formal verification tools such as
Conformal or Formality, an RTL-to-gate level name mapping file is created.
Instance level name mapping, in addition to instance/pin and net level mapping,
also can be performed, using the mapping file format:
adsInst <instance_in_RTL> <instance_in_DEF>
• Switching activity at state points (PIs, FF, latches) is propagated through the
logic using the state propagation algorithm.
• Clock gating is inherently supported in this flow
• For missing VCD coverage, a constraint file can be used to assign toggle rates,
in addition to available RTL VCD, to improve switching activity.
• Realistic toggle rate distribution, which drives vectorless switching scenario
creation.
- Gate-level VCD
• Gate level VCD can be directly mapped to the design
• Peak power cycle is identified by scanning through the entire VCD
• Toggle rates are derived from VCD for all nets and used to guide vectorless
switching scenario creation
Characteristics of Event-driven VCD dynamic analysis
• Gate-level VCD with timing back annotation is used for a pure VCD analysis.
• VCD used for representing worst case and for measurement/correlation purposes.
• Peak power cycle(s) are identified by scanning through entire VCD.
• Specific cycle analysis with switching events and delays are derived from VCD.
The following sections describe the procedures for performing each type of dynamic
analysis.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 83
Vectorless Dynamic Analysis
Overview
If there is no VCD file available for the design, then a vectorless methodology can be used
to analyze the areas of significant dynamic voltage drop. There are two vectorless
methods that can be utilized, one that is beneficial early in the design process with
preliminary information that is very fast, and also normal vectorless analysis with good
information when high accuracy is required:
• Accelerated Dynamic (AD) analysis
• can be used for fast initial prototyping of the design, but is not intended as a
replacement for regular RedHawk analysis (not for sign-off)
• fast simulation time, with average speed-up of 5-6x
• average DvD accuracy degradation of 10-15%
• does not change DvD hot spot trend
• normal vectorless analysis
The input data and setup for both types of vectorless analysis is the same, as described in
the following section.
Input Data and Assumptions
For any vectorless type of analysis STA information is required to achieve reasonable
accuracy. The following information defined in the RedHawk timing file (compiled from
STA and typically named <design>.timing) is used for vectorless analysis:
• Clocks have a specified operating frequency, and domain information. Clock buffers
toggle twice every cycle, once on each positive or negative transition. An analysis of
the expected switching of instances in areas of P/G weakness can be performed using
the EVA_PG_AWARE keyword set to 1 (see section "EVA_PG_AWARE", page C-589)
and TOGGLE_RATE set to 0.
• Timing windows for each instance output pin have specified maximum and minimum
rise times and maximum and minimum fall times. Instances that belong to a clock
network are identified by their clock index number.
• Transition times (“slew”) for each instance pin have specified maximum and minimum
rise and fall times. The transition times for input pins are also used during designspecific APL characterization.
• Boolean multi-state definitions can be used in vectorless analysis if they are defined in
the Global Switching Configuration file (see section "Global Switching Configuration
(GSC) File", page C-548.
The following assumptions are made during dynamic analysis for the instances that
switch:
• Any instance that is determined to switch and has its timing window in the first cycle of
the simulation period will switch in the first cycle of the simulation period. In the next
cycle of simulation the instance will also switch, but in the opposite direction.
• For memories, if the instance is in 'write' mode during the first cycle, the instance will
be in the 'read' mode during the second cycle.
Standard Vectorless Analysis Procedure
The following are the key steps in performing vectorless dynamic voltage drop analysis:
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 84
1.
For the most accurate power analysis you must compile and input the best toggle
rate information available to indicate the average switching performance of the
instances in the design. The general priorities for setting toggle rates using GSR
keyword values are listed below, from highest to lowest. However, because there
are interactions between values chosen for each keyword in a specific design, see
section "Setting the Toggle Rate", page 4-38, or Appendix C, for more information
about toggle rate specification and instance toggle rate estimation. The general
priorities for toggle rate determination are described in Chapter 4. See section
"Setting the Toggle Rate", page 4-38.
2.
To control the switching scenario, set the switching state parameters for instances
in the Global Switching Configuration (GSC) file and refer to the file with the GSR
keyword GSC_FILE.
3.
When the best toggle rate information available has been input into the GSR, use
the Dynamic -> Vectorless Dynamic Voltage Drop Analysis command to start
execution.
4.
A worst-case switching scenario for the sequential nets is derived by RedHawk
based on the user-specified toggle rate information. The switching scenario
constructed by RedHawk is constrained to meet the known total average chip
power specified in the GSR, so that a realistic switching scenario is obtained.
5.
Using the worst-case switching scenarios and current profiles from either the LIB
files, or for more accuracy, from APL characterization, RedHawk performs a
simulation of peak current contributions from all switching events to obtain a
realistic time-varying current over the simulation time at each node.
6.
To support multi-state analysis, if Boolean function states are defined in either
SIM2IPROF or AVM, and the state names are specified in the GSC file per
instance, RedHawk power calculation and dynamic analysis automatically use
those state definitions in the analysis.
7.
From the time-varying node currents RedHawk computes the associated timevarying dynamic voltage drop at each node over the simulation time.
Note: You can import a different STA file during or after analysis to create a different
simulation scenario using an ‘import sta’ command in the batch file or from the
TCL command line.
Unified Clock Gate Handling and Analysis
There are two ways to handle clock gates-- Gated On Percentage (GOP) and Automatic
Clock Gate Handling. Both of these types of analysis flows are merged using the
STATE_PROPAGATION GSR keyword, with different options. If this keyword is not
defined, state propagation is off and instance switching is determined by default toggle
rates in the design. The dynamic part of state propagation is controlled by a separate
option, now called FLOP_ON_PERCENTAGE.
Automatic Clock Gate Handling (default)
The GSR setting for basic State Propagation is
STATE_PROPAGATION {
PROPAGATION_MODE probability
}
With this invocation the gate enable ratio is automatically set at the output of the clock
gates (the enable ratio specifies the probability that any clock gate is On, and is the value
used to scale the clock toggle rate down). The enable rate is derived by propagating
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 85
upstream toggle rate values from the primary inputs. You can turn this off by setting the
SP option AUTO_CLOCK_TRACING to 0 (On by default).
Two Flow Types
Basic clock gate handling can be divided into two types of flows, Ratio-Based and On/OffBased. The basic elements of the two flows are shown graphically in Figure 5-2.
• Ratio-Based flow
• The toggle rates at clock gate outputs are scaled down.
• Can be used for both static and dynamic analysis.
• ON/OFF-Based flow
• Each clock gate is set to either ON or OFF.
• Can be used to control switching scenarios during dynamic analysis.
Figure 5-2
Two types of clock gate handling
Ratio-Based Approach
The syntax for the ratio-based approach is:
STATE_PROPAGATION {
PROPAGATION_MODE probability
CLOCK_GATE_ENABLE_RATIO <ratio>
}
In this approach, a single clock gate enable ratio value is specified, which is applied to all
clock gates in the design, and the output clock toggle rates are all scaled down by this
ratio. Note that this setting is the same as using GOP, along with the TCL command
‘setup analysis_mode static’, but a warning is displayed if GOP is also used, and
this option is obsolete.
Note that the SP option CLOCK_GATE_ENABLE_RATIO by default affects both Inferred
and Instantiated clock gates. Instantiated clock gates are a type of clock gate by lib
definition, while Inferred Clock Gates are instances such as AND gates, which can be
used as clock gates. However, there is also an option to provide separate control for
inferred clock gates, as follows:
STATE_PROPAGATION {
PROPAGATION_MODE probability
CLOCK_GATE_ENABLE_RATIO <>
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 86
INFERRED_CLOCK_GATE_ENABLE_RATIO <ratio>
}
You can set the option “INFERRED_CLOCK_GATE_ENABLE_RATIO 1” if you do not want
inferred clock gates to affect the clock toggle rate.
The unified flow also offers the flexibility to choose between cascaded and non-cascaded
modes of clock gate handling. The following diagram explains cascaded and noncascaded flows in clock gate handling. When the gating ratio is cascaded, the gating ratio
at any gate depends on the upstream gates and their probability of its switching. The
following is an example of cascaded flow:
And the following is a non-cascaded flow.
The default flow is non-cascaded, to be consistent with the traditional GOP flow. You can
enable cascaded-type handling (which is more realistic) using the following setting:
STATE_PROPAGATION {
PROPAGATION_MODE probability
CLOCK_GATE_ENABLE_RATIO <ratio>
ENABLE_CASCADED_CLOCK_GATING 1
}
Custom clock gate enable ratio values also can be specified for desired clock gates with
the help of a user-defined clock gates file. The keyword setting is:
STATE_PROPAGATION {
PROPAGATION_MODE probability
CLOCK_GATE_ENABLE_RATIO_FILE <cg_ratio.file>
}
where the <cg_ratio.file> format is:
#<clock_gate_name> <enable_ratio>
...
ON/OFF-Based Approach
In the ON/OFF-based gate handling approach, each clock gate is set either ON or OFF.
This is the same as the dynamic behavior of the previous similar option
GATED_ON_PERCENTAGE. The GOP option name is changed to FLOP_ON_PERCENTAGE
to reflect more accurately the behavior of the option. When the FOP fraction is set 0.5, it
does not mean that 50% of the clock gates are ON, it only means that 50% of flops are
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 87
ON. This is achieved by controlling clock gates upstream of these flops. PowerStream
finds the number of flops controlled by each clock gate, looks at the specified FOP
fraction value, assesses the number of flops be turned ON to reach the target, and
decides which clock gates must be set ON to achieve this target. The syntax is:
STATE_PROPAGATION {
PROPAGATION_MODE probability
FLOP_ON_PERCENTAGE <FOP_fraction>
FOP_CONTROL_FILE <cg_on_off.file>
}
Just as for the Ratio-based approach, there is also a custom flow setting file for the ON/
OFF approach, using FOP_CONTROL_FILE <cg_on_off.file>, where the
<cg_on_off.file> format is:
#<clock_gate_name> <ON/OFF>
...
RTL VCD-Driven Vectorless Dynamic Analysis
Designs with gate level VCD files have a complete set of vectors available for accurate
power analysis at the instance level. However, for designs with RTL level VCD data,
detailed switching information at the instance level must be estimated. Designers often
want to employ unit-delay or true-timing gate-level simulation results as stimuli to achieve
very accurate DvD analysis. However, true-timing gate-level simulation data often takes a
prohibitive amount of time to generate, and it is often not available until the end of the
design cycle.
RedHawk provides a state propagation engine to achieve a statistically realistic method of
evaluating power in both clock and logic circuits under complex switching conditions,
such as clock gating methodologies, without gate-level simulation data. This method
automatically produces an accurate set of toggle rates for each instance in the design.
RedHawk supports state propagation-based power calculation in the RTL-VCD flow, as
well as event propagation-based power calculation. In the RTL VCD-based State
Propagation flow the toggle rates for the primary inputs and flop/latch outputs are
calculated from the RTL VCD, and then this activity is propagated using State
Propagation. This provides a compromise between RTL VCD-driven Event propagation
and probabilistic State Propagation, which is useful when you want to calculate power for
a longer duration of the VCD, and event propagation engine would have a run time
penalty. State propagation analysis is controlled using STATE_PROPAGATION GSR
keyword options, as described in Appendix C.
Data Requirements for State Propagation
RTL VCD or FSDB files
VCD is the output of functional simulators such as VCS, NC-Verilog and ModelSim. FSDB
is a binary and reduced-size version of the VCD file. Both block-level and top-level VCD
or FSDB files can be imported into RedHawk. A switching toggle rate is extracted from
them for a given time frame (or for the entire VCD simulation period) for all state points.
You can also set toggle rates, or override those in VCD file, using a constraint file. For
nodes missing in the VCD file, default toggle rates can be used.
Mapping files
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 88
RTL level netlist names map to different gate-level DEF netlist names. RedHawk requires
a mapping file in a two-column format, associating each node in the RTL level with the
corresponding DEF netlist name, with the RTL names on the left and the DEF names on
the right. This mapping information can be easily extracted from tools like Conformal and
Formality. Note that in the RTL VCD mapping file the RTL names are on the left and DEF
names are on the right.
Mapping inverted elements
The RedHawk RTL VCD flow supports inverted mapping, such that while annotating from
RTL VCD, an inversion is performed before annotating activity to the QN pin. The
AutoNameMapping function maps inverted flops using the following syntax in the name
mapping file:
<RTL_signal_path_RTL_VCD> <Gate_pin_path_design> -inverted
For example,
top/block/count top/block/count_reg/QN -inverted
For all inverted mapping, RedHawk first inverts the signal state in RTL VCD and then
does annotation to the GATE pin.
GSR Keywords to Support RTL VCD Flow
The Global System Requirements file keywords VCD_FILE (see section "VCD_FILE",
page C-585) and BLOCK_VCD_FILE (see section "BLOCK_VCD_FILES", page C-560)
specify RTL VCD files, along with parameters affecting how the VCD files will be
imported. If multiple VCD files need to be imported, use the BLOCK_VCD_FILE keyword.
The VCD_FILE option FILE_TYPE should be set to RTL_VCD or RTL_FSDB, and the
option VCD_DRIVEN should be set to “1”, then the State Propagation engine is activated
in RTL VCD-driven mode. It scans the RTL VCD to derive the toggle rate at state points
(FF/registers), and propagates the toggle rate to downstream logic. See section "Global
System Requirements File (*.gsr)", page C-550, for more information on using these RTLVCD related keywords.
State Propagation Constraint File
For nodes that are missing in the VCD/FSDB files, toggle rate constraints can be set
through a constraint file designated with the CONSTRAINT_FILE option of
STATE_PROPAGATION. A template of this constraint file listing all the state points in the
design can be generated with the RedHawk TCL command ‘dump sptemplate’. The
generated template file from this command is adsRpt/state_propagation.template. An
example of a state propagation constraint file is shown below:
# analysis mode: static
# Format: <port/pin> <toggle_rate (2.0-based)>
# 1. Clock roots
clk_A 0
clk_B 1.8
# Primary inputs
scan_mode 0.05
scan_en 0.08
# Register outputs
i_pram_00/mem3/do[11] 0.15
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 89
Note: The maximum toggle rate is 2.0, which means that the signal makes 2 transitions
(0>1 and 1>0) every cycle. Fully active clocks have a toggle rate equal to 2.
You can propagate a toggle rate of 2 to MUXs during state propagation, independent of
the 'Select' pin toggle rate, using the GSR keyword 'SP_CLKMUX_AUTO 1'. Since it is
very tedious to identify the Select pins of multiplexers and assign the correct state to
them, a toggle rate of 2 can be assigned from a multiplexer onward in the clock network.
When using STATE_PROPAGATION without any VCD files, toggle rates are still
propagated based on the constraint file or the default toggle rate. Using the constraint file,
you can specify toggle rates for clock roots, primary inputs, and outputs of registers. For
memories, both input and output toggle counts need to be included.
Following setting up the appropriate keyword values and constraint files for estimating
toggle rates and performing state propagation, RedHawk can run static and dynamic
analysis normally without any additional command.
RTL VCD Reports
There are several reports generated by RTL VCD analysis:
• the adsRpt/vcd_uncovered_syms file contains the VCD symbols that are not in the
design.
• the adsRpt/vcd_uncovered_mems file contains the memory instances that are not
covered in the design.
• the adsRpt/vcd_uncovered_ffs lists ffs/latches that are not covered and are not in the
clock network
• the adsRpt/vcd_uncovered_clk_ffs file lists ffs/latches that are not covered and in the
clock network
Also note that several other reports are generated if the PS_RTL_EP_REPORT GSR
keyword is set, as follows:
• adsRpt/vcd_covered_ffs : list of ff/latches that are “covered” in VCD/FSDB, meaning
those in which one of the outputs is covered.
• adsRpt/vcd_covered_nets : list of nets that are covered in VCD/FSDB
• adsRpt/propagated_insts : list of instances that are propagated
• adsRpt/propagated_nets : list of nets that are propagated through
Gate Level VCD-Driven Vectorless Dynamic Analysis
Input Data and Assumptions
To use the VCD-driven vectorless method in a hierarchical design, specify the VCD file in
the GSR file, along with the hierarchical prefix in the VCD and the start and end times, as
follows:
BLOCK_VCD_FILE {
VCD_FILE
{
<Hierarch_path/DEF_instance_name1> <VCD file>
FILE_TYPE <VCD | FSDB | RTL_VCD | RTL_FSDB >
FRONT_PATH <redundant_path_string>
SUBSTITUTE_PATH <substitute_path_string>
FRAME_SIZE <cycle_time>
START_TIME <analysis_start_time>
TRUE_TIME [0|1]
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 90
MAPPING <filename>
}
VCD_FILE
{
<Hierarch_path/DEF_instance_name2> <VCD file>
...
}
}
where
<Hierarch_path/DEF_instance_name> <VCD file>: specifies the hierarchical
block name that matches that identified in the DEF and the absolute or
relative path to the VCD or FSDB file
FILE_TYPE [ VCD | FSDB | RTL_VCD | RTL_FSDB] : identifies the type of input
FRONT_PATH <redundant_path_string> : specifies the string that does not match
the DEF path. Must be replaced by SUBSTITUTE_PATH string.
SUBSTITUTE_PATH <substitute_path_string>: the substitute path string to match
the DEF hierarchy.
FRAME_SIZE <value_ps> : specifies the duration per frame for cycle-by-cycle
power calculation; the cycle time in ps (1/FREQ); default is 5000 ps.
START_TIME <value_ps> : optional, specifies the analysis start time in the VCD
for power calculation; start default time = 0, end default time is end of VCD/
FSDB file.
TRUE_TIME : if =0, uses STA timing data and assumes no glitches; if =1, uses
VCD switching and timing data; default=0.
MAPPING <filename> : name of map file with RTL VCD instance names and
corresponding DEF instance name
Analysis Procedure
The following are the key steps in performing VCD-driven dynamic voltage drop analysis:
1.
After putting the appropriate information into the VCD_FILE GSR keyword, use the
Dynamic -> Vectorless Dynamic Voltage Drop Analysis command.
Alternatively, the TCL command for invoking vectorless dynamic analysis is:
perform analysis -vectorless
ANSYS, Inc.
2.
For a VCD-driven vectorless dynamic simulation, the switching and transition times
are obtained automatically from the STA file. The switching scenario is created
based on the toggle rate obtained from the VCD.
3.
Using the worst-case switching scenarios and current profiles from either the LIB
files, or more accurately, from APL characterization, RedHawk performs a
simulation of peak current contributions from all switching events to obtain a
realistic time-varying current waveform over the simulation time at each node.
4.
From the time-varying node currents RedHawk computes the associated timevarying dynamic voltage drop at each node over the simulation time.
5.
The worst case node voltages are then compiled into an ordered list.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 91
VCD Dynamic Analysis
Input Data and Assumptions
If the VCD file for the full chip or block level is available and the timing information is
accurate in the VCD files, then VCD dynamic analysis can be used. Accurate timing in
the VCD can be obtained if delays (that is, through SDF) are back-annotated during
simulation. In the case of VCD dynamic analysis, the following assumptions are made:
1.
Switching scenario. The switching scenario is determined entirely from the VCD
files. Every active net should be described in the VCD; for any net not in the VCD
file, it is assumed that instances attached to the net are inactive.
2.
Instance switching. Any instance that is determined to switch from the VCD file
will switch in simulation, with the switching time defined in the VCD file. STA timing
windows are not used.
Note: Instances specified in the GSC file override the VCD file net specification.
3.
Transition times. Switching instances use the transition times in the STA file. If an
STA file is not provided, the value of the INPUT_TRANSITION keyword in the GSR
is used for every instance in the design. Therefore, using STA file values is strongly
recommended.
4.
Cycle Selection. For automatic cycle selection by RedHawk, set the following
option of the VCD_FILE GSR keyword:
VCD_FILE
{...
SELECT_RANGE <start_time> <end_time>
...
}
If -1 is set for start and end times, the full VCD period is included in cycle selection.
5.
Simulating entire VCD. When DYNAMIC_SIMULATION_TIME is set to 0 and
START/END_TIME are not specified, entire VCD is used for power calculation and
simulation.
6.
Multi-state Boolean functions. Boolean definitions of the multi-states are
checked in the VCD file. Where there is a match with definitions in AVM or
SIM2IPROF. the state is triggered using the current profile defined for the state in
AVM or SIM2IPROF.
VCD Critical Cycle Selection
When the critical cycle selection feature is used, RedHawk automatically selects the most
critical cycles from a large vector dump. Cycle selection supports both True-time and nonTrue-time gate and RTL level VCD analysis in power calculation. The method calculates
the power for each cycle and finds the cycle consuming the highest power. The time span
(width of each cycle) is decided by the keyword DYNAMIC_SIMULATION_TIME. Each
span is swept by a small time-step and power is calculated across this span using a
sliding window.
An ordered list of critical cycles identified during cycle selection is automatically provided
in the report file adsRpt/worst_power_cycle.rpt.
PRUNE Feature in RTL VCD flow
The RTL VCD PRUNE feature improves the performance of RTL_VCD cycle selection by
optimizing selection of candidate power-intensive cycles for event propagation, and
reducing the total time required for cycle selection. The key features of Pruning are:
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 92
• No event propagation - The algorithm extracts net weights from the design directly and
does not need to propagate the events. The toggling nets determine the cycle powers
directly.
• No timing delay calculation - It is assumed that a net toggling results in subsequent
toggling immediately. This saves most of the work on clocking analysis.
• VCD-covered nets only - Typically an RTL-VCD case has VCD coverage less than
10%. The algorithm focuses on the VCD-covered nets only, and hence reduces
memory usage and I/O operations.
• Block- based pruning methodology (that is, pruning analysis performed on each block
separately when multiple RTL-VCD files are present)
• RTL-VCD file reuse (pruning results are reused for duplicate blocks)
• Support for cycle selection mode (VCD_FILE option WORST_DPDT_CYCLE).
• Support for VCD_FILE option STA_VCD_FREQ_RATIO and GSR keyword
POWER_VCD_NUM_PROCESS.
Pruning is most effective for the following design conditions:
• Extensive VCD/FSDB data - The overhead to collect pruning data offsets the
performance gain if the cycle number is not high.
• Progressive power profiles - Pruning is more effective when switching intensity
changes in a progressive manner. It is more difficult for cycle powers that vary within a
narrow range and in a rapidly oscillating fashion.
• Sporadic impulsive power changes - Pruning is most effective if the cycle power profile
has sporadic impulsive changes. The time spans between the pulses can all be
pruned.
The pruning process is enabled by adding the ‘PRUNE 1’ option of the VCD_FILE GSR
keyword, such as:
VCD_FILE {
core_top top.vcd
FILE_TYPE RTL_VCD
PRUNE 1
SELECT_RANGE 10000 100000
}
Multi-Bit Sequential Cell Handling in VCD Analysis
Multi-bit sequential cell handling can include individual edge-triggered events, where all
input/output pins do not have to trigger off the same event, such as the clock toggle. Multibit sequential cell handling considers edge-triggered events if they are defined using the
sim2iprof configuration file COMPOSITE_STATE keyword (see section
"COMPOSITE_STATE", page E-899).
Mixed Mode VCD and Vectorless Analysis
RedHawk supports input data including both VCD and Vectorless settings, which provides
more freedom to fine-tune the settings at block level. Some key features are:
• A block level VCD with a top-level vectorless approach is supported, where you can
provide one or more block VCDs.
• The GSR keyword BLOCK_VCD_FILE defines one or more VCD blocks for analysis.
Each block is specified using the VCD_FILE option with a block name (hierarchy
path).
• Mixed mode allows you to specify a mix of True time and Non-True time VCDs.
• S-parameter package models are supported.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 93
• CPM creation is enabled.
• Allows for scaling VCD and STA frequencies with STA_VCD_FREQ_RATIO. Note that
block level STA_VCD_FREQ_RATIO is supported only in Mixed Mode.
• GSR keywords DYNAMIC_SIMULATION_TIME and DYNAMIC_PRESIM_TIME
define the VCD simulation time span. VCD_FILE ‘Start_Time’ is honored, but
‘End_Time’ is not used. DYNAMIC_PRESIM_TIME defines the presim time span at
‘Start_Time’ backward. Auto Presim, that is the default DYNAMIC_PRESIM_TIME, or
set to -1, is honored.
• Low power analysis is enabled in mixed mode. For procedures to run dynamic voltage
drop analysis on low-power designs, see Chapter 13, "Low Power Design Analysis".
The following GSR keywords are supported for non-VCD blocks:
• GSC_FILE
• BLOCK_POWER_FOR_SCALING(_FILE)
• STATE_PROPAGATION
• STA_FILE CONST
• TOGGLE_RATE_RATIO_COMB_FF
• INSTANCE_TOGGLE_RATE(_FILE)
• BLOCK_TOGGLE_RATE(_FILE)
• TOGGLE_RATE
If you provide a block VCD file for a block that has a sub-block not covered in the VCD,
then the instances inside sub-block are always Off, unless otherwise specified in the
GSC. If simulation time is a multiple of FREQ, then the multi-cycle vectorless approach is
used for the instances that are not covered by VCD.
Analysis Procedure
1.
To use VCD files in the analysis, define the desired VCD constraints and parameters in
the GSR keyword VCD_FILE.
2.
Invoke the Dynamic -> VCD-based Dynamic Voltage Drop Analysis menu
selection in the GUI, and select the Use VCD Timing option in the dialog box. The
start and end times for VCD simulation can be for any duration in the VCD file. The
utility vcdscan can also be used to determine the start and end times for simulation.
3.
For worst-case DvD cycle selection, the procedure is:
setup design
perform pwrcalc # calculates power for the critical cycle
perform extraction
setup package
perform analysis -vcd # dynamic run for the critical cycle
A sample portion of a GSR file for a mixed mode design follows:
...
FREQ 200e6
TOGGLE_RATE 0.2
BLOCK_VCD_FILE
{
VCD_FILE
{
ABCD10_SEL user_data/vcd.1
front_path "TOP/CHIP/"
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 94
substitute_path ""
start_time 100000
true_time 1
}
VCD_FILE
{
ABCD20_TEG user_data/vcd.2
front_path "TOP/CHIP/"
substitute_path ""
start_time 600000
true_time 1
}
}
DYNAMIC_PRESIM_TIME 10n
DYNAMIC_SIMULATION_TIME 20n
...
This example has two VCD blocks, ABCD10_SEL and ABCD20_TEG. The ABCD10_SEL
block has a VCD presim time (90ns-100ns) and simulation time (100ns-120ns). The
ABCD20_TEG block has a VCD presim time (590ns-600ns) and simulation time (600ns620ns). The remaining sections of the design will be handled as vectorless.
Gated Clock Dynamic Analysis
Gated clock control activity is typically defined in the VCD file, and, in the case of RTLVCD flow, it is propagated through the clock network and logic. However, if no VCD is
available, the gated clock domain activity is controlled using the GSR keyword STATE
PROPAGATION and option GATED_ON_PERCENTAGE. The state propagation engine
is used to propagate the assigned logic level at the gated clock control throughout the
downstream clock network, as well as through the data paths controlled by this clock
domain. State Propagation uses a vectorless method to model statistically several
aspects of gated clock domain activity for static/dynamic analysis. State propagation
automatically identifies gated control nets through back-tracing from FF clock pins or STA
data.
Input Data
The required input data for gated clock domain analysis is as follows:
• Technology file
• LEF file that describes macros placed in the design
• Top-level DEF file
• Voltage source locations (from PLOC/DEF file)
• Synopsys Library models (.LIB models)
• STA/TIMING file, having TWs defined for all the instances in clock tree network
• SPEF file (optional)
GSR Keywords for Clock Domain Gating
State propagation allows users to control gated clock domain activity using the GSR
keywords STATE_PROPAGATION and its option GATED_ON_PERCENTAGE
<On_fraction>, GATED_CONTROL_FILE <control_filename>, and
SP_CLOCK_GATING_RATIO.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 95
State Propagation can find the gating ratio at each clock gate automatically by
determining the duty cycle at each enable net and propagating toggle rates from
upstream logic to obtain gating ratios for each clock gate in the design. For RTL_VCD
State Propagation this helps achieve very accurate power values for sequential logic.
For vectorless State Propagation, this provides a much better estimation of chip power, as
the gating ratio is derived through propagation from primary inputs. The GSR keyword
PS_SP_GATED_CLOCK_LOGIC can be set to 0 to disable this feature.
For more control over the gating ratio, set a global gating ratio for all clock gates in the
design, using the GSR keyword ‘SP_CLOCK_GATING_RATIO <ratio> ‘, where the
<ratio> value must be between 0 and 1.
Gated clock control activity can be specified globally using GATED_ON_PERCENTAGE,
which counts flop/latches/memory instances at leaf level, and includes always-on leaf
cells. Note that by specifying GATED_ON_PERCENTAGE as the fraction 0.5, for
example, RedHawk randomly picks 50% of the gated control cells and turns them “On”.
However, for dynamic analysis this may not ensure that the clock network power is scaled
down to exactly 50%, since it depends upon the gated clock control granularity. Individual
settings for certain gated clock instances can be specified using the
GATED_CONTROL_FILE option, with the remaining unspecified individual states being
assigned according to the global On setting.
Modeling methods and the associated keywords for clock gating are described below.
The POWER_TRANSIENT_ANALYSIS GSR keyword can be used to specify
configuration files to define gated clock control activities for each time frame of interest.
Multiple time frames define different clock activities over defined groups of cycles.
GSR Settings for State Propagation
State propagation analysis is controlled using the following GSR syntax:
STATE_PROPAGATION {
GATED_ON_PERCENTAGE <On_fraction>
PROPAGATION_MODE PROBABILITY
? CONSTRAINT_FILE <constraint_filename> ?
? GATED_CLOCK_COVERAGE [ 0| 1]?
? GATED_CONTROL_FILE <control_filename>?
where
GATED_ON_PERCENTAGE <on_fraction>: specifies the percentage of buffers
that are on, as follows:
All gating cells are on if GATED_ON_PERCENTAGE is 1
All gating cells are off if GATED_ON_PERCENTAGE is 0
Increasing the value of GOP turns on additional buffers, and does not turn
off any that are already turned on. So, any clock buffer that is on with a
GOP of, for example, 0.6, is also on when GOP is set to 0.8.
PROPAGATION_MODE : PROBABILITY automatically determines switching
probability for instances.
CONSTRAINT_FILE : specifies a file describing the toggle rate of key instances
or nets for accurate toggle rate propagation.
GATED_CLOCK_COVERAGE : when set to 1, provides better design coverage
when using GATED_ON_PERCENTAGE, and allows choosing different
clock gate turn-on scenarios for each frame so that overall analysis coverage
is increased. Note that POWER_TRANSIENT_ANALYSIS must also be
turned on.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 96
GATED_CONTROL_FILE : specifies a file defining the On/Off status of individual
gated control cells, with the following syntax: The format of the gated control
file data is as follows for both static and dynamic analyses:
<gated_clock_instance> [ On | Off ]
Setting State Propagation Constraints
The State Propagation flow has a convenient method for assigning gating ratios for clock
gates, as well as activity factors for primary inputs. Even before the power calculation
step, RedHawk can dump files containing all clock gates and primary inputs. You can
then edit these files to set custom clock gating ratios at the required clock gates, and also
specify activity at the desired primary inputs. State Propagation then uses these settings
to determine toggle rates for all nets in the design.
The Tcl command is:
dump sp_constraints
This command dumps files state_propagation.cg and state_propagation.pi in the adsRpt
directory. The formats of these files are shown below:
Format for file adsRpt/state_propagation.cg:
<clock-gate_instance> <gating_ratio> <level>
Format for file adsRpt/state_propagation.pi:
<net-name> <toggle_rate> <duty_cycle>
These files can be edited to give specific gating ratios to clock gates, and also to set
activity for the primary nets. All clock gates whose gating ratios have not been defined
through a constraint file have their gating ratio derived by default from upstream logic, or
from global gating ratio keyword settings. The edited files can be passed back to
RedHawk using two GSR keywords.
For Clock Gates:
SP_CG_CONSTRAINT_FILE state_propagation.cg
For Primary Inputs:
NET_TOGGLE_RATE_FILE state_propagation.pi
If there is already a NET_TOGGLE_RATE_FILE, then the constraints file
state_propagation.pi is appended to it.
adsRpt/state_propagation.GCControls file
Each state propagation run dumps out a list of all gated clock control cells’ On/Off states
in the adsRpt/state_propagation.GCControls file. If you have your own list of control
signals present in the design, you can modify this file with your list and use it as input to
the GATED_CLOCK_CONTROL option. The format of the file is (per gate):
<gc_instance_name> <cell_type> [On | Off] <user_setting> <On_fraction>
where
gc_instance_name : gated clock instance name
On/Off : whether the gate is set to On or Off
user_setting : 0 - no user setting , 1 – user set to On, 2- user set to Off
On_fraction: actual realized Gated On Percentage so far. The <On_fraction> for
static analysis is the On-percentage/100 for a gated clock instance. For
dynamic analysis the <On_fraction> is the cumulative On percentage up to
the gated clock instance, in ascending order.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 97
Troubleshooting Files and Tips
Files that can be helpful in looking at problems are:
• adsRpt/state_propagation.template
• adsRpt/state_propagation.GCControl
• .apache/apache.tr - toggle rate information for each net
• .apache/apache.tr.i - toggle rate information for each instance
The following steps can be helpful in finding issues in clock domain analysis:
1.
Make sure .lib models are defined for all cells present in the clock tree network.
2.
Make sure LEF models are defined for all macros used in the design/clock tree
network.
3.
Check for adsRpt/apache.refCell.* files in the adsRpt directory.
4.
Make sure all the instances present in the clock tree network have timing windows
defined in STA/TIMING file.
• Check adsRpt/apache.tw0 for a list of instances that have missing timing
windows.
• State Propagation gets the clock network information based on the timing file
read in.
Scan Mode Dynamic Analysis
One of the largest peak current events in SOC designs occurs during scan chain
activation. Since clock skew is always minimized as standard practice, all toggling occurs
almost exactly at the same time. The subsequent propagation of changes races down the
logic networks. Even if the test frequency is slow relative to the functional frequency, all
current consumption occurs in the short period following the edges of the clock.
For example, as shown in a typical scan current analysis in Figure 5-3, the high current
peaks in scan mode can be 10-100 times the current in normal mode due to the
simultaneous switching of most of the registers.
A sample output is shown in Figure 5-3 below:
Figure 5-3
Switching current from scan mode analysis
Early design vectorless scan mode analysis
Full VCD gate-level scan mode analysis is the same as for functional mode analysis, and
is described in section "VCD Dynamic Analysis", page 5-91.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 98
Gate-level timing-annotated VCD with scan activity is usually available very late in design
cycle. Therefore, evaluating potential scan clock network problems early in design (based
on initial placement) by using this scan methodology, in which RedHawk generates the
scenario files from constraint file specifications, can avoid many cases of chip failure and
yield reduction.
The scan mode flow is a non-true timing flow, in which PowerStream decides the
sequence of switching, but the actual time of switching is determined by the STA file.
RedHawk can drive the data outputs of scan registers according to the scan outputs, and
their behavior is based on the functions described in LIB file.
GSR keywords DYNAMIC_SIMULATION_TIME and PRESIM_TIME are also honored in
this flow
Key characteristics
• Toggle activity at scan flip-flops derived from input pattern
• Toggle activity at scan flip-flops propagated through combinational logic
• Scan input patterns can be simple, such as “1010” (stress pattern), or more designspecific from ATPG
• Activity at all nodes in design highly deterministic (not random)
Input Scan File Preparation
The input data required for early scan mode analysis requires only preparation of the scan
constraint files, and specifying the files and the required patterns using the
SCAN_CONSTRINT_FILES GSR keyword, as follows:
SCAN_CONSTRAINT_FILES {
<scan_chain_file_1> <pattern_1>
<scan_chain_file_2> <pattern_2>
...
}
The format of the constraint file contents is:
<inst_name>/<pin_name>
Example contents:
FF_inst/Q
...
Example 1: All scan chains have the same pattern, 01:
SCAN_CONSTRAINT_FILES {
scan_chain.spc
}
If no pattern is specified, the default pattern “01” is assumed.
Example 2: All scan chains have the same pattern, 0011:
SCAN_CONSTRAINT_FILES {
scan.spc 0011
}
Example 3: Multiple scan chains, each has its own pattern:
SCAN_CONSTRAINT_FILES {
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Methods of Dynamic Voltage Drop Analysis
RedHawk User Manual
| 99
scan_chain_1.spc 01
scan_chain_2.spc 101
scan_chain_3.spc 0011
...
}
Example 4: Using a scan chain order file. You can provide the actual scan chain
information, along with the scan pattern, using a scan chain order file. Each scan chain
order file contains one scan chain. A sample scan_chain_order file is shown below:
reg_1/Q
# driver for reg_2
reg_2/Q
# receiver for reg_1, driver for reg_3
reg_3/QB
# receiver for reg_2
...
Scan-chain order files dumped from the implementation environment can be converted in
the above format using simple scripting. The switching sequence of the scan fflops is
determined by the given pattern, whereas switching time is annotated from the STA file.
The switching pattern can be directly specified in the GSR-- for example, “10101”, or
using a pattern file (in case the pattern is long). If the pattern length is less than the chain
length, the pattern is repeated for the remaining chain. If the pattern or pattern-file is not
specified, a pattern of “0101…” is used.
Sample pattern files, either a single bit in each line:
0
1
1
0
...
or a whole pattern in a single line:
0110...
During simulation, the pattern is shifted, and that determines the switching activity on the
fflops, as well as subsequent data-paths. For example, consider there are 10 registers in
the chain, and the scan pattern is “1001”. RedHawk repeats the pattern to make it the
same length as the scan-chain length -- so “1001100110”. During simulation, the last
fflop output switches from 0 to 1, second to last fflop output switches from 1 to 1, and so
on. The same pattern is continued in subsequent clock cycles, as shown below:
0 1 1 0 0 1 1 0 0 1 - at the beginning of simulation
0 0 1 1 0 0 1 1 0 0 - after first clock cycle
1 0 0 1 1 0 0 1 1 0 - after second clock cycle
Auto Tracing Scan Method
RedHawk also can perform auto-tracing of scan chains, using the AUTO_TRACING
option, as follows:
SCAN_CONSTRAINT_FILES {
AUTO_TRACING [<pattern>]
}
When auto-tracing is specified, PowerStream finds all scan chains in the design and
applies the specified <pattern> to those chains.
Running RedHawk analysis
The normal dynamic analysis flow commands for scan mode are:
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Evaluating DvD Analysis Results
RedHawk User Manual
| 100
setup design <design>.gsr
perform pwrcalc
perform extraction -power -ground -c
perform analysis -vcd
The -vcd option has to be specified in the ‘perform analysis’ command so that simulation
picks up the scenario created by scan flow.
Gate-level VCD scan mode analysis
Scan mode analysis flow is the same as normal functional mode gate-level VCD analysis,
as described in section "VCD Dynamic Analysis", page 5-91.
Key characteristics
• Determines worst power or worst dynamic voltage drop cycles
• Activity derived in chosen cycles from VCD
• Dynamic analysis replicates scenario in VCD
Evaluating DvD Analysis Results
Types of DvD Results
After completing dynamic analysis, select the IR menu button to display the results.
RedHawk-EV outputs include:
• Dynamic voltage drop contour maps
• Power density and current maps
• Capacitance maps, including decap effects
• Report files (see Chapter 6, "Reports"), including summary files for dynamic voltage
drop, power, EM and pad current, Error and Warning reports, and command log files.
To view a list of high voltage drop instances and their VDD-VSS values, use the Results > List of Worst DVD Instances for Dynamic Simulation command. A table is displayed
showing instances in order of highest DvD, and a number of other related parameters,
including
• ‘Ave DV’ - average dynamic voltage within the timing window
• ‘Max DV’ - maximum dynamic voltage within the timing window
• ‘Min DV’ - minimum dynamic voltage within the timing window
• ‘Min DV WC’ - minimum dynamic voltage for the whole cycle
• location of instance
• name of instance
The list can be sorted based on any of the four DV parameters.
• ‘Max VDD-VSS’
• ‘Min VDD-VSS’ over the simulation cycle
• ‘Min VDD-VSS over timing window’ of the instance
• ‘Avg VDD-VSS over the timing window’.
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Evaluating DvD Analysis Results
RedHawk User Manual
| 101
These parameters are shown in Figure 5-4 below.
Vdd-Vss Difference Waveform
m
M
Timing Window
M minimum difference over simulation time
m minimum difference over TW
effective Vdd-Vss over TW (average)
Figure 5-4
Instance DvD Analysis Criteria
The highest voltage drop instances can also be viewed in a voltage drop map by selecting
'View -> Dynamic Instance Result and then selecting one of the four maps.
• View the wire based voltage drop map
• View the instance based voltage drop map
• View the decoupling capacitance used in the analysis using the DD button.
• View the dynamic power density using the PD button.
Note the differences between each.
All the log files and data files are under adsRpt directory. Look in that directory to see the
files that have been created. Files specific to a dynamic analysis are kept in the Dynamic
sub-directory.
The file <designName>.ipwr has the time domain current information of the total current
demand by all instances in the design, while the file <designName>.ivdd has the time
domain current information for the current supplied by the pads.
Power and ground waveforms can be plotted using the TCL commands:
plot current [-vdd | -gnd | -pwr | -net ?-name <net_names> ?|
-pad ? -name <pad_names>? ] ?-o <output>? ?-sv?
where
-vdd | -gnd | -pwr | -pad: plots VDD, GND, PWR, or PAD current
waveforms. If lists of <net_names> or <pad_names> are not given for -net or
-pad, all net or pad current waveforms are displayed.
By default the waveforms are extracted and rendered in 'xgraph', while the ‘-sv’
option plots it using the Apache 'sv' program.
Filtering Minimum DvD Results
Using the keyword DVD_GLITCH_FILTER, conditions for filtering (ignoring) some values
of minimum DvD over the timing window (called “minTW”), based on voltage level and
glitch width conditions, can be set, as shown in the Figure 5-5 diagram. Minimum DvD
values can be filtered globally or using instance-specific conditions. An output report
listing the included and filtered DvD values is written to the file /adsRpt/Dynamic/
<designName>.minTW_filtered. Note: do not use glitch filtering in scan mode or
ANSYS, Inc.
CHAPTER 5 — Dynamic Voltage Drop Analysis
Replaying a Previous RedHawk Session
RedHawk User Manual
| 102
with power cycle selection. For details on filtering minimum DvD values, see the
keyword definition in section "DVD_GLITCH_FILTER", page C-673.
Timing window
Meas_V
W
minW
Figure 5-5
Glitch width filtering with DvD_Glitch_Filter
Replaying a Previous RedHawk Session
To use the GUI to start a script-based RedHawk run of a previous session, use the menu
command File -> Playback, which brings up a project directory dialog box that allows you
to select the run script from a command log of a previous session. The command log files
have filenames of the type: cmd.log.<date-time>. You must know the date and time of
the session to be able to select the correct session to play back.
TCL Commands to Run Dynamic Voltage Drop Analysis)
The follow table lists TCL commands available for running DvD analysis.
ANSYS, Inc.
TCL
Purpose
<vcd_cycle_time>? ?-a
<start_sim_time>?<end_sim_time>?
?-w <logical_ path>
<physical_path>? ?-d
<adsPower_directory>? ?-o
<outputFileName>? ?-msg
<msgFileName>? ?-cmd
<cmdFileName>?
?-tt <presim_time_ps> ?
Sets up for full VCD dynamic
DvD analysis when the GSR
contains the VCD_FILE section
defining the VCD constraints
for analysis.
perform analysis [-lowpower |
-vcd | -vectorless ]
Runs dynamic DvD analysis.
CHAPTER 6 — Reports
Introduction
RedHawk User Manual
| 103
Chapter 6
Reports
Introduction
Following the selected analysis, a number of method of reviewing the results are
available. Many methods of color mapping results are available from the Tools and
Results menus. See the GUI menu descriptions (section "RedHawk Graphic User
Interface Description", page D-794).
RedHawk displays the progress and results of each analysis command to a standard text
output. In addition, summary reports are written to the adsRpt and adsPower directories.
The various types of RedHawk results, maps and report files available are described in
this section.
The most complete set of results and outputs analysis tools can be found in Explorer
utility, under the Explorer menu.
RedHawk Log Files
Command Files
A command file is created in the adsRpt/Cmd directory for each RedHawk session, which
contains a record of all the top-level commands that were executed, such as design
setup, extraction, power calculation and static IR drop analysis. The date and time-stamp
extension of the filename represents the time when the RedHawk session was invoked:
redhawk.cmd.<date>-<time-stamp>
The command file can be used as a playback file to run RedHawk in batch mode, if a
replay is desired.
Log and Error Files
A complete RedHawk log file is created in the adsRpt /Log directory for each RedHawk
session, using the date and time when the session was invoked as the extension of the
filename, such as:
redhawk.log.<date>-<start-time>
The log file captures the standard output from a complete RedHawk run, including all
Error and Warning messages. Session information is also displayed in the log message
window, as well as written to the log file.
The Error and Warning messages are also written into individual files in separate
subdirectories adsRpt/Error and adsRpt/Warn, as follows:
Warn/redhawk.warn.<date>-<time-stamp>
Error/redhawk.err.<date>-<time-stamp>
You can chose a different directory and/or filename to redirect the RedHawk log and error/
warning files into by using the ‘-log’ option, as follows:’
redhawk -log <user_log_dir/filename>
This creates a log file in the selected directory and filename, and also Warning and Error
files in the same directory with similar names (no time stamps):
Log: <user_log_dir/filename>
ANSYS, Inc.
CHAPTER 6 — Reports
RedHawk Log Files
RedHawk User Manual
| 104
Warning: <user_log_dir/filename>.warn
Error: <user_log_dir/filename>.err
Links to Latest Log and Message Files
Under the adsRpt/ directory, RedHawk (and also other tools such as GDS2DEF/GDS2RH
and APL) creates top level Log, Command, Warning and Error files that are soft links to
the latest version of the file, as follows:
Log: Log/redhawk.log.<date>-<time-stamp> (link to latest file)
Command: Cmd/redhawk.cmd.<date>-<time-stamp> (link to latest file)
Error: Error/redhawk.err.<date>-<time-stamp> (link to latest file)
Warning: Warn/redhawk.warn.<date>-<time-stamp> (link to latest file)
APL, gds2def/gds2rh, and other RedHawk tools follow the same protocol.
GUI Log Message Viewer
From the GUI, you can quickly find specific Info, Warning and Error reports by going to the
Results menu and selecting the Log Message Viewer, as shown in Figure 6-6.
Figure 6-6
Opening the Log Message Viewer
In the upper window by default you will get an Error/Warnings Summary of the Info,
Warning, and Error log messages generated during the current session, as shown in
Figure 6-7.
ANSYS, Inc.
CHAPTER 6 — Reports
RedHawk Log Files
RedHawk User Manual
| 105
By clicking on one of the Log Message categories you can get a list of messages in that
category, as shown in Figure 6-8. If you then click on an individual message the message
is highlighted in the session log in the lower view window. By right clicking on the
message in the upper view window you can get additional information on that particular
Error or Warning.
By clicking on CPU/Memory Usage you get a summary of the session CPU and Memory
usage by stage up to the present time.
The Setup Design button displays all input files processed during the setup step, color
coded to indicate if there were any problems with the file, as follows:
• green - no problems were encountered in processing the file
• orange - there was one or more Warning messages generated in processing the file
• red - there was one or more Error messages generated in processing the file
Figure 6-7
List of Messages in Log Viewer
The Power button displays the Power Summary report of results from the Power
Calculation step.
At the bottom of the ‘Log Message Viewer’ the name and path of the log file displayed is
shown in the ‘Log File’ window. The Browse and Apply buttons allow you to select and
display log files from other RedHawk sessions. If a session has continued since you
displayed the log file, you can update the log message display by using the Refresh
button.
ANSYS, Inc.
CHAPTER 6 — Reports
RedHawk Log Files
Figure 6-8
RedHawk User Manual
| 106
Reviewing the List of Error Messages
Reviewing Shorts in the Design
RedHawk can detect and report shorts between any two nets, including those in the same
domain (for example, if both are power nets), or in different domains (one power, one
ground). Shorts can occur between wires, a wire and a via, a wire and a pin, a via and a
pin, and so on. Shorts can be displayed in the GUI using the menu command View ->
Connectivity -> Shorts. This brings up a list of shorts in the design, which you can use to
zoom to each location by clicking on the item in the list.
RedHawk also lists shorts in the file adsRpt/Error/redhawk.err<timestamp> file, with
message IDs CON-109, CON-110 and CON-111. There are several reporting cases,
depending on whether both shorted items are extracted or not and the setting of the
IGNORE_SHORT keyword in the GSR.
1.
If one shorted net is to be extracted (that is, the net is in the VDD_NET list or
GND_NET list in the GSR) and the other is not (that is, the net is in neither the
VDD_NET list nor the GND_NET list), then RedHawk reports the short in a CON111 message, regardless of the IGNORE_SHORT keyword setting:
WARNING (CON-111): A short between net <A> and <B> is detected on layer
<M1> at (x1,y1 x2,y2) by wires. But since net<B> is not extracted, net<A>'s R
network is not affected.
ANSYS, Inc.
CHAPTER 6 — Reports
RedHawk Log Files
2.
RedHawk User Manual
| 107
If both shorted nets are extracted (that is, they are listed in either the VDD_NET list
or GND_NET list in the GSR), then depending on the IGNORE_SHORT setting in
the GSR, RedHawk reports either a CON-109 or a CON-110 message:
a. If IGNORE_SHORT 1 (default), RedHawk does NOT short the R network of
the two nets and reports a CON-110 message:
WARNING (CON-110): A short between net <A> and <B> is detected on
layer<M1> at (x1,y1 x2,y2) by wires. The short is ignored and their R network
will not be shorted!
b. If IGNORE_SHORT 0, RedHawk shorts the R network of the two nets and
reports a CON-109 message:
ERROR (CON-109): A short between net<A> and <B> is detected on
layer<M1> at (x1,y1 x2,y2) by wires, their R network will be shorted!
Tech File Viewer
Through the GUI interface the Tech File Viewer can present different views of the Tech
File. Use View>Technology Layers to see more information about the layer parameters
in the Tech file, as shown in Figure 6-9. The Technology Viewer has a Zoom button to
make information larger, and also a GIF button for obtaining a GIF format output of the
Technology Viewer.
.
Figure 6-9
Tech File Viewer use
You can also view up to three via models between two metal layers in the technology
viewer, activated using the 'Substrate button' in the technology viewer dialog.
DEF Import Summary
A file adsRpt/tech_summary.rpt is created after importing DEF, which reports which
layers are used and which layers are ignored in the design.
ANSYS, Inc.
CHAPTER 6 — Reports
Summary Files for Power
RedHawk User Manual
| 108
Summary Files for Power
power_summary.rpt File
The Power > Calculate Power command from the GUI, or the perform pwrcalc from
the TCL shell automatically generates a summary results file for power called
power_summary.rpt in the adsRpt directory. This file contains a detailed breakdown of
power for each block in the chip. An example of a power_summary.rpt is shown below:
------------------------------------------------------------------Recommended dynamic simulation time, 5000psec, to include 100%
of total power for DYNAMIC_SIMULATION_TIME in GSR.
INFO: Importing user specified power file: demo.inst.power
INFO: Instances not specified in this file will have zero power.
INFO: 100% of instances specified in instance_power_file have corresponding
instances in the design.
0 out of 4142 instances do not have corresponding instance in the design.
INFO: For complete list of PWR-121 and PWR-122 WARNINGS, please see adsRpt/
apache.inst_pwr_file.mismatch.
The power is based on the INSTANCE_POWER FILE: demo.inst.power
Redhawk honors instance-by-instance power as specified in the above file.
Individual components of power, like switching power, internal power,
however, are calculated by Redhawk and may have been scaled to
meet the total instance-specific power number.
Power of different frequency (MHz) domain in Watts:
Frequency
4.000e+02
2.000e+02
0.000e+00
total_pwr leakage_pwr internal_pwr switching_pwr %_total_pwr
1.729e-02 1.704e-04
1.107e-02
6.052e-03
8.333e+01%
3.4595e-03 2.1869e-05 3.1000e-03
3.3758e-04
1.666e+01%
0.000e+00 0.000e+00
0.000e+00
0.000e+00
0.000e+00%
Power of different Vdd domain in Watts:
Vdd_domain total_pwr leakage_pwr internal_pwr switching_pwr %_total_pwr
VDD (1.1V) 2.075e-02 1.922e-04 1.417e-02
6.389e-03
1.000e+02%
Power of different cell types in Watts:
cell_type
total_pwr leakage_pwr internal_pwr switching_pwr %_total_pwr
combinational 7.111e-03 1.221e-04 1.754e-03
5.235e-03 3.426e+01
latch_and_FF 4.292e-03 3.890e-05 3.323e-03
9.301e-04 2.067e+01
memory
0.000e+00 0.000e+00 0.000e+00
0.000e+00 0.000e+00
I/O
0.000e+00 0.000e+00 0.000e+00
0.000e+00 0.000e+00
clocked_inst 9.352e-03 3.119e-05 9.096e-03
2.246e-04 4.505e+01
decap
0.000e+00 0.000e+00 0.000e+00
0.000e+00 0.000e+00
where clocked_inst are instances that cannot be classified as latch_and_FF,
memory, or I/O, but have clock pin(s).
Total chip power, 0.020757 Watt including core power and other domain power.
ANSYS, Inc.
CHAPTER 6 — Reports
Results for Static and Dynamic Voltage and Current Analyses
RedHawk User Manual
| 109
Total clock network only power, 0.003225 Watt. Total clock power, including
clock network and FF/latch clock pin power, 0.005992 Watt.
<top_level_block>.power.rpt File
A file called <top_level_block>.power.rpt is created in the adsRpt directory by power
calculation. This file contains the following power information for each instance (all power
is specified in Watts, and current is specified in Amps). For multiple-Vdd/Vss designs,
each power pin has a separate set of data (pin name at end):
<inst_name> <cell_name> <freq_Hz> <toggle_rate> <leakage_power>
<switching_power> <internal_power + clock_pin_power> <total_power>
<X_loc_um> <Y_loc _m> <VDD/VSS_domain>
<[leakage_data_source]_[internal_pwr_data source]>
<domain_type: [ 1 | 2 | 0 ]> <leakage_current> <total_current>
<LIB_name> <cell_p/g_pin_name>
where
<inst_name>: name of instance
<cell_name>: cell name
<freq_Hz>: operating frequency
<toggle_rate> : average number of value changes per clock cycle
<leakage_power>: leakage power
<switching_power>: switching power
<internal_power + clock_pin_power> : internal power including clock pin power
<total_power>: toal power consumption of pin
<X_loc_um> <Y_loc _m> : coordinates of block
<VDD/VSS_domain> : name of power domain to which pin is connected
<[leakage_data_source]_[internal_pwr_data source]>: each specified as ‘apl’ or
‘lib’
<domain_type>: 1 = non-multi_rail_pwr_domain; 2 = multi-rail_Vdd_domain; 0 =
multi-rail_VSS_domain
<leakage_current> : leakage current
<total_current> : total current, A
<LIB_name> : cell .lib name (if cell is not defined in a .lib, “lef2lib” is shown)
<cell_pg_pin_name>: P/G pin name
apache.power.info File
A file called apache.power.info is created in adsRpt directory containing additional
information, such as missing nets in VCD and STA files to help guide the users in
debugging their power calculation results.
Results for Static and Dynamic Voltage and Current Analyses
EM, Static IR and DvD Colormap Displays
Most of the results of RedHawk analyses can be displayed as full chip color maps in the
GUI, by clicking on the appropriate menu command or button (see section "RedHawk
Graphic User Interface Description", page D-794), or using the TCL ‘show’ command (see
section "TCL / Script Commands", page D-729).
ANSYS, Inc.
CHAPTER 6 — Reports
Results for Static and Dynamic Voltage and Current Analyses
RedHawk User Manual
| 110
Static EM and IR Drop Results Files
The following static summary files can be found in the adsRpt/Static directory.
Note: net names listed are actual domain names.
The <design>.em.worst file specifies the worst EM violations for wire pieces and vias in
decreasing order.
The report contains the following information on each line.
For Wires:
<metal_layer> <location> <EM_ratio> <domain_name> <metal_width>
For Vias:
<via_name> <location> <EM_ratio> <VDD | VSS>
The <design>.ir.worst file specifies the nodes with the worst static IR drop (voltage drop
and ground bounce) in decreasing order. The report contains the following information on
each line:
<actual_voltage> <ideal_voltage> <domain_name> <x_y_location> <layer_name>.
A sample file follows:
#voltage #volt #net
#x_y_location
#layer_name
1.0734
1.0800 VDD2 ( 261.700, 155.760)MET2
1.0734
1.0800 VDD2 ( 262.780, 155.760)MET2
1.0736
1.0800 VDD2 ( 261.700, 232.980)MET2
...
The <design>.inst.worst file specifies the instances with the worst static IR drop (voltage
drop and ground bounce) in decreasing order. The report contains the following
information on each line:
<inst_vdd> <vdd_drop> <gnd_bounce> <ideal_vdd> <domain_name> <x_y_loc>
<inst_name>
An example file follows:
#inst_vdd #inst_drop #gnd_bounce
#inst_name
1.0787 0.0006 0.0006 1.0800
1.0787 0.0006 0.0006 1.0800
1.0786 0.0008 0.0006 1.0800
#ideal_vdd #pwr_net #x_y_location
VDD1( 60.7200, 273.7350) inst1
VDD1( 71.6100, 273.7350) inst2
VDD1( 28.3800, 265.1550) inst3
...
The switch_static.rpt report is for instances of header/footer switches used in low power
design application only. This file specifies the voltage and current information for the
header/footer switches. The report contains the following information on each line:
<internal_node_voltage> <voltage_on_switch> <average_current>
<header | footer> <instance_name>
An example file follows:
#int_node_volt #volt_on_switch #avg_current #type #instance_name
1.0800 0.0037
0.6248 header QNP_1_CORNER_HS_CELL_002
1.0800 0.0033
0.5533 header QNP_1_CORNER_HS_CELL_001
1.0796 0.0049
0.8231 header QNP_1_BOTTOM_HS_CELL_115
...
ANSYS, Inc.
CHAPTER 6 — Reports
Results for Static and Dynamic Voltage and Current Analyses
RedHawk User Manual
| 111
Static and Dynamic Voltage Drop Results Files
The following dynamic summary files can be found in the adsRpt/Dynamic/ directory.
Note that intermediate graph results of ivdd and ipwr plots can be viewed during long runs
using the 'xgraph <filename>' command.
Note: net names listed are actual domain names.
<design>.ir.worst File
The <design>.ir.worst file specifies the location of the worst dynamic voltage drop
(voltage drop and ground bounce) in decreasing order. The report contains the following
information on each line:
<actual_voltage> <ideal_voltage> <domain_name> <x_y_location> <layer_name>.
An example file follows.
#voltage #ideal_volt
0.9262
1.0800
0.9275
1.0800
0.9504
1.0800
...
#net #x_y_location
#layer_name
VDD1 (261.700, 155.760)
MET2
VDD1 (262.780, 155.760)
MET2
VDD1 (174.500, 155.760)
MET2
<design>.dvd File
The <design>.dvd file reports voltage drop in terms of VDD-VSS differential for each
instance, in decreasing order. The report contains the following information on each line:
<x_loc> <y_loc> <effective_vdd-vss_over_TW> <max_vdd-vss_over_TW>
<min_vdd-vss_over_TW> <min_vdd-vss_of_clockcycle>
<min_vdd_voltage_over_TW> <max_gnd_bounce_over_TW> <VDD | VSS>
<instance_name>
To obtain a valid effective Vdd, the values are averaged over several small sample
windows, not over the entire timing window defined in STA file. By sliding a small window
through the entire timing window of the instance, several average effective Vdd numbers
are obtained. The worst of the averages computed is then reported as the effective (VddVss) voltage value. If no timing window data are available, the DvD values based on
timing window are not reported.
The <TW_flag> parameter indicates the Timing Window coverage in the dynamic
simulation time. If it is an empty string, the TW is covered in the dynamic simulation time.
If it is “^”, the TW is partially covered in the dynamic simulation time. If it is “*”, the TW is
not covered in the dynamic simulation time.
A sample file follows.
#loc_x loc_y eff_vdd max_pg_tw
domain instance_name
218.122 167.320 0.9671 0.9794
267.134 157.905 0.9808 0.9904
264.996 153.615 1.0034 1.0079
...
min_pg_tw min_pg_sim min_vdd_tw max_vss_tw
0.9555 0.8798 1.0012 0.0458 VDD inst241
0.9736 0.9181 1.0122 0.0386 VDD inst3469
0.9992 0.9635 1.0069 0.0085 VDD inst2463
Static and Dynamic Results for Vias
RedHawk can generate a Via Voltage Drop and Current report for both static and dynamic
analysis. The report is generated in the adsRpt folder and contains voltage drop and
current values for vias. This option can be turned On using the GSR keyword
'VIA_IR_REPORT 1' . Alternatively, you can use the TCL command
report [ ir | dvd ] -via -o <output_file>
to generate this report. The output filenames are:
ANSYS, Inc.
CHAPTER 6 — Reports
Results for Static and Dynamic Voltage and Current Analyses
RedHawk User Manual
| 112
• Static: adsRpt/Static/<>.via.ir.worst
• Dynamic: adsRpt/Dynamic/<>.via.ir.worst
A sample output report is shown in Figure 6-10
Figure 6-10
Via voltage drop and current report
Current Report Files
<design>.ignd File
The <design>.ignd file reports the summation of all the instances’ Vss current over the
simulation time. The report contains the following information on each line:
<simulation_time> <current_value>. A sample file follows.
Time
i(gnd)
0.000000
0.0
-3480
-0.0038748
-3470
-0.00309187
-3460
-0.00320901
...
<design>.ipwr File
The <design>.ipwr file reports the summation of all the instances’ Vdd current demand
over the simulation time. The report contains the following information on each line:
<simulation_time> <current_value>. A sample file follows.
Time
i(pwr)
0.000000
0.0
-3480
0.0038748
-3470
0.00309187
...
<design>.ivdd File
The <design>.ivdd file reports the chip power supply current over the simulation time.
This power supply current is supplied by the voltage sources for each power/ground
source. Without a package, ivdd measures the current at the pads of the design, and
therefore includes the effect of all on-chip parasitics, decaps, and other capacitative
effects. With a package, ivdd measures the current at the voltage sources external to the
package, and therefore includes the effect of package parasitics, in addition to on-chip
parasitics, and other capacitative effects. The report contains the following information on
each line: <simulation_time> <current_value>. A sample file follows.
Time
i(vdd)
0.000000
0.0
-3490.0000
0.00265285
ANSYS, Inc.
CHAPTER 6 — Reports
Results for Static and Dynamic Voltage and Current Analyses
-3480.0000
-3470.0000
...
RedHawk User Manual
| 113
0.0036665
0.00341904
<design>.ivdd.vsrc File
Following dynamic analysis the <design_name>.ivdd.vsrc file is generated in the
adsRpt/Dynamic directory, which contains the supply current waveforms for all power
sources. See example in Figure 6-11.
The TCL command that plots the total supply current from all pads that belong to a
specified net is:
plot current -net -name <net_name> -pad -sv
Current demand for
domain vdd
Supply current for
domain vdd
Figure 6-11
current demand and supply current waveforms
<design>.ipwr.domain File
The <design_name>.ipwr.domain file is generated after dynamic analysis, containing
current demand waveforms for each power domain defined in the GSR keyword
VDD_NETS. See example in Figure 6-11.
The TCL command that plots the total current demand from a specified net is:
plot current -net -name <net_name> -sv
<design>.ignd.domain File
The <desig_name>.ignd.domain file is generated after dynamic analysis containing
ground current waveforms for each power domain defined in the GSR keyword
VSS_NETS.
switch_dynamic.rpt File
The switch_dynamic.rpt report contains analysis results for instances of header/footer
switches used in low power design applications only.
For vectorless switch analysis, this file specifies the worst VDD-VSS differential, and the
maximum voltage and current over simulation time for the header/footer switch instances.
ANSYS, Inc.
CHAPTER 6 — Reports
Results for Static and Dynamic Voltage and Current Analyses
RedHawk User Manual
| 114
The report contains the following information on each line: instance name, switch type,
worst Vdd-Vss voltage, and maximum switch voltage and current. A sample file follows.
#<inst_name> <type> <worst_int_Vdd-Vss_Volt> <max_Vsw_Volt> <max_Isw_Amp>
QNP_1_BOTTOM_HS_CELL_083 H 1.051716 0.024256
0.004053
QNP_1_BOTTOM_HS_CELL_082 H 1.051716 0.025019
0.004180
QNP_1_BOTTOM_HS_CELL_081 H 1.051716 0.026545
0.004434
...
Ramp-up analysis reports include the max switch current and the status of each header or
footer switch at the end of the simulation period (OFF or ON). The file syntax and an
example follows:
#instance_name\ttype maximal_Isw(Amp) status (SAT)
#SAT: maximal_Isw > saturation_current as specified in switch model file
switch_inst_R17_C52 header 5.000000e-09 OFF SAT
switch_inst_R17_C52 header 2.603736e-09 OFF
This allows you to quickly see which switch turned ON and its efficiency.
decaps.rpt File
Depending on the value of the DYNAMIC_REPORT_DECAP keyword in the GSR, the
decaps.rpt file reports: for keyword value = 1, the maximum current reported for all
intentional decaps as defined in the GSR; for value = 2, in addition to decaps reported in
mode 1, reports also the maximum current associated with non-switching instances. Or if
the keyword has value = 0 (default), off (there is no decap report).
freqd_ipwr.out File
This file is generated for the baseline DvD flow; for all other modes it is not generated.
Each instance in a design can be associated with a particular clock and hence a
frequency domain. The freqd_ipwr.out file contains a waveform representing the sum of
all switching currents for the instances associated with each frequency domain. The
current waveforms may be displayed using the xgraph command as follows:
xgraph freqd_ipwr.out
The file has two columns to define the total current waveform for each clock frequency:
time and current in Amps.
Pad Current File
The pad.current file specifies the current from the pad cells or pad locations, excluding
presim time current. This file is very helpful for determining whether the connectivity is
complete from the specified pad locations. This report is generated for both static IR/EM
and dynamic voltage drop analysis. The report generated from static IR/EM analysis is
written to adsRpt/Static directory and contains the following information on each line:
<current_value> <x_y_location_of_pad_center> <pad_name>. A sample file follows.
#current
#pad_center_location
#pad_name
2.4745
( 65.282, 0.082)
Vdd_130564_1645
2.1274
( 163.329, 0.082)
Vdd_326658_1645
2.4745
( 263.206, 0.130)
Vdd_526412_2605
...
The report generated from dynamic voltage drop analysis is written to adsRpt/Dynamic
directory and contains the pad current over simulation time, in the following format:
<pad_name_a>
<simulation_time1 > <current_value >
...
ANSYS, Inc.
CHAPTER 6 — Reports
CMM Constraint Violation Reports
RedHawk User Manual
| 115
<pad_name_b>
<simulation_time1 > <current_value >
...
A sample file follows:
“Vss1
-1750 -1.13646e-05
-1740 -0.00240712
...
-20
-0.0511077
-10
-0.0508567
0
-0.0506185
10
-0.0503398
20
-0.0500513
....
2490
-0.0914897
2500
-0.0909729
“Vdd1
-1750
-1740
....
2490
2500
1.13646e-05
0.0023354
0.0911803
0.0906709
CMM Constraint Violation Reports
Constraint Violation Summary
After top-level analysis, if there are any constraints defined in sub-block CMMs, a violation
summary table is recorded in the redhawk.log file after post-processing of simulation
results. An example is shown below:
Summary of CMM Constraint Violation:
--------------------------------------------------Constraint Type No. of violations
--------------------------------------------------Top Connection Min Voltage 50
Top Connection Max Voltage 50
Pin Min Voltage 500
Pin Max Voltage 500
There are total 1100 constraint violations in the CMM
instances, please look at adsRpt/Dynamic/
CMM_constraint_violation.rpt for detail!
Dynamic Analysis Constraint Summary
For dynamic analysis, the final CMM constraint violation report is recorded in the file
adsRpt/Dynamic/CMM_constraint_violation.rpt. The file format is:
# Top connection max voltage constraint violation:
# <inst> <cell> <x,y,layer> <net_name> <contraint> <voltage_value>
ANSYS, Inc.
CHAPTER 6 — Reports
CMM Constraint Violation Reports
RedHawk User Manual
| 116
#---------------------------------------------------# Top connection min voltage constraint violation:
# <inst> <cell> <x,y,layer> <net_name> <contraint> <voltage_value>
#-----------------------------------------------------# pin max voltage constraint violation:
# <inst:pin> <cell> <x,y> <contraint> <voltage_value>
#-----------------------------------------------------# pin min voltage constraint violation:
# <inst:pin> <cell> <x,y> <contraint> <voltage_value>
#-----------------------------------------------------For example:
# Top connection min voltage constraint violation:
# <inst> <cell> <x,y,layer> <net_name> <contraint> <voltage_value>
#--------------------------------------------------------------ABC_CORE/ram64/adsU1 ram32x8x2 (1759.3600,783.0350, METAL2) VDD 1.7820
1.7309
# Top connection max voltage constraint violation:
# <inst> <cell> <x,y,layer> <net_name> <contraint> <voltage_value>
#--------------------------------------------------------------ABC_CORE/ram64/adsU1 ram32x8x2 (1763.9600,778.4350, METAL2) VSS 0.0010
0.0528
# Pin min voltage constraint violation:
# <inst:pin> <cell> <x,y> <contraint> <voltage_value>
#--------------------------------------------------------------ABC_CORE/ram64/adsU1:VDD ram32x8x2 (1792.3700,727.8150) 1.7460 1.7294
# Pin max voltage constraint violation:
# <inst:pin> <cell> <x,y> <contraint> <voltage_value>
#--------------------------------------------------------------ABC_CORE/ram64/adsU1:VSS ram32x8x2 (1790.1550,727.6450) 0.0100 0.0534
Static Analysis Constraint Summary
For Static, the final report is recorded in the file adsRpt/Static/
CMM_constraint_violation.rpt. The file format is:
# Top connection IR constraint violation:
# <inst> <cell> <x,y,layer> <net_name> <contraint> <voltage_value>
#--------------------------------------------------------------# pin IR constraint violation:
# <inst:pin> <cell> <x,y> <contraint> <voltage_value>
#--------------------------------------------------------------For example:
# Top connection IR constraint violation:
# <inst> <cell> <x,y,layer> <net_name> <contraint> <voltage_value>
#--------------------------------------------------------------ABC_CORE/ram64/adsU1 ram32x8x2 (1759.3600,783.0350, METAL2) VDD 1.7960
1.7909
# Pin IR constraint violation:
# <inst:pin> <cell> <x,y> <contraint> <voltage_value>
ANSYS, Inc.
CHAPTER 6 — Reports
Debugging Using Summary Files in the GUI
RedHawk User Manual
| 117
#--------------------------------------------------------------ABC_CORE/ram64/adsU1:VDD ram32x8x2 (1792.3700,727.8150) 1.7910
1.7909
Debugging Using Summary Files in the GUI
After generating the text results reports, they can be brought up in the GUI for interactive
debugging. The following GUI commands enable interactive debugging of EM violations
and static IR/dynamic voltage drop violations. The execution of any of these commands
generates a ranked list of violations in a pop-up window. An individual violation can be
selected and highlighted on the layout using the following menu selections:
Results > List of worst EM for static simulation
Results > List of worst IR instances for static simulation
Results > List of worst IR for wire and via for static simulation
Results > List of worst DvD instances for dynamic simulation
Output Files from Multiple Vdd/Vss Analysis
Table 6-1summarizes the files and reports available for multiple Vdd analysis.
Table 6-1
Multiple Vdd Result Files
Name of File
ANSYS, Inc.
Information
adsRpt/apache.refCell.noPGarcs
Lists cells with missing P/G arc information,
along with the names of the P/G pins.
adsRpt/Dynamic/<design>.dvd.arc
Dynamic voltage drop, as in standard
<design>.dvd file, but on a per arc basis.
adsRpt/Dynamic/<design>.dvd.pin
Dynamic voltage drop, as in standard
<design>.dvd file, but on a per pin basis.
adsRpt/Static/<design>.inst.pin
Static instance voltage drop data, one line
for each P/G pin value for every instance.
adsRpt/Static/<design>.inst.arc
Static instance voltage drop data, one line
for each P/G arc value for every instance.
CHAPTER 6 — Reports
Other Files
RedHawk User Manual
| 118
Other Files
RedHawk writes out various files in the adsRpt directory that provide additional
information in preparation for or after an analysis run.
Miscellaneous
The following files are generated by RedHawk to report nonstandard library or simulation
conditions.
File
ANSYS, Inc.
Description
apache.noLefPins
List of cells with no pins defined in their LEF macro
definition.
apache.noLibPins
List of cells with no pins defined in their library
definition.
apache.rcNoDriver
List of nets with no drivers.
apache.refCell.noLefLib
List of cells present in design, but not in library or
lef files.
apache.refCell.noLib
List of cells present in design, but not in library files.
apache.refCell.noLef
List of cells present in design, but not in lef files.
apache.refCell.noPwr
List of cells present in design without any internal
power tables specified in their library definition.
apache.refCell.noTriggerEdge
List of cells present in design with no identifiable
clock triggering edges in the library files.
apache.inst.libCurrent
For instances with missing APL data, this file
provides current profile information from the .lib
files.
apache.switchCellnoTW
List of names of instances that are switch cell type
but have no timing window from the STA file for
their control pin.
clock.untraced
List of nets that are STA clock nets, but are
untraceable by RedHawk tracer.
<design>.power.unused
List of instances that are not hooked to the power
network.
<design>.power.worst
List of instances that have the highest static power
consumption.
<design_name>.rcFail
Information on those nets for which RedHawk was
unable to create a pi-model for their output load.
<design_net>.Via.unconnect
List of vias belonging to the net that are physically
isolated from a power source.
<design_net>.Wire.unconnect
List of wires belonging to the net that are physically
isolated from the driving source.
<design_net>.Pin.unconnect
List of pins belonging to the net that are physically
isolated from a power source.
<design_net>.PinInst.unconnect
List of pin instances belonging to the net that are
physically isolated from a power source.
CHAPTER 6 — Reports
Other Files
RedHawk User Manual
| 119
<design_net>.PinInst.unconnect.lo
gic
List of PinInsts which are logically disconnected but
physically connected and their connected nets.
<design>.unplaced
List of instances designated ”UNPLACED” in the
DEF file.
<design>.stackvia
List of missing vias in the working directory or
adsRpt directory, to cover complex stacked via
scenarios.
GC.unreachable.fflatch
Lists percent of flip flops and latches that are
reachable from the gated clock controls, and also
lists the unreachable flip-flops and latches.
libParser.errMsgs
List of error messages generated during parsing of
the Synopsys Liberty library.
ppi_multi_group_pin_geo_cells
After setup design, list of cells in the design with
pins having multiple groups of disconnected
geometries and significant IR drops.
undefined_cells
List of all master cell names instantiated in the
design with no definition in DEF or LEF.
PG.ploc
List of Power/Ground sources (connections),
x,y locations, and layer assignments, which
RedHawk identifies during network extraction.
If .pad or .pcell files are used for specifying
pad instances or cells, when only pad
instance/pad cell names are used, a source is
automatically identified by the intersection of
each P/G pin's geometries and routing wires
on the same routing layer.
When a specific pin of a pad cell/instance is
specified in the .pad/.pcell file, only the
intersections of the geometries of the
specified pin are examined. If there are
multiple connections between a pin's
geometries and routing, then the format for
the name of each source (connection), in the
first column of the PG.ploc file, is
<instance_name>:<net_name>:
<# of source>.
If a *.ploc file is used, the PG.ploc file should
be exactly the same, unless there are
disconnected sources in the imported *.ploc
file.
ANSYS, Inc.
CHAPTER 6 — Reports
Other Files
RedHawk User Manual
DEF.ploc
| 120
A reformatted version of the top cell DEF file PINS
section, which can be used for P/G source
debugging and post-processing.
The adsRpt/DEF.ploc file is created after
importing DEF if the GSR keyword
‘ADD_PLOC_FROM_TOP_DEF’ is set to 1 (which
means that the design’s top cell's pins --i.e. , VDD
or GND sources-- are read directly from the top cell
DEF instead of from user-specified .ploc/.pad/
.pcell files).
Note that RedHawk exits if a script contains both
import pad commands and
‘ADD_PLOC_FROM_TOP_DEF 1’.)
Debugging
The following files provide additional information that is useful in debugging RedHawk
results.
File
Description
apache.clkPin0
List of all clock pins that are connected to non-clock nets.
apache.dupLIBCells
List of all cells with multiple references in the library files.
apache.rc0Net
List of nets with zero capacitance value.
apache.rcBogus
List of nets and lines in SPEF file that cannot be mapped to a
design.
apache.rcMismatch
Reports of inconsistent drivers between SPEF and DEF files.
apache.slew0
List of instances which are missing slew data in timing file. For
sequential instances, CLK and OUT pins missing slew are
reported and for combinational instances IN and OUT pin
missing slew are reported
apache.staBogus
List of incorrect STA related data, such as timing window for
instances that are not present in the design.
apache.staFlatten
List of instances that are flattened inside of the RedHawk
database and their timing window will be ignored.
apache.tw0
List of instances not covered in the provided STA file.
apache.twclk0
List of sequential instances whose clock pins do not have timing
window covered in the STA file.
apache.twclkLate
List of sequential instances whose output pins switch before the
clock pin.
inst.reactivated
List of instances not covered in STA file but whose toggle rate is
forced to a non-zero state.
<design>_<net>.
collided_vias
List of vias that touch or collide with other vias.
aplchk.log
List of APL-related errors and warnings.
Dynamic Simulation Preparation
ANSYS, Inc.
CHAPTER 6 — Reports
Other Files
RedHawk User Manual
| 121
The following report files are created when preparing for dynamic simulation.
File
Description
Dynamic/cell.rpt
Lists of cells that have and do not have APL
characterization data.
<design>.PG.unconnect
List o f instances belonging to analyzed PG network that are
physically isolated from VDD and GND. These instances will
be ignored during dynamic analysis.
<design>.VDD.unconnect
List of instances belonging to analyzed PG network that are
physically isolated from VDD. These instances will be
ignored during dynamic analysis.
<design>.GND.unconnect
List of instances belonging to analyzed PG network that are
physically isolated from GND. These instances will be
ignored during dynamic analysis.
<design>.noTiming
List of instances belonging to analyzed PG network that do
not have valid timing windows. These instances will not
toggle/switch during dynamic analysis.
Low Power Ramp Up Analysis
The following report files are created from low power ramp-up analysis.
File
virtual_domain_total_i.rpt:
virtual_domain_worst_v.rpt:
ANSYS, Inc.
Description
Total ramp-up current waveforms for each voltage domain
controlled by a header/footer switch in the design. Two
columns: time and current in Amps.
Worst case node voltage waveforms during ramp-up for
each voltage domain controlled by a header/footer switch in
the design. Two columns: time and voltage in Volts.
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Introduction
RedHawk User Manual
| 122
Chapter 7
Fixing and Optimizing Grid and
Power Performance
Introduction
After RedHawk static (IR) or dynamic voltage drop (DvD) analyses have identified areas
in the design that have unacceptable voltage drops, RedHawk Fixing and Optimization
(FAO) functions allow you to modify the power grid and/or allocate new decoupling
capacitance to meet specific static and dynamic voltage drop targets, and also powerrelated circuit timing problems. Fixing voltage drop problems also can reduce noise from
ground bounce. Operations on instances with multiple Vdd power sources is handled
transparently.
Once a trial power grid and initial placement information is available, RedHawk FAO can
be used to globally modify power grid parameters to meet specific voltage drop targets.
RedHawk enables you to easily add or delete power/ground pads, straps, and vias at any
stage of a run to explore their impact on voltage drop and electro-migration (EM).
RedHawk is capable of incrementally taking in new changes during IR drop and EM
analysis. After detailed placement, and prior to detailed routing, RedHawk can be used to
identify high dynamic voltage drop areas, or areas with significant timing impacts from
DvD, and fix them through a combination of power grid wire changes and targeted decap
placement.
The first part of this chapter describes the manual grid and decap modification commands
available in RedHawk, as follows:
• Changing existing layer or via resistivity
• Adding a power/ground pad
• Deleting a power/ground pad
• Adding a via
• Deleting a via
• Adding a power strap
• Editing/deleting a power strap
• Adding a decap cell
• Adding metal layers and via or via arrays
• Writing an ECO file
• Reading an ECO file
As the design moves through final placement and routing, you can use RedHawk Fixing
and Optimization functions to automatically modify the grid parameters and decap
placement to meet specified goals for both voltage drop and also power-related circuit
timing. When all of your voltage drop constraints are met, RedHawk can export an ECO
file with the needed design changes and then perform a final Spice-accurate power
analysis signoff of the design.
You can perform Undo or Redo operations after making FAO changes, allowing you to try
out FAO changes and then reverse them if the results are not satisfactory. Any number of
Undo or Redo commands can be performed consecutively until the commands in the
stack are exhausted.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
RedHawk User Manual
| 123
The fixing and optimization functions are described in the following sections.
Manual Power Grid Modification
Changing a Metal Layer or Via Resistivity
An existing metal layer or via resistivity can be changed in the RedHawk technology
(.tech) file and then RedHawk can be rerun to see the effects of the changes. Please
refer to Appendix C, "File Definitions", for the format of the Apache .tech file.
Adding a Single Power/Ground Pad
A new power or ground pad can be created using the Edit > Add Pad command, as
shown in Figure 7-1. A pop-up menu allows the selection of the metal layer to which the
pad will be connected. Pick the location for the new pad on the metal layer by clicking at
the desired location. The new pad is added to the design in the selected location.
New power pads are displayed as orange rectangular boxes and new ground pads are
displayed as white boxes. Use File > Export ECO to export the added pad locations and
use File > Import ECO to import the ECO file to back annotate for future runs. See the
section "Saving Design Changes with the ECO Command", page 7-151, for more
information on the ECO command.
Figure 7-1
Edit > Add Pad Menu
Adding a Set of Power/Ground Pads over a Specified Area
The command 'fao add pad' adds a set of power /ground pads over an entire mesh, or in
a defined window. You must specify a window, a metal layer, a net, and also a pitch in
both x and y directions by which to distribute pads evenly over the specified region. Undo/
Redo commands can be used. The command line syntax is:
fao add pad -window {llx lly urx ury} -metal <layer>
-net <net_name> -pitchX <microns> -pitchY <microns>
-r <resistance> -l <inductance> -c <capacitance>
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
RedHawk User Manual
| 124
where
-window { }: defines lower left and upper right x,y coordinates of the rectangular
area in which pads are added (by default, the entire mesh).
-metal: defines the routing layer (required). Only one metal layer is allowed, since
every metal has its own placement.
-net: defines the net name (required)
-pitchX -pitchY: defines the incremental distance between pads, starting at lower
left corner of the rectangle specified by '-window { }' (required) .
For example, for “-window {a b c d}”, starting at {a b}, RedHawk adds pads at
{a b}, {a+pitchX b}, {a+2*pitchX b} ..., {a b+pitchY}, {a+pitchX b+pitchY},
{a+2*pitchX b+pitchY} ... , over the entire window.
-r -l -c: specifies pad RLC parameters (units the same as in the PLOC file)
Deleting a Power/Ground Pad
An existing power/ground pad can be selected and deleted using the command Edit >
Delete Pad. Use the pop-up menu to choose a pad for deletion.
Adding a Via
New vias can be added using the command Edit->Add Via. Click on the design in the
desired location. Use the pop-up form to define the top and bottom metal layers for the
inserted via stack. When adding stacked vias, make sure that the appropriate number of
vias and via layers are selected. The new via or stacked vias are added to the design and
displayed as a blue box, after saving the changes.
Deleting a Via
An existing via can be selected and deleted using the command Edit > Delete Via. You
may have to make the vias visible by turning them on with the View Layers Configuration
button, or the command View -> Map Configuration -> Layers Color Map, and then
select Fill or Outline display for the set of vias you want to look at. First select the via for
deletion by clicking on it with the left mouse button. The selected via is highlighted in
yellow. Use the pop-up menu to choose an existing via for deletion.
Adding One or Multiple Power Straps
1.
To add power straps graphically (recommended), select Edit -> Add Power Strap.
A ‘Power Strap’ dialog box is displayed.
2.
Deselect Add strap by text input.
3.
Display the layers that are important in relation to the new strap.
4.
Use the right mouse button to draw a desired strap on the layout. If you want to
add several identical straps, draw the first strap representing one edge of the set
you want to add, and select Add multiple straps.
5.
Calculate and enter in the dialog box the location of the outside edge of the last
strap to be added and also the desired pitch. RedHawk will add the maximum
number of legal straps meeting the constraints specified.
6.
Select the layer on which to add the new straps (metal1 is the default).
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
RedHawk User Manual
| 125
7.
Click on Commit adding when the specification and drawn straps are correct
(there is no undo function). If there is a physical error or short, an error message
will be displayed. A successful strap addition is illustrated in Figure 7-3.
8.
If you make a mistake or want to change the added straps, use the Edit->Power
Strap function to select and then delete or change a strap.
Figure 7-2
Form for adding a strap by text input
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
Figure 7-3
RedHawk User Manual
| 126
Adding multiple straps with Add multiple straps
For an example of adding straps, please refer to the section "Example Procedure to Fix IR
Drop Problems", page 4-74.
GUI option for ‘eco add strap’
To automatically add stack vias for two or more layers above or below the wiring on the
GUI, select the checkbox ‘Include stackvias'.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
Figure 7-4
RedHawk User Manual
| 127
GUI option for ‘eco add strap’
The behavior is:
• When the checkbox ‘Include stackvias' is selected: eco add strap adds vias for all
possible metal layers. For example, if you are adding a wire A on M2, it will search if
there are wires on all metals layers (except for M2) that overlaps wire A, and add vias
if possible.
• When ‘Include stackvias' checkbox is not selected: eco add strap adds vias for
adjacent metal layers only. For example, if you are adding a wire A on M2, it will only
search if there are wires on M1/M3 that overlaps wire A, and add vias if possible.
Editing/Deleting a Power Strap
An existing power strap can be selected and edited by using the command Edit > Edit
Power Strap. First, select the power strap by clicking on it with the left mouse button. The
selected strap will be highlighted in yellow. Use the pop-up menu to change the length
and width, as well as the x and y start locations of the selected power strap, as illustrated
in Figure 7-5. The strap can also be deleted from the design database.
Note: New vias will NOT be automatically added as a result of editing an existing
power strap.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
Figure 7-5
RedHawk User Manual
| 128
Edit->Edit Power Strap
Adding a Decap Cell
One or more intentional decap cells can be added by using the command Edit > Add
Decap Cell. Click on the Select Vdd button on the Add Decap Cell form and then click on
the VDD wire location on the lowest metal layer where the decap should be inserted.
Next, click on the Select Gnd button on the form and click on a VSS location very close to
the previously selected VDD location. A list of available decap models will be shown on
the form, which were previously defined by the ‘DECAP_CELL’ keyword in the GSR file. If
no appropriate models have been defined, you must provide them in the GSR file.
Note: Corresponding DECAP cell definitions must exist in the LEF file and in the
GSR file.
After intentional decaps are characterized through the RedHawk APL flow, obtain the
ESC (effective power circuit capacitance) and ESR (effective power circuit resistance)
values from the <cell>.cdev file. Click on Commit Adding to see the decap appear on
the layout. The addition of decap is now complete, as illustrated in Figure 7-6 and Figure
7-7. Use File -> Export ECO to write out the added decaps and export the ECO files for
inclusion in the design on future runs.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
Figure 7-6
Edit -> Add Decap Cell
Figure 7-7
Decap added on layout
ANSYS INC - Apache Design Business Unit
RedHawk User Manual
| 129
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Manual Power Grid Modification
RedHawk User Manual
| 130
Adding Metal Layers and Vias or Via Arrays
The following steps allow you to add straps on an additional layer of metal, in addition to
the existing metal layers. For example, if the existing layers of metal are metal1 to metal6,
the additional layer of metal should be specified as metal7, on top of metal6.
1.
Add the extra layer definition to LAYER section of the .lef file, which contains the
technology definition for layers. In the example below, there are six metal layers.
Edit the .lef file to add metal7 and via67 as shown below. Make sure that the
sequence and numbering are correct (i.e., specify VIA67 and METAL7 after
METAL6).
LAYER VIA67
TYPE CUT ;
END VIA67
LAYER METAL7
TYPE ROUTING ;
END METAL7
VIA via6 DEFAULT
# (Worst case resistance model for via5 = 2.54 ohm/ct) = 2.5400e+00
RESISTANCE 2.5400e+00 ;
LAYER METAL6 ;
RECT -0.240 -0.190 0.240 0.190 ;
LAYER VIA67 ;
RECT -0.180 -0.180 0.180 0.180 ;
LAYER METAL7 ;
RECT -0.270 -0.270 0.270 0.270 ;
END via6
Add the metal layer and via information the *.tech file, as shown below.
metal METAL7 {
Thickness 0.4
Resistance 0.065
TC 0
EM 1.22
Above
DIEL6
}
via VIA67
{
Width { 0.19 }
Resistance 1.2
EM 0.126
UpperLayer metal7
LowerLayer metal6
}
2.
Create the required via arrays in the VIAS section of the top-level .def file. Since
there is no existing via array definition, you must create the required via arrays in
the VIAS section. The via arrays for VIA67 can be created by copying the VIA56
definition in the existing .def file and changing the parameters to match VIA67, as
shown below:
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 131
- $TCARY$via6_0_2_1_1420_1420_F + RECT METAL6 ( -1200 -380 )
( 1200 380 ) + RECT METAL7 ( -1260 -540 ) ( 1260 540 ) + RECT VIA67
( -1080 -360 ) ( -360 360 ) RECT VIA67 ( 360 -360 ) ( 1080 360 ) ;
3.
After the metal layer and via arrays are created, follow the same steps to add pads
and straps, as previously discussed.
Undo and Redo
You can perform Undo or Redo operations after making FAO changes, allowing you to try
out FAO changes and then reverse them if the results are not satisfactory. Any number of
Edit -> Undo or Edit -> Redo menu commands can be performed consecutively until the
commands in the stack are exhausted. On the TCL command line, ‘fao undo’ and ‘fao
redo’ commands also can be executed with the same results.
Automated Grid Optimization and Fixing Procedures
Fixing and Optimization Flow for Static IR Drop Improvement
The primary steps in the FAO static voltage drop optimization flow are outlined in Figure
7-8 below.
RedHawk FAO Static
IR Drop Improvement
Trial Power Grid/ Prototype
Initial Placement
RedHawk Static
IR Drop Analysis
IR OK?
YES
NO
User Design/FAO Constraints
Static Voltage Drop Limit
Mesh Optimize/Fix
NO
IR OK?
YES
RedHawk Dynamic
Voltage Drop Analysis
Figure 7-8
RedHawk flow for static IR drop analysis
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 132
FAO Procedure for Multiple Vdd Designs
For multiple Vdd domain designs, only one power domain is analyzed and modified by
FAO at a time. Specify each power domain in order using the GSR keyword FAO_NETS .
For example, if there are two power domains, VDD and VDD_B, first invoke:
gsr set fao_nets VDD
Now you can run FAO analysis, and perform the needed VDD grid and decap
modifications. Following fixing and optimization on the VDD net, use the command:
gsr set fao_nets VDD_B
Then run FAO analysis and power problem mitigation on the VDD_B net.
If there is more than 1 power net defined in fao_nets, only the first one listed is
considered, and RH returns the following warning:
WARNING: =================================================
WARNING: *** FAO_NETS has > 1 VDD net: Only consider <VDD>
WARNING: *** Set fao_nets for EACH power net and apply fao separately.
WARNING: =================================================
Grid Optimization
Mesh Commands
The key commands for using FAO to adjust grid widths are invoked in the GUI or TCL
format, and have the following functionality:
• mesh optimize - investigates a grid width solution within a defined area
(fao_region). All wire segments on the specified metal layers will be adjusted to the
same width to solve the voltage drop problem, either for the full chip or within the width
of the specified region (but the full height of the chip). With the -taper option, grid wire
segments are only resized within fao_region, and not outside of it (not the full height of
the chip).
• mesh fix - investigates a grid width solution within a rectangular region that includes
all “hot spots” (high voltage drop nodes) and their associated fix_window areas. For all
hot spots within fao_region, wire segments in vertical and horizontal bands (full width
and height of chip) defined by the dimensions of the fix_window, will be adjusted to an
appropriate width to solve the voltage drop problem. With the -taper option, grid wire
segments are only resized within the specified region (fao_region), and not outside of
it.
• mesh snscalc - for a selected region and set of layers and nets, mesh snscalc
calculates and reports a number representing the relative average sensitivity for
modifying the width of wires associated each layer and net selected--the higher the
sensitivity number reported (in mv of voltage drop reduction per micron of additional
wire width), the more effective a wire width change would be in reducing the worstcase voltage drop within the selected region. Using this command is recommended
before performing any grid resizing.
• mesh sub_grid - adds a new subgrid mesh, with an area defined by the GSR
keyword 'fao_region', including power nets defined by 'fao_sub_grid_nets' and with
physical characteristics defined by 'fao_sub_grid_spec'. The new subgrid is targeted
to achieve a voltage drop specified by the GSR keyword 'noise_reduction' . The min/
max width of the new grids to be sized is specified by 'fao_range'. The minimum width
is also used to create the initial subgrid before sizing analysis.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 133
• mesh set_width - allows the mesh wire width to be modified for the specified
layer(s). By default the wire width is modified equally on both sides of the mesh center
line, but the width change can be made on only one side of the wire by specifying the
‘expand_dir’ (or it could be the contracting direction if you are making the width
smaller).
Several additional commands are available for modifying the power grid, but are not
needed frequently, and are summarized below.
• mesh add - allows you to add a specified mesh section to the grid, including specific
layers and regions of the design. Useful for easily modifying the grid and evaluating
the effect on voltage drop
• mesh delete - allows you to delete a specified mesh section of the grid, including
specific layers and regions of the design. Useful for easily modifying the grid and
evaluating the effect on voltage drop
• mesh vias - allows you to add optimal sized vias in a region of the design using
specified via models
• mesh generate - generates a prototype grid based on the user constraints that are
provided in the design constraints file (.dcf)
• ring add/delete - adds or deletes a specified power/ground ring
Following is a brief summary of the GSR keywords available to control grid modification.
The general TCL syntax for setting GSR keyword values is: gsr set <variable
name> <value>. All FAO options and GSR keyword values will be collected in RedHawk
and then the GSR file can be used to set initial values and then save-and-reload will set
the GSR keyword values properly. More detailed descriptions of these GSR keywords
and their options and syntax are provided in section Grid Fixing and Optimization
Keywords on page C-687.
GSR Keywords for Region-based Grid Width Sizing (mesh optimize)
1. To select IR drop or DvD analysis: FAO_DYNAMIC_MODE (default - off )
2. To set a target voltage drop reduction: NOISE_REDUCTION (input required)
3. To specify a net or group of nets for optimization: FAO_NETS (input required)
4, 5. To specify layer and grid width constraints: fao_layers, FAO_RANGE (input required
for both)
6. To select accurate or turbo mode: FAO_TURBO_MODE (default is on)
7. To specify an optimization area: FAO_REGION (default - whole chip)
8.To select the number of high voltage drop areas to optimize: NUM_HOTSPOT (default 1)
9. To specify layer/width relationships: FAO_WIDTH_CNSTR (default: no specification)
10. To specify the percentage voltage drop reduction to be achieved on specific layers:
MESH_SEARCH (default - even distribution on selected layers)
GSR Keywords for Hot-spot Based Grid Width Fixing (mesh fix)
GSR keywords 1 through 10 described above for mesh optimize also can be used for
mesh fix. In this command ‘fao_region’ is used to define the overall evaluation area,
and a “fix window” around each hotspot within the region is investigated for a grid width
modification, as follows:
11. To select the horizontal and vertical dimension of the area, centered on each hotspot,
in which to modify the grid widths: fix_window (default - 100u x 100u)
Several example static IR drop analyses are provided in the following section.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 134
Examples of Grid Optimization
Example A - Full Chip Optimization - Relaxing Static IR Drop
Conditions: Early in design development. Your design allows you to relax (increase) the
existing worst case voltage drop and perhaps save grid resources. You want to use full
chip uniform grid optimization methodology, so mesh optimize is used.
Goal: Perform full power grid optimization, increasing the static IR drop target 15%.
1.
Decide on what GSR keyword settings you want to set for performing a ‘mesh
optimize’ operation. Assume in this case the initial worst case static IR drop is
18mV on VDD, and we can accept a slightly higher voltage drop without problems.
Therefore we will do a full grid optimization to relax this drop by 15%, as shown in
the following TCL input lines:
gsr set fao_turbo_mode 0
gsr set fao_nets VDD
gsr set fao_layers { {metal6 hor <= 29.4} }
gsr set fao_range { {metal6 8 29.4}}
gsr set noise_reduction -15
No region has been defined using ‘fao_region’, so the entire power grid is
optimized (default). For this run FAO will do an 'accurate' mode search of low static
voltage drop areas and optimize only the VDD net. It will examine all METAL6
wires running horizontally of width less than or equal to 29.4um (the existing grid
width) as its target wires. FAO will try to relax the worst case static voltage drop by
15%. Note that this will create a reduction in metal usage, so you must specify a
width range less than the existing width, such as the 8 to 29.4u range in this
example.
2.
Run mesh optimize as follows, specifying an output eco file:
mesh optimize -eco <filename>.eco
3.
Based on the requested grid optimization parameters, RedHawk reports the wires
it optimized in the region defined (the whole grid in this case), as follows
ECO File: fao_mesh_opt_23:15:47_022242005.eco
Region: <0 0 6817.32 8316.08>
FAO Mode: accurate
Simulation Mode: static
Net: VDD
Noise Reduction: -15%
+++++++++++++++++++++++++++++++++++++++
Initial Worst Static Noise: 17.578mv
Voltage Noise Constraints: 20.2147mv
*============================================*
*
Searching Target Grids
*
*============================================*
Net <VDD>:
Layer <metal6>: identified 44 wires
*============================================*
*
Sizing Target Grids
*
*============================================*
Following the run, FAO reports 44 wire change recommendations, as shown in the
log file below. In this case, there will be less metal usage in the metal6 VDD net as
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 135
a result of the relaxation in the static voltage drop limit. Note that new via models
also are specified to match the wire changes
Optimization succeed: no error
Optimized width of layer metal6: 23.8um
*========================================================*
Metal Usage Change Report
Net <VDD>:
Layer <metal6>:5.05281e+06um^2 => 4.09119e+06um^2 (-19.03%)
Total: 5.05281e+06um^2 => 4.09119e+06^2 (-19.03%)
*========================================================*
Replacing optimized grids...
Replace <metal6> mesh grids :
net <VDD> : 44 wires replaced.
DEF file for new via models: SH_VIA_VDD.def
To do a final check on the fix, rerun RedHawk with the same setup commands and
options as described in the initial preparation steps. Package RLC units are Ohms,
pH and pF, respectively:
perform extraction
setup pad
setup wirebond
setup package
perform analysis -static
The final static voltage drop on the VDD network is 21mV (a 15% relaxation), with
a 19% saving in metal resources over the entire design.
Example B - Full Chip Grid Fixing - Reducing Static IR Drop
Conditions: Early in design development. Your design requires a lower voltage drop. You
want to use full chip uniform grid optimize methodology, so mesh optimize is used.
Goal: Perform full power grid optimization for static voltage, reducing the static IR drop
target from the existing 18 mv, as shown in Figure 7-9.
1.
Decide on what GSR keyword settings are necessary. This time we will tighten the
voltage drop, evaluating the grid width on metal6 for whole design.
Keep in mind if a tighter voltage drop limit is specified (using ‘noise_reduction’),
then the fao_range should be increased to allow FAO to increase grid widths . For
example, if you want to reduce the voltage limit by 10%, then the following GSR
keyword settings should be used:
gsr set fao_turbo_mode 0
gsr set fao_nets VDD
gsr set fao_layers {{metal6 hor <= 29.4}}
gsr set fao_range {{metal6 10 35}}
gsr set noise_reduction 10
The allowable range of horizontal metal6 widths for this analysis is now 10-35
microns, instead of 8-29.4u in the previous example, and the ‘noise_reduction’
value is now a positive number, 10 percent.
2.
Run mesh optimize as follows:
mesh optimize -eco <filename>.eco
3.
Look at your results as described previously.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
Figure 7-9
RedHawk User Manual
| 136
Static IR drop map
Example C - Partial Chip Optimization, Relaxing Static IR Drop
Conditions: Later in design development. Your design can accept a higher voltage drop
than 18mv, but you do not want to make changes over the entire grid. You want to specify
a “fix window” of a particular size, so mesh fix is used.
Goal: To perform a limited power grid fix to relax the static IR drop 15% by modifying wire
widths for only a selected area of the power grid.
1.
Decide on what GSR keyword settings are necessary. This time we will allow the
voltage drop to increase, evaluating the grid width on metal6 for part of the design,
as shown in the GSR keyword values set below:
gsr set fao_region {2600 2677 6487 5304}
gsr set fao_turbo_mode 0
gsr set fao_nets VDD
gsr set fao_layers { {metal hor <= 29.4} }
gsr set fao_range { {metal6 8 29.4} }
gsr set noise_reduction -15
gsr set fix_window {600 600}
gsr set num_hotspot 1
By using the above GSR keyword values, we have defined a bound area with
corner locations (2600,2677) and (6487,5304) for grid fixing. RedHawk FAO
searches for “hot-spots” within this area (in this run only one is being evaluated),
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 137
perform an ‘accurate’ mode voltage drop analysis, and fix only the VDD net within
the specified area. The recommended changes to the grid is performed in the
selected “fix window” with the hotspot at the center. Note that the grid will not be
modified just within the fix window, but across the entire width and height of the
chip with the specified x,y dimensions (as modified by the metal layer constraints).
FAO will search all METAL6 wires running horizontally of width less than or equal
to 29.4um in the “fix window”. It fixes the specified portion of the grid to relax the
voltage drop by 15%. Since the specified operation will entail a reduction in metal
usage, you must specify an analysis range for METAL6 width less than the existing
width (in this case between 8 and 29.4 microns).
2.
Run mesh fix as follows:
mesh fix -eco <filename>.eco
3.
Based on the specified grid fixing parameters, RedHawk reports the wires to be
fixed within the defined region, finding 1 hotspot, as shown in the following output
to the screen and to the log file:
ECO File: fao.static.eco
Region: <2600 2677 6487 5304>
FAO Mode: accurate
Simulation Mode: static
Net: VDD
Noise Reduction: -15%
Mesh Style: uniform
Hot-spots Number: 1
Fix-Window Size: 600x600
+++++++++++++++++++++++++++++++++++++++
Initial Worst Static Noise: 17.578mv
Voltage Noise Constraints: 20.2147mv
Identified 1 hots-spots:
(3123.26, 3058.42)
Fixing Window: <2823.26 2758.42 3423.26 3358.42>
*============================================*
*
Searching Target Grids
*
*============================================*
Net <VDD>:
Layer <metal6>: identified 11 wires
*============================================*
*
Sizing Target Grids
*
*=========================================*
Optimization succeed: no error
Optimized width of layer metal6: 17.9um
*========================================================*
Metal Usage Change Report
Net <VDD>:
Layer <metal6>: 5.05281e+06um^2 => 4.56558e+06um^2 (-9.64%)
Total: 5.05281e+06um^2 => 4.56558e+06^2 (-9.64%)
*========================================================*
Replacing optimized grids...
Replace <metal6> mesh grids :
net <VDD> : 11 wires replaced.
DEF file for new via models: SH_VIA_VDD.def
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 138
The recommended fix involves 11 metal6 wire changes. Since the voltage drop
was allowed to increase, there is less metal usage in the wires identified for
modification.
4.
To check on the new static IR drop, execute the standard RedHawk IR analysis
again:
perform extraction
setup pad
setup wirebond
setup package
perform analysis -static
The final static IR drop on the VDD network is 21mV (a 15% relaxation) with a 10%
saving in metal resources.
Example D - Partial Chip Fixing, Reducing Static IR Drop
Conditions: Later in design development. Your design requires a lower voltage drop than
18mv, but you do not want to make changes over the entire grid. You want to specify a fix
window, so mesh fix is used.
Goal: To perform a limited power grid fix to reduce the worst static IR drop 15% by
modifying wire widths for only a selected area of the power grid.
1.
Decide on what GSR keyword settings are necessary. This time the voltage drop is
tightened, and the grid wire widths evaluated for a portion of the design. Since a
tighter limit is specified for noise_reduction, the fao_range must be increased to
allow wider metal strips. For example, if you want to tighten the voltage drop by
10%, the following GSR keyword settings should be used:
gsr set fao_region {2600 2677 6487 5304}
gsr set fao_turbo_mode 0
gsr set fao_nets VDD
gsr set fao_layers { {metal hor <= 29.4} }
gsr set fao_range { {metal6 10 40} }
gsr set noise_reduction 10
gsr set fix_window {1200 1200}
gsr set num_hotspot 1
As before, a limited part of the grid is specified for evaluation, and a fix window of
1200 by 1200 microns is specified around each hotspot. The range of grid width is
widened to allow wider wires this time to achieve a noise reduction.
2.
Run mesh fix as follows:
mesh fix -eco <filename>.eco
3.
The screen and log file output summarizing the results from this run is shown
below, and are shown graphically in Figure 7-10.
ECO File: drop_improv_15.eco
Region: {2600 2677 6487 5304}
FAO Mode: accurate
Simulation Mode: static
Nets: VDD
Noise Reduction: 10%
Mesh Style: uniform
Hot-spots Number: 1
Fix-Window Size: 1200x1200
.........................................
Initial Worst Static Noise(mv): 17.578
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
RedHawk User Manual
| 139
Voltage Noise Constraint(mv): 15.8202
Identified 1 hot-spots:
(3123.26, 3058.42)
Fixing window: <2523.26 2458.42 3723.26 3658.42>
*========================================*
*
Searching Target Wires
*
*========================================*
Net <VDD>:
Layer <metal6>: identified 17 wires
*========================================*
*
Sizing Target Wires
*
*========================================*
Optimization succeed: no error.
Optimized width of layer metal6: 37.47um
*========================================================*
Metal Usage Change Report
Net <VDD>:
Layer <metal6>:5.05281e+06um^2 => 5.58121e+06um^2 (+10.46%)
Total: 5.052814e+06um^2 => 5.581216e+06um^2 (+10.46%)
*========================================================*
Replacing optimized grids...
Replace <metal6> mesh grids :
net <VDD> : 17 wires replaced.
DEF file for new via models: SH_VIA_VDD.def
*********************************************************
****
FAO Verify Power Grids
*********************************************************
Resulting Voltage Noise(mv): 15.8578
Note that the target reduction in voltage drop was achieved by increasing the width
of 17 metal6 wires by 10.46%.
4.
As before, verify the new static IR drop by executing the standard RedHawk IR
analysis:
perform extraction
setup pad
setup wirebond
setup package
perform analysis -static
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Grid Optimization and Fixing Procedures
Figure 7-10
RedHawk User Manual
| 140
Static IR drop map after FAO operations
Example E - Mesh Optimize, -taper option, to reduce regional static IR drop
Conditions: Your design requires a lower voltage drop on two layers in a particular
region, so mesh optimize -taper is used.
Goal: To perform a 5% static voltage drop reduction with changes on METAL3 and
METAL4 layers in a defined FAO_REGION. We choose to limit the width of new wires to
between 2 and 5 microns. The '-taper' option is used to ensure that the grid modifications
are performed only within the 'fao_region' and not across the entire width and height of
the chip.
1.
Decide on what GSR keyword settings are necessary. With the conditions
described above, the following scripted GSR keyword settings should be used:
gsr set fao_nets VDD
gsr set fao_drc 0
gsr set fao_region {x1 y1 x2 y2}
gsr set fao_layers { {METAL4} {METAL3} }
gsr set fao_range { { METAL4 2 5 } { METAL3 2 5 } }
gsr set noise_reduction 5
mesh optimize -taper
export eco mesh_optimize.eco
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
| 141
2.
By executing the above script, FAO searches for all METAL4 and METAL3 wires in
the defined fao_region that can be modified to achieve the voltage drop of 5%. The
'-taper' option ensures that the grid fix is performed only within the 'fao_region' and
not across the entire width and height of the chip.
3.
The ECO changes from this procedure would be the deletion of a number of small
wire segments within the defined fao_region on METAL3 and/or METAL4, and
larger wires added in their place.
Example F - Mesh Fix, -taper option, to reduce hot spot static IR drop
Conditions: Your design requires a lower voltage drop for hot spots on two layers in a
particular region, so mesh fix -taper is used.
Goal: To achieve a 2% static voltage drop reduction for hot spots in a defined
FAO_REGION with changes on METAL3 and METAL4 layers. We choose to limit the
width of new wires to between 2 and 5 microns. The '-taper' option is used here to ensure
that the grid modifications are performed only within the 'fix_window' areas around each
hot spot and not across the entire width and height of the chip.
1.
Decide on what GSR keyword settings are necessary. With the conditions
described above, the following scripted GSR keyword settings should be used:
gsr set fao_dynamic_mode 1
gsr set fao_nets VDD
gsr set FAO_DRC 0
gsr set fao_region { x1 y1 x2 y2 }
gsr set fao_layers { {METAL4} {METAL3} }
gsr set fao_range { { METAL4 2 10} { METAL3 2 10 } }
gsr set noise_reduction 2
gsr set fix_window { 600 600 }
gsr set num_hotspot 5
mesh fix -taper
export eco mesh_fix.eco
2.
By using the above GSR keyword values, we have defined an FAO_REGION area
with corner locations (x1,y1) and (x2,y2) for identifying hot spots and grid fixing.
FAO searches for 5 hot-spots within this area and finds grid changes that can
reduce their voltage drop by at least 2%.
3.
The ECO changes from this procedure would be the deletion of a number of small
wire segments within the specified 600x600 fix_window area around 5 identified
hot spots, and larger wires added in their place.
Automated Fixing and Optimization (FAO) for DvD and Timing
Overview
An overview of the flow for using RedHawk to fix and optimize dynamic voltage drop and
timing problems is shown in Figure 7-11. Three criteria for running FAO are available:
• instances having the worst-case dynamic voltage drop (DvD) (hot instances)
• all instances having the highest delta slack and delta delay caused by DvD
• instances in critical paths having the highest delta slack and delta delay caused by
DvD
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
| 142
Timing Aware FAO Flow
LEF/DEF
STA/.lib/spef
FAO objective options (FAO_OBJ)
DvD
RedHawk
RedHawk
DvD
DvD
• Sub-gridding
• Re-sizing
• Via insertion
• Cell swapping
• Decap insertion
Prioritized by DvD
DvD & timing sens
Prioritized by
Slack/Delay & DvD
STA (pin-slack TW)
SDF (delay)
DvD & timing sens
Prioritized by
Critical-Path & DvD
ECO
mSDF
Hot
Instances
&
Area
PG-Aware
PG-Aware
RedHawk
RedHawk
DvD
DvD
User Critical
Path Report
35
Figure 7-11
FAO Flow
Based on the specified value of the GSR keyword/FAO GSR keyword FAO_OBJ, the
program creates an ordered list of instances that, for pure DvD runs have the worst case
DvD values, or for the timing-based runs are most likely to be seriously impacted by DvD.
The three types of FAO analysis are described below as invoked using the FAO_OBJ
keyword:
FAO_OBJ
FAO keyword and GSR keyword that selects the type of instance prioritization and
results desired. Optional; default: DVD
Syntax
FAO_OBJ [ DVD | TIMING ?<slack threshold>? |
PATH ?<slack threshold>? ]
where
DVD : instances with highest voltage drop are selected for FAO
TIMING <slack_threshold>: all instances in the design with high delta delay and
delta slack values caused by DvD are selected for FAO. The default value of
the slack threshold is 0.
Note: To use FAO_OBJ TIMING you must execute ‘import sdf xxx.sdf’
before cell swapping, or the candidates for swapping will be zero. Also,
fao_region is still honored to filter out candidates from critical path or timing/
slack info.
PATH <slack_worse than> : instances in critical timing paths with high delta delay
and delta slack values caused by DvD are selected for FAO. The default
value of the slack threshold is 0.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
| 143
The target instances to be investigated and fixed can be further filtered using parameters
such as the value of DvD, the total number of instances, or a special region of interest, as
described in the following sections.
Preparation for Decap FAO
Prior to running decap FAO, verify that the available decap cells are properly prepared as
follows:
1.
Define the list of decaps in the GSR file, using the option DECAP_CELL:
DECAP_CELL
{
<decap_cellname> ? <width_um> <height_um> <C_pF> <R_ohm>
<metal_layer_name> ?
...
}
Usually only the list of decap cell names is required, since the other information is
in the LEF files.
2.
Run APL characterization for decaps in RedHawk, which produces the
<cell>.cdev file containing the R, C and/or leakage power definitions.
3.
Insure that the proper physical information is defined in the LEF file and included in
LEFS with power/ground pins defined for the layer.
MACRO cell_name
CLASS <class_type> ;
ORIGIN <value> ;
SIZE <value> BY <value> ;
PIN GND
USE GROUND ;
PORT
LAYER <layer_name> ;
RECT <x1> <y1> <x2> <y2> ;
END
END GND
PIN VDD
USE POWER ;
PORT
LAYER <layer_name> ;
RECT <x1> <y1> <x2> <y2> ;
END
END VDD
END cell_name
Decap Modification Operations
RedHawk FAO also allows you to investigate the use of decoupling capacitance to fix
dynamic voltage drop and timing problems.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
| 144
Decoupling Capacitance Modification Commands
The key commands for fixing decoupling capacitance can be invoked in TCL command
line or from the GUI. The TCL commands have the following functionality:
• decap advise - finds the total amount of decap that can be placed very quickly, without
providing specific placements. The ‘-place’ option uses an algorithm to determine the
largest amount of decap that fits in the available row width; saves the result in a userspecified decap placement file (dpf).
• decap fill - places decaps using one of several methods:
• targeted - within a defined rectangle around each specified hot instance (DvD)
• hot instance area - within a rectangular area encompassing a specified set of
hot instances
• region - within a specified area
• prefill - adjacent to hot instances after making space in the row
• uniform - uniformly over all standard cell rows to fill a specified percentage of
rows.
• decap remove - removes all ineffective inserted decaps within a specified area, as
defined by a specified peak current (default: 30 uA or less).
Additional information on the functions, syntax and usage of these commands is provided
in the FAO command reference at the end of the chapter.
Following is a brief summary of GSR keywords available to control the operation of FAO
to investigate modifying decoupling capacitance. The general TCL syntax for setting GSR
keyword values is: ‘gsr set <variable name> <value>’ .
A detailed description of these GSR keywords and their options and syntax is provided in
section "GSR File Keywords", page C-550.
Decap Modification Constraints and Interfaces with Other Programs
• Commands ‘decap advise -place’, ‘decap fill’ and ‘cell swap’ honor the DEF file option
'+FIXED' so that no modifications are made to fixed instances.
• Commands ‘decap advise -place’, ‘decap fill’ and ‘cell swap’ honor DEF placement
blockage if the GSR keyword 'FAO_DRC_PL_OBS' is set to 1 (On).
• In case decaps include metal1 structures, decap placement detects DRC check
against metal1 signal routes with GSR keyword 'FAO_DRC_OBS' set to 1 (On). If set
to 0 (Off), there is no DRC metal1 signal route check.
• Decaps listed in GSR are not moved during cell swap if designated with option ‘fixed_inst/cell’ in cell swap command.
• Cells with tie high/low connections are not moved unless the ‘-include_thtl’ option is
used (but can move prior to routing).
GSR Keywords Controlling Decap Modification
The following GSR keywords can be used to control the operation of FAO commands:
‘decap advise’ and ‘decap fill’.
1.
To select the target voltage drop reduction: NOISE_REDUCTION (input required)
2.
To specify the percent improvement in voltage drop: NOISE_LIMIT (no default)
3.
To select a fixing area: FAO_REGION (default - whole chip)
4.
To select an area around a hot instance to be fixed: FIX_WINDOW
(default -40 X 40 u)
5.
To select the number of highest voltage drop areas to fix: NUM_HOTINST (default 10)
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
6.
To limit the total decoupling capacitance added: CAP_LIMIT (default - infinity)
7.
To limit the power leakage from all added decaps: LEAKAGE_LIMIT (default infinity)
| 145
The following GSR keywords can only be used for ‘decap advise -place’:
8.
To allow decap placement in illegal locations where there is no available space:
FAO_DECAP_OVERLAP (default - no overlap)
9.
To specify placement of a multiple of each legal decap for placement:
DECAP_DENSITY (default - 1)
Other GSR keywords are available that are specific to individual commands. See the
command reference at the end of the chapter.
Additional Tools for Fixing High Voltage Drop Areas
Supplemental Power Routing with ‘route fix’
In some situations a high voltage drop node can be repaired by routing a supplementary
power wire from it to a nearby low voltage drop node on the same net, providing a parallel
path to equalize the voltage drop between the two nodes. This can be performed using
the ‘route fix’ command, which uses a shape-based point-to-point router. It is invoked by
the following syntax:
route fix [-from { x1 y1 x2 y2 <layer>} | -from_pt { xf yf <layer>} ]
[-to {x1 y1 x2 y2 <layer>} | -to_pt { xt yt <layer>} ] -width <float>
This command finds the shortest DRC-clean legal route for new power/ground wires and
vias from a specified target “from” point (or area) and layer to another specified target “to”
point (or area) and layer. The “export eco” command defines the added wires/vias for the
design database. If the existing via models are not correct for the new routing, any new
vias required will be specified and documented in the file ‘adsRpt/faoVIAS.def’. The width
of the new routing is specified by the value of option ‘-width’.
This command is used to improve power supply wiring from a stronger point to a weaker
point (in terms of voltage drop), as identified from PG-Aware reports.
Cell Moving or Cell Swapping of “Hot Instances”
Some high voltage drop areas can be mitigated by moving a “hot instance” cell to a
nearby node on the same grid with better voltage drop conditions, redistributing and
equalizing current demand on the chip.
After running RedHawk dynamic analysis, the FAO process for moving or swapping
instances to improve DvD or timing is as follows:
1.
Select the analysis criteria by setting the value of FAO_OBJ keyword:
c. DVD - evaluate all instances that have significant DvD impacts
d. TIMING - evaluate all instances that have significant slack and delay impacts
from DvD
e. PATH - evaluate critical paths instances that have significant slack and delay
impacts from DvD
2.
Select fix_window size - the area around each hot instance to investigate swapping
cells (default: 40 X 40 microns)
3.
Select DvD criteria desired setting ‘cell swap’ command options:
-eff_vdd_tw : use average effective voltage (Vdd-Vss) over the timing window to
define swapping targets (default DvD criteria)
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
| 146
-max_vdd_tw : use maximum effective voltage (Vdd-Vss) over the timing window
to define swapping targets
-min_vdd_tw : use minimum effective voltage (Vdd-Vss) over the timing window to
define swapping targets
-min_vdd_all : use minimum effective voltage (Vdd-Vss) over clock cycle to define
swapping targets
4.
Eliminate any cells from swapping by declaring them “fixed”, or define an exclusive
list of cells or instances to swap, using ‘cell swap’ options.
5.
Invoke ‘cell swap’ using the command syntax at the end of this procedure.
6.
FAO generates a list of candidate hot instances to attempt to swap based on the
selected criteria and instance constraints.
7.
For each hot instance in the candidate list, FAO first attempts to move it to all open
locations in the fix_window rectangle surrounding the instance. If the criteria are
improved by moving any candidate cells, it makes the change.
8.
Next FAO attempts to swap the candidate with all other legal instances in the
fix_window. If the selected performance criteria is improved by any attempted
swaps, it makes the change.
9.
FAO iterates through all swap candidates on the specified instance list.
10. An ECO report of instances swapped is automatically prepared.
11. Run the -report and/or -plot options to view the swapping results.
The detailed syntax and usage for the ‘cell swap’ command is as follows:
cell swap ?-eco <file_name>?
?-decap_cells {cell1 cell2 ...}?
?-fixed_cells {cell1 cell2 ...}?
?-fixed_insts {inst1 inst2 ...}?
?-removable_cells {cell1 cell2 ...}?
?-glob|-regexp|-exact?
?-include_clock ?
?-inst_list {inst1 inst2 ...}?
?-inst_file <file_name>?
?-search_only?
?-eff_vdd_tw? ?-max_vdd_tw?
?-min_vdd_tw? ?-min_vdd_all?
?-report? ?-plot?
where
-eco: specifies the filename of the ECO file describing the changes to the design
-decap_cells: : specifies the names or families of master decap cells that can be
used in cell swapping with hot instances. Default: any cells with no logic
connection can be used for swapping. Three options define how the cells are
specified:
-glob: allows global wildcard symbols (such as *) to be used to define families
of decap cells allowed for swapping
-regexp: allows regular expressions to be used to define categories of decap
cells allowed for swapping
-exact: supplies the specific names of decap cells allowed for swapping
-fixed_cells {cell1 cell2 ...} : specifies the names of fixed master cells not allowed
for swapping
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
| 147
-fixed_insts {inst1 inst2 ...} : specifies the names of fixed instances not allowed for
swapping
-removable_cells {cell1 cell2 ...} : specifies the names or families of decap cells
that can be removed from the design, if necessary, during cell swapping.
Default: no decap cells can be removed. The -glob, -regexp, and -exact suboptions are also available for this option, with the same usage as for the decap cell option.
-include_clock : allows clock elements to be included in cell swapping
-inst_list {inst1 inst2 ...} : specifies exclusive list of instance names for cell
swapping
-inst_file <file_name> : specifies file containing exclusive list of instance names
for cell swapping
-search_only : only generates file with list of candidate instances for swapping
based on selection criteria; no swapping is performed (default file name:
cell_swap_<time>.list. If you want to change the name, use the ‘-inst_file
<filename>’ option to specify.)
-eff_vdd_tw : use average effective voltage (Vdd-Vss) over the timing window to
define swapping targets (default DvD criteria)
-max_vdd_tw : use maximum effective voltage (Vdd-Vss) over the timing window
to define swapping targets
-min_vdd_tw : use minimum effective voltage (Vdd-Vss) over the timing window to
define swapping targets
-min_vdd_all : use minimum effective voltage (Vdd-Vss) over clock cycle to define
swapping targets
-report : generates text table of last cell swapping result cell_swap.rpt, showing
instances swapped, and the change in voltage drop (see Figure 7-12)
-plot : generates histogram of last cell swapping result in file cell_swap.hist,
showing the number of instances vs. the change in criteria Vdd value
selected.
*******************************************************************************
**** FAO Cell Swapping Report
*******************************************************************************
Cell Swapping Result Summary
Total swapping instance number : 2182
Actually Moved instance number : 436
Actually Deleted instance number: 0
maximum voltage change (mv)
: 171
minimum voltage change (mv)
: -18
**** Please see adsRpt/cell_swap.rpt for detail DvD change.
**** To view histogram of DvD change, please execute xgraph
adsRpt/cell_swap.hist.
MEMORY USAGE: 2265 MBytes
TOTAL CPU TIME: 1 hrs 17 mins 52 secs
WALLTIME: 1 hrs 27 mins 56 secs.
*******************************************************************************
Figure 7-12
Sample Cell Swapping Report
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
RedHawk User Manual
| 148
There are several GSR keywords that specify how the cell swap command operates:
fao_region: specifies the target analysis area containing high power instances to
be fixed
fao_nets: when there are multiple VDD nets in the design, specifies the name of
the VDD net with which the hot instances are associated
noise_limit: for the list of worst case hot instances, the noise_limit specifies the
voltage drop threshold below which the hot instance will not be considered
for swapping. For example, if noise_limit is set at 5%, hot instances with less
than a 5% voltage drop would not be considered for swapping.
num_hotinst: specifies the number of worst case hot instances to be swapped in
the region
fix_window: specifies the size of the area centered on each identified hotinst
within which the cell would be moved or swapped (default: 40 x 40 u)
fao_verbose: (0/1) controls the volume of output messages. (default: 0, small
amount)
Examples of FAO for DvD
Several examples of dynamic voltage drop improvement using FAO are provided in the
following section.
Example G - Full Chip DvD Reduction - Non-overlap Decap and Grid Fix
Conditions: Early in design development. For this example, the initial worst case
dynamic voltage drop (DvD) has been evaluated at 306mv by RedHawk. Your design
requires a voltage drop at least 10% lower.
Goal: Perform ’decap advise -place’ over the full design, attempting to reduce DvD by
10% (to 276mV) by adding decoupling capacitance. If the target is not met with decap
additions, follow up with a grid fixing run.
1.
Decide on the GSR keyword settings to use. For this run, use all default settings
for decap insertion, except specify a noise reduction of 10%, using the command:
gsr set noise_reduction 10
2.
Run decap placement as follows:
decap advise -place
3. During the evaluation, FAO reports the following:
|Target Worst Average DvD percent over TW: 24.1895%(0.27576)(v.s. Vdd=1.14)
This report shows the that the target DvD reduction of 276mv would be 24.2% of
Vdd. The measured DvD is the worst case average over the timing window (TW).
(The timing window is the range of time in which a particular gate could be
switching, according to a Static Timing Analysis (STA) tool).
4.
After completing the evaluation, FAO reports the following decap changes:
Placed decap cells for 29 hot instances.
Added decap 5.092 pF
FAO then automatically performs another dynamic analysis to determine how close
to the target the result is with the initial decap changes, and adds more
capacitance for the hot instances if needed. It then reports the total decap added in
the second run, so the total decap added in the two placements is now 209.8pf.
Placed decap cells for 29 hot instances.
Added decap 204.718 pF
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
5.
RedHawk User Manual
| 149
Now rerun RedHawk extraction and dynamic analysis as follows, to check the
improvement achieved:
perform extraction -power -ground -c
setup pad -power -r 0.005 -ground -r 0.005
setup wirebond -power -r 0.001 -l 1000 -ground -r 0.001 -l 1000
setup package -r 0.001 -l 250 -c 5
perform analysis -vectorless
In this case the dynamic voltage drop has improved to 284mV, with a target value
of 276mV.
6.
Obtain a report of the decaps added and the improvement achieved using the
‘decap report’ command. Then export the required changes into an ECO file, as
follows:
decap report
export eco decap.1.eco
The decap report for the operation follows:
*************************************************************
****
FAO Decap Report on top Hot Instances
*************************************************************
Inserted Decap Inst Num : 3579
Inserted Decap Total
: 209.81 pF
V0/V1 : Average (VDD - GND) over TW before/after decap placement.
DvD0/DvD1 : Dynamic Voltage Drop (VDD - V0/V1) before/after decap
placement. Improvement % : (DvD0 - DvD1)/DvD0 %.
inst
V0
V1
DvD0
DvD1
Improvement%
------------------------------------------------INFO(FAO-75): inst194510 : 0.8343 0.8568 0.3057 0.2832 7.36017%
INFO(FAO-75): inst117100 : 0.8346 0.8574 0.3054 0.2826 7.46563%
INFO(FAO-75): inst76925 : 0.8395 0.8607 0.3005 0.2793 7.05491%
-------------------------------------New Top Hot Instances:
inst
&
avgVoltage_TW
-------------------------------------inst194510 0.8568
inst117100 0.8574
inst76925 0.8607
-------------------------------------Overall DvD improvement = 7.3601 % v.s. initial DvD
MEMORY USAGE: 622 MBytes
************************************************************
7.
In the ECO file, filter the list of instance names of the added decaps (those with a
decap* prefix), then use the RedHawk command:
select add "decap*" -glob -linewidth 3
to highlight them for viewing on screen.
8.
Using the ‘decap report’ (above) showing a DvD improvement of 7.36%, assign
the remaining improvement needed (2.64%) to the next step, wire fixing. Set the
new target voltage drop as follows:
gsr set noise_reduction 2.64
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Automated Fixing and Optimization (FAO) for DvD and Timing
9.
RedHawk User Manual
| 150
Now on the target layers run ‘mesh optimize’ (if you want to look at the entire
grid), or ‘mesh fix’, with a specified ‘fix window’ if you want a localized fix, and
see if that achieves the desired voltage drop goal.
10. As in the previous examples, rerun RedHawk dynamic simulation to check on your
results.
Example H - Full Chip DvD Reduction - Decap Overlap
Conditions: Early in design development. For this example, the initial worst case
dynamic voltage drop (DvD) is again found to be 306mv by RedHawk. Your design
requires a 10% lower voltage drop. This time we are going to search for a solution in
which decaps can be placed anywhere, whether there is legal space or not.
Goal: Perform decap placement over the full design, attempting to reduce DvD by 10% to
276mV by adding decoupling capacitance.
1.
Decide on the GSR keyword settings to use. Using the same RedHawk design
inputs, this time use the 'overlap true' GSR keyword setting for ‘decap advise
-place’. This allows the needed decaps to be inserted both legally and also
where there is no placement space presently available, to attempt to reduce the
local DvD. Set GSR keyword values as follows to request a 10 % reduction in DvD
and allow decaps to be placed in illegal areas:
gsr set fao_decap_overlap 1
gsr set noise_reduction 10
2.
As in previous example, verify the amount of decap added and the final DvD
savings achieved. A sample output report is shown below:
**********************************************************
****
FAO Decap Report on top Hot Instances
**********************************************************
Inserted Decap Inst Num : 305
Inserted Decap Total
: 229.938 pf
V0/V1 : Average (VDD - GND) over TW before/after decap fix.
DvD0/DvD1:Dynamic Voltage Drop (VDD - V0/V1) before/after decap fix.
Improvement % : (DvD0 - DvD1)/DvD0 %.
inst
V0
V1 DvD0 DvD1 Improvement%
-------------------------------------------------------INFO(FAO-75): inst117100 : 0.8346 0.8573 0.3054 0.2827 7.43288%
INFO(FAO-75): inst194510 : 0.8344 0.8609 0.3056 0.2791 8.67146%
INFO(FAO-75): inst76925 : 0.8396 0.8623 0.3004 0.2777 7.55658%
------------------------------------------------------New Top Hot Instances:
inst
&
avgVoltage_TW
------------------------------inst117100 0.8573
inst194510 0.8609
inst76925 0.8623
------------------------------Overall DvD improvement = 7.73499 % v.s. initial DvD
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Saving Design Changes with the ECO Command
RedHawk User Manual
| 151
Saving Design Changes with the ECO Command
Once a voltage drop target is met, the ECO file created by the mesh and decap
placement operations can be read into RedHawk by using the File > Import ECO
command from the GUI. (The ECO file is written in an ASCII text format such that it can
be easily exported to designers’ routing tools to complete the physical design and
verification flow.)
Writing an ECO File
The command File > Export ECO exports all the recent design changes to an ECO file in
the RedHawk working directory. When selected, the pop-up form will query you for a file
name, otherwise use the default name apache.eco. The format of the ECO file is
described below. For the TCL invocation of the ‘export eco’ command, see section
"export", page D-746.
Reading an ECO File
The ECO file can be imported by using the File > Import ECO command after the design
is read in with the File > Import Design Data command. Database setup must be
completed also. When this is performed, all what-if changes as specified in the ECO file
or apache.eco will be included in the design during IR drop and EM analysis.
ECO File Format Definition
NOTE:
The ECO file syntax is described below to help you understand the file
contents, which are generated automatically by RedHawk. Do not try to
create or edit an ECO file manually.
The following is an example of a tabular *.eco file created by the File -> Export ECO
command:
Keyword
Obj
Obj name
(uniq ID)
P/G Layer/ via Rotation
name
Coordinates
Direction
add
pad
pvdd1
Vdd
metal1
None
x_new y_new
(center)
None
delete
pad
pvdd2
Gnd
metal1
None
x_old y_old
(center)
None
add
via
via67_new
Vdd1
via7_1
<code>
x_new y_new
(center)
None
delete
via
via67_old
Vdd1
via7_2
None
x_old y_old
(center)
None
add
wire
wire1
Vdd2
metal7
None
x1 y1 (lower left)
x2 y2 (upper right)
[ horizontal |
vertical ]
add
wire45 wireCD
Vdd
metal7
None
x3 y3 x4 y4
x5 y5 x6 y6
(trapezoid corners)
None
delete
wire
Vdd
metal7
None
x1 y1 (lower left)
x2 y2 (upper right)
None
wire2
The ECO file format description, by column, is as follows:
Column 1: ‘Keyword’ represents the type of ECO change:
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Saving Design Changes with the ECO Command
RedHawk User Manual
| 152
add - a new object added to database
delete - an existing object deleted from database
Column 2: ‘Obj ’ represents the type of object that was changed:
pad - a pad object
via - a via object
wire - a horizontal or vertical wire object
wire45 - a wire object, not on grid
Column 3: ‘Obj name (uniq ID)’ represents the unique name of the object.
Column 4: ‘P/G Name’, for pads is ‘VDD’ or ‘GND’, and for wires and vias is the net name
Column 5: ‘layer/via’ is the name of metal layer or via defined in LEF:
metal1 - metal layers defined in LEF
via7_1 - via definition defined in LEF
Column 6 : represents the coordinates of the object being changed by ECO, except for
‘add via’:
For pads, indicates the x,y coordinates of the center of the power/ground pad being
added or deleted
For ‘add via’, indicates the rotation code associated with the via added, as follows:
-1
No rotation
0-6
RedHawk rotation code
For ‘delete via’, indicates the center of the via to be deleted.
For wires, indicates the lower left and upper right x,y coordinates of the bounding box
for the wire being added or deleted. Note that you can delete a non-grid wire segment with the command ‘delete wire’.
For wire45 objects, x3 y3, x4 y4, x5 y5, and x6 y6 represent the four corners of the
trapezoidal wire segment to be added. Any corner can be the first corner specified,
but the corners must be listed in counterclockwise order.
Column 7: For ‘add via’, indicates the x,y coordinates of the center of the via to be added.
This via and its size/layer must have already been defined in LEF.
Column 8: For ‘add wire’, indicates the direction--vertical or horizontal-- of the wire to be
added.
Note: ECO added wires are not merged by RedHawk, so if an added wire overlaps
another wire on the same net and on the same layer, the capacitance extracted for
the overlap portion of the two wires will be double counted (too large), and the
resistance for the overlap portion will be that much smaller due to the double
counting. For this reason, the amount of overlap should be minimized.
ECO File Translation for Use by Place and Route Tools
ECO file formats can be easily post-processed into formats that are readable by EDA
place and route tools. This flexibility provided by RedHawk ensures a smooth data flow
between RedHawk and P&R tools.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
RedHawk User Manual
| 153
Fixing and Optimization Command Reference
Descriptions of Mesh Optimization Commands
The following section describes the commands available for performing grid optimization
and fixing in RedHawk FAO (alphabetic order). The GSR keywords associated with each
command are described in the next section. See the last section for syntax conventions.
Mesh and ring commands - FAO functions to optimize and fix grids.
mesh [ add| delete| fix| generate| optimize| snscalc |
sub_grid | set_width | vias ] ? args ?
ring add ? args ?
ring delete <ring_name>
Table 7-1
Grid Optimization and Fixing Commands
Command
Description
Allows you to add a specified mesh to the power grid.
Associated GSR keywords: none
Options
[ -vertical | -horizontal ]
Select either horizontal or vertical direction for adding mesh.
-window { <x1> <y1> <x2> <y2> }
Add mesh in rectangular area specified by corner coordinates
‘x1’,’y1’, and ‘x2’,’y2’
-layer <layer_name>
Add mesh layer named ‘layer_name’.
-offset <offset_value_microns>
Offsets new layer as specified from left edge of selected
window vertically, or from bottom edge of window horizontally .
mesh add
-space <space_amount>
Add ‘space_amount’ in microns between the power nets
specified in the -net option.
-pitch <pitch>
Add mesh with pitch of ‘pitch’ microns.
-width <mesh_width>
Add mesh with width of ‘mesh_width’ microns.
[-novia | -viatop <metal_layer_name_above>
-viabottom <metal_layer_name_below>]
Add mesh either without a via or with vias going from
‘metal_layer_name_below’ up to ‘metal_layer_name_above’
-net { <net1> <net2> ... <netn>}
Add mesh associated with net names ‘net1’ to ‘netn’
-clip_cell {<macro1> <macro2> ... }
Blocks metal from being added inside the boundary of the
specified cells, to prevent shorts of pin geometries inside cells.
-exclude_regions {{x1 y1 x2 y2} {<excluded_region2_coords>} ... }
Excludes one or more specified regions for mesh addition.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-1
RedHawk User Manual
| 154
Grid Optimization and Fixing
Calculates a number representing the relative voltage drop
sensitivity (in mv/um) for changes to wire width for the selected
layers and nets within the selected region.
mesh snscalc
Associated GSR keywords: fao_region, fao_nets, fao_layers
Options
? -taper ?
Resizes grid wires on target layers only within the specified
region (fao_region), not the full height or width of the chip.
Allows you to delete specified parts of the power grid.
Associated GSR keywords: None
Options
[ -vertical | -horizontal ]
Delete mesh in either horizontal or vertical direction.
-window { <x1> <y1> <x2> <y2> }
Delete mesh in rectangular area specified by corner
coordinates ‘x1’,’y1’, and ‘x2’,’y2’
-layer <layer_name>
Delete mesh layer named ‘layer_name’.
-net { <net1> <net2> ... <netn>}
Delete mesh associated with net names ‘net1’ to ‘netn’.
mesh delete
-width { ?<Oper>? <width-1> ?<Oper> <width-2>? ? <width>? }
Defines grids to be deleted by function of width. <Oper> is a
relational operator of the group: =, >, <, >=, or <= . “Width” is
defined orthogonal to the wire direction
-length { ?<Oper>? <length-1> ?<Oper> <length-2>? ?<length> ?}
Defines grids to be deleted by function of length. <Oper> is a
relational operator of the group: =, >, <, >=, or <= . “Length” is
defined in the wire direction.
-out_of_ratio { n m }
Defines partial grid wire deletion, or how many grid wires, “n
wires out of every m wires”, are to be deleted.
-all
Specifies that all available mesh object parameters are deleted
except as specifically listed in the ‘mesh delete’ command.
-exclude_regions {x1 y1 x2 y2} {excluded_region2_coords} ...
Specifies one or more regions to be excluded from the ‘mesh
delete’ command specified, where x1, y1, x2, y2 are lower left
and upper right coordinates for the region to be excluded.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-1
RedHawk User Manual
| 155
Grid Optimization and Fixing
Allows you to perform hot-spot based grid width fixing.
Associated GSR keywords: fao_region, mesh_search, fao_layers,
fao_turbo_mode, fao_dynamic_mode, fao_nets, fao_range,
fao_width_cnstr, noise_reduction, fix_window, num_hotspot
Options
mesh fix
? -taper
Resizes grid wires on target layers only within the specified
region (FAO_REGION), or FIX_WINDOW if defined, not the
full height or width of the chip.
? -eco <eco_filename>?
Prepare ECO report file ‘eco_filename’ in RedHawk ECO text
format.
Allows you to investigate and fix voltage drop problems using
uniform grid modifications on selected parts of the grid system.
Associated GSR keywords: fao_region, mesh_search, fao_layers,
fao_turbo_mode, sim_mode, fao_nets, fao_range, fao_width_cnstr,
noise_reduction, num_hotspot
Options
mesh optimize
? -taper
Resizes grid wires on target layers only within the specified
region (FAO_REGION), not the full height or width of the chip.
?-eco <eco_filename>
Prepare ECO report file ‘eco_filename’ in RedHawk ECO text
format.
Adds a set of subgrids defined in a region defined by 'fao_region',
nets defined 'fao_sub_grid_nets', and with layers, pitch and
spacing defined by 'fao_sub_grid_spec'. The program sizes the
new subgrid to meet a preset voltage drop target 'noise_reduction' .
The min/max width of the new grids considered is specified by
'fao_range'. The minimum width is also used to create the initial
subgrid before adjusting the size.
mesh sub_grid
Associated GSR keywords: fao_region, fao_sub_grid_nets,
fao_sub_grid_spec, fao_range, noise_reduction, fao_turbo_mode,
fao_dynamic_mode
Options
?-eco <eco_filename>
Prepare ECO report file ‘eco_filename’ in RedHawk ECO text
format.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-1
RedHawk User Manual
| 156
Grid Optimization and Fixing
Adds specified optimal-sized stacked vias to improve voltage drop- that is, adds the via with the largest possible dimension in the
rectangular region overlapping the upper and lower metal layers.
Associated GSR keywords: none
Options
-toplayer <top_layer_name>
Specifies top layer connection of vias to be added.
-bottomlayer <bottom_layer_name>
Specifies bottom layer connection of vias to be added.
-viarule {<generate_viarule_name>}
Specifies which LEF VIARULE_GENERATE rule is used.
[-window { <x1> <y1> <x2> <y2>} | -inst {< inst1> <inst2> ... }]
Specifies corner coordinates ‘x1’,’y1’ and ‘x2’,’y2’ for window in
which to add stacked vias, or specifes windows determined by
the locations of cell instances ‘inst1’ to ’instn’.
?-net { <n1> <<n2> ... }?
Specifies nets ‘n1’ to ‘nn’ for which to add stacked vias.
?-topwidth {<tw1> <tw2> ... }? ?-bottomwidth { <bw1> <bw2> ... }?
Defines the top widths ‘tw1’ to ‘twn’ of the existing top layer
and bottom widths ‘bw1 to ‘bw2’ for which stacked vias will be
added in the overlapped area.
?-viamodel { <m1> <m2> ... }? ?-replace?
Specifies viamodels ‘m1 to ‘mn’ to be used.
mesh vias
?-between_layer {<layer1> <layer2>}
Specifies a via to be connected between defined layers. The toplayer and -bottomlayer options having a different direction
are used to define the location of the new via using their
intersections with <layer1>/<layer2>. No via connections are
made outside of the <layer1> to <layer2> range in this usage.
?-eeq_net {<net1> <net2>}
Specifies a via be dropped between the wires of the specified
top and bottom layers, even though they have different names.
? -pt_file <filename>
Specifies a file listing potential via x,y coordinates. The file
format is '<x_coord> <y_coord>', with one entry per line, or
when using a script such as report_missing_vias.tcl, entries
may use either the form '<x_coord> <y_coord>', or the
command form 'marker add -position <x_coord> <y_coord>'.
?-delete -window { x1 y1 x2 y2} -viamodel {Via1 Via2 ...}
-cut_layer <layer>
Specifies vias to be deleted for a specified rectangular area,
viamodel, or layer, or viamodel. If you do not define -window,
then FAO uses the FAO_Region GSR keyword definition as
the window. If FAO_Region is not defined, then the whole chip
is used. If -viamodel is not defined, all viamodels in the box
are deleted. If neither -window nor -viamodel are defined, then
all types of vias in FAO_Region, or on whole chip are deleted.
Viamodels are defined in Tech LEF or in top DEF.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-1
mesh vias
(cont.)
RedHawk User Manual
| 157
Grid Optimization and Fixing
? -vr_percent_x <value> ? ? -vr_percent_y <value> ? ? -vr_x
<value> ? ? -vr_y <value> ?
Specifies percentage or length and width constraints to add a
via array. Where :
-vr_percent_x <value> : percentages of length of via arrays on
metal overlap area .
-vr_percent_y <value> : percentages of width of via arrays on
metal overlap area.
-vr_x <value> : length of via array (unit um).
-vr_y <value> : width of via array (unit um).
Manipulates and reports on specified stacked vias to improve
voltage drop.
Associated GSR keywords: FAO_LAYERS, FAO_LAYERS,
FAO_NETS.
Options
mesh vias
(cont.)
?-report_missing ? -exclude_stack_via ?
? '-check_valid_vias?
Reports if metal overlap can accommodate a valid via model.
Note that this option does not work with '-min_width' and GSR
'FAO_LAYERS'. All other switches and keywords are
supported.
? -exclude_cell/-exclude_instance :
excludes the area covered by all instances of a given cell, or
an area covered by a specified list of instances from the
missing via report.
? [-inst {<inst1> ...} | -cell { <cell1> ...} | -window { x1 y1 x2 y2 } ?
? -exclude_regions { x1 y1 x2 y2 } ? -sort_by_hot_inst ?
? -toplayer <layer1> -bottomlayer <layer2> ? ? -gds ?
? -threshold [ -1 | <voltage_V> ] ? ? -min_width <value>?
? -fao_layers { {layer1 [h|v]} {layer2 [h|v] } ...}? ?-marker ?
? -no_partial_overlap ? ?-pitch <via_center-center distance>
? -from_edge [0|1] ? –x_pitch <value> ?? -y_pitch <value>
? -x_offset <value> ? -y_offset <value> ? -ignore_inter_med
? -adjust_offset
Specifies missing vias to be reported, by default includes
stacked vias. Supports FAO_REGION and 45-degree wires.
If the ‘-exclude_stack_via’ option is used, stack vias are
excluded. Using the -inst, -cell, or ‘-window’ options reports
only missing vias of the specified inst or cell type, or
overlapping the defined window boundaries. The default is the
full chip. Multiple rectlinear/rectangular regions are also
supported in ’-window’ option in the format “-window {{x1 y1 x2
y2 x3 y3 ..} ...{x4 y4 x5 y5 ...}}” .
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
mesh vias
(cont.)
ANSYS INC - Apache Design Business Unit
RedHawk User Manual
| 158
Using ‘-exclude_regions’, multiple rectilinear/rectangular
region can be excluded from missing via check (same format
as ‘-window’ option).
Using the ‘-sort_by_hot_inst’ option sorts missing vias by
voltage drop, where default sorting is by average delta V
between defined layers.
The -gds option flags missing via locations both inside the
GDS block region and in routes over GDS blocks. By default
missing via check ignores all items inside or overlapping the
area of a GDS2DEF/GDSMMX block. To flag all missing vias
within and overlapping the gds*-based cell region, the -gds
option is required.
‘-threshold < >’ is used to set the voltage threshold between
overlapped geometries that trigger a missing via report. If the
option is set to ‘-1’ the voltage check is not used as a filtering
criteria-- for example, if dynamic analysis has not been
performed and there are no voltage drop values. Default: 1mV.
-min_width ignores segments with less than specified width.
-fao_layers <layers...> specifies layers and their horizontal or
vertical orientation for which missing vias are to be reported.
Length based constraint is also supported. By default, widthbased constraint is available
-marker specifies the missing via is highlighted in GUI.
-no_partial_overlap ignores partial metal overlaps with missing
vias. This option works by setting GSR keyword
‘FAO_IGNORE_COMPRESS_VIAS’
-pitch <via center-center dist> specifies the pitch for missing
vias on parallel wires crossing or touching GDS blocks. A pitch
may start from either left-edge or right-edge for a horizontal
overlap (that is, width > height), or a pitch may start from either
bottom-edge or top-edge for a vertical overlap. Use option ‘from_edge [0|1]’ to specify this, using ‘-from_edge 0’ for
parallel nets from left/bottom edge and ‘- from_edge 1’ for
parallel nets from right/top edge. - ignore_inter_med ignores
wires on all layers between the specified -toplayer < tl> and bottomlayer <bl>. -x_offset, -y_offset specifies the offset from
the overlapping geometry edge to the location of the first via. adjust_offset specified along with -x_offset/-y_offset and x_pitch/-y_pitch. - x_offset/-y_offset is a must and is used to
generate missing via locations on empty overlaps. If there are
some vias existing in the overlap region, abandon the given x_offset/-y_offset and generate new -x_offset calculated from
the left-most via present to the left edge with -x_pitch.
Likewise, new - y_offset from bottom most via present to the
bottom edge with -y_pitch
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
RedHawk User Manual
| 159
Modifies the mesh wire width on specified layers.
Associated GSR keywords: Fao_Region, Fao_Sub_Grid_Nets,
Fao_Layers
Options
mesh set_width
{ { <layer1> <new_mesh_width1> ? <width_change_dir1> ?} ...
{ <layerN> <new_mesh_widthN> ? <width_change_dirN> ?} }
where
<layerN>
Specifies name of layer to have mesh width changed.
<new_mesh_widthN>
Specifies new mesh wire width for <layerN> in microns.
? <width_change_dirN> ?
Specifies direction of width change, if not equal on both sides
of centerline (default).
Direction values are [ left | right | top | bot ].
Adds specified power/ground rings to design.
Associated GSR keywords: None
Options
ring add
?-name <ring_name>? ?-window { x1 y1 x2 y2 } ?
{ -[ top| bottom| left| right] -layer <layer_name>
-offset <offset> -width <width>
-space <space> -net <net1 net2 ...netN> }
Specifies location and dimensions of two or more power/
ground rings.
[ top| bottom| left| right] are sides of the rings to be added
-window { x1 y1 x2 y2 } are corners of a specified window in
the design (or chip boundary by default)
<layer_name> - name of layer where ring segment is added
<offset> - distance (u) from defined window (negative value is
toward inside of window)
<width> is the width of ring (u), measured toward outside of the
chip
<space> is the space (u) between rings. Multiple ‘width’ and
‘space’ pairs are added (equal to the number of nets specified)
<netN> is the net name associated with the rings in the order
defined.
Deletes all elements of the specified power/ground ring from the
design.
ring delete
Associated GSR keywords:None
Options
<ring_name>
Name of previously-added ring to be deleted.
Descriptions of Decap Modification Commands
The following section describes the commands available for performing decoupling
capacitance fixing in RedHawk FAO. The GSR keywords associated with each command
are described in the next section.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
RedHawk User Manual
| 160
Decap commands - the following commands provide FAO functions to perform
modifications on decoupling capacitance. They are described in the table below.
decap [ advise | place | fill | remove | report ] ? arg ?
cell swap ? arg?
Table 7-2
Decap Modification Commands
After running a decap fao command creates an output report in the
file adsRpt/faoOverlapDecap listing the total number of decaps, the
cap value, and the associated DvD improvement.
Associated GSR keywords: none
Options
? -overlap ?
Includes report of number of overlapping decaps in the decap
report in the format:
<decap_master> loc_x loc_y <num_decaps>
decap report
? [ -eff_vdd_tw | -min_vdd_tw | -max_vdd_tw | -min_vdd_all ] ?
Sets up ‘decap report’ for the specified DvD criteria, which are
defined as:
eff_vdd_tw : average effective voltage (Vdd-Vss) over the
timing window to define fixing targets (default DvD
criteria)
max_vdd_tw : maximum effective voltage (Vdd-Vss) over
the timing window to define fixing targets
min_vdd_tw : minimum effective voltage (Vdd-Vss) over
the timing window to define fixing targets
min_vdd_all : minimum effective voltage (Vdd-Vss) over
clock cycle to define fixing targets.
(Default: -eff_vdd_tw)
Creates a DRC report on FAO decap changes, and, with the '-fix'
option, fixes DRC violations for user-placed decap cells.
Associated GSR keywords: none
Options
decap drc
? -fix ?
Uses flipping and removal techniques to fix DRC violations on
pin geometries in user-placed decap cells that violate signal/
shield routes.
? -o <filename> ?
Specifies the output file describing DRC locations and fixes in
a decap DRC report.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-2
RedHawk User Manual
| 161
Decap Modification Commands
Provides an assessment of the amount decap that could be placed
in specified areas of the design, and creates a *.dpf file of results.
Associated GSR keywords: fao_region, noise_reduction,
noise_limit, num_hotinst, cap_limit, fao_decap_overlap, cap_limit,
leakage_limit, decap_density,
Options
? -place ?
Implements maximum decap placement based on ‘advise’
analysis. Creates *.dpf file describing placements.
? -dpf <dpf_filename> ?
Specifies the name of the input decap placement file. (Default:
adsRpt/fao.dpf)
? -distribute ?
Ignores ‘noise_limit’ and ‘noise_reduction’ constraints and
fixes decap cells up to ‘cap_limit’ around ‘num_hotinst’ of hot
instances in proportion to their criteria DvD values. (Default:
off)
? [ -eff_vdd_tw | -min_vdd_tw | -max_vdd_tw | -min_vdd_all ] ?
Specifies which type of DvD criteria is used to select candidate
hot instances to investigate for fixing. Instances and
associated criteria values are defined in the adsRpt/Dynamic/
<design>.dvd lookup table. The criteria are:
eff_vdd_tw : use average effective voltage (Vdd-Vss) over
the timing window to define fixing targets (default DvD
criteria)
decap advise
max_vdd_tw : use maximum effective voltage (Vdd-Vss)
over the timing window to define fixing targets
min_vdd_tw : use minimum effective voltage (Vdd-Vss)
over the timing window to define fixing targets
min_vdd_all : use minimum effective voltage (Vdd-Vss)
over clock cycle to define fixing targets.
(Default: -eff_vdd_tw)
? [ -inst_file <filename> | -inst {inst1 inst2 ... } ] ?
-inst_file <file_name> : defines a file containing exclusive list of
instances as target areas for filling.
-inst { inst1 inst2 ... } : specifies exclusive list of instances as
target areas for filling
? repeat [-iter <n> ] ?
Specifies automatic repeat up to n times of 'decap advise place’, then extraction, and DvD analysis. At the end of each
iteration, the DvD value is checked against the noise_limit. If
the noise_limit is met, less than 1% DvD improvment is
achieved, or n is reached, iteration stops. Default n =1.
?-mmx?
Provides an assessment of the amount of decap that could be
placed in a custom block or design modeled with MMX
methodology, and records the results in the log file.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-2
RedHawk User Manual
| 162
Decap Modification Commands
Provides specific decap placements at hot instance locations
based on ‘decap advise’ results showing how much is needed.
Associated GSR keywords: fao_decap_overlap, cap_limit,
leakage_limit, decap_density, noise_limit
decap place
Options
? -dpf <dpf_filename> ?
Specifies the input decap placement file. (Default: adsRpt/
fao.dpf)
? -eco <eco_filename> ?
Prepares ECO report file in RedHawk ECO text format.
Measures QoR (results quality) of decaps inserted by FAO.
Associated GSR keywords: decap_fill.
Options
decap qor
? -i <input_decap_inst_file>
Specifies input decap instance list file.
? -o <output_dir>
Specifies the output directory name.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-2
RedHawk User Manual
| 163
Decap Modification Commands
Provides decap filling in available spaces. If neither ‘-fao_region’
nor ‘-hot_area’ are defined, spaces in the fix_window area around
each hot instance are filled. Leakage of the decap is considered
when you use the GSR keyword ‘FAO_DECAP_FILL_ALG’.
Associated GSR keywords: fao_region, noise_reduction,
noise_limit, num_hotinst, cap_limit, fao_decap_overlap, cap_limit,
leakage_limit, decap_density, fao_max_shift, fao_row_vdd_site.
Options
? repeat [-iter <n> ]?
Specifies automatic repeat of 'decap fill', After each iteration,
DvD value is checked against the noise_limit. After the first
normal ‘decap fill’ run, subsequent iterations place decaps
(specified with ‘density_step’) at the top 5% hot instance
locations in the ‘fix_window’, then extraction and DvD analysis.
When the noise_limit is met, less than 1% DvD improvment is
achieved, or n is reached, iteration stops. Default n =3.
? -density_step <s> ?
Specifies the number of decaps to add at each of the top 5%
hot instance locations in the ‘fix_window’ for each ‘repeat’
iteration after the first ‘decap fill’. Default s=1.
decap fill
? -eco_name_pattern <string> ?
Allows a specified alpha-numeric string to be added to the
names of a group of decaps being placed during a 'decap fill'
operation. Default string = SH. Names can be of the form:
‘<decap_cell>_<eco_string><number>’
The value of this option overrides any value set using the
ECO_NAME_PATTERN GSR keyword.
? -no_adjust_fix_window ?
Turns off default proportional adjustment of the fix window size
per voltage drop so all fix_windows are specified size (default
300x300 microns). If this option is not invoked the highest DvD
hot instance has the specified fix_window size, and the size of
the fix_window for other hot instances is reduced in proportion
to the DvD down to 50% of the maximum fix_window
dimension for the lowest hot instance specified.
? -clone_cells { <list of block cellnames> } ?
For a block instantiated multiple times at top level, replicates
the fill of decap cells exactly the same in all instances of the
block, including different orientations. An ECO report is
generated listing the decaps added and the numbered clones
of the decap instantiation in each block.
?-prefill ? -no_ff_move ? ? -ignore_fixed ?
First performs decap prefill described in the ‘-prefill_only’, then
performs the selected ‘decap fill’ command. If ‘-no_ff_move’
used, no FFs defined in LIB file are moved. Typically used after
CTS. If ‘-ignore_fixed’ is used, "fixed" elements such as
instances can be moved in executing the decap fill operation.
?-uniform <percentage>
Places decap cells uniformly over all standard cell rows to fill
the specified percentage of rows (may cause overlaps with
existing standard cells).
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-2
RedHawk User Manual
| 164
Decap Modification Commands
Options
? -fao_region ?
If selected, uses definition in GSR keyword for x,y coordinates
of rectangle within which all spaces will be filled with decap.
(default: whole design)
?-hot_area?
If selected, uses definition in GSR keyword for rectangular
area to be filled that includes all hot instances meeting
constraints on total capacitance, leakage, and noise_limit;
(default: if -fao_region and -hot_area are not defined, the
fix_window area around each hot instance is filled).
? [ -eff_vdd_tw | -min_vdd_tw | -max_vdd_tw | -min_vdd_all ] ?
Specifies which type of DvD criteria is used to select candidate
hot instance areas to investigate for filling. Instances and
associated criteria values are defined in the adsRpt/Dynamic/
<design>.dvd lookup table. The DvD criteria are:
eff_vdd_tw : use average VDD over the timing window to
define filling targets (default)
max_vdd_tw : use maximum VDD over the timing window
to define filling targets
min_vdd_tw : use minimum VDD over the timing window to
define filling targets
decap fill
(cont.)
min_vdd_all : use minimum VDD over clock cycle to define
filling targets
? [ -inst_file <filename> | -inst { inst1 inst2 ... } ] ?
-inst_file <file_name> : defines a file containing exclusive list of
instances as target areas for filling.
-inst { inst1 inst2 ... } : specifies exclusive list of instances as
target areas for filling (Default: null)
? -prefill_only ?
Moves cells adjacent to each defined hot instance as far as
possible away from them in the row, up to the value of GSR
keyword FAO_MAX_SHIFT (5 um default). Decap cells are
then placed in the larger of space available on either side of
hot instance. Cells that have +FIXED flag in DEF, or are listed
in the ‘-fixed_insts’ or ‘-fixed_cells’ options, are not shifted.
? [ -fixed_insts | -fixed_cells ] { ... } ?
Fixes the location of listed instances or cells, and prevents any
movement by the ‘-prefill_only’ or ‘-prefill’ commands.
? -replace_filler {<filler1> ...}? or ? ‘replace_filler_file <fillename>‘ ?
Specifies existing filler cells to be replaced with decap cells
(GSR keyword DECAP_CELL). Either list the filler cells, or
specify a file containing a list of filler cells to be replaced.
-inst_type specifies a 'FIXED' or ‘PLACED' attribute for replace_filler', or ‘ALL’ includes all types of filler cells (default).
-replace_filler_hot_area automatically generates a "hot box" to
replace ineffective fillers (the most significant area to replace
fillers with decaps, based on the selected DvD criteria option.
Wild cards for <filler_name> are allowed.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-2
RedHawk User Manual
| 165
Decap Modification Commands
Removes all “ineffective” decap cells, as defined by the value of the
‘-imax_less_than’ criteria (default: 30uA).
Associated GSR keywords: fao_nets, fao_region, fix_window,
noise_limit, noise_reduction, num_hotinst, cap_limit,
fao_decap_overlap, cap_limit, leakage_limit, decap_density,
fao_verbose
Options
? -imax_less_than <peak_current> ?
Specifies the smallest peak decap current to keep a decap in
place and not remove it (default: 30 uA). Decap list: adsRpt/
Dynamic/decaps.rpt.
? -dvmax_less_than ?
Specifies a small delta voltage associated with the peak decap
current as a threshold below which no decap removal is
performed (default: 0)
? -fao_region ?
If selected, specifies that decaps would be removed only within
the rectangular region defined by the GSR keyword, according
to other option values set or their default values.
? -hot_area ?
If selected, specifies a rectangular area that includes all hot
instances (as defined by noise_limit and num_hotinst) that will
have no decaps removed.
decap remove
? -user_decap ?
If selected, also removes user-specified decaps, in addition to
FAO-added decaps.
? [ -eff_vdd_tw | -min_vdd_tw | -max_vdd_tw | -min_vdd_all ] ?
Specifies which type of DvD criteria is used to select candidate
hot instances to investigate for decap removal. Instances and
associated criteria values are defined in the adsRpt/Dynamic/
<design>.dvd lookup table. The criteria are:
eff_vdd_tw : use average effective voltage (Vdd-Vss) over
the timing window to define removal targets (default)
max_vdd_tw : use maximum effective voltage (Vdd-Vss)
over the timing window to define removal targets
min_vdd_tw : use minimum effective voltage (Vdd-Vss)
over the timing window to define removal targets
min_vdd_all : use minimum effective voltage (Vdd-Vss)
over clock cycle to define removal targets
? -ignore_cap_limit ?
After removing ineffective decaps based on the imax criteria,
this option stops decap removal, even if cap_limit is exceeded
(default: off - decap removal continues on decaps associated
with lowest-ranked “best” DvD instances in the target list until
both capacitance and leakage limits are achieved).
? -no_decap_report
Cancels decap removal reporting to speed up repetitive
removal process.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-2
RedHawk User Manual
| 166
Decap Modification Commands
? -ignore_leakage_limit ?
After removing ineffective decaps based on imax criteria, this
option stops decap removal, even if leakage_limit is exceeded
(default: off - decap removal continues on decaps associated
with lowest-ranked “best” DvD instances in the target list until
both capacitance and leakage limits are achieved).
decap remove
(cont.)
? -clone_cells ?
Removes all identical decap cells from all cloned instances if
none of them cause a degradation of DvD performance. If any
decap removals would increase DvD, none of cloned decap
cells are removed.
? -all ?
Regardless of other options set or their default values,
removes all decaps on the chip, or, if the -fao_region option is
set, within the specified region.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
Table 7-2
RedHawk User Manual
| 167
Decap Modification Commands
Moves defined hot instance cells to open spaces, or swaps them
with either decap cells or cells with lower power demand in a
specified area.
Associated GSR keywords: fao_region, fao_nets, fix_window,
noise_limit, num_hotinst, fao_verbose
Options
? -eco <ECO_filename> ?
Prepares ECO report file ‘eco_filename’ in RedHawk ECO text
format.
? -decap_cells: ?
Specifies the names or families of master decap cells that can
be used in cell swapping with hot instances. Default: any cells
with no logic connection can be used for swapping. Three
options define how the cells are specified:
-glob: allows global wildcard symbols (such as *) to be
used to define families of decap cells allowed for
swapping
-regexp: allows regular expressions to be used to define
categories of decap cells allowed for swapping
-exact: supplies the specific names of decap cells allowed
for swapping
cell swap
? -fixed_cells { cell1 cell2 ...} ?
Specifies the names of fixed master cells not allowed for
swapping
? -fixed_insts { inst1 inst2 ...} ?
Specifies the names of fixed instances not allowed for
swapping
? -removable_cells { cell1 cell2 ...} ?
Specifies the names or families of decap cells that can be
removed from the design, if necessary, during cell swapping.
The ‘-glob’, ‘-regexp’, and ‘-exact’ sub-options are also
available for this option, with the same usage as for the ‘decap cells’ option (default - no decap cells are removed).
? -include_clock ?
Allows clock elements to be included in cell swapping.
? [ -inst_file <filename> | -inst { inst1 inst2 ... } ] ?
-inst_file <file_name> : defines a file containing an exclusive
list of instances as targets for swapping.
-inst { inst1 inst2 ... } : specifies an exclusive list of instances as
targets for swapping
? search_only
Only generates a file with a list of candidate instances for
swapping based on selection criteria; no swapping is
performed (default file name: cell_swap_<time>.list. If you
want to change the filename, use the ‘-inst_file <filename>’
option to specify).
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
RedHawk User Manual
| 168
[ -eff_vdd_tw | -min_vdd_tw | -max_vdd_tw | -min_vdd_all ]
Specifies which type of DvD criteria is used to select candidate
hot instances to investigate for decap swapping. Instances
and associated criteria values are defined in the adsRpt/
Dynamic/<design>.dvd lookup table. The criteria are:
eff_vdd_tw : use average effective voltage (Vdd-Vss) over
the timing window to define swapping targets (default)
max_vdd_tw : use maximum effective voltage (Vdd-Vss)
over the timing window to define swapping targets
min_vdd_tw : use minimum effective voltage (Vdd-Vss)
over the timing window to define swapping targets
min_vdd_all : use minimum effective voltage (Vdd-Vss)
over the clock cycle to define swapping targets
? -report ?
Generates text table of the last cell swapping results in file
cell_swap.rpt, showing instances swapped and the change in
voltage drop.
cell swap
(cont.)
? -plot ?
Generates a histogram of the last cell swapping results in file
cell_swap.hist, showing the number of instances vs. the
change in the criteria DvD value selected.
?-swappable_cells {cell1 cell2 ...} ?
Lists master cells available for swapping.
? -ff_only ?
Specifies that only instances directly connected to a flip-flop
input should be moved. Used in conjunction with the ‘swappable_cell’ option, only listed cells that connect to a
flipflop input are swapped to improve their voltage drop.
? -pre_proc ?
Specifies that hot instances in the row with the highest
average voltage drop have their cells swapped first. Then hot
instances in rows with the next highest average voltage drop
are done in order.
? -to_scan_in_only <cell1 cell2 ...> ?
Specifies that only instances that are attached to scan-in pins
of specified scan cells are included in cell swapping.
? -include_thtl ?
Specifies that instances with tie-high and tie-low pins can be
included in cell swapping. By default these cells are excluded.
? -drc_m2 ?
Specifies that any instances that have metal2 features cannot
be swapped to a target area with metal2 access.
ANSYS INC - Apache Design Business Unit
CHAPTER 7 — Fixing and Optimizing Grid and Power Performance
Fixing and Optimization Command Reference
RedHawk User Manual
| 169
Supplementary Voltage Drop Fixing Commands
Table 7-3
Route Fix Commands
Command
Description
Finds the shortest DRC-clean legal route for a new power/ground
wire and vias from the specified target “from” point (or area) and
layer to another specified target “to” point (or area) and layer.
Associated GSR keywords: None
Options
route fix
[-from { x1 y1 x2 y2 <layer>} | -from_pt { xf yf <layer>} ]
Specifies the origin area or x,y point and layer for new pwr/
grnd routing.
[ -to {x1 y1 x2 y2 <layer>} | -to_pt { xt yt <layer>} ]
Specifies the terminating area or x,y point and layer for new
pwr/grnd routing.
-width <routing-width>
Specifies the width of the new pwr/grnd routing in um.
GSR Keywords Supporting FAO Functionality
Special GSR keywords modify the function of the ‘mesh optimize’, ‘mesh fix’, ‘route fix’,
‘decap advise’/-place’, and ‘cell swap’ commands, and are described in detail in the
section "FAO General Keywords", page C-684, section "Grid Fixing and Optimization
Keywords", page C-687, and section "Decap Optimization Keywords", page C-691.
Command and GSR Keyword Syntax Conventions
<
[
?
{
{
+
x
a
x
a
x
-
>
|
?
b
}
*
b | c ]
c }
...
/
x is a variable name or value to be specified
one of a, b, or c must be selected
x is an optional parameter
a, b and c parameters all must be specified
an element such as {x} can be added
standard arithmetic operators for add, subtract,
multiply, divide
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Introduction
RedHawk User Manual
| 170
Chapter 8
Analysis of DvD and Cross-coupling
Noise Impacts on Timing
Introduction
As designs moved below 65 nm scale, smaller geometries and higher densities increased
crosstalk noise and coupling delay, adversely affecting the chip’s overall timing. Today,
most existing timing analysis tools are based on static analysis at the cell-level (or gatelevel) and only consider cell delay and coupling delay in timing analysis.
However, as more designs use 32 nm scale technologies and beyond, the traditional
methods of static analysis are no longer adequate, especially when considering the
impact of power integrity on timing. It is becoming a necessity to consider dynamic
voltage drop and ground bounce caused by simultaneous switching of core, I/O, and
memories in analyzing and closing overall chip timing.
Typically, design tools rely on cell-based abstraction, coarse table-lookup model, and
semi-accurate fast SPICE engines, which can result in inaccurate, overly constrained,
and marginally guard-banded designs. In reality, sub-90nm designs require a solution that
can concurrently analyze all the nanometer scale physical effects found in real silicon,
such as coupling capacitance and dynamic voltage drop, or risk significant timing errors or
noise problems close to tapeout.
Impacts on Timing
The waveforms in Figure 8-1 demonstrate the impact of dynamic voltage drop and power/
ground noise on the circuit timing. The waveform labeled “without PI and SI noise” shows
a typical, well-behaved rising waveform.
Figure 8-1
Signal noise (SI) and voltage drop (PI) impact on timing.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Introduction
RedHawk User Manual
| 171
Overview
The RedHawk timing analysis tools can identify and analyze potential signal crosstalk and
timing problems caused by power and ground noise, so that corrections can be made
prior to design signoff. The tools leverage RedHawk, a foundry-certified, sign-off accurate,
full-chip dynamic power integrity solution, and NSPICE, a high capacity, high performance
SPICE simulator, to deliver the most accurate timing analysis solution for designs at 65nm
gate size and below. For jitter analysis, both fast Fullchip and also Spice-based Sign-off
solutions are available.
Timing analysis considers the concurrent effects of signal integrity and dynamic power
integrity on clock tree and critical timing paths, including I/O, IP, and memories. It
accurately computes the gate propagation delay, coupled delays, interconnect delays,
rise time degradation for low supply voltage and cross-talk influence from adjacent wires,
while precisely tracking the signal waveform, cross-talk noise, and glitches. is used close
to sign-off to provide timing results that reflect actual silicon performance and quickly
reach noise closure. Figure 8-2 shows the overall design flow.
By default in the RedHawk integrated flow it concurrently analyzes the effects of power
integrity (PI) and signal integrity (SI) to consider coupling RLC networks, aggressor
drivers and receivers, worst/best case coupling delays, aggressor vector sensitization and
alignment, timing window filtering, and power/ground dynamic voltage drop. Signal
integrity and power integrity analyses also can be performed independently if desired.
Timing analysis is most conveniently run within the RedHawk environment, either using
the TCL command line or the GUI menus. Many types of useful graphical results are then
available, in the form of waveforms, clock trees and jitter. However, if the necessary input
files have been generated in a previous RedHawk run, timing analysis can be run in batch
mode from a TCL command line, and the results evaluated using text file outputs.
This chapter describes the procedure for running RedHawk impact on timing analysis.
Design
Flow
Design
Flow
RTL / Block Power
Estimation
RedHawk-3DX
RedHawk-EV
Dynamic Voltage Drop Analysis
Partition / Floorplan
Initial Cell Placement
Placement & Routing
PsiWinder
Timing
Analysis
• Clock Jitter Analysis
• Clock Tree Analysis
• Critical Path Analysis
Timing / Sign-off
Figure 8-2
• Concurrent PI/SI Signoff
RedHawk timing analysis design flow.
The following types of RedHawk circuit timing analyses are available to help avoid
adverse timing effects and functional failures in a design:
• Clock tree analysis, which includes both jitter and skew analysis
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Introduction
RedHawk User Manual
| 172
• Critical path delay analysis
These features are discussed in more detail in the following sections.
PJX Clock Tree Jitter Analysis
Clock signal quality is essential for timing closure in high frequency designs. Clock tree
jitter in particular can have serious impacts on clock signal arrival time, which usually
causes timing failure. Clock tree jitter can be caused by several noise sources, such as
crosstalk noise and simultaneous switching noise. RedHawk performs multiple-cycle
Spice simulation to accurately predict clock tree jitter results. Designers can verify that the
jitter in their clock networks in the presence of Vdd/Gnd noise is within specification and
that the duty cycle variation has been accounted for.
RedHawk provides two Clock Jitter Solutions--a High Capacity Fullchip level ATE-based
Jitter Solution and a Sign-off accurate NX-based Jitter Solution. The two types of
RedHawk clock tree jitter analysis are described in Figure 8-3. You can perform separate
fullchip and sign-off jitter analyses.
Figure 8-3
RedHawk PJX Clock Tree Jitter Analysis
The work flow for integrated RedHawk PJX Clock Tree Jitter Analysis is as follows:
Setup Design -> Power Calculation -> Extraction -> DvD Analysis ->
Fullchip Jitter Analysis -> Sign-Off Analysis
Skew Analysis
Optimized clock trees and clock meshes are essential to good digital circuit design,
primarily for clock skew control. RedHawk allows you to easily analyze how cross-talk and
power / ground grid noise affects clock skew. Clock tree and clock mesh design can be
optimized using the high quality SPICE accuracy of RedHawk.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Introduction
RedHawk User Manual
| 173
Analysis Modes
There are four modes available to run clock tree jitter and clock tree skew analyses, as
described below:
• Basic analysis mode - uses ideal voltages to evaluate clock tree and clock mesh
parameters with no capacitance coupling analysis. This mode is typically used to verify
timing results with those from PrimeTime. Supports analysis of multiple Vdd/Vss
designs.
• Signal integrity analysis only mode - uses ideal voltages to perform effective coupling
analysis between key aggressor and victim nets-- signal and/or clock nets that have
slew, delay and slack adversely affected by capacitive coupling. No dynamic voltage
drop analysis is necessary.
• Power integrity analysis only mode - evaluates the adverse effects of dynamic voltage
drop on slew, delay and slack for signal and/or clock nets. No capacitive coupling
analysis is performed.
• Simultaneous power and signal integrity analysis mode - evaluates the adverse effects
on signal and/or clock nets of simultaneous impacts of both capacitive coupling and
dynamic voltage drop.
For clock tree jitter analysis, power integrity analysis is always considered. You can
choose to also consider signal integrity analysis with the appropriate setup conditions.
Timing Analysis Applications
Accurate timing analysis is useful in a nanometer scale IC design flow, where a
successful silicon design depends upon catching problems related to power and timing
before manufacturing. This is particularly valuable when a design faces the challenges of
dynamic voltage drop, ground bounce and cross-talk noise. The following are typical
applications that can be very useful.
False Violation Filter
Many design houses use a cell-based methodology to verify timing and signal integrity.
The setup time check is vital to final silicon performance. Furthermore, the hold time and
peak noise checks find potential errors that can cause the chip to fail functionally. Cell
libraries are built to check each cell type, but are not accurate enough for each cell
instance. Characterization of standard cell libraries is deliberately conservative. The
conservativeness of cell library methodology may create many unwanted violations.
These false violations add an extra burden on the designers. SPICE-accurate results can
serve as a golden reference for identifying real violations. As a result, the designers can
focus on fixing the real problems.
Design Margin Adjustment
A design specification usually requires that additional guard-band be added to account for
the inaccuracies caused by either timing/signal integrity tools or model abstraction. With
timing analysis, the designer may be able to reduce or eliminate the guard band
requirements. The designer can rely on the SPICE accuracy as the tape-out reference.
Methodology Calibration
Some design houses use cell-based tools for low turn-around time and transistor-level
tools for accuracy. Because RedHawk is a SPICE-based tool, it can pinpoint the sources
of inaccuracy from cell modeling and library characterization and improve the overall
accuracy of the design flow. In this way, even though the design project still uses a cellANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Fullchip Clock Tree Jitter Analysis
RedHawk User Manual
| 174
based design flow, the transistor-level accuracy will guide the design into silicon
convergence.
Case Analysis for Stress Test
Occasionally, the designer wants to ensure the reliability of the design by running stress
tests. Their attention usually focuses on critical design spots such as bus design, I/O
pads, long wire nets, and clock nets. This tool is for discovering and analyzing the effects
of coupled delay and noise on vulnerable signal nets, with voltage drop and ground
bounce on power/ground nets.
Silicon Correlation
The designer can test different process corner scenarios, supply voltages, and
temperatures to correlate the design with real silicon. A good correlation will help the
designer or manufacturer to optimize yields under various process conditions. After
refinement of the critical paths, the design can be fine-tuned for volume production with
good manufacturing yields.
LEF-SPICE Pin Mapping
Designers can map LEF pin names to Spice pin names if they are different, using the
timing analysis configuration file keyword LEF2SPICE_PIN_MAPPING, which provides
mapping between LEF pin names and SPICE pin names. The syntax is as follows:
LEF2SPICE_PIN_MAPPING {
<LEF_pin_name> <Spice pin_name>
...
}
PJX Fullchip Clock Tree Jitter Analysis
Overview
PJX-full-chip is a fast, full-chip analysis tool, which provides jitter-related voltage drop
results in the context of impact on chip timing.
PJX calculates voltage-only induced jitter in order to identify grid defects/weaknesses that
cause jitter. The focus is on voltage induction and not SI (Signal Integrity) effects.
PJX is an STA-based tool for preliminary high level analysis and not simulation. It is not a
replacement for SPICE-based jitter calculation that includes PI, SI and other factors
causing timing jitter.
Flow and Interface Description
PJX-full-chip analysis performs N cycles of timing computation using the STA-based builtin multi-threaded Apache Timing Engine (ATE). In each cycle it uses RedHawk per
instance cycle voltage and APL models to compute voltage derated delays. It then
performs timing analysis to calculate clock arrival time at leaf pins (network endpoints) for
all clocks. Jitter at clock endpoints is based on the differences among calculated N arrival
times.
PJX-full-chip offers a GUI to analyze timing impact result for jittery clocks, endpoints,
path-traces, bottleneck regions and instances .
The PJX-full-chip GUI is integrated into the RedHawk GUI to allow overlaying jittery path
traces (as flylines) on various RedHawk colormaps, to assist in diagnosis through visual
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Fullchip Clock Tree Jitter Analysis
RedHawk User Manual
| 175
analysis of grid weaknesses that can cause jitter, such as low decaps values around
jittery clock elements, or portions of traces.
Input Data Preparation and Setup
The following RedHawk inputs and settings ensure that PJX-full-chip analysis has
sufficient accuracy and coverage :
• APL files should be specified in the GSR file, and should be complete so as to cover
all clock network cells. PJX uses APL info for cell delay derating.
• RedHawk DvD analysis should be performed in multi-cycle mode, so simulation time
should be sufficiently large to let each clock run for multiple cycles. Specify the option
“-mcycle” with the “perform analysis” command for vectorless dynamic analysis. No
such option is required for VCD-based dynamic analysis or for static analysis.
• The STA timing file used in RedHawk should be consistent with the DEF netlist and
SDC file. If the STA file comes from an external source that uses a Verilog netlist, you
must ensure the consistency of that Verilog netlist. Otherwise, set the GSR keyword
‘ENABLE_ATE 1’ to allow RedHawk to generate its STA (timing) file using ATE, which
is consistent with the DEF and SDC data that is being used for RedHawk and PJX.
• Specify the dynamic simulation time range that experiences jitter.
• Specify enough presim time to avoid transient disturbances in the initial cycles to
appear as a cause of jitter.
• PJX requires a redhawk_pjx license.
• Specify required SDC files using the following GSR keyword :
ATE_CONSTRAINT_FILES {
<SDC_file1>
<SDC_file2>
...}
}
Note: the SDC files should be consistent with the DEF netlist specified in the GSR,
otherwise mismatch-related errors are reported in the “Load Timing Constraint”
section in the fullchipjitter.log file, which can impact PJX-full-chip results.
• If the imported RedHawk DB lacks an SDC specification, then SDC files can be
specified on-the-fly on the RedHawk command line before launching PJX, as follows :
gsr set ATE_CONSTRAINT_FILES { /path/to/sdc/file.sdc }
Running PJX Fullchip Jitter Analysis
PJX full-chip analysis can be launched in the RedHawk GUI by clicking :
Tools / Clock Jitter / Fullchip Jitter / Analyze
Or you can add the command “perform jitter -fullchip” in the RedHawk command file after
completion of multi-cycle DvD Analysis or Static Analysis.
Analyzing Results
All PJX full-chip results can be viewed in the PJX GUI, which is integrated with the
RedHawk GUI under the menu command Tools -> Clock Jitter ->Fullchip Jitter. The
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 176
integrated GUI allows display of fly-lines showing worst jitter path traces overlaid on
relevant RedHawk colormaps, such as DvD and decap, to give a global perspective and
visual orientation of key jitter-related issues over the whole chip.
Click on Tools -> Clock Jitter ->Fullchip Jitter ->Long Term Jitter Report to display all
clocks, rank ordered on the basis of worst long-term jitter (% of period), observed in their
respective domains. Long Term Jitter at a clock destination pin (end-point) is defined as
the difference between the earliest-arrival-time and latest-arrival-time among the recorded
arrival times of N cycles.
In the Long Term Jitter Report, for a selected entry the following results can be displayed:
Show Summary : brings up the summary report of the worst 1000 endpoints (leaf
pins) of the selected clock. In this report, Show Browser displays the
schematic connectivity from clock sources to the selected endpoint.
“Highlight” in the “Show Browser” report displays the flyline of the path trace
to the selected endpoint. “Show Trace” shows the path trace from source to
endpoint with all relevant details, such as the earliest and latest cycles,
cycles voltages for instances on the path, absolute jitter, and jitter as a
percent of period.
Show Detail : brings up the detail report with jitter information for all elements in
the entire network of the selected clock. You can use the search box to get
the elements of interest and other features such as “Show Browser”, and
highlighting and zooming instances.
Show Browser : brings up a schematic view of the entire network of selected
clocks. Clicking Highlight on this report displays the entire network as
flylines in the RedHawk GUI.
You can use various RedHawk maps and other GUI commands to diagnose grid defects
and weaknesses that caused each path-trace (flyline) to become a worst jitter victim.
Similarly, Tools -> Clock Jitter ->Fullchip Jitter -> Long Term Cycle-2-Cycle Jitter
Report displays results in similar format, of jitter type “Long-Term Cycle-2-Cycle”, Long
Term Cycle-2-Cycle Jitter at a destination pin is defined as the worst (max) jitter among
the differences of arrival times of consecutive cycles.
The file adsRpt/fullchipjitter.log records the PJX-full-chip analysis. The errors and
warnings recorded from PJX-full-chip analysis are captured in files adsRpt/
fullchipjitter.err and adsRpt/fullchipjitter.warn respectively.
PJX Clock Tree Jitter Sign-Off Analysis
Overview
After successfully running DvD analysis in RedHawk, you can perform clock tree jitter
analysis.
Required Inputs for Clock Tree Jitter Sign-Off Analysis
The specific input data files that are needed are listed below, along with their purpose and
the operations performed on them.
1.
SPICE cell netlist file (CIR) for each gate in the cell library
• Defines voltage levels for I/O pad cells.
Jitter analysis matches the SPICE cell netlists to cell instances and connects
instance power/ground ports to local voltage sources.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 177
2.
SPICE technology library file (SPICE format)
• Defines transistor models
• Defines process corners for SPICE simulation
• Defines On-chip process variation (OCV) for Spice simulation.
• Specifies process/voltage/temperature (PVT) values for process corner case
simulation
3.
Additional timing constraints, using the configuration file keyword
DEFINE_DESIGN_CONSTRAINTS (section
"DEFINE_DESIGN_CONSTRAINTS", page 8-208).
Input Data Preparation
The following sections describe the preparation steps needed for each type of required
input prior to running an analysis.
Spice Cell Netlist (.CIR) File
RedHawk reads the Spice netlist (defined in the SPICE_NETLIST configuration file
keyword) of each cell from a specified file for later Spice simulation. The Spice cell file
should contain all necessary cells under analysis. You can also use the ‘.include’
directive to include all related files, but only the full file path name is accepted. For
example:
.include ‘/projects/AABB15/src/abcd18_3.cir’
.include ‘/projects/AABB15/src/abcd18io_4.cir’
Each cell found in the Spice netlist should have a corresponding Spice sub-circuit netlist
to describe its electrical model in detail. Sub-circuit calls—that is, X-statements—inside
the cell sub-circuit construct are allowed. The cell netlist is complete as long as all subcircuit calls can be found.
When RedHawk matches cell sub-circuits into netlist cell instantiations, the sub-circuit
ports will connect to the nets in the design by name. In some cases, power and ground
are present as cell sub-circuit ports. You may want to keep the same name for this kind of
global power and ground nets for simulation. However, if the given subcircuit port is called
‘gnd’, then execute the following to rename it (since GND is the global virtual ground node
defined in Spice language):
SPICE_CELL_TOKEN_RENAME gnd vss
The consistency of sub-circuit ports and design cell port instantiations is checked. If there
are any mismatches, a warning is issued in the run log.
SPICE Technology Library Data
Spice technology library data for Spice device models are included by using the
DEVICE_MODEL_LIBRARY keyword in the jitter configuration file.
A few examples of how to specify Spice technology library paths follow:
INCLUDE /usr/cadtool/technology/logic018param.l
DEVICE_MODEL_LIBRARY /usr/cadtool/technology/logic018io.l SS
DEVICE_MODEL_LIBRARY ‘/projects/BCM7315B0/technology/logic018.l’ SS
The last statement above uses single quotations to preserve the upper-case characters in
the names.
Additional Timing Constraints
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 178
Additional constraints may be needed for the information missing in the input data.
Specify design constraints in the DEFINE_DESIGN_CONSTRAINTS keyword section of
the timing configuration file (section "DEFINE_DESIGN_CONSTRAINTS", page 8-208).
For the certain special cases you need to set constraint inputs as follows:
1.
If external loading is missing in the given parasitic SPF file. For example, the
output node of the critical path is a chip/block boundary port. Add the loading
information to the configuration file, as follows:
set_load 4000 “sdram_dqm[7]”
set_load 3500 “sdram_cke”
The additional loading is specified in femtoFarads (ff).
2.
If net resistance is missing in the given parasitic SPF file. Add the net resistance
information (Ohms) and port or net name in the configuration file as follows:
set_resistance 100 “net_clock”
3.
If you want to control the input state of instances, then add the input logic state
setting, as in the following example:
set_logic_one/ set_logic_zero “mux_1/sel”
The logic state of the specified port is set to one/zero when performing vector
sensitization.
4.
If you want to analyze the clock tree through a divider circuit, then add the clock
divider pin name in the constraint, as in the following example:
set_clock_divider div_reg:q
5.
If you want to stop clock tree/jitter analysis at specified pins, then add the selected
clock leaf pins in the constraints, as in the following example:
set_clock_leaf clk_mux:i0
6.
If you want to exclude a subset of a tree below a specified pin in clock tree or jitter
analysis, add the excluded pin in the constraints, as in the following example:
exclude_clock_leaf clk_reg:d
Clock Tree Jitter Analysis Setup Procedure
Use the following steps to set up and run clock tree jitter analysis:
1.
RedHawk Data Preparation
a. Most required files should already have been prepared for DvD analysis.
b. Prepare and use package netlist or package lumped RLC model in
analysis.
c. Set up GSR keywords as described below:
• Jitter awareness enable
JITTER_ENABLE 1
This is a required keyword to make RedHawk flow “jitter-aware”. Dynamic
simulation is optimized to extract only the clock instance waveform.
• Cycle selection
CYCLE_SELECTION [ WORST_JITTER_CYCLE |WORST_PERIOD_JITTER_CYCLE
| WORST_MIN_PERIOD_JITTER_CYCLE | WORST_MAX_PERIOD_JITTER_CYCLE
| WORST_C2C_JITTER_CYCLE ]
where
WORST_JITTER_CYCLE : selects cycles for both worst period jitter and
cycle-to-cycle jitter analysis
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 179
WORST_PERIOD_JITTER_CYCLE: selects cycles for worst period jitter
analysis
WORST_MIN_PERIOD_JITTER_CYCLE: selects cycles for jitter analysis
to get minimum period
WORST_MAX_PERIOD_JITTER_CYCLE: selects cycles for jitter analysis
to get maximum period
WORST_C2C_JITTER_CYCLE: selects cycles for worst case cycle-tocycle jitter analysis
• Using the power histogram to select the most critical jitter cycles
IGNORE_JITTER_FASTSIM 1
The default is 0/Off, meaning “do not ignore simulation-based cycle
selection”.
d. In RedHawk analysis, provide a SPEF file with coupling capacitance data in
order to perform cross-talk analysis.
2.
Selecting Clock Roots
After RedHawk dynamic analysis, use the following RedHawk TCL command to
generate the clock network summary.
report clocknetwork -o <output_filename>
The summary includes clock tree instance and leaf information on a clock domain
basis, and also a summary table in the log file. This also shows clock root, domain
frequency, buffer/gate count, leaf count, maximum level, minimum level, and
effective Vdd information for each clock domain. Command syntax help can be
obtained by requesting it on the command line, as shown in Figure 8-4.
Figure 8-4
Log window and clocknetwork command help
The clock network summary can also be invoked using the menu command
Tools -> Clock Jitter -> Clock Network Summary
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 180
as shown in Figure 8-5.
Figure 8-5
Clock Network Summary
Based on the clock network summary report, you may select which clock roots
should be used for jitter analysis purposes, depending on the DvD values for each
clock root, as shown in Figure 8-6.
Figure 8-6
3.
Clock root selection dialog
Jitter analysis preparation. Set up the configuration file, to describe the Spice cell
netlist, Spice technology data, additional timing constraints, and other variables.
The timing configuration file must have the following keywords:
• SPICE_NETLIST/SPICE_SUBCKT_DIR
• DEVICE_MODEL_LIBRARY/INCLUDE
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
•
RedHawk User Manual
| 181
CLOCK_SOURCES (if not specified from the TCL command line)
Other optional keywords that can be used to optimize jitter analysis performance,
with little reduction in accuracy, are:
• CLOCK_TREE_MAX_LEVEL
• DEFINE_CASE_ANALYSIS
•
When set, reduces signal crosstalk pessimism (make less likely to fail) using
options 'pgvolt', 'clock_jitter_worst' and 'clock_jitter_best' (default
PGVOLT).
EXTEND_CYCLE_SELECTION [ -1 | 0 | 1 ]
Manages cycle selection for sets of non-consecutive cycles, as follows:
-1 : removes non-consecutive cycles
0 : keeps all selected cycles, consecutive or non-consecutive
1 : adds more cycles to make cycles consecutive
For example, if the specified cycles are 10 15 16 17,
- setting 'EXTEND_CYCLE_SELECTION -1' means cycle 10 is discarded,
- setting 'EXTEND_CYCLE_SELECTION 1' means cycles 10 11 12 or 9
10 11 are added, based on worst-best-worst/best-worst-best ranking
pattern
•
•
•
•
- setting 'EXTEND_CYCLE_SELECTION 0' retains cycles as specified (10
15 16 17)
FALL_SLEW <value>
FALL_SLEW_AGRS <value>
RISE_SLEW <value>
RISE_SLEW_AGRS <value>
•
•
•
The units for the *_SLEW transition time keywords are in ns, so input values
should be greater than 0 and less than or equal to 1.0 ns. If input data is
out of this range, such as a value in ps, an error message is displayed
and processing stops. The default value for all is 0.05 ns.
JITTER_FAST_MODE
JITTER_CUTOFF_FREQ
LEF2SPICE_PIN_MAPPING
•
•
You can map LEF pin names to Spice pin names if they are different using
this keyword, with the syntax:
LEF2SPICE_PIN_MAPPING {
<LEF_pin_name> <Spice pin_name>
...
}
SETTLE_TIME
SETTLE_TIME_RATIO
•
Sets the value of SETTLE_TIME based on the specified clock period ratio.
For example, if SETTLE_TIME_RATIO is set to 0.5, a SETTLE_TIME of
‘0.5*<clock_period>’ is used. This is useful in cases in which multiple
clock frequencies are present in the design. The default value is 0.75.
The syntax is:
SETTLE_TIME_RATIO <value>
STA_SWITCH_TIME_READ [ 0 | 1]
•
If there are switch times missing from the RedHawk DvD waveforms, they
are obtained from the STA file if this keyword is set.
TIMING_WINDOW_OVERLAP_RATIO_THRESHOLD <overlap_factor>'
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
•
RedHawk User Manual
| 182
Controls the selection of aggressor nets based on the Timing Window
overlap ratio, which is the fraction of the TW overlap (0.0-1.0).
DEFINE_DESIGN_CONSTRAINTS
For setting other design constraints, such as defining a divider FF Q-pin as
'set_clock_divider <Q_pin>' .
For a more descriptions of timing configuration file keywords, please refer to
section "Clock Tree Analysis Configuration File Reference", page 8-200.
4.
TW filtering for Jitter Analysis. For jitter analysis with signal integrity, you can
control the aggressor selection for coupling based on TW overlap threshold. By
default all aggressors having any TW overlap with a victim are selected for
coupling, which may increase runtime. The timing configuration file keyword
TIMING_WINDOW_OVERLAP_RATIO_THRESHOLD is available for filtering
coupling calculations based on the amount of timing window overlap of aggressor
and victim. The syntax is:
TIMING_WINDOW_OVERLAP_RATIO_THRESHOLD <value>
For more details, see section
"TIMING_WINDOW_OVERLAP_RATIO_THRESHOLD", page 8-203.
Edge-to-Edge DDR Clock Jitter Measurements
Edge-to-edge jitter is the variation in the delay between a triggering event and a response
event. Edge-to-edge jitter assumes an input signal, and so is only defined for driven
systems. It is an input-referred jitter metric, meaning that the jitter measurement is
referenced to a point on a noise-free input signal, so the reference point is fixed.
Write Mode
For every rise/fall edge of the Reference signal (Clock), the Setup and Hold
measurements are performed to the closest rising or falling edge of the Data signal, as
shown in Figure 8-7. Setup and Hold measurements should be made for every rise/fall
edge of the clock signal, regardless of whether the Data signal rising or falling edge
belongs to another bit cycle. The configuration file syntax is:
DDR_DIFFERENTIAL_JITTER
{
WRITE_PATH ? -idealBitPeriod <bit_period> ?
-clock <clock_pin> -data {<data_pin1> <data_pin2> ... }
}
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
Figure 8-7
RedHawk User Manual
| 183
Edge-to-edge jitter - Write Mode
Read Mode
For each Clock signal, only the rising edge is utilized to capture the Setup/Hold timing
measurements relative to the closest corresponding Data signal rising or falling edge. The
diagram below (Figure 8-8) illustrates the end point timing. The configuration file syntax is:
DDR_DIFFERENTIAL_JITTER
{
READ_PATH ? -idealBitPeriod <bit_period> ?
-clock <clock_pin> -data {<data_pin1> <data_pin2> ... }
}
Figure 8-8
Edge-to-edge jitter - Read Mode
Running Clock Tree Jitter Sign-Off Analysis from the RedHawk GUI
After completing the RedHawk data setup and creating a timing configuration file, the
Clock Tree Jitter Analysis flow can be invoked using the RedHawk Tools menu.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 184
If DvD analysis has not already been performed, clock tree jitter commands on the Tools
menu can be run in the order in which they appear, as follows:
Tools -> Clock Jitter -> Clock Network Summary
Dynamic -> Power -> Calculate/ Import
Network Extraction
Pad, Wirebond and Package Constraints
RedHawk performs either vectorless or VCD-based jitter cycle selection, based on the
STATE_PROPAGATION or VCD_FILE GSR options specified in the GSR.
Clock Jitter Analysis
If DvD analysis has already been performed, then just use this command. RedHawk runs
either vectorless or VCD True Time mode dynamic simulation. Then, multiple-cycle power
ground waveforms are extracted and multiple-cycle Spice simulation is performed to
obtain clock tree jitter results.
Clock Jitter Report
Use this command to check and debug the jitter results and waveforms through the GUI
interface.
Clock Jitter Bottleneck Report
Use the jitter bottleneck ranking report to determine the worst jitter weakness locations.
Fixing jitter on pins with highest rankings maximizes the benefit in reducing the overall
jitter problem.
Running Clock Tree Jitter Sign-off Analysis in Batch Mode
Before performing clock tree jitter analysis in batch mode, do the same setup procedure
as for the GUI invocation, as described previously.
Setup for Batch Mode Invocation
If DvD analysis has not already been performed, for power Integrity only, or for
simultaneous signal integrity and power integrity modes, run RedHawk through the
package setup stage, or load a database saved before dynamic analysis. The set of TCL
commands required to set up a database for power integrity mode is given in the following
example:
import gsr design_dynamic.gsr
setup design
import apl cell.current
import apl -c cell.cdev
perform pwrcalc
perform extraction -power -ground -c
setup pad -power -r 0.010000 -c 0.5
setup pad -ground -r 0.010000 -c 0.5
setup wirebond -power -r 0.245000 -l 1420 -c 5
setup wirebond -ground -r 0.24500 -l 1420 -c 5
setup package -r 0.002 -l 100 -c 5
Jitter Analysis Command Line Invocation
Following is the method of running clock tree jitter analysis in batch mode, relying on
having proper keyword definitions in the timing configuration file. Run through RedHawk
dynamic analysis and then perform clock tree jitter analysis:
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 185
[perform jitter_cycle_select] #Optional to select cycles
perform analysis [options]
perform jitter [options]
show jitter [options]
The full syntax for invoking clock tree jitter is as follows:
perform jitter -config <psi_jitter_config> [-clk_source
<clk_src>]
[-leaf_inst_pin <leaf_inst_pin>][-no_data_check ]
[-mode [ waveform_pg | effVDD | eff_pg ]]
where
waveform_pg : jitter analysis based on the power/ground voltage waveforms from
RedHawk analysis
effVDD :jitter analysis based on the multi-cycle effective Vdd reported by
RedHawk analysis
eff_pg: jitter analysis based on the effective power/ground voltages calculated
In batch mode, you can only specify a single ‘clk_src’ and ‘leaf_inst_pin’.
A sample TCL invocation of clock tree jitter analysis is:
setup design test.gsr
perform pwrcalc
perform extraction -power -ground
perform jitter_cycle_select -type WORST_JITTER_CYCLE -vcd
perform analysis -vcd
perform jitter -config psi.jitter_config
show jitter c2c rise
Also, 'perform jitter' analysis can be run on a post-dynamic RedHawk database, by using
the following commands:
import db post_dynamic.db
perform jitter -config
...
After 'perform jitter' has been successfully completed, you can export the entire database
(including jitter results) with the following command:
export db post_jitter.db
This exported database can be imported to view jitter results, as follows:
import db post_jitter.db
Specifying clock instances
To specify the instances to be simulation, you must first import the DvD analysis
database, then perform the following steps:
1.
Run the TCL command
report clocknetwork -root <root_name> -o <clk_out>
2.
Then manually reduce the clock buffers by editing the <clk_out> file (do not add
new instances).
3.
Specify the edited instance file in the configuration file keyword CLK_INST_FILE
<edited_clk_out>, and ensure that the CLOCK_SOURCES <clock> keyword
specification is the same as the <root_name> specified in the 'report clocknetwork'
command.
4.
Run the TCL command 'perform jitter -config psi.config', and then 'perform jitter'.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 186
Clock Tree Jitter Results
A number of types of graphic displays and output data of jitter results are produced, as
described in the following sections.
Clock Tree Jitter Report
If you perform clock jitter analysis, the command Tools -> Clock Jitter -> Sign-off Jitter
-> Clock Jitter Report creates a clock tree summary table of period jitter data, as well as
cycle-to-cycle jitter data. A sample Clock Jitter Report is shown in Figure 8-9.
Figure 8-9
Clock Tree Jitter Report
The data displayed in the Clock Jitter Report columns are as follows:
• Clock Root - clock tree root pin name
• Leaf Num - number of terminating leafs in the clock tree
• Inst Num - number of instances in the clock tree
• Max P Jitter R - maximum rise period jitter among all leafs
• Max P Jitter F - maximum fall period jitter among all leafs
• Max C-C Jitter R - maximum rise cycle-to-cycle jitter among all leafs
• Max C-C Jitter F- maximum fall cycle-to-cycle jitter among all leafs
• Skew R - difference in longest and shortest rising insertion delay (ps)
• Skew F - difference in longest and shortest falling insertion delay (ps)
• Max Delay R - maximum rising delay in the clock tree, root to leaf (ps)
• Max Delay F - maximum falling delay in the clock tree, root to leaf (ps)
• Min Delay R - minimum rising delay in clock tree, root to leaf (ps)
• Min Delay F - minimum falling delay in clock tree, root to leaf (ps)
Clock Tree Browser Display
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 187
To display the Clock Tree Browser, click on Tools-> Clock Jitter-> Clock Jitter Report.
The ‘Clock Tree Report’ dialog box is displayed. Now click on the Show Browser button
to see the ‘Clock Tree Browser’ dialog box (see Figure 8-10).
Figure 8-10
Clock tree browser display
A maximum of 500 paths can be displayed in the ‘Clock Tree Browser’. Information and
functions on the clock tree schematic viewer is as follows:
• Clock Path Symbol Summary: displays symbols for the Interconnect path (timing arc
between cells), IO path (timing arc inside cell), Highlighted pin (pin selected to obtain
pin information), Common branch (branch common to selected pins), and pins
connecting Selected pin or pins.
• Clock Pin Information: clicking any node on the schematic clock tree path browser
brings up detailed clock pin information, such as Pin Name, Level, Cell Type, Delay
Rise and Fall times, and Slope (transition) Rise and Fall times (ps).
• Highlight button: highlights the entire selected clock path from root to the selected pins
in the GUI design layout window. If multiple pins are selected, the common path will be
highlighted in yellow. See Figure 8-11.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
Figure 8-11
RedHawk User Manual
| 188
Highlighted clock network
• Clear Highlight button: clears highlighted clock paths.
• Zoom to Instance button: highlights and zooms to the selected instance in the GUI
layout window. See Figure 8-12.
Figure 8-12
Zoom to clock instance
• Up button: selects and highlights the next upstream pin in the path displayed in the
schematic viewer. The clock pin information changes accordingly.
• Down button: selects and highlights the next downstream pin along the path in the
schematic viewer. The clock pin information changes accordingly.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 189
• Close button: closes the tree browser.
Clock Tree Jitter Details Report
To obtain additional details on the clock jitter analysis select a clock tree from the ‘Clock
Jitter Report’ window and click on the ‘Show Detail’ button, which displays the ‘Clock Jitter
Details’ window, with detailed results of clock jitter analysis by pin, as shown in Figure 813. All instances and pins in the clock tree are listed, and by selecting them they can be
identified in the design using the ‘Zoom to Inst’ and ‘Highlight Inst’ buttons. You can sort
the list by values in any column by clicking the column header. Default sort order is by rise
transition Vdd voltage (‘VDrop’).
Figure 8-13
Clock Tree Jitter Details display
The data displayed in the Clock Jitter Details window columns, left to right, are:
• Pin Name - name of pin
• Cell Type - master cell name
• Level - number of stages below root
• VDrop (R) - rail voltage of instance at rising switching time (v)
• VDrop (F) - rail voltage of instance at falling switching time (v)
• GBnce (R) - ground voltage of instance at rising switching time (v)
• GBnce (F) - ground voltage of instance at falling switching time (v)
• Delay (R) - delay from root to pin (rising root transition) (ps)
• Delay (F) - delay from root to pin (falling root transition) (ps)
• Slope (R) - rising transition time at pin (ps)
• Slope (F) - falling transition time at pin (ps)
• P Jitter (R): period jitter at pin when root transition is rising
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 190
• P Jitter (F): period jitter at pin when root transition is rising
• C-C Jitter (R): cycle-to-cycle jitter at pin when root transition is rising
• C-C Jitter (F): cycle-to-cycle jitter at pin when root transition is falling
Features below the ‘Clock Jitter Details’ list assist in reducing and sorting items on the list:
• Type button: specifies a set of sorting categories for the list: Whole Tree, Pin Name,
Cell Type, Level, Leaf, or Non-leaf. For anything but Whole Tree, Leaf and Non-leaf, a
name fitting the Type selected must be typed into the adjacent box.
• Search button: allows you to sort the whole tree and display a smaller list of items
• Waveform selection button: selects ‘rising’ or ‘falling’ waveforms to plot
• Plot button: plots several waveforms associated with the instance selected. See
description in the following section.
• Select All: selects all items in the list
• Clear Selected: clears all selected items in the list
Along the bottom of the ‘Clock Jitter Details’ dialog are additional function buttons:
• Show Browser button: select one or more pins in the Clock Tree Details list and click
on the ‘Show Browser’ button to display the paths from root to the selected pins in a
schematic viewer. This display is described in the section "Clock Tree Browser
Display", page 8-187.
• Zoom to Instance button: zooms GUI display to the instances selected
• Highlight Instances button: after selecting one or more pins on the list, click on the
‘Highlight Instances’ button to highlight the instances in the GUI.
• Highlight tree: highlights selected portion of clock tree in GUI display
• Clear Highlight button: clears all highlighted objects in the GUI
Edge-to-edge DDR Clock Tree Jitter Reports
Report 1: Edge-to-edge jitter report
After DDR clock jitter analysis, edge-to-edge jitter results are available in the file adsRpt/
Jitter/edge_to_edge.jitter. The report summarizes the edge-to-edge relative jitter
between the Clock and Data path timing analysis, as shown in the example format below.
This measurement should be captured at the logical end points of the Clock and Data
logical paths.
# CLOCK : <clock pin name>
# DATA_1 : <data pin name>
# DATA_2 : ...
# ...
# Ideal Bit Period : <ideal bit period>
CLOCK
DATA_1
DATA_2
Rise Edge No
Setup Time (ps)
Hold Time (ps)
Setup Time (ps)
Hold Time (ps)
..
1
…
…
…
…
..
2
…
…
…
…
..
Min tDS/tDH(ps)
<min setup time>
<min hold time>
<min setup time>
<min hold time>
..
Edge-to-edge jitter
(ps)
<jitter>
ANSYS INC - Apache Design Business Unit
<jitter>
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 191
Report 2: Periodic DDR clock jitter report
A quick summary of the period and cycle-to-cycle jitter is reported in the adsRpt/Jitter/
tree_*_pi/peak_to_peak.jitter file for each instance along the path being measured. The
instance pins are reported in sequential order from the beginning of the logical path to the
end of the logical path. The report format is shown below:
Period Jitter (ps)
Max
Cycle-to_cycle Jitter (ps)
Min
Rise / Fall
Max
Rise / Fall
Rise / Fall
Min
Rise / Fall
Peak-to_peak Jitter (ps)
Pin Name
Period
Jitter
..
Cycle-toCycle Jitter
..
Waveform Plots
To plot waveforms, after selecting a pin on the clock jitter list, click the Plot button in the
‘Clock Tree Browser’ dialog box and the waveform plot is displayed (see Figure 8-14).
You can see multiple cycles of clock signal waveforms at the selected points. The
difference in time between the earliest and latest transitions is the clock jitter.
Figure 8-14
Plot waveform display
Examples of the rising and falling waveform jitter measurements are given in Figure 8-15
and Figure 8-16:
• signal waveforms for cycles 1, 2, 3
• power waveforms for cycles 1, 2, 3
• ground waveforms for cycles 1, 2, 3
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 192
Jitter = 774.150 ps
Figure 8-15
Jitter Rise Waveforms
Jitter = 963.263 ps
Figure 8-16
Jitter Fall Waveforms
Clock Jitter Bottleneck Report
Executing the menu command Tools -> Clock Jitter -> Sign-off jitter -> Clock Jitter
Bottleneck Report creates a ranking table displaying the worst jitter weakness locations.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 193
Fixing jitter on pins with the highest rankings maximizes the reduction in the overall jitter
problem in the design. A sample Jitter Bottleneck Report is shown in Figure 8-18.
Clock Jitter Report
Jitter BottleNeck Report
Figure 8-17
Jitter Bottleneck Report
• Clock tree jitter bottleneck report - Click on Tools-> Clock Jitter-> Sign-off Jitter ->
Clock Jitter Bottleneck Report. The ‘Jitter Bottleneck Report’ dialog box is
displayed. (see Figure 8-18).
Figure 8-18
Clock Jitter Bottleneck Report
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 194
Pin timing parameters can be sorted by any header criteria by clicking on the column
header. The parameter values shown on the Clock Jitter Bottleneck Report are:
No: ranking order based on the sorting criteria chosen
Max Delay: maximum rising or falling transition delay from driver to pin for
multiple cycles
Min Delay: minimum rising or falling transition delay from driver to pin for multiple
cycles
Delay Diff: difference between maximum and minimum delay at the pin
DS Leaf Jitter: sum of the jitter at all leafs below the pin
P Jitter (R): period jitter at pin when root transition is rising
P Jitter (F): period jitter at pin when root transition is falling
C-C Jitter (R): cycle-to-cycle jitter at pin when root transition is rising
C-C Jitter (F): cycle-to-cycle jitter at pin when root transition is falling
Level: the clock tree level from root
Leaf #: the number of leafs below the pin in the tree
Pin Name: instance pin name
Buttons at the bottom of the Jitter Bottleneck report are:
Reset to Default Order: resets ranking list to default sorting order (considering
both highest delay difference between pin maximum and pin minimum delay
and downstream leaf jitter)
Go To Location: highlights and zooms to selected location on design. If selected,
highlights each new location selected on the list.
Up: selects jitter bottleneck location above the one presently selected.
Down: selects jitter bottleneck location below the one presently selected
Previous 1000: selects the previous 1000 worst case pins in the design, based on
the sorting criteria selected
Next 1000: selects the next 1000 worst case pins in the design, based on the
sorting criteria selected
Jitter Color Map
Selecting the menu command View -> Clock Jitter Map -> allows you to choose the type
of jitter map data to display. The choices are:
• Rise Period Jitter - displays period jitter at pin when root transition is rising. Click on
the ‘Set Color Range’ button on the RedHawk ‘Configuration’ palette to see the
meaning of the colors, as a percentage of the maximum jitter in the design.
• Fall Period Jitter - displays period jitter at pin when root transition is falling
• Rise C-to-C Jitter - displays cycle-to-cycle jitter at pin when root transition is rising
• Fall C-to-C Jitter - displays cycle-to-cycle jitter at pin when root transition is falling
A jitter colormap can be displayed using the following TCL commands:
show jitter [period | c2c] [rise | fall]
One of each of the two options must be chosen.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 195
Period Jitter Colormaps
Figure 8-19
Period jitter colormaps
• Period jitter instance colormaps - Click on View->Clock Jitter Map->Rise/Fall Period
Jitter. The selected colormap is displayed (see Figure 8-19). This can also be
displayed using the TCL ‘show jitter’ command.
Cycle-to-cycle Jitter Colormaps
Figure 8-20
Instance cycle-to-cycle jitter colormaps
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
PJX Clock Tree Jitter Sign-Off Analysis
RedHawk User Manual
| 196
• Instance cycle-to-cycle jitter colormaps - Click on View->Clock Jitter Map->Rise/Fall
C-to-C Jitter. The selected colormap is displayed (see Figure 8-20). This can also be
displayed using the TCL ‘show jitter’ command.
Text Reports
Sign-off clock tree jitter analysis produces the following files, which are written into the
directory ‘adsRpt/Jitter ’, as shown in the directory structure of Figure 8-21 below. The
jitter.log, jitter.err and, and jitter.warn files are updated dynamically to provide
intermediate results during a run. Each clock tree root is saved to the sub-directory under
‘adsRpt/Jitter ’. The subdirectories are labeled ‘tree_1_pi’, ‘tree_2_pi’, and so on, for
clock tree jitter analysis. All the temporary files created during jitter analysis go to
the.apache/jitter directory.
-------------------------------------------------------------------( Jitter analysis outputs data under the RedHawk run directory )
|___adsRpt/Jitter
|___ jitter.log
( complete jitter analysis log file )
|___ jitter.err
( complete jitter analysis error file )
|___ jitter.warn
( complete jitter analysis warning file )
|___ tree_ id_map ( map b/w tree_<id>_<suffix> dir and clock tree roots )
|___ tree_<id>_<suffix> ( <suffix> is one of: pi, pisi )
|___ tree.sdf
( sdf format output )
|___ tree.skw
(delay, skew summary report )
|___ tree.leaf
( leaf summary report and histogram)
|___ tree.jitter
( period and cycle2cycle jitter summary report )
|___ jitter.bottleneck (jitter bottleneck summary report )
|___ tree.jitter_leaf cycle2cycle jitter summary report and histogram )
|___ tree.jitter_detail (long term jitter summary report )
|___ jitter.wfm
...
(waveform and duty cycle report )
|___DomainRpt/
(duplicate results organized by sub-tree)
|___subtree_1/
(sub-domain clock tree reports)
|___subtree.skw
|___subtree.leaf
|___subtree.jitter
|___subtree.bottleneck
|___subtree_2/
...
Figure 8-21
Timing analysis directory structure - jitter
To turn off generation of the additional DomainRpt directory and subtree files, use the
following configuration file keyword setting:
CLOCKTREE_DOMAIN_SPLIT_REPORT 0
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Skew Analysis
RedHawk User Manual
| 197
Clock Tree Skew Analysis
Overview
During clock skew analysis, RedHawk computes gate propagation delays, interconnect
delays, and slew, and reports rise and fall skew values for the clock tree. The results
reflect actual silicon performance related to the impact of DvD on timing, and allow quick
noise-aware timing closure.
Required Inputs and Data Preparation
Required inputs and data preparation are the same as for clock tree jitter analysis. See
section "Required Inputs for Clock Tree Jitter Sign-Off Analysis", page 8-176 and section
"Input Data Preparation", page 8-177.
Procedure for Clock Tree Skew Analysis
Running Clock Tree Skew Analysis from the RedHawk GUI
To enable analysis of crosstalk impacts, set 'SIGNAL_INTEGRITY 1' in the timing
configuration file.
To use the GUI menu commands, after completing the setup procedures for a DvD run, or
loading an appropriate RedHawk database:
1.
Execute the GUI command Timing-> Sign-off Clock Tree-> Analysis to perform
the analysis. A ‘Clock Tree Set up’ dialog box is displayed to specify the ‘config file
Name'.
2.
Insert the appropriate configuration file name, and click on Run.
Running Clock Tree Skew Analysis in Batch Mode
Following is the method of running clock tree skew analysis in batch mode, relying on
proper keyword definitions in the timing configuration file. The full TCL syntax is:
perform clockskew -config <config_file>
?-clk_source <clk_src>? ?-leaf_inst_pin <leaf_inst_pin> ?
?-no_data_check? ?-mode [basic | static | dynamic]?
As sample TCL invocation of clock tree skew is:
setup design test.gsr
...
perform clockskew -config psi.skew_config
Following are the details for running batch mode skew analysis, depending on the
selected analysis mode.
Basic Analysis Mode
The basic analysis mode can be performed right after 'setup design' in RedHawk, using
the command
perform clockskew -config <config_file> -mode basic
Note that the above command overwrites 'POWER_INTEGRITY 1' in the timing
configuration file.
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Skew Analysis
RedHawk User Manual
| 198
Signal Integrity Analysis Mode
Signal integrity analysis also can be performed right after 'setup design' in RedHawk, with
'SIGNAL_INTEGRITY 1’ set in the timing configuration file, using the same command
perform clockskew -config <config_file> -mode basic
Make sure that coupling capacitance information is available in the imported SPEF file.
Also note that the above setting overwrites 'POWER_INTEGRITY 1' in the configuration
file.
Power Integrity Analysis Mode
This mode considers the effects of static or dynamic voltage drops in the skew analysis.
The default mode is dynamic, which is equivalent to
perform clockskew -config <config_file> -mode dynamic
Static voltage drop impacts are analyses using the command
perform clockskew -config <config_file> -mode static
Note that the above setting overwrites 'POWER_INTEGRITY 0' in the configuration file.
Simultaneous Power and Signal Integrity Analysis Mode
Simultaneous power and signal integrity analysis mode in invoked by
perform clockskew -config <config_file> -mode [static|dynamic]
and also specifying 'SIGNAL_INTEGRITY 1' in the configuration file. Make sure that
coupling capacitance information is available in the imported SPEF file.
Note that the above setting overwrites 'POWER_INTEGRITY 0' in the configuration file.
Clock Tree Skew Analysis Results
Various graphic displays and output data are produced by Clock Tree Skew Analysis, as
described in the following sections.
Clock Tree Skew Summary Report
After performing clock tree skew analysis, use the menu command Timing -> Sign-off
Clock Tree -> Clock Tree Report to create a summary, as shown in Figure 8-22.
Figure 8-22
Clock Tree Skew summary report
The data displayed in the Clock Skew Report columns are as follows:
• Clock Root - clock tree root pin name
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Skew Analysis
RedHawk User Manual
| 199
• Leaf Num - number of terminating leafs in the clock tree
• Inst Num - number of instances in the clock tree
• Skew R - difference in longest and shortest rising insertion delay (ps)
• Skew F - difference in longest and shortest falling insertion delay (ps)
• Max Delay R - maximum rising delay in the clock tree, root to leaf (ps)
• Max Delay F - maximum falling delay in the clock tree, root to leaf (ps)
• Min Delay R - minimum rising delay in clock tree, root to leaf (ps)
• Min Delay F - minimum falling delay in clock tree, root to leaf (ps)
Clock Tree Skew Analysis Text Reports
RedHawk clock tree skew analysis produces the following files, which are written into the
directory ‘adsRpt/Clkskw’, as shown in the directory structure of Figure 8-23 below. Each
clock tree root is saved to the sub-directory under ‘adsRpt/Clkskw’. The subdirectories
are labeled ‘tree_1_pi’, ‘tree_2_pi’, and so on, for clock tree skew analysis. All the
temporary files created during clock tree skew analysis go to the .apache/clkskw run
directory, as shown in Figure 8-23.
-------------------------------------------------------------------( Clock tree skew analysis outputs data under the RedHawk run directory )
|___adsRpt/Clkskw
|___ skew.log
( complete skew log file )
|___ skew.err
( complete skew error file )
|___ skew.warn
( complete skew warning file )
|___ tree_ id_map ( map b/w tree_<id>_<suffix> dir and clock tree roots )
|___ tree_<id>_<suffix> ( <suffix> is one of: basic, pi, si, pisi )
|___ tree.sdf
( sdf format output )
|___ tree.skw
(delay, skew summary report )
|___ tree.leaf
( leaf summary report and histogram)
...
|___DomainRpt/
(duplicate results organized by sub-tree)
|___subtree_1/
(sub-domain clock tree reports)
|___subtree.sdf
|___subtree.skw
|___subtree.leaf
|___subtree_2/
...
Figure 8-23
timing analysis directory structure - skew
To turn off generation of the additional DomainRpt directory and subtree files, use the
following configuration file keyword setting:
CLOCKTREE_DOMAIN_SPLIT_REPORT 0
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 200
Clock Tree Analysis Configuration File Reference
The timing analysis configuration file allows users to customize the application
environment in which they run. The following sections describe the available configuration
file keywords and their usage, organized by function:
• Clock Tree Analysis
• Input Data Settings
• Jitter Analysis
• Signal Waveforms
• Simulation Controls
• Spice Elements
• Multi-task Controls
• Constraint Settings
• Application Type Selection
• RedHawk Data Usage
• Report Formats
Clock Tree Analysis Keywords
The following keywords are associated with clock tree analysis.
CLOCK_SOURCES
Specifies clock tree sources/roots for skew/jitter analysis.
Syntax:
CLOCK_SOURCES {
<clock_root1>
<clock_root2>
...
}
or for a single root, the simplified syntax is:
CLOCK_SOURCES <clock_root>
CLOCK_PATHS
Specifies the clock paths to be analyzed, by pairing root name and leaf names of interest.
Syntax:
CLOCK_PATHS {
ROOT <clock_root_1> -leafs {<leaf_1> <leaf_2> ... }
ROOT <clock_root_2> -leafs {<leaf_1> <leaf_2> ... }
...
}
COMMON_CLOCK_SIMULATION
Common simulations for all clock roots defined in the keyword CLOCK_SOURCES,
speeding up overall simulation run time.
Syntax:
COMMON_CLOCK_SIMULATION [0 | 1]
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 201
CLOCKTREE_BYPASS_UNDEFINED_GRAY_CELL
Continues clock tracing through “undefined” gray cells. A gray cell is undefined if it is
missing its Spice netlist data.
Syntax:
CLOCKTREE_BYPASS_UNDEFINED_GRAY_CELL [0 | 1]
CLOCK_TREE_MAX_LEVEL
Sets the limit on the number of levels of clock trees for simulation, which is useful for pipe
clean testing.
Syntax:
CLOCK_TREE_MAX_LEVEL <value>
LEAF_INST_PINS
Specifies instance pins to stop clock tracing from clock source/root.
Syntax:
LEAF_INST_PINS {
<leaf_pin1>
...
}
Input Data Settings
The following keywords are associated with input data settings:
CLOCK_INST_FILE
Supports a customer-specified clock instance file, which lists instances that should be
simulated. The keyword syntax is:
CLK_INST_FILE <fileName>
The file format is as follows:
#| Clock Tree Instance Summary
# Root=CK1 Period=2000(ps) Freq=500.000(Mhz)
# InstName CellName (InstType) Freq EffVdd
T_buf1 zbfp (C_COMB) 500.000MHz
T_buf3 zbfp (C_COMB) 500.000MHz
T_buf4 zbfp (C_COMB) 500.000MHz
T_buf5 zbfp (C_COMB) 500.000MHz
...
# Buffer/Gate=29 Sequential(Total) Leafs=2(2)
# Buf/Gate: Number of clock buffer and gates in the clock tree
# Leafs(Sequential): Number clock leafs and sequential leafs in the
clock tree
# Max/Min Lvl: Maximum and minimum level of the clock tree
# Clock Network Summary:
# -------------------------------------------------------------------# Freq(Mhz) Buf/Gate Leafs(Sequential) Max/Min Lvl Root_Net Root_Pin
# -------------------------------------------------------------------# 500.000
29
2( 2)
31/ 31
CK1
CK1
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 202
SPICE_NETLIST
Specifies one or multiple Spice cell netlist files.
Syntax:
SPICE_NETLIST {
<Spice_file1>
...
}
or for a single netlist, the simplified syntax is:
SPICE_NETLIST <Spice_file>
SPICE_SUBCKT_DIR
Specifies the directory path containing the Spice cell netlist files.
Syntax:
SPICE_SUBCKT_DIR <dir_path>
STA_CONST_READ
Turning this off (0) suppresses reading “CONST” lines in the STA file.
Syntax:
STA_CONST_READ [ 0 |1 ]
Jitter Analysis
The following keywords are associated with jitter analysis:
CYCLE_SELECTION
Selects criteria for automatic jitter cycle selection to determine the number of cycles to be
included in the jitter analysis, or turns cycle selection off.
Syntax:
CYCLE_SELECTION
[ DISABLE | WORST_C2C_JITTER_CYCLE | WORST_PERIOD_JITTER_CYCLE |
WORST_MIN_PERIOD_JITTER_CYCLE | WORST_MAX_PERIOD_JITTER_CYCLE ]
DYNAMIC_SIMULATION_CYCLES
Specifies the number of specific simulation cycles to be used for clock tree jitter analysis,
either by listing each one, or by specifying first and last.
Syntax:
DYNAMIC_SIMULATION_CYCLES
[ <cycle1> <cycle2> ... <cycleN> | <cycle1> : <cycleN> ]
JITTER_CUTOFF_FREQ
Specifies the minimum simulation clock frequency for jitter analysis to allow elimination of
clock domains, or instances with very low frequencies, and to speed up runtime. Default
4 MHz.
Syntax:
JITTER_CUTOFF_FREQ <value_MHz>
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 203
JITTER_FAST_MODE
Setting this keyword to 1 turns on fast jitter simulation analysis with eff DvD for PWL
waveforms. Setting to 2 turns on multi-cycle effective VDD support. Default 0 - Off.
Syntax:
JITTER_FAST_MODE [0 | 1 | 2 ]
TIMING_WINDOW_OVERLAP_RATIO_THRESHOLD
In jitter analysis with signal integrity, this keyword can control the aggressor selection for
coupling based on the amount of timing window overlap of aggressor and victim. The
overlap ratio is calculated as the fraction of the maximum possible period that the
aggressor and victim timing windows overlap, where the maximum period is the smaller of
the two 'On' periods. For example, if an aggressor has a TW between time 2 and 10 and
the victim has a TW between time 8 and 20, the overlap is between time 8 and 10, or 2.
The maximum overlap is the smaller timing window. That is, 10 - 2 = 8, which is less than
20 - 8 = 12. So the overlap ratio = 2/8 = 0.25. Aggressors with overlap ratios greater than
the user-specified threshold value (between 0 and 1.0) are selected for coupling analysis
for the victim.
Syntax:
TIMING_WINDOW_OVERLAP_RATIO_THRESHOLD <value>
Signal Waveforms
The following keywords are associated with signal waveform specifications:
FALL_SLEW
Sets the fall time in ns. Default 0.05 ns.
Syntax:
FALL_SLEW <value>
FALL_SLEW_AGRS
Sets the coupling aggressor fall time in ns. Default 0.05 ns.
Syntax:
FALL_SLEW_AGRS <value>
PWL_WAVEFORM
Defines waveform measurement points, which must be a fraction of Vdd and must be in
ascending order. The delay is measured at point 'M:' keyword. The slope is measured
between two points, 'L:' and 'H:'. A maximum of 10 measurement points is allowed.
Default values: 0.1, L: 0.3, M: 0.5, H: 0.7, 0.9.
Syntax:
PWL_WAVEFORM <val1>…<valN>
RISE_SLEW
Sets the rise time in ns. Default 0.05 ns.
Syntax:
RISE_SLEW <value>
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 204
RISE_SLEW_AGRS
Sets the coupling aggressor rise time in ns. Default 0.05 ns.
Syntax:
RISE_SLEW_AGRS <value>
Simulation Controls
The following keywords are associated with Spice simulation control:
SPICE_SIMULATOR
Specifies the type of Spice simulator. The command name is the same executable binary
or shell script as the Spice simulator. The binary (or shell script) must be accessible in the
run environment.
Syntax:
SPICE_SIMULATOR [ NSpice | HSpice | Eldo ]
SETTLE_TIME
Sets the simulation data transition time interval in ns. Default 0.
Syntax:
SETTLE_TIME <value>
SPICE_TIME_STEP
Sets the time increment for Spice transient analysis in ns. Default 0.01.
Syntax:
SPICE_TIME_STEP <value>
SPICE_PROBE_USE
Turns on printing of “.probe” lines in the Spice deck and generating *.ta0 signal waveform
file. Default 0.
Syntax:
SPICE_PROBE_USE [ 0 | 1 ]
SPICE_FILE_BACKUP
If set to 1, writes out individual Spice decks for each run. Default 0.
Syntax:
SPICE_FILE_BACKUP [ 0 | 1 ]
GROUP_CLUSTERING
Allows performing cluster-based jitter simulation. RedHawk splits the clock tree into
smaller clusters and simulates them serially, which improves overall simulation time. The
output clock waveform from each cluster is propagated to the subsequent one to ensure
the accuracy of the results. Default: DISABLE.
Syntax:
GROUP_CLUSTERING [ ENABLE | DISABLE ]
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 205
GROUP_CLUSTERING_DEPTH
Defines the maximum number of logic levels for each Spice run. Allows configuring the
depth of clock tree clusters per group. The default value is 3, which means that each
cluster created has a maximum depth of 3.
Syntax:
GROUP_CLUSTERING_DEPTH <cluster_depth_per_group>
SIMULATION_REDO_MAX
Defines the maximum number of iterations allowed for PWL waveform alignment. Default
10.
Syntax:
SIMULATION_REDO_MAX <value>
DEVICE_MODEL_LIBRARY
Specifies the full file path to the SPICE device model library (parameterized device
models). The model files can be defined multiple times. Use the process corner specified
in the LIB file, such as “TT”, “FF”, “SS”.
Syntax:
DEVICE_MODEL_LIBRARY <file_path>
INCLUDE
Specifies the full file paths for SPICE device models (.models) or files for other parameter
values needed. The models can be defined multiple times. This keyword directly passes
specified models to NSPICE's 'INCLUDE' function.
Syntax:
INCLUDE <Spice_device_model_file_path>
OPTION
Specifies any needed Spice simulation options, such as ‘OPTION mode=turbo’.
Syntax:
OPTION <Spice option1>
OPTION {
<Spice option2>
...
}
Spice Elements
The following keywords are associated with Spice elements:
SPF_COUPLE_CAP_MULTIPLIER
Defines coupling capacitor multiplier globally in SPEF. Default 1.
Syntax:
SPF_COUPLE_CAP_MULTIPLIER <value>
COUPLE_CAP_MULTIPLIER
Defines grounded coupling capacitor multiplier globally. Default 1.
Syntax:
COUPLE_CAP_MULTIPLIER <value>
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 206
CAP_MULTIPLIER
Defines ground capacitor multiplier globally. Default 1.
Syntax:
CAP_MULTIPLIER <value>
RES_MULTIPLIER
Defines resistor multiplier globally. Default 1.
Syntax:
RES_MULTIPLIER <value>
COUPLING_CAP_RATIO_THRESHOLD
Specifies the ratio between 0 and 1.0 of aggressor net coupling capacitance to the total
victim net capacitance. Includes the aggressor for coupling analysis if its ratio >= the
threshold. Increasing the ratio value reduces runtime and accuracy. Default 0.05.
Syntax:
COUPLING_CAP_RATIO_THRESHOLD <value>
COUPLING_WINDOW_MARGIN
Specifies the allowable extension of the victim TW (in number of rise times) to check
possible effects of overlapping with aggressor TW. Default=1.0 (value of 1 rise time in
both positive and negative directions).
Syntax:
COUPLING_WINDOW_MARGIN <value>
CAP_LOAD_UNIT
Specifies the capacitance unit for 'set_load' command in configuration file keyword
DEFINE_DESIGN_CONSTRAINTS. Default unit is femto-Farad (1e-15).
Syntax:
CAP_LOAD_UNIT <value>
SPEF_CAPACITANCE
Specifies the capacitance value for missing SPEF data for the net in specified SPEF
file(s) in femtoFarads. Default 0.001.
Syntax:
SPEF_CAPACITANCE <value>
SPEF_RESISTANCE
Specifies the value for missing SPEF resistance data for nets in specified SPEF file(s), in
Ohms. Default 0.001
Syntax:
SPEF_RESISTANCE <value>
Multi-task Controls
The following keywords are associated with multi-task controls:
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 207
GRID_TYPE
Specifies the multi-tasking job management platform. Default MULTICPU.
Syntax:
GRID_TYPE [ LSF | SUNGRID | MULTICPU ]
JOB_COUNT
Specifies the maximum number of parallel jobs to run. Note that the number should not
exceed he number of ‘nspice_psi’ licenses. Set the keyword to '0' to run in single job
mode. Default= number of CPU's * 2.
Syntax:
[ JOB_COUNT | LSF_JOB_COUNT ] <max number of jobs >
PARALLEL_SIMULATIONS
Allows simulating multiple clock networks in parallel to improve run time for cases with
multiple clock roots. Set JOB_COUNT also to control CPU use. Default OFF.
Syntax:
PARALLEL_SIMULATIONS [OFF |ON]
BATCH_QUEUING_COMMAND
Selects batch queuing type. Specify 'bsub' for LSF and 'qsub' for SUNGRID.
Syntax:
BATCH_QUEUING_COMMAND [bsub | qsub ]
BATCH_QUEUING_OPTIONS
Specifies options needed in the bsub command arguments or qsub shell script file.
Syntax:
BATCH_QUEUING_OPTIONS <options>
QUEUE
Defines name of LSF/SUNGRID queue. For SUNGRID, add comma between names of
queues, such as 'apl24.q, apl25.q, apl26.q'.
Syntax:
QUEUE <string>
EXEC_PATH
Defines the path to the bsub/qsub binary, which can be different from the environment
setting.
Syntax:
EXEC_PATH <binary_path>
TIMER
Defines the desired wait time to check parallel job status, in seconds. Default 60.
Syntax:
TIMER <wait time>
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 208
LSF_JOB_TIMEOUT
Defines timeout limit for pending parallel jobs, in hours. Aborts if there are no active jobs
and all pending jobs exceed the timeout limit.
Syntax:
LSF_JOB_TIMEOUT <hrs>
Constraint Settings
The following keywords are associated with constraint settings:
DEFINE_DESIGN_CONSTRAINTS
Defines timing constraints as follows:
set_dc <pin_name> <voltage>: sets DC voltage for the Spice netlist ports during
simulation
set_clock_divider: specifies the clock divider circuitry to allow analysis passing
through the flip-flop.
set_logic_zero or set_logic_one: sets pin logic state.
create_clock : specifies clock source for the clock period in the duty cycle report.
Unit is seconds.
set_disable_timing: specifies the blockage for clock signal propagation.
set_propagated_clock_cell: specifies timing arc for clock propagation through.
set_black_cell: sets the cell to be a black box cell. RedHawk does not try to
simulate the cell and continues propagating through it, whether the cell has a
Spice netlist or not.
set_clock_leaf: sets port name or pin name to be a leaf
Syntax:
DEFINE_DESIGN_CONSTRAINTS
{
set_dc <pin_name> <voltage>
set_clock_divider <port_name>
set_logic_zero <port_name>
set_logic_one <port_name>
create_clock -period <value> -waveform { <value> <value> }
<clock_root>
set_disable_timing [-from <pin_name> -to <pin_name>]
[get_cells {inst_name}]
set_propagated_clock_cell <cell_name> <pin_name1><pin_name2>
set_black_cell <cell_name>
set_clock_leaf <port_name/pin_name>
}
Application Type Selection
The following keywords are associated with application type selection:
POWER_INTEGRITY
Turns off power/ground noise impact analysis. Clock Tree Jitter Analysis automatically
turns on P/G noise analysis.
Syntax:
POWER_INTEGRITY
ANSYS INC - Apache Design Business Unit
[ 0 |1 ]
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 209
SIGNAL_INTEGRITY
Turns on capacitive coupling noise impact analysis.
Syntax:
SIGNAL_INTEGRITY
[ 0 |1 ]
RedHawk Data Usage
The following keywords are associated with RedHawk data usage.
DVD_ALIGNMENT_CONFIGURATIONS
In Jitter analysis with effective P/G waveforms, P/G noise introduces delay in clock
switching, which causes misalignment between the clock and the P/G waveform. This
keyword allows back annotation of the delay due to P/G noise, and aligning the dynamic
waveforms with the instance switching times.
Syntax:
DVD_ALIGNMENT_CONFIGURATIONS {
MAX_SIMULATION_REDO <num_iterations>
PG_WAVEFORM_SHIFT_PERCENT <Max_percent>
}
DVD_WAVE_WINDOW_RANGE
Defines the time span of power/ground waveforms with respect to each cell switching
point for Spice simulation. Two numbers define the spans for starting time and end time at
the switching point. Defaults 0.5, 2 ns.
Syntax:
DVD_WAVE_WINDOW_RANGE <val1> <val2>
DVD_WAVEFORM_ALIGN
Sets alignment of P/G noise switching time to the cell Spice simulation switching time. Set
to '1' to align P/G noise switching time to the cell Spice simulation switching time. Set to '0'
to disable P/G waveform alignment. Set to '-2' to plug original P/G waveform into Spice
simulation, without automatic alignment. Default 1.
Syntax:
DVD_WAVEFORM_ALIGN [ 0 | 1 | -2 ]
DEF_CONNECTIVITY
When set to 1, turns on DEF connectivity data from RedHawk as reference. Otherwise
uses SPEF data to define net connectivity (0).
Syntax:
DEF_CONNECTIVITY [ 0 | 1 ]
EXTRACT_NODE_LIMIT
Specifies the maximum limit of node numbers in one batch for power/ground waveform
extraction. The size control can improve waveform extraction runtime. Default 50000.
Syntax:
EXTRACT_NODE_LIMIT <value>
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 210
Report Formats
The following keywords are associated with report formats:
JITTER_VERBOSE_REPORT
Turns on printing of complete jitter report with statistics and details. Default 0.
Syntax:
JITTER_VERBOSE_REPORT [ 0 | 1 ]
PERIOD_JITTER_DEFINITION
Turns on period jitter definition as the difference of max and min jitter periods. Default '0'
defines period jitter as the deviation from the ideal period.
Syntax:
PERIOD_JITTER_DEFINITION [ 0 | 1 ]
CLOCKTREE_DOMAIN_SPLIT_REPORT
Turns on printing of clock sub-tree report from master tree report separated by clock
divider. Default 1.
Syntax:
CLOCKTREE_DOMAIN_SPLIT_REPORT [ 0 | 1 ]
REPORT_JITTER_AS_PERCENT_OF_ROOT_FREQUENCY
Turning on (1) generates the jitter report based on clock root frequency. Default 0.
Syntax:
REPORT_JITTER_AS_PERCENT_OF_ROOT_FREQUENCY [0 | 1]
SORT_JITTER_REPORT
Sorts the jitter report based on Jitter_Number or Level. Default ‘Jitter_Number’
Syntax:
SORT_JITTER_REPORT [Jitter_Number | Level ]
Sample Timing Configuration File
The following is an example of a timing configuration control file, with inactive keywords
commented out:
#| ------------------------------------------------------#| Timing Config File:
#| ------------------------------------------------------CLOCK_SOURCES
{
chip_sclk_src
edt_clock
tc_tck_routes
}
SPICE_NETLIST
{
user_data/SPI/cell.spi
ANSYS INC - Apache Design Business Unit
CHAPTER 8 — Analysis of DvD and Cross-coupling Noise Impacts on Timing
Clock Tree Analysis Configuration File Reference
RedHawk User Manual
| 211
user_data/SPI/iocell.spi
}
DEVICE_MODEL_LIBRARY /circuits/spice/models/spice_model.hlib SS
# The following keywords are optional, shown commented out
# --- SIGNAL WAVEFORM --- #
# PWL_WAVEFORM 0.1 RL: 0.25 FL: 0.45 M: 0.5 RH: 0.55 FH: 0.75 0.9
#
#
#
#
#
#
--- SIMULATION CONTROL --- #
CIRCUIT_SIMULATOR nspice
TEMPERATURE 125
SETTLE_TIME 10
SPICE_TIME_STEP 0.01
GROUP_CLUSTERING_DEPTH 5
#
#
#
#
#
#
#
#
#
#
--- CONSTRAINT SETTING --- #
DEFINE_DESIGN_CONSTRAINT
{
set_logic_zero mux1:s1
set_logic_one mux1:s2
set_clock_divider div_reg:q
set_disable_timing -from A -to y [get_cells {sndk/ABCck_id_5} ]
set_propagated_clock_cell xyzvc a y 0.12
set_black_cell Mnop3_bsfm
}
# --- APPLICATION TYPE SELECTION --- #
# SIGNAL_INTEGRITY 0
# --- JITTER ANALYSIS --- #
# JITTER_CUTOFF_FREQ 40
# JITTER_FAST_MODE 1
#
#
#
#
--- CLOCK TREE ANALYSIS --- #
COMMON_CLOCK_SIMULATION 1
CLOCKTREE_BYPASS_UNDEFINED_GRAY_CELL 0
CLOCK_TREE_MAX_LEVEL 5
# --- INPUT DATA SETTINGS --- #
# STA_CONST_READ 0
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Introduction
RedHawk User Manual
| 212
Chapter 9
Characterization Using Apache
Power Library
Introduction
The Apache Power Library program is used to characterize cells, creating accurate
switching current waveforms (profiles), output-state dependent decoupling capacitance
(intrinsic decap), equivalent power circuit resistance (called ESR, “Effective Series
Resistance”), switching delay, and leakage current, all at multiple conditions, for the
desired set of cells. These data are required for accurate RedHawk dynamic analysis.
APL has three basic modes:
• fast library checking mode
• design-independent full library characterization mode
• design-dependent characterization mode, for cells under particular design conditions
for sign-off quality
The general APL flow is shown in Figure 9-1.
Figure 9-1
APL data flow for cell characterization
Each mode of APL produces a set of “sample” switching waveforms for each cell for
selected values of output capacitance loading, transition time (“slew”) and Vdd. In fast
library checking mode only one sample is generated--that is, one set of waveforms for
each cell at one Vdd, Cload, and slew condition. For APL-DI characterization, switching
current profiles for many combinations of Vdd, and Cload/slew are generated to cover the
expected usage range of each cell. In design-specific characterization, waveform
samples for the particular design conditions are generated, hence fewer samples are
generated, but they are more accurate for the design than are those from designANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Overview of APL Characterization
RedHawk User Manual
| 213
independent characterization. Separate APL runs are required to characterize decap cells
for regular, as well as low-voltage, designs with header and footer switch components.
Overview of APL Characterization
Types of Cell Checking and Characterization
RedHawk has several types of cell checking and characterization, depending upon the
scope, accuracy and speed of analysis you require, as follows:
• Pre-run Sample Integrity Checking
• Fast Library Checking
• Library, or Design-Independent (APL-DI) Characterization
• Design-Dependent (APL-DD) Characterization
These methodologies for cell checking and characterization are compared in the following
section.
Pre-run Sample Integrity Checking
To check input sample data integrity for transition times (“slew”), Cload and Vdd values,
APL checks data from *.lib or other similar tools to screen for out-of-range data that can
corrupt APL results and significantly reduce computation speed.
Sample checking is performed before characterization starts upon invoking either Fast
Library Checking or APL-DI. The APL configuration file keywords used to set the data out
of range limits for transition times, Cload values, and Vdd values are
WARN_SLEW_CHECK, ERROR _SLEW_CHECK, WARN_CLOAD_CHECK,
ERROR_CLOAD_CHECK, WARN_VDD_CHECK, ERROR_VDD_CHECK, and
MIN_VDD_CHECK.
Fast Library Checking
The fast library checking mode runs an error check of the Spice netlist, device models,
LEF/DEF and Synopsys LIB files for each library cell at one corner condition, as a way of
verifying basic library data integrity. This is recommended as a first step before
characterization, but no actual characterization is performed in this step. Typical fast
checking mode run time for a 2000-cell library would be a few hours on a desktop
computer.
Library (APL-DI) and Design-dependent (APL-DD) Characterization
All characterization functions can be run on a single machine or multiple machines from a
UNIX command line using the command apldi, both full library (DI, the default) and
design-specific (DD) characterization, except for memories. To characterize memories,
use the sim2iprof utility (see section "sim2iprof", page E-895) and ACE utility (see section
"ACE Decap and ESR Characterization", page 9-262). For library characterization, apldi
reads cell library data from *.lib files, generates representative samples based on cell
delay and load tables, and runs on a local machine or multiple machines (through multijob management software). It generates characteristics for each specified process corner.
Applicability
Library characterization, or design-independent characterization, is performed on the
whole cell library, generally before any real design starts. APL-DI picks representative
switching conditions from a matrix of input slew, output capacitive load, and Vdd values
for each cell and runs characterization to extract each cell's dynamic switching current
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Overview of APL Characterization
RedHawk User Manual
| 214
and switching delay, as well as the intrinsic device capacitance and leakage current.
Design-dependent characterization is performed for the cells in a design from SPEF and
STA data, so all switching relationships to input slew, output Cload, and Vdd values are
specific to the design.
Accuracy
Since APL-DI is usually run on a full library before a design is available, and the specific
operating conditions are not known, it is less accurate than using APL-DD design-specific
data. However, APL-DI analysis results typically are within 10% of DD results.
Run time
APL-DI is run one time on the complete library, whereas APL-DD is run for each new
design. For a DI run, depending on the library size and computing resource used, the run
time can be a day to a week (for example, a 2000-cell library characterization time can be
around 3 days using a 10-machine LSF farm). For DD, the run time depends strongly on
the number of cells and the number of samples chosen. Due to the large number of cells/
samples to be characterized, using a batch computing farm (that is, LSF or SunGrid), or a
local machine with multiple CPUs, to run the characterization is recommended.
Simulator Support
By default APL uses its internal NSPICE simulator for characterization, which has tested
Spice accuracy, but it also supports direct use of the HSPICE simulator using the APL
configuration file keyword APL_HSPICE <binary_path>, and also the ELDO simulator
with the APL configuration keyword APL_ELDO <binary_path>.
Characterization Functions
From a characterization viewpoint, there are three categories of design components,
which are handled somewhat differently in the characterization flow:
• standard library cells, I/O cells, and custom IP
• intentional decoupling capacitance cells
• memories
There are three types of information required to provide complete operational
characterization:
• current waveforms under switching conditions, as well as delay and slew data
• values of intrinsic device decap, leakage current and effective power circuit resistance
(“ESR”) at nominal voltage for On and Off conditions.
• piecewise linear voltage functions for intentional decap values and library cell
performance under power-up conditions for power gating applications.
To perform characterization on a complete set of components for a library or design, the
following Apache characterization program runs are required, each of which includes an
appropriate number of corner conditions for the accuracy requested:
1.
To obtain switching current, switching delay and slew for all library standard cells, I/
O cells, and custom IP other than memories, use the apldi program
2.
To obtain intrinsic decap, ESR, and leakage current for all library cells, I/O cells,
and custom IP other than memories, use apldi -c.
3.
To obtain intrinsic decap, ESR, and leakage current for intentional decap cells, use
apldi -p.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Overview of APL Characterization
4.
RedHawk User Manual
| 215
For memories, use sim2iprof to obtain switching current, switching delay and slew,
and ACE to obtain intrinsic decap, ESR, and leakage current. Or for faster
characterization, use avm to perform datasheet-based memory characterization.
For low power designs such as power gating, with component on and off cycles,
additional characterization runs are needed to analyze their behavior under voltage rampup conditions:
5.
To obtain piecewise linear voltage relationships for intentional decap and switching
current, delay, and slew for standard cells, I/O cells, and custom IP, use apldi -w.
6.
To create characterization data for low-power header and footer switches, use
aplsw.
Apache cell characterization software is summarized in Table 9-1.
Table 9-1
Apache characterization software
Program
Description
apldi
Performs characterization on all library cells, using a single machine or
multiple machines in parallel. Generates waveform-based Vdd/Vss switching
current profiles, equivalent power circuit series resistance and leakage current,
and intrinsic decaps. In design-dependent mode, characterizes cells for a set
of specific design conditions.
apldi -c
Generates intrinsic decap, ESR, and leakage current for all library
cells, I/O cells, and custom IP other than memories
apldi -p
Generates intrinsic decap, ESR, and leakage current for intentional
decap cells
aplsw
apldi -w
sim2iprof and
ACE
avm
Generates characterization data for header and footer switches used in powergating low power designs
Performs low-power characterization of standard cells, intrinsic decap,
leakage current and ESR, creating a piecewise linear function of voltage
Performs characterization on custom cells, I/O cells, memories, and IP
macros. Generates waveform-based Vdd/Vss switching current profiles,
equivalent power circuit series resistance and leakage current., and intrinsic
decaps.
Generates fast datasheet-based Vdd/Vss current profiles and device decaps
for memory and IP macros.
Multiple Machine Batch Management
To run parallel APL characterization jobs, Platform LSF or Sun Grid batch management
package should be installed on the network, so that the program can be accessed by all
needed computing machines. To use Platform LSF or Sun Grid programs, set up the
appropriate commands and utilities, similar to a C-shell environment. For example:
For Platform LSF: %source /appls/lsf/conf/cshrc.lsf
For Sun Grid: %source /appls/sge/default/common/settings.csh
Note that on all participating machines the working directory should be readable and
writable. For more information on Platform LSF and Sun Grid use, please refer to their
respective user manuals.
The environment variable APACHEROOT should be defined before running apldi. For
example:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 216
setenv APACHEROOT /install_dir/apacheda/<RedHawk_release>
See the section "Running APL Characterization from a UNIX Shell", page 9-245, for the
syntax for batch submittal.
Platforms Supported
APL currently supports the following five platforms:
1.
ix86-ent3-32b - 32-bit RedHat Enterprise version 3
2.
opt-ent3-64b - 64-bit Opteron RedHat Enterprise version 3.x
3.
ix86-ent3-32b - 32-bit CentOS version 4
4.
opt-ent3-64b - 64-bit CentOS version 4
5.
sparc-sol8-64b - 64-bit Solaris version 8.x
APL Working Directory
During characterization, APL needs a temporary directory to store the intermediate
working files, such as Spice netlist files and simulation result files. The default working
directory is .apache/APL. You can change the working directory by using the TMP_DIR
keyword in the APL configuration file.
It is important to make sure that the temporary directory has enough disk space to work
with, especially if there are many large Spice subcircuit netlist files to be included in the
characterization. For example, for a typical library of 500 cells, 500 MB or more of
available disk space is recommended for characterization.
Cell Characterization Data Preparation
Data Requirements
The data required for standard cell APL characterizations are described in the this
section. The vectors used in characterization are automatically generated by APL. Before
running APL you need the following files:
• *.lib files - cell library data files, including cell function, pin definitions, and state tables.
Required for running library APL characterization. (Standard design files.)
• P/G arc definitions - for designs that have cells with multiple Vdd and multiple Vss
pins, the P/G arcs must be defined for decap characterization, which arc-based. For
design-independent (DI, full library) characterization, APLDI can interpret the P/G arc
data if the .lib “related_power/ground_pin” keywords exist (otherwise, the P/G arcs
must be defined in a custom .lib file). The syntax in LIB is:
pin(D) {
direction : input;
related_power_pin : VDD;
related_ground_pin : VSS;
}
APLDI reads the 'related_power_pin' and 'related_ground_pin' to get the P/G arcs as
VDD to VSS. If overlaps are found in the P/G arc data between the custom lib and the
.lib files, then the priority to choose the P/G arcs is as follows:
a. cell level P/G arcs from custom lib
b. cell level P/G arcs from LIB
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 217
c. file level P/G arcs from custom lib
For design-specific (DD) characterization, the file .apache/apache.pgarc generated by
RedHawk is needed. APL automatically searches for this file.
• Spice subcircuit files - the Spice netlist for each cell. Must be in HSpice-compatible
format. You can have multiple subckt files. The pin order can be different. Also, VDD/
GND pins are usually not defined in the cell library. This is allowable; APL matches the
missing VDD/GND pins automatically. (Standard design files.)
• Spice device model files - the device model file to run Spice. Model of process corners
for each device referenced in the Spice netlist. Must be in HSpice-compatible format.
Multiple library model files/entries are allowed. (Standard design files.)
• Spice to LEF pin mapping - to handle P/G pins with different names in SPICE and LEF
APL outputs LEF P/G pin, but uses Spice P/G pin internally. The APL keyword
SPICE2LEF_PIN_MAPPING applies to switching currents, CDEV, and PWCAP data
for all cells.
Only the following mapping is allowed:
1 LEF pin <-> 1 Spice pin
Multiple LEF pins <-> 1 Spice pin
If no pin mapping is given in the APL configuration file, the P/G pin name must be the
same in LEF and Spice.
Example:
SPICE2LEF_PIN_MAPPING {
Vdd_spice
Vdd_lef
Vss_spice
gnd_lef
}
• APL configuration file - specifies all of the above files. Usually called apldi.config or
apl.config. In the configuration file you can also specify other parameters such as
temperature, ideal power supply voltage, power/ground node names, and scaling
factors. The APL configuration file and the required and optional keywords is
described in detail in the following section. (Special file required for APL.)
• cell list file - for design-specific cell characterization (if library APL has not been
performed) or for custom cell characterization, you need to create a text file listing the
cells to be characterized. (Optional special file for APL.)
• input vector files - input vector definitions (Special APL file needed for custom cell
characterization. See the section "Custom Cell Characterization Data Preparation",
page 9-240)
NOTE:
The load capacitance used for the characterization of the cells comes
from SPEF/DSPF files defined in the .gsr file. Otherwise, Steiner tree
approximations are used.
The slew rate used for the characterization of the cells comes from the
PrimeTime data defined in the .gsr file. Otherwise, the default slew value
specified in the .gsr is used.
APL Configuration File Description
The configuration file contains the information required to perform cell characterization.
There are several categories of keywords in this section, which are divided into
• keywords required for all types of APL runs
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 218
• keywords required for library APL (design-independent) only
• optional keywords
Required APL Configuration File Keywords
The following is a list of required keywords used in the configuration file for cell
characterization.
APL_RUN_MODE
APL_RUN_MODE defines the APL run mode, either design-dependent (DD) or librarybased design-independent (DI). The default is DI.
Note: If there is no DESIGN CORNER definition, the run is design-dependent, even if
DI is specified for APL_RUN_MODE.
Syntax:
APL_RUN_MODE [ DD | DI ]
Example:
APL_RUN_MODE DI
DC
Allows specification of special DC voltage values for particular pins during
characterization.
Syntax:
DC <pinName> <voltage_value>
Example:
DC VSSV 0
Note that if the pins are defined as DC pins, they should be present on a ‘.subckt’ line in
the subcircuit definitions.
DEVICE_MODEL_LIBRARY
Specifies the SPICE device model library (parameterized device models) file used for cell
characterization. The path to the model library file must be a full path. The model files can
be defined multiple times. Use the process corner specified in the LIB file, such as “TT”,
“FF”, “SS”.
Syntax:
DEVICE_MODEL_LIBRARY
<SPICE_model_lib_path> <process_corner>
Example:
DEVICE_MODEL_LIBRARY /home/design/13um.lib TT
INCLUDE
Specifies files for SPICE device models (.models) or files for other parameter values
needed for cell characterization. The path to the files must be a full path. The models can
be defined multiple times. This keyword directly passes specified models to NSPICE’s
INCLUDE function.
Syntax:
INCLUDE <SPICE_device_model_filePath> ...
Example:
INCLUDE /home/design/spice.models
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 219
PROCESS
To comply with the MSDF flow, each characterized <cell>.current file needs to provide
the process corner name for RedHawk simulation. Although this information is usually
available from the Spice device library (corner name), the meaning of the library names
may not be clear to the timing tool, so this specification is required. For RedHawk
computation, WC=SS=slow, BC=FF=fast, and TC=TT=typical. Note that if the
DESIGN_CORNER keyword is specified, PROCESS should be a DESIGN_CORNER
sub-keyword, but otherwise PROCESS is specified separately.
Syntax:
PROCESS [ FF | TT | SS | BC | TC | WC ]
Example:
PROCESS FF
REDHAWK_WORKING_DIRECTORY
Defines the path to the working directory for the RedHawk run.
Syntax:
REDHAWK_WORKING_DIRECTORY <RedHawk_working_directory>
Example:
REDHAWK_WORKING_DIRECTORY /home/apache_work
SIZE_SCALE
Optional size scaling factor for all devices in the SPICE netlist. The factor scales the
MOSFET’s drawn channel length and width. The SIZE_SCALE factor should be set to 1
(default) if the device sizes are specified in microns (um), and set to the proper scale
value if the device sizes are not in um units. For example, if a MOSFET’s channel length
(L) is specified in micron units in the netlist, then the size scale factor should be 1.
Likewise, if a MOSFET’s L is specified in meters, then the correct size scale factor would
be 1.0e-6.
Specifying the correct factor value is extremely important, since this directly affects the
electrical behavior of each transistor, thus the overall behavior of the cell.
Syntax:
SIZE_SCALE <value_for_scaling_factor>
Example:
SIZE_SCALE 1.0e-6
SPICE_NETLIST
Specifies the SPICE netlist file for the subcircuit models used for cell characterization.
Syntax:
SPICE_NETLIST <Spice_netlist>
Example:
SPICE_NETLIST Spice.sp
SWEEP_TEMPERATURE
Required keyword in APL thermal leakage characterization to specify a list of
characterization temperature samples, in degrees Centigrade.
Syntax:
SWEEP_TEMPERATURE <t1> <t2> ...
Example:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 220
SWEEP_TEMPERATURE 25 50 125
TEMP
Defines the temperature used for cell characterization. The value should be consistent
with the value in the corresponding Synopsys .LIB and parasitic extraction (SPEF or
DSPF) files.
Syntax:
TEMP <char_temp_in_centigrade>
Example:
TEMP -40
VDD
Defines the voltage supply value at the Vdd pin. The value should be the one specified in
LIB nom_voltage.
Syntax:
VDD <voltage>
Example:
VDD 1.32
VDD_VALUES
Specifies the VDD values for multi-VDD case. User can explicitly specify voltage values
for all domains. If both VDD_VALUES and VDD keywords are specified in config file, then
VDD_VALUES will have higher preference. This keyword also honors user defined VDD
values for leakage current characterization.
Syntax (for multi-VDD):
VDD_VALUES {
<vdd_pin_name1> <value1> <value2> ...
<vdd_pin_name2> <value1> <value2> ...
...
}
Syntax (for leakage current characterization:
VDD_VALUES {
<vdd_pin_name1> <vdd value>
<vdd_pin_name2> <vdd value>
...
}
VDD_PIN_NAME / GND_PIN_NAME
Specifies pin names for cells with single power/ground grids (multiple Vdd/Vss pins are
specified in LEF). The Vdd names should match the power pin names found in the Spice
subcircuit netlist. If more than one pin name is specified, names following the first one are
considered alias pins. These names may be different than the design’s power net names
specified in the .gsr file.
Syntax:
VDD_PIN_NAME <vdd_pin_name> <vdd_alias_pin_name1> <...>
GND_PIN_NAME <gnd_pin_name> <gnd_alias_pin_name1> <...>
Example:
VDD_PIN_NAME VDD
GND_PIN_NAME VSS
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 221
Required for Library APL (Design-independent) Configuration File Only
The following is a list of keywords used in the configuration file for APL-DI standard cell
characterization.
APL_RUN_PASS
APL_RUN_FAIL
These keywords - APL_RUN_PASS and APL_RUN_FAIL- can be used to dump spice
netlist and output waveform file while doing current characterization.
Syntax:
APL_RUN_PASS [ NONE | DECK | ALL ]
APL_RUN_FAIL [ NONE | DECK | ALL ]
CUSTOM_LIBS_FILE
Typically, multiple Vdd/Vss pins are specified in LEF files. APL uses the nominal voltages
defined in the .lib files and creates custom LIB files for characterization. If LEF files are
not available, CUSTOM_LIBS_FILE can be used to specify one (only) manually-created
custom LIB file needed to define the Vdd/Vss pins. APL-DI extracts the Vdd/Vss pins and
puts them in the Pin section of the adsLib.output file.
Syntax:
CUSTOM_LIBS_FILE {
<.lib_file>
}
Example:
CUSTOM_LIBS_FILE {
/nfs/apl1/user_data/lib/ABC.lib
}
DESIGN_CORNER
Each design process corner (a combination of a temperature and voltage) generate one
set of cell characteristics. Multiple design corners generate multiple sets of cell
characteristics. There can be multiple LIB_ENTRY, SUBCKT, and LIB_FILES/DIR entries
for each corner definition. If the TEMP, VDD, LIB_ENTRY, SUBCKT, or LIB_FILES/DIR is
not defined for a corner, its common definition in the configuration file is applied to all
corners. The PROCESS keyword defines the standard process corner. The <lib_type>
parameter is a customized name that specifies which library type is used, which could be
a standard name (i.e., Typical (TT), Fast (FF), and Slow (SS)), or a different name
designated by the user.
Syntax:
DESIGN_CORNER {
? <corner_name1> ? {
TEMPERATURE <value in Celsius>
PROCESS [ FF | TT | SS | WC | BC | TC ]
[LIB_ENTRY | MODEL | DEVICE_MODEL_LIBRARY ] <lib_file> ?<lib_type>?
[SUBCKT[_DIR]| SPICE_NETLIST[_DIR]]<subckt_file/dir_name>
? VDD <vdd value>?
LIB_FILES <lib_file_name>
...
? LIB_FILES {
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 222
<File1>
...
<Dir1>
...
} ?
? Custom_lib_file <filename>
Custom_lib_file {
<custom_file>
} ?
? LIBS_DIRECTORY <lib_dir_name> ?
...
}
? <corner_name2> {
TEMPERATURE <value in Celsius>
PROCESS [ FF | TT | SS | WC | BC | TC ]
[LIB_ENTRY | MODEL | DEVICE_MODEL_LIBRARY ]<lib_file> ?<lib_type>?
[SUBCKT[_DIR]| SPICE_NETLIST[_DIR]]<subckt_file/dir_name>
? VDD <vdd value>?
LIB_FILES <lib_file_name>
? LIB_FILES
{
<File1>
<File2>
...
<Dir1>
<Dir2>
...
} ?
Custom_lib_file <filename>
Custom_lib_file {
<custom_filename>
? LIBS_DIRECTORY <lib_dir_name> ?
...
}?
}
Example:
DESIGN_CORNER {
TT_25 {
TEMP 25
PROCESS TT
VDD 1.0
MODEL /nfs/apl1/model TT
}
FF_125 {
TEMP 125
PROCESS FF
VDD 1.1
MODEL /nfs/apl1/model FF
LIB_FILES lib_dir1
LIB_FILES lib_dir2/clkGen_fast.lib
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 223
}
}
LEF_FILES
RedHawk supports APL characterization for cells having multiple power and ground pins,
as defined in the LEF files. APL captures the current/cap profiles for different power/
ground pins separately. LEF_FILES defines the LEF files containing the P/G pin
specifications. With no LEF pin specifications, you must manually define multiple Vdd/Vss
pins using custom LIB files.
Syntax:
LEF_FILES {
<lef_file_1>
<lef_file_2>
...
}
Example:
LEF_FILES {
design_data/lef/cella.lef
design_data/lef/cellb.lef
}
If LEF files are not available while running APLDI, you can specify P/G pins for each multivoltage cell in a custom LIB file. The format for the custom LIB file is as follows:
cell <cell_name> {
pin <pin_name> {
type <vdd | gnd>
}
}
Example:
cell CELLA {
pin VDDIN {
type vdd
}
pin VDD {
type vdd
}
pin VSS {
type gnd
}
}
Specify the custom LIB filename in the APLDI config file using the keyword
'CUSTOM_LIBS_FILE'.
LIB_FILES
Specifies Synopsys library files (*.lib) or a custom library P/G arc file to be used in the
design (only one custom *.lib file may be specified). If a directory is specified, all files in
the directory are selected.
Syntax:
LIB_FILES {
[ <lib_filename> | <lib_file_dir> ] ? CUSTOM ?
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 224
...
}
where
<lib_filename> : specifies library or p/g arc filename
<lib_file_dir>: specifies library directory
CUSTOM: specifies one custom P/G arc file or directory
Examples:
LIB_FILES
{ libs/special/custom.lib CUSTOM
libs/typical
libs/memory/mem.lib
}
LIB_FILES
{ abc_lib
libs/special/pgarc.lib CUSTOM
}
where
abc_lib: specifies the library name
libs/special/pgarc.lib CUSTOM: specifies a file that contains P/G arc definitions
of the following form (see section "P/G Arc Definitions in Custom LIB Files",
page 3-20 for more details):
pgarc {
<vdd_pin_name> <vss_pin_name>
...
}
Handling large device capacitances
APLDI relaxes the upper limit on cdev values for special cells, which changes ESC values
for large cdev. Note that although large cdev values can be extracted successfully using
this step, these values cannot be treated as normal cdev values by RedHawk and APL
utilities, since they have checks on cdev values in place and import would fail. So to
handle large cdev values, the following steps should be taken:
1.
When running aplchk/aplreader/aplmerge, the option '-icheck' must be specified to
ignore large cdev values. And when running APL characterization, do not specify
'-o <outfile>' in APL, and do not put 'MERGE_RESULT 1' in the config file, as in
those cases aplmerge would be launched (without the ‘-icheck’ option) and cause
characterization failure.
2.
When importing large cdev values into RedHawk, set the GSR keyword
'IGNORE_APL_CHECK 1', otherwise it cannot run through the checking stage and
APL data cannot be imported successfully.
Optional APL Configuration File Keywords
APL_ELDO
Allows use of the ELDO simulator to perform switching current characterization, as well
as cdev/pwcdev switch characterization. Eldo handles both switching current
characterization and ACE, as well as cdev/pwcdev/switch characterization flow. To use
the ELDO simulator for characterization, instead of the default NSPICE, the location of
the binary must be specified with APL_ELDO.
Syntax:
APL_ELDO <full_path_to_binary>
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 225
Example:
APL_ELDO abc/sim/eldo
APL_ELDO_WDB
APL supports ELDO syntax natively, and also supports WDB-only modes for the APLELDO interface when this keyword is set (default is 0).
Syntax:
APL_ELDO_WDB [ 0 | 1 ]
APL_FORMAT_CORRECTION
When set to 1, aplcopy automatically identifies incorrect cell types based on the toggle
rates for the cells, and corrects the cell types automatically. The default cell type is 'Gate'
if the toggle value is two. Default is 0.
APL_FORMAT_CORRECTION [0|1]
APL_HSPICE
To use the HSPICE simulator for characterization, instead of the default, NSPICE, the
location of the binary must be specified with APL_HSPICE.
Syntax:
APL_HSPICE <path_to_binary>
Example:
APL_HSPICE abc/sim/hspice
APL_SPECTRE
To use the Spectre simulator for characterization, instead of the default NSPICE, the
location of the binary must be specified with APL_SPECTRE.
Syntax:
APL_SPECTRE <path_to_binary>
Example:
APL_SPECTRE abc/sim/spectre
APL_RESULT_DIRECTORY
APL_RESULT_DIRECTORY allows you to specify a directory for writing APL result files
for individual cells, with filenames of the form
• for current, <APL_dir_name>/<corner>/CURRENT/<cellname>.spiprof,
• for decap, <APL_dir_name>/<corner>/CAP/<cellname>.cdev, and
• for pwcap cells, <APL_dir_name>/<corner>/PWC/<cellname>.pwcdev,
as well as log file names of the form
• for current, <APL_dir_name>/<corner>/CURRENT/<cellname>.current.<time>.log
• for decap, <APL_dir_name>/<corner>/CAP/<cellname>.cap.<time>.log, and
• for pwcap cells, <APL_dir_name>/<corner>/PWC/<cellname>.pwcdev.<time>.log
where <time> is a timestamp of the form <date-time>.
The default directory for the output and log files is APLDD_<time>/ or APLDI_<time>/.
To specify a single file with all output result files merged, use the ‘-o <output_filename>’
option during APL invocation.
Syntax:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 226
APL_RESULT_DIRECTORY <APL_dir_name>
Example:
APL_RESULT_DIRECTORY Apl-out-ABC
APL_SAMPLE_MODE
Selects the type of APL characterization to be performed, based on the accuracy desired.
The number of samples is automatically selected based on the range of voltage, load and
slew values in the library. Default mode is 1 (DEFAULT). (Previously called
APLDI_SAMPLE.)
Syntax:
APL_SAMPLE_MODE [ FAST_CHECK | DEFAULT ]
where
FAST_CHECK: specifies fast library checking, uses one voltage/load/slew
sample per cell to perform basic library data integrity (completeness) checks
DEFAULT: specifies default characterization mode with multiple samples per cell,
depending on the range of voltage, load and slew values in the library.
Example:
APL_SAMPLE_MODE FAST_CHECK
APL_TAIL_REDUCTION
By default, APL uses an equal time step waveform to save switching current. Due to the
intrinsic limitation of equal time step waveforms, there is a trade-off between waveform
accuracy and file size. To reduce the number of APL waveform time points and data size,
there is a back-trace process in APL after current extraction to cut part of the tail current
waveform when the tail is long, but not reduce sharply down to its leakage value, which is
typically in the nA range. This 'moderate' mode makes the tail reduction process more
stable and less sensitive to time step changes in simulation results.
Syntax:
APL_TAIL_REDUCTION [ 0 | 1 | moderate ]
where
0: turns off waveform tail reduction process (default)
1: turns on original waveform tail reduction process
‘moderate’ : turns on improved waveform tail reduction (works with
'EXTRACTION_METHOD pwl' keyword)
APL_TECH_LEVEL
When set, switching current characterization is performed using PWL input waveforms,
providing improved accuracy and support for custom vector flow. APL characterization is
speeded up by reducing number of APLDI samples, which also reduces the disk file size
requirement by 50%. Note that this feature is available only for NSpice and HSpice
interfaces.
Example:
APL_TECH_LEVEL [ 0 | 1 ]
APL_VOLTAGES
For design-independent libraries, APL_VOLTAGES specifies characterization voltage
values as a fraction of LIB nominal voltage, which are used for creating the current
profiles. Voltage fractions should be specified in either ascending or descending order.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 227
If no voltage fraction at least 1.15 times nominal is specified, APLDI automatically adds an
additional voltage point equal to the highest among the VDD values in the config file, or
1.15 times the Lib_nom_voltage. Default: APL_VOLTAGES 4 1.15 1.0 0.9 0.75
Syntax:
APL_VOLTAGES <Num_volt_samples> <fraction 1> ... <fraction N>
Example:
APL_VOLTAGES 4 0.8 0.9 1.0 1.2
which creates current profiles for following four voltage values:
0.8 x Nom_V, 0.9 x Nom_V, 1.0 x Nom_V, 1.2 x Nom_V
CDEV_AC_OPEN_INPUT
When set, cdev characterization excludes the capacitance of all input pins from cell
intrinsic capacitance. The default value is 0 (off).
Syntax:
CDEV_AC_OPEN_INPUT [ 0 | 1 ]
CELL_PROPERTY_FILE
Specifies a file that provides a flexible interface for you to specify the output load for each
cell. The format of the cell property file contents is:
cell <cell name> {
pin <pin name> {
load <load value>
}
...
}
...
Syntax:
CELL_PROPERTY <cell property filename>
CONVERT_CCS_CAP
When set, converts CCS libraries that contain intrinsic parasitic ESC/ESR elements and
leakage current into APL cdev data. Default: 0.
Syntax:
CONVERT_CCS_CAP [0 |1]
DC_TABLE_THRESHOLD
Enables LDO dc table to have reduced data points when user specifies very fine sweep
step in spice dc simulation
Syntax:
DC_TABLE_THRESHOLD <slope_threshold>
Example:
DC_TABLE_THRESHOLD
0.08
DEBUG
DEBUG sets the debug flag, which saves intermediate and error files for debugging and
analysis.
Syntax:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 228
DEBUG [ 0 | 1 ]
DESIGN_CORNER
Specifies voltages to be defined in the APL leak characterization output file (*.leak) in the
thermal flow.
Syntax:
DESIGN_CORNER { <corner_name> { VDD <voltage>} }
Example:
DESIGN_CORNER {
Corner1 {
PROCESS TT
VDD 0.8
TEMP 125
}
}
In this case the voltage dumped in the *.leak file is 0.8V, although the cell leak
characterization is done at the NOMINAL_VOLTAGE derived from the .lib file.
ELDO_VECTOR_MODE
Selects between two different ELDO vector handling modes in APL extraction. By default
APL treats ELDO vectors as HSpice-compatible, in which the time point in digital vectors
are their initial values. When this keyword is set to 1, ELDO is in native digital vector
handling mode, and treats the time point in digital vectors as their final voltage values.
Syntax:
ELDO_VECTOR_MODE [0 | 1]
EXTRACTION_METHOD
Allows changing the APL waveform extraction method to PWL (piecewise linear). The
default APL waveform model using equal time steps can result in a very large file size for
very rapidly changing waveforms. The pwl extraction method retains nearly the accuracy
of the original Spice waveform, but the file size increase is negligible. Default: 0.
Syntax:
EXTRACTION_METHOD [ 0 | pwl ]
FAST_CHECKING
If FAST_CHECKING is set to 1, a data check is performed on each cell in the library at
one sample condition. A list of cells that cannot be characterized properly is created, the
same as using the ‘-fc’ option in apldi, or setting the GSR keyword
‘APLDI_SAMPLE_MODE’ to ‘fast_check’. The default is 0 (regular APL characterization).
Syntax:
FAST_CHECKING [ 1 | 0 ]
GZIP_RESULT
When set, dumps a compressed current file (default is 0).
GZIP_RESULT [ 0 | 1 ]
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 229
IGNORE_DC_CHECK
When turned On, APL ignores input pin checking for user-specified DC bias; the global
DC bias can be used for the whole library characterization. This helps in situations in
which you must use a single configuration file for cells with and without a particular DC
bias pins in the netlist. If not set, APL characterization errors out, so you must create two
configuration files and split the cell list. The default is 0.
IGNORE_DC_CHECK [ 0 | 1 ]
IGNORE_NETLIST_CHECK
Supports P/G pin pre-checking before APL characterization. If set to 0, APL checks the
netlist for pin mismatches and proceeds only if the P/G pin names specified in the
configuration file match those in the netlist (default 1).
Syntax:
IGNORE_NETLIST_CHECK [ 1 | 0 ]
IGNORE_RESET_PIN
When set, if defined Set/Reset pins are not found for a cell, RedHawk displays a Warning
and continues. By default (off), pins that are defined but do not exist generate an Error out
condition.
Syntax:
IGNORE_RESET_PIN [ 0 | 1 ]
IGNORE_UPF_PGARC
When set, if the UPF lib does not have p/g pins, pg arc information is defined using the
custom lib file (default 0).
IGNORE_UPF_PGARC [ 0 | 1 ]
INCREMENTAL_APL
If characterization for some cells fail or several new cells added, INCREMENTAL_APL
can be set to 1 and only the failed or new cells are characterized. After fixing the problem
with the failed cells and executing the last command prior to the failure, APL identifies and
re-characterizes the failed cells if INCREMENTAL_APL is set to 1. The default value is 0,
which is normal characterization of all cells. Note that when an incremental run is
executed, the APL_RESULT_DIRECTORY must be specified in the APL config file.
Syntax:
INCREMENTAL_APL [ 0 | 1 ]
INPUT_TYPE
Allows using a more realistic input stimulus waveform model than the preset stimulus
waveform used for characterization by default. Especially for new technologies, the
threshold interval (linear segment) becomes shorter and shorter. Therefore, this keyword
creates a stimulus waveform that minimizes the error introduced by this.
Syntax:
INPUT_TYPE [ 0 | 2 | 3 | 4 ]
where
0 : 1-segment ramp (default)
1 : 5-segment PWL
2 : ramp+RC filter
3 : 5-segment PWL+RC filter
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 230
4 : 50-segment PWL (recommended for accuracy)
LEAKAGE_DEVICE_MODEL_LIBRARY
Provides a separate Spice device model file for leakage current characterization.
Syntax:
LEAKAGE_DEVICE_MODEL_LIBRARY <devMod_file> ?<proc_corner>?
LEAK_HIGH_TO_MID_RATIO_LIMIT
LEAK_HIGH_TO_LOW_RATIO_LIMIT
For pwcap files, these keywords specify leakage current limits for the aplchk command.
LEAK_HIGH_TO_MID_RATIO_LIMIT specifies the ratio of current leakage at the highest
Vdd value (1.1xV) divided by the current leakage at the mid-voltage value (0.5xV). Those
values less than the ratio are not reported in the log. Keyword
LEAK_HIGH_TO_LOW_RATIO_LIMIT specifies the ratio of current leakage at the highest
Vdd value (1.1xV) divided by the current leakage at the lowest Vdd value (0.1xV). Those
values less than the ratio are not reported in the log. Violation warnings are recorded in
adsRpt/aplchk.log. There are no default ratios; if no value is specified, the comparison is
not computed.
Syntax:
LEAK_HIGH_TO_MID_RATIO_LIMIT <ratio>
LEAK_HIGH_TO_LOW_RATIO_LIMIT <ratio>
MAX_LOAD_SAMPLE
MIN_LOAD_SAMPLE
Sets minimum and maximum values for capacitive load (in Farads) used in
characterization, which may be either a wider or narrow range of values than those in LIB
files. Note that these values override the input range settings in the
WARN_CLOAD_CHECK and ERROR_CLOAD_CHECK parameters. No default.
Syntax:
MIN_LOAD_SAMPLE <load_Farads>
MAX_LOAD_SAMPLE <load_Farads>
Example:
MIN_LOAD_SAMPLE 10e-15
MAX_LOAD_SAMPLE 500e-15
MAX_SLEW_SAMPLE
MIN_SLEW_SAMPLE
Sets minimum and maximum values for transition times (in seconds) used in
characterization, which may be either a wider or narrow range of values than those in LIB
files. Note that these values override the input range settings in the
WARN_SLEW_CHECK and ERROR_SLEW_CHECK parameters. No default.
Syntax:
MIN_SLEW_SAMPLE <trans_time-sec>
MAX_SLEW_SAMPLE <trans_time-sec>
Example:
MIN_SLEW_SAMPLE 10e-12
MAX_SLEW_SAMPLE 500e-12
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 231
MEMORYFILE | INPVECFILE
MEMORYFILE and INPVECFILE specify the input vector file for characterizing a memory
cell or a special custom cell.
Syntax:
[ MEMORYFILE | INPVECFILE ] </nfs/filename>
Example:
MEMORYFILE /nfs/apl1/memfile
MERGE_RESULT
APL now generates characterization results in separate files in the APL results directory
by default. If MERGE_RESULT is set to 1, the result files are merged into a single file in
the run directory.
Also, the results are merged if the command ‘apldi -o <filename>’ is executed on the
command line. Files should merged only for APL design dependent (DD) runs, or one
corner condition design independent (DI) runs.
Syntax:
MERGE_RESULT [ 0 | 1 ]
MULTI_CORE
Allows several APL jobs to be run in parallel on a multiple-CPU local machine. The default
is '1', which means multi-core capability is turned On and APL submits multiple jobs,
depending on the number of CPUs and the memory available. If set to '0', multi-core is
turned off and only one job is submitted.
Syntax:
MULTI_CORE [ 0 | 1 ]
MULTI_NOMINAL
Leakage current for a cell changes with different supply voltage, which can be
accommodated in APL. MULTI_NOMINAL should be turned on for multi-voltage cdev/
leakage characterization to capture leakage current at every voltage point. The generated
cdev file can be read by RedHawk, and PowerStream computes the variable leakage
power depending on the voltages of the cell.
Syntax:
MULTI_NOMINAL [ 0 | 1 ]
MULTI_NOMINAL_VOLTAGES_METHOD
When set, APL supports multiple nominal voltage characterization, and uses all of them to
do scaling. In low power designs, one cell may operate under multiple nominal voltages
(voltage islands). This keyword specifies the voltages to be used in characterization for
such multi-nominal voltage cells.
In default mode (0), only the first nominal voltage in .LIB is used for voltage derating. This
method ignores other nominal voltage values, making the characterization less accurate
under the missed nominal voltages. When set to 1, APL honors all nominal voltages from
.LIB, and combines the derated voltages with the nominal voltages to form the final
voltage list for characterization. In this way, all nominal voltages and also their derated
values are included in characterization. Also, if a cell has multi-nominal voltage as well as
multiple Vdd domains, the same derating factor is applied for all multiple-nominal voltages
across all Vdd domains.
Syntax:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 232
MULTI_NOMINAL_VOLTAGES_METHOD [ 0 | 1 ]
MULTI_SPICE
APL supports a multi-level hierarchical netlist by splitting the Spice run into different Vdd
values, which automatically adjusts the VIH values in the input vector file into several
values that are percentages of the nominal VDD value. For each Vdd value, APL
generates one Spice deck as <cellname>_apl#.sp, where ‘#’ is a serial index number.
Custom vector cells also have a different vector file for each Vdd value, and the VIH
values also are appropriate percentages of the nominal Vdd value, as determined by
APL. This feature is turned off by default to minimize run-time (on a single-CPU machine).
Syntax:
MULTI_SPICE [ 0 | 1 ]
OPENPIN
When an input or output pin has no defined connection or function, the OPENPIN
keyword can be used to identify this condition and allow characterization. To provide a
circuit connection for characterization, APL assigns a very large resistance to ground for
specified open pins.
Syntax:
OPENPIN <pinA> <pinB> ...
Example:
OPENPIN ABCpin3A MNOpin14BC
OPTION
OPTION specifies any needed SPICE simulation options.
Syntax:
OPTION <Spice option1>
OPTION <Spice option2>
...
or
OPTION {
<Spice option1>
<Spice option2>
...
}
Example:
OPTION mode=turbo
OUTPUT_STATE_CHECK
When set, improves APL cdev characterization that uses STATE_TABLE for vector
generation from the .LIB file, in order to better identify HIGH and LOW states in cdev
generation. Default 0.
Syntax:
OUTPUT_STATE_CHECK [ 0 | 1 ]
PIN_LIST
PIN_LIST specifies the pin names and associated tie pins.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 233
Syntax:
PIN_LIST {
<pin_name> <tie_pin>
...
}
where
pin_name: specifies the name of the pin
tie_pin: specifies the name of the pin to which <pin_name> is connected.
Example:
PIN_LIST {
A1 VDD1
}
In this case, A1 is connected to VDD1.
PRIMARY_GND_PIN
When there are multiple ground pins in a cell, PRIMARY_GND_PIN defines which ground
pin is used to connect the output load. Although all ground pins are declared in the .lib
file, there is no property to specify the output load connectivity. There could be multiple
ground pin scenarios, in which there are both internal and external ground pins,
connected by footer switches, or there could be core and I/O ground pins. The
PRIMARY_GND_PIN is the closest pin to the output load; as such it carries the most
discharging current, and can be a Spice ground name (for multi-rail cells).
Syntax:
PRIMARY_GND_PIN <primary_gnd_pin>
Example:
PRIMARY_GND_PIN VSS0
PWCAP_MULTI_SPICE
When set, improves pwcap characterization for runs that include many SPICE simulations
for 10%, 20%... of nominal VDD value, which otherwise are sequentially performed and
could take substantial run time. To reduce APL run-time, specify a <parallel run count>
value to allow SPICE simulations with different VDD values to be performed
simultaneously. Note that PWCAP_MULTI_SPICE applies only to multi-core/CPU runs,
and not to LSF. This feature has no impact on accuracy of results.
Syntax:
PWCAP_MULTI_SPICE <parallel run count>
RUN_TIME_LIMIT
Allows specification of a limit on LSF and Sun Grid Engine (SGE) processes. The
RUN_TIME_LIMIT ensures that APLDI continues at the end of the specified run time
limit, even through processing errors.
Syntax:
RUN_TIME_LIMIT <limit_hrs>
SAMPLE_SPLIT
When turned on, SAMPLE_SPLIT distributes characterization jobs sample-by-sample to
different machines to speed up characterization and avoid negative network impacts.
When the keyword is unset (default ), APL internally determines cell-by-cell, based on
how large the cell netlist is, whether the sample split mode is used. When set to ‘0’, no
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 234
cells are submitted using sample split mode, and when set to ‘1’, all cells large or small
are submitted using sample split mode (a single sample may be submitted). To avoid
unnecessary management overhead, turning on SAMPLE_SPLIT is not recommended
for cells with small netlists. SAMPLE_SPLIT is not supported for multi-corner runs.
Note that the keyword LSF_RUN_TIME_LIMIT is available for both 'SAMPLE_SPLIT 1' in
the SGE environment and also for 'SAMPLE_SPLIT 0'.
Syntax:
SAMPLE_SPLIT [ 0 | 1 ]
SCANMODE
SCANMODE turns scan mode characterization On or Off for flip-flops and other cells with
scan logic. Default is off (0).
Syntax:
SCANMODE [ 0 | 1 ]
SCAN_OUTPUT_LOAD
Allows specifying the attachment of a constant load for various samples for APL
characterization. If specified, APL attaches the specified constant load to the scan pin of
the cell, if present. The libreader automatically identifies the scan pin. Default: none.
Syntax:
SCAN_OUTPUT_LOAD <load>
SIM_TIME_SCALE
Allows improvement in run time for Spice transient analysis by scaling the pulse width/
period and tstop in SPICE transient simulation in APL cdev/leakage characterization. For
example, when ‘SIM_TIME_SCALE 0.1’ is set, the pulse width/period and tstop are
reduced to 0.1x, then the SPICE simulation run-time would be reduced accordingly. Note
that by default the keyword value is 1.0 for the cdev flow. For temperature-based leakage
characterization, the default value is 0.1.
Syntax:
SIM_TIME_SCALE <value>
SIMULATION_COMMAND
The keyword SIMULATION_COMMAND should be used for any situation in which you
have your own wrapper to submit APL simulation jobs through LSF.
Syntax:
SIMULATION_COMMAND <sim_command>
Example:
SIMULATION_COMMAND bsub -q normal -q linux -Ip -R
“ select [type==LINUX64 && mem> 8000 ] rusage[hsim=1:duration=2]
“ hsim -i $input_file -o $output_file
In this example, $input_file and $output_file are replaced by files with the file
names required by APL. The $input_file specification is required, while
$output_file is optional. The simulator type is still determined by the existing
keyword, such as ‘APL_HSIM ~/bin/hsim’ for using HSIM.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 235
SIMULATOR_COMMAND_OPTION
Supports the efficient use of NSpice, HSpice, Eldo, and Spectre tools. Adding this
keyword appends the specified user options to the Spice simulation command line.
Syntax:
SIMULATOR_COMMAND_OPTION <option>
SMOOTH_PWC_LEAK
To smooth the leakage value glitches for lower voltage samples for APL pwdev
characterization. Default: 0
Syntax:
SMOOTH_PWC_LEAK [ 1 | 0 ]
SPICE_SUBCKT_DIR
The SPICE_SUBCKT_DIR option specifies the directory path containing the Spice
subcircuit files for the library cells to be characterized. APLDI automatically reads the
corresponding Spice subckt file while characterizing a particular cell.
Under the <directory_path> specification each cell has its own Spice subckt file. The suffix
of the subckt filename can be anything, but the <cell name> has to be the cell name (can
be case-insensitive), followed by a period “.”. Subckt files should not contain any other
subckt files.
Syntax:
SPICE_SUBCKT_DIR <directory path>
Example:
SPICE_SUBCKT_DIR ./spice_netlists
Note: The SPICE_SUBCKT_DIR and SPICE_NETLIST keywords are mutually
exclusive. The first one specified is processed and the second one is ignored. Except
for hierarchical netlists, use SPICE_SUBCKT_DIR to specify subcircuit files for best
processing performance.
SPICE2LEF_PIN_MAPPING
To handle P/G pins with different names in SPICE and LEF, APL uses Spice pin names
internally, but outputs LEF pin names. SPICE2LEF_PIN_MAPPING applies to all cells. If
no pin mapping is given in the APL configuration file, P/G pin names output to LEF are the
same as in Spice. Mapping is allowed only between one Spice pin to one LEF pin or one
Spice pin to multiple LEF pins. SPICE2LEF_PIN_MAPPING supports switching currents,
CDEV, and PWCAP data.
Syntax:
SPICE2LEF_PIN_MAPPING {
<Spice_pin_name> <LEF_pin_name> }
...
}
Example:
SPICE2LEF_PIN_MAPPING {
Vdd_spice1 Vdd_lef1A
Vss_spice1 Vss_ref1B
...
Vss_spiceN gnd_lefM
}
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 236
SUPPRESS_INTERNAL_OPTION
When set, provides an interface to control simulation convergence. That is, APL does not
specify convergence-related options (such as method=gear) for SPICE simulation. You
may specify other options with the keyword OPTION. Default is 0.
SUPPRESS_INTERNAL_OPTION [ 0 | 1 ]
SWEEPSOURCE
For header and footer switches in low power designs, the associated power or ground pin
name can be defined for APL characterization. If SWEEPSOURCE is not specified, the
name is set by keywords PRIMARY_VDD_PIN or PRIMARY_GND_PIN, if either one is
specified. If none of them is specified, the default is Vdd.
Syntax:
SWEEPSOURCE [<power_pin_for_header> | <gnd_pin_for_footer> ]
Example:
SWEEPSOURCE vdd1
SWEEPVALUE
Specifies the effective voltage values (Vdd - Vss) to be used for characterization instead
of the default values. The effective Vdd values must be larger than 0 and less than ‘10 *
Vdd’. There are eleven default values used for characterization: 1.1*Veff, Veff, 0.9*Veff,
0.8*Veff, 0.7*Veff, 0.6*Veff, 0.5*Veff, 0.4*Veff, 0.3*Veff, 0.2*Veff, and 0.1*Veff .
Syntax:
SWEEPVALUE <eff_vdd_value1> <eff_vdd_value2> ...
Example:
SWEEPSOURCE vdd
SWEEPVALUE 1.0 0.9 0.8 0.7
The output is a list of device capacitance values (“cdev”) at Vdd values of 1.0, 0.9,
0.8, and 0.7 volts.
Example:
SWEEPSOURCE vss
SWEEPVALUE 1.0 0.9 0.8 0.7
VDD 1.0
The output is a list of cdev values at Vss values of 0, 0.1, 0.2, and 0.3 volts.
SWITCH_PRE_DRIVER
Switch pre-drivers are devices inside switch cells that drive the switch transistors. You
can characterize switch pre-driver ESR and ESC values for power/ground arcs by using
APLSW with this keyword. The DC pin specification must make the output of the predriver '1' for header switches and '0' for footer switches, so the switch is in its Off state.
The results of pre-driver characterization are saved in the following format:
CDEV: <arc-based_cap_F> <arc-based_R_ohms>
Syntax:
SWITCH_PRE_DRIVER {
VDD_PIN_NAME <VDD_pinname_pre-driver>
VSS_PIN_NAME <VSS_pinname_pre-driver>
? DC <input_pinname_pre-driver> <voltage_dc_pin> ?
...
}
Example:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 237
SWITCH_PRE_DRIVER {
VDD_PIN_NAME VDD_EXT
GND_PIN_NAME VSS
DC POWERUP_CNTL 1.08
DC POWERON_CNTL 1.08
}
TMP_DIR
Defines the directory used for writing out temporary files.
Syntax:
TMP_DIR <directory_path>
Example:
TMP_DIR /home/tmp
WARN_CLOAD_CHECK
ERROR_CLOAD_CHECK
These options set limits for pre-checking load capacitance values from *.lib files. Default
values are shown in the syntax below. Units: picoFarads.
Syntax:
WARN_CLOAD_CHECK {
S <std_cell_warn_val> # Default: 5
M <mem_cell_warn_val> # Default: 50
I <I/O_cell_warn_val> # Default: 50
}
ERROR_CLOAD_CHECK {
S <std_cell_error_val> # Default: 50
M <mem_cell_error_val> # Default: 500
I <I/O_cell_error_val> # Default: 500
}
Example:
WARN_CLOAD_CHECK {
S 10
M 20
I 30
}
ERROR_CLOAD_CHECK {
S 75
M 300
I 300
}
WARN_SLEW_CHECK
ERROR_SLEW_CHECK
These options set limits for pre-checking input transition time values from *.lib files.
Default values are listed in the syntax below. Units: nsec.
Syntax:
WARN_SLEW_CHECK {
S <std_cell_warn_val> # Default: 5
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 238
M <mem_cell_warn_val> # Default: 10
I <I/O_cell_warn_val> # Default: 10
}
ERROR_SLEW_CHECK <slew_error_val> {
S <std_cell_error_val> # Default: 50
M <mem_cell_error_val> # Default: 100
I <I/O_cell_error_val> # Default: 100
}
Example:
WARN_SLEW_CHECK {
S 2
M 7
I 20
}
ERROR_SLEW_CHECK {
S 30
M 70
I 80
}
WARN_VDD_CHECK
ERROR_VDD_CHECK
MIN_VDD_CHECK
These options set limits for pre-checking nominal Vdd values from .lib files. Default value
for a Warning notice is above 5V, and for an Error notice is above 10V, or below 0.5V
minimum value.
Syntax:
WARN_VDD_CHECK <Vdd_warn_val>
ERROR_VDD_CHECK <Vdd_high_error_val>
MIN_VDD_CHECK <Vdd_low_error_val>
Example:
WARN_VDD_CHECK 3
ERROR_VDD_CHECK 5
MIN_VDD_CHECK 0.7
Parallel Run Keywords
The following ten keywords are optional for parallel runs on Platform LSF or Sun Grid, and
can be defined in the APL configuration file:
BATCH_QUEUING_COMMAND
BATCH_QUEUING_COMMAND specifies the queue command. The default is 'bsub' for
GRID_TYPE LSF. If the GRID_TYPE is SUN_GRID, the default queuing command is
'qsub'.
Syntax:
BATCH_QUEUING_COMMAND <command_name>
Example:
BATCH_QUEUING_COMMAND qsub
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Cell Characterization Data Preparation
RedHawk User Manual
| 239
BATCH_QUEUING_OPTIONS
BATCH_QUEUING_OPTIONS specify run options specific to Platform LSF or Sun Grid
software.
Note: only one BATCH_QUEUING_OPTIONS keyword can appear in the file and all
options must be listed in a continuous line.
Syntax:
BATCH_QUEUING_OPTIONS <options>
Example:
BATCH_QUEUING_OPTIONS -P mary -cwd -b y -p -50 -j y -shell n
-hard -l wrapper=TRUE -V -l aplchar=1 -l arch=lx24-amd64
(for a Sungrid submittal) -rerun <num_times_auto_rerun>
EXEC_PATH
EXEC_PATH specifies the path to the Platform LSF or Sun Grid binaries.
Syntax:
EXEC_PATH
<path name>
Example:
EXEC_PATH /appls/lsf/6.0/linux2.4-glibc2.3-x86/bin
GRID_TYPE
GRID_TYPE defines the parallel run platform. The default is LSF.
GRID_TYPE <LSF | SUN_GRID>
Example:
GRID_TYPE LSF
JOB_COUNT | LSF_JOB_COUNT
JOB_COUNT | LSF_JOB_COUNT specifies the maximum number of simultaneous
characterization jobs that can be submitted (one job per cell). Default is 10. The maximum
is 100 for Sun Grid.
Syntax:
[ JOB_COUNT | LSF_JOB_COUNT ] <max number of jobs >
Example:
JOB_COUNT 20
LSF_ARRAY_SUBMIT_LIMIT
Specifies array submission limit. The job array size that apldi2 uses for first time submit is
based on this keyword. Default: 1000.
Syntax:
LSF_ARRAY_SUBMIT_LIMIT <value>
LSF_JOB_TIME_OUT
APL jobs running under the Platform LSF batch program that are suspended by the
system are killed after a suspended period specified by LSF_JOB_TIME_OUT, which has
a default value of 1 hour. The killed jobs are resubmitted one more time to the LSF farm.
APL also kills jobs that hang because of program or data problems if they take longer than
12 hours.
Syntax
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Custom Cell Characterization Data Preparation
RedHawk User Manual
| 240
LSF_JOB_TIME_OUT <hours>
Example:
LSF_JOB_TIME_OUT 2
Before starting apldi or avm characterization, set the environment variable
APACHEROOT in the csh environment, as follows.
setenv APACHEROOT <path_to_redhawk_release_directory>
LSF_SUBMIT_MODE
LSF_SUBMIT_MODE specifies the Platform LSF job submission mode. 1= bsub, 2= LSF
API. Both modes do the same batch submission. Which one to use depends somewhat
on the user environment. Often LSF API mode 2 runs successfully when bsub mode 1
does not. The default is 1 (bsub).
Syntax:
LSF_SUBMIT_MODE [ 1 | 2 ]
Example:
LSF_SUBMIT_MODE 2
QUEUE
QUEUE allows you to specify the queues for running APL jobs.
Syntax:
QUEUE <queue name> ...
Example:
QUEUE short
TIMER
TIMER specifies the time in seconds between checks on the status of the jobs
submitted.The default value is 60 seconds.
Syntax:
TIMER <value>
Example:
TIMER 10
Custom Cell Characterization Data Preparation
APL can be used to characterize custom cells, including combinational and sequential
cells. For custom cells, you must specify the vectors used for cell characterization and
therefore it requires several user input steps.
Custom cell characterization requires the same data as standard cell characterization,
with the addition of an input vector file. An input vector file must exist for every cell that
needs to be characterized. The configuration file must contain the keyword VECTOR_DIR
to specify the location of the input vector files.
VECTOR_DIR
Specifies the location of the input vector files. The path to the input vector file must be a
full path.
Syntax:
VECTOR_DIR <vector_dirPath>
Example:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Custom Cell Characterization Data Preparation
RedHawk User Manual
| 241
VECTOR_DIR /home/design/input_vectors
Input Vector Files
In APL-DI mode APL calls the libreader program to create the vector file. In APL-DD
mode RedHawk calls libreader to create the vector file. For custom cells you must create
the vector file.
The following parameters are specified in the input vector file.
• Input vectors to be used.
• Pins whose timing arcs determine the delay of the cell.
• Input bias values for intrinsic decoupling capacitance and leakage current estimation.
The name of the input vector file must be <cell_name>.inv and must be created for every
cell that needs to be characterized. The following is a list of keywords used in the input
vector file for custom cell characterization.
• Define the DC bias level for inputs. The name of the dc bias level should be the same
as the Vdd/Vss pin names specified in the APL configuration file. The DC bias level
may also be set by specifying the voltage value or using the voltage value defined in
the param statement, as shown below.
Note: Be careful with the voltage spec, to avoid a mismatch with the APL
configuration file.
Syntax:
param <bias_level> <value>
...
dc <pin1> <bias_level>
dc <pin2> <bias_level>
...
• Specify the primary inputs and outputs. The primary-input-to-primary-output path
defines the primary timing arc that determines the delay for that cell.
Syntax:
active_input <input_pin1> <input_pin2>
<...>
active_output <output_pin>
• Define input vectors.
Syntax:
vector {
vname <input1> <input2> <...>
tunit ps
vih [ <Vdd_name> |<VIH_value> ]
...
<time_step> <input_state_Pin1><input_state_Pin2><...> <state_name>
}
where
vname <input1>... : specifies the input pins, which must be listed in the same
order as the input states.
tunit: defines the time unit.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Custom Cell Characterization Data Preparation
RedHawk User Manual
| 242
vih [ <Vdd_name> | <VIH_value> ]: if Vdd_name is specified, and the APL config
file keyword MULTI_SPICE is set to 1, the VIH value is set to a percentage of
the specified nominal Vdd value. If a VIH_value is given, the high-state
voltage for the specified input pin does not change.
<time_step>: defines multiples of APL-generated unit time step, which depends
on slew, time unit, and slew threshold values. Note that the value is not in
actual time (i.e., ns); APL scales the time appropriately. A time_step_num 0
is required for initialization. Subsequent time step values denote when the
inputs change to toggle the output.
<input_state_Pinx>: defines the input state for Pinx at each time step.
Note: No spaces between vector state values.
<state_name>: user-specified name for state at time step
The following is an example of an input multiple vector file for a five-input combinational
gate. For multiple vector definitions, the tunit and time steps must be the same for all.
dc c vdd
dc d 0
active_input a
active_output y
vector {
vname a b
tunit ps
vih Vdd1
0 10
1 01
5 10
}
vector {
vname e
tunit ps
vih Vdd2
0 1
1 0
5 1
}
Note that input pins ‘a’ and ‘b’ have a different power domain (‘vdd1’) than pin ‘e’ (‘vdd2’).
For combinational logic, a sufficient number of input vector toggles should be specified to
ensure a 0-to-1 and 1-to-0 transition at the output. The following shows the input states
for the above input vector definition. The signal profiles generated for the defined vectors
are shown in Figure 9-2.
• At time step 0, Pin A = 1, Pin B =0
• At time step 1, Pin A = 0, Pin B =1
• At time step 5, Pin A = 1, Pin B =0
This ensures that the output toggles from 0 to 1 and from 1 to 0. The current profiles for
these two output transitions capture the behavior of a combinational cell during dynamic
simulation.
For a sequential cell, a sufficient number of clock toggles and input data pin toggles must
be specified to ensure that the following output states are captured.
• output toggling from 0 to 1, TRAN01
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Custom Cell Characterization Data Preparation
RedHawk User Manual
| 243
• output toggling from 1 to 0, TRAN10
• clock triggering edge with non-toggle output, TRAN11
• clock non-triggering edge with non-toggle output, TRAN00
Figure 9-2
Signal profiles generated for a two-input combination cell.
The following is an example of an input vector file for a sequential cell:
dc scen 0
dc scin 0
active_input clock
active_output nq
vector {
vname clock d
tunit ns
vih 1.2
0 00
2 10
4 01
6 11 tran10
8 01
10 11
12 01
14 10 tran01
16 00 tran00
18 10 tran11
20 00
}
In this example the “tranxx” names are user-assigned state names for the switching
conditions.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Running Cell Characterization
RedHawk User Manual
| 244
The signal profiles generated for the defined vectors are shown in Figure 9-3
Transitions: 1->0
0->1
0->0
Output Pin
Figure 9-3
Signal profiles generated for a sequential cell.
In Figure 9-3, transitions ‘0->0’ means a non-triggering clock edge, ‘1->1’ means a
triggering clock edge, and neither causes the output to toggle (output stays at 1 or 0).
NOTE:
All input vector files, <cell_name-n>.inv, must reside in the directory
specified by the VECTOR_DIR keyword in the configuration file.
Running Cell Characterization
Setup for a Design-independent (Library-based) APL Run
1.
Prepare the APL configuration file defining characterization conditions desired, as
described previously in section "APL Configuration File Description", page 9-217.
2.
Run APL -DI to obtain switching current profiles, device capacitance and
resistance for cell high and low states, and leakage current for all library cells.
Setup for a Design-dependent APL Run
For design-specific characterization:
1.
Prepare the GSR file for running RedHawk. Refer to Appendix C, “File Definitions”.
2.
Select the GUI command APL -> Setup in RedHawk, or use the TCL command
setup apl -dir <dir_name>
This generates two intermediate files required for APL characterization, apache.apl
and adsLib.output, and places them in the <dir_name>/.apache directory.
In addition, four types of APL configuration file templates are created in the
specified <dir_name> directory, to assist in preparing the proper configuration files
for characterization:
•
•
•
•
apl.custom.config
apl.io.config
apl.memory.config
apl.std.config
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Running Cell Characterization
RedHawk User Manual
| 245
Cell list files for all four types of cells are also placed in the <dir_name> directory.
3.
Prepare the APL configuration file defining characterization conditions desired, as
described previously in section "APL Configuration File Description", page 9-217.
4.
Run APL-DD to obtain switching current profiles, device capacitance and
resistance for cell high and low states, and leakage current for all design cells.
5.
For low power designs with power-up cycles, run APL additionally for header and
footer components and for decap (pwcap). See section "Low Power Design
Characterization", page 9-248.
Setup for Enhanced Design-Independent Characterization
To automatically generate additional design-specific samples to supplement those from
APL-DI library characterization, set the GSR keyword APL_DID to 1. During the RedHawk
run, APL runs automatically to cover instances that are not covered well in the APL-DI
library, providing a transparent, quick and automatic incremental characterization with
APL-DI accuracy.
To make Spice models and libraries available, a “packaging” step is performed during the
APL-DI phase. A sub-directory ‘PACKAGE’ is created under the directory
APLDI_[yyyymmdd]/corner[n]/CURRENT/
which contains all Spice files, the apache.apldi file (APL-DI sample file), and a designspecific configuration file derived from the APL-DI configuration file. All the necessary
Spice files are collected here, and the ‘include’ file paths in these files are modified to be
local.
For previously-generated DI libraries, a utility ‘aplgenpkg’ can be used to create the
PACKAGE sub-directory without having to rerun APL-DI. To do this, go to the APL-DI run
directory and execute the command:
aplgenpkg –d APLDI_[yyyymmdd] –c <apldi_config_file>
where APLDI_[yyyymmdd] is the directory containing the current files you are using.
You must import APL-DI using the directory format (instead of a single *.current file)
during RedHawk ‘import apl’ in order to take advantage this enhanced characterization
capability. Use the TCL command:
import apl <file>
where <file> is of the form
APLDI/APLDI_20070310/corner1/CURRENT
Running APL Characterization from a UNIX Shell
All APL characterization procedures can be executed from a UNIX shell using the
following syntax. By default design-independent current characterization is performed on
the full cell library.
% apldi [-c] [-w] [ -l <cell_file> | -p <decap_file> ]
? -o <output_file>? ? -s [1|2]? ?-j [1|2]? ?-v?
?-fc ? <apl_config_file>
where
-c: runs decap characterization on library cells
-w: runs pwcap characterization for low power designs
-l <cell_file>: runs APL only on the cells specified in the cell file.
-o <output_file>: writes the characterization result to specified file. The default is
*.spcurrent for DD switching current characterization, *.cdev for decap
characterization, and *.pwcdev for low power characterization.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Running Cell Characterization
RedHawk User Manual
| 246
Note: Do not specify the reserved names *.spiprof (intermediate working files),
*.spcurrent, *.cdev or *.pwcdev as extensions for output file names.
-p <decap_file>: specifies intentional decap cells for characterization. An example
of a decap file is shown with the decap example invocations in the following
sections. The input pins of the decap cells are defined in the sub-circuit
library, with arbitrary ordering. (Should not be combined with -c option.)
-s [ 1 | 2] (for APL_RUN_MODE DI only): 1 - generates samples only, does not
run characterization; 2 - runs APL without generating samples, such as for a
design-dependent characterization, when samples for the design have
already been generated during the ‘setup apl’ phase. This option is
ignored if APL_RUN_MODE is set to DD.
-j [1 | 2]; indicates a multiple machine run with 1: Platform LSF bsub mode, or 2:
Platform LSF API mode (allows use of more options)
Note: The -j option also must be used for a SunGrid submittal; the number is ignored
if specified.
-v: displays messages in detail (“verbose” mode)
-fc: runs fast library checking mode for potential data problems in the cell library.
<apl_config_file>: specifies the configuration filename. Note that this file is
required and should be the last argument in the command.
Note that the characterization mode by default is design independent. The mode can be
set to design-specific using the APL_RUN_MODE keyword in the APL configuration file.
lmwait is supported in apldi utility to wait for license availability for a defined amount of
time rather than immediate exit
Usage:
setenv APACHEDA_LICENSE_WAIT <xxx:unit sec>
Apldi utility waits for time as set by above variable before erroring out
Multiple Vdd /Vss Decap Cells
Since decap cells are not present in the LIB files, their characterization is different from
standard cells. For multiple Vdd/Vss decap cells, Vdd and Vss values and P/G pin
information must be specified, as shown below:
1.
Vdd values are specified using the 'DECAP_VDD_PIN' keyword in the APL config
file (apldi.config), as in the example below:
DECAP_VDD_PIN {
VDD 1.2
VDDPST 3.3
}
2.
P/G pin information is read from the custom lib file, specified by the
‘CUSTOM_LIBS_FILE’ keyword in the APL config file:
CUSTOM_LIBS_FILE {
<custom.lib>
}
The format of the specified <custom.lib> file is as follows:
cell TIEOFF_LL {
pin VDD {
type vdd
}
pin VDDPST {
type vdd
}
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Running Cell Characterization
RedHawk User Manual
| 247
pin VSS {
type gnd
}
pin VSSPST {
type gnd
}
In addition to the specifications above, since LIB does not have any information on
intentional decap cells, power/ground arcs for designs with multiple Vdd and multiple Vss
decaps must be defined manually by the user in the pgarc.lib file (default name), along
with other pgarc definitions. Examples of these declarations in the pgarc file are given
below:
cell <decap_cell_name> {
pgarc {
<vdd> <vss>
...
}
}
For example:
cell decap234 {
pgarc {
VDD
VSS
VDDPST VSSPST
}
}
Sample APL Invocations
The following are examples of UNIX shell invocations of APL for design-specific
characterization:
% apldi -s 2 -l cell_list2 apl.config
Runs APL switching current characterization on the cells found in file cell_list2 on a
local machine. Results are in the file ./cell.spcurrent.
% apldi -j 2 -s 2 -l cell_list2 apl.config
Runs APL switching current characterization on the cells found in file cell_list2 on a
parallel batch farm.
% apldi -l cell_list1 -c apldi.config
Runs APL decap characterization on the cells designated on a local machine. The
results are in default file ./<cell>.cdev.
% apldi -p decap_cell_list6 apl.config
Runs APL decap characterization on the intentional decap cells found in the
decap_cell_list6. The results are in file ./<cell>.cdev.
The syntax for a decap list file is as follows:
Syntax:
<cell_name1>
...
<cell_nameN
Example:
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Running Cell Characterization
RedHawk User Manual
| 248
DECAP123
DECAP678
The following are examples of UNIX shell invocations of APL for library cell (designindependent) characterization:
% apldi -j 2 apldi.config
Runs APL switching current characterization on the cells designated on a parallel
batch farm. The results are in the default file corner*.current, where * is a corner
number.
% apldi -j 2 -c -l cell_list_dc apldi.config
Runs decap characterization in multiple machine batch mode on cells found in file
cell_list_dc. The results are in file corner*. cdev.
% apldi -j 2 -w cell_list_pw apldi.config
Runs APL in multiple machine batch mode on low power cells found in file
cell_list_pw. The results are in file corner*.pwcdev.
Low Power Design Characterization
Characterization for Low Power Designs
Accurate power-up simulation using header or footer switches requires characterization of
the cells in the design to get the piecewise linear models for intrinsic capacitances,
leakage currents, and effective series resistance, as a function of voltage.
For multiple Vdd and multiple Vss low power designs, pwlcap characterization is arcbased. The arc is characterized based on the keywords PRIMARY_VDD_PIN and
PRIMARY_GND_PIN in APL configuration file, with a format the same as that for singlerail cells. The syntax for these keywords is provided below:
PRIMARY_VDD_PIN <vdd_pin_name>
PRIMARY_GND_PIN <gnd_pin_name>
which specify the primary Vdd and Vss pin names. The Vdd names should match the
power pin names found in the SPICE subcircuit netlist. These names may be different
than the design’s power net names specified in the GSR file.
The APL utility apldi -w -s 2 is used to characterize a list of standard cells or decap cells
present in a low power design, or in a complete library (apldi -w), to generate the required
PWL model. The UNIX shell command syntax is:
% apldi -w [ -l <cell_list_file> | -p <decap_list_file> ]
[-o <output_file>] <apl_config_file>
Basically the same configuration file is used for low power designs as for other APL
characterizations. When characterizing piecewise linear capacitance, leakage, and
resistance data for standard cells, the power or ground pin is specified as a sweep
source. For header- based designs, the effective voltage on the Vdd pin is swept from
near-zero to Vdd, while in footer- based designs the effective voltage on the Vss pin is
swept from near-Vdd to zero. The associated power/ground pin name for the header or
footer switch can be specified with the APL configuration file keyword (default pin name
Vdd):
SWEEPSOURCE [<power_pin_for_header> | <gnd_pin_for_footer> ]
The default set of eleven characterization voltages (0.1 fractions of the effective voltage,
Vdd-Vss, from 0.1*Veff to 1.1*Veff) can be replaced using the configuration file keyword:
SWEEPVALUE <eff_vdd_value1> <eff_vdd_value2> ...
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Multi-Job Management in APL
RedHawk User Manual
| 249
The output file from the above characterization can be included for a subsequent
RedHawk analysis by using the GSR command:
PIECEWISE_CAP_FILE <PWL_cap_file>
Switch Characterization with aplsw
Header and footer switches in low power designs are characterized using the aplsw
utility and a switch model file. Non-ideal piecewise linear control pin inputs can be
accommodated in the current modeling. The UNIX shell command syntax is:
aplsw [-c] [-d] [-o <output_file>] <sw_config_list.conf>
where
-c: check generated result
-d: debug mode
-o <output_file>: output file name
<sw_config_list.conf>: switch configuration list file
For more information about the modeling and analysis of switches, see section "Low
Power Analysis Switch Modeling", page 13-322.
Multi-Job Management in APL
APL submits jobs on "9.x LSF" version where LSF env uses feature called Job array to
perform Job Management. All jobs in the array share the same job ID and parameters.
Usage:
1. Specify LSF submit mode in APL config
GRID_TYPE lsf
BATCH_QUEUING_COMMAND bsub
LSF_SUBMIT_MODE 3
BATCH_QUEUING_OPTIONS -J shortjob
//-- array submission
'-J' option helps to "Assign the specified name to the job". APL will assign each job with
unique ID to identify the job. If user does not specify, APL will use aplchar as job array
name
2. Make sure to specify "-j 1". Array submission is supported ONLY in bsub mode.
Example:
$APACHEROOT/bin/apldi2 -l list -j 1 apl.current.config
3. From this version, APL uses its own mechanism to monitor job, won't query LSF
daemon anymore.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Output Files
RedHawk User Manual
| 250
The default LSF Array size of LSF 9.x is 1000. So, in sample split mode, please make
sure the LSF array size is bigger than APL jobs number, else, submission will fail.
Output Files
Overall Process Files
Process Log Files
The primary process log files are written in the adsRpt/Log/ directory and contain the
detailed status of the characterization process, including messages from subprograms,
and information on which computations for each cell have been completed successfully,
which ones have failed, which ones need to be characterized, the characterization
conditions, Spice error messages and a numerical summary of these statistics. The
process log files have the following filename formats:
• current: apl.current.log.<time_stamp>
• decap: apl.cap.log.<time_stamp>
• pwcap (low power): apl.pwcap.log.<time_stamp>
where <time_stamp> takes the form ‘2006-05-02-11:52’. Under /adsRpt/ each
characterization run creates a top level log file that soft-links to the latest results file,
although previous versions are still available in the directory.
The previous apldi.*.log files have been replaced by the apl.*.<time_stamp> files in the
./adsRpt/Log/ directory.
An example current log file is shown below:
Nominal VDD used: 1.8
Temperature used: 25
Netlist used: /../spice/cellabc.sp
Voltage range: 2.07 1.8 1.62 1.35
#
|------- slews --------|
stat #smpl #smpl_done c_min c_max rs_min rs_max fs_min fs_max vec cell_name
pass 70
70 1.00 278.8 0.012 2.500 0.012 2.500 LIB bufx1
Error and Warning Files
Error flags during characterization are written into adsRpt/Error directory files with the
following filenames:
• current: apl.current.err.<time_stamp>
• decap: apl.cap.err.<time_stamp>
• pwcap (low power): apl.pwcap.err.<time_stamp>
Warning flags during characterization are written into adsRpt/Warn/ directory files with
the following filenames:
• current: apl.current.warn.<time_stamp>
• decap: apl.cap.warn.<time_stamp>
• pwcap (low power): apl.pwcap.warn.<time_stamp>
Under /adsRpt/ each characterization run creates a top level /warn/err file that soft-links
to the latest results file, although previous versions are still available in the directory.
Status Log File
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Output Files
RedHawk User Manual
| 251
The output of the aplstat <apl_config_file> command displays on screen, and
writes to a log file aplstat.log in the run directory, a summary of the cell characterization
process as it progresses (the cells that have been characterized successfully, the cells
that have failed and the cells still pending), including the reason for failure for each cell
characterization that was unsuccessful. A sample portion of an APLSTAT log is shown
below:
APLSTAT: Apache Power Library Cell-characterization
Status Monitor
#### Cell Status ####
#### 1606 Cells Succeeded ####
AND2_wxyz pass
AND2_nmop fail
AND2_rstu pass
AND2_qvwx pass
...
Results Files
Each type of characterization generates a set of output files for holding results. Both
design-independent library characterization and design-specific characterization can
generate three types of files as desired, one set for switching waveforms, one for decap
and one for piecewise linear decap for ramp-up low power applications. Each type of
output has a default filename, but the filename can be specified using the option
apldi -o <filename>
APL-DI Output Files
• Switching waveform files - contain a set of current profiles for all switching conditions
for each cell in the library. Default filename: /<corner_name>.current
• Decap files - contain the intrinsic decap values, as well as ESR and leakage current
for each cell in the library, including specified intentional decap cells. Default filename:
/<corner_name>.cdev
• Power-up decap files - contain the piecewise linear voltage relationships for intrinsic
decap values, as well as for ESR and leakage current for each cell in the library,
including specified intentional decap cells. Default filename:
/<corner_name>.pwcdev
APL-DD Output Files
• Switching waveform files - contain a set of current profiles for all switching conditions
for each cell in the design. Default filename: /<cell>.spcurrent. The maximum
number of nodes in the *.spcurrent file that can be used in analysis is 1 billion.
• Decap files - contain the intrinsic decap values, as well as ESR and leakage current
for each cell in the design, including specified intentional decap cells. Default filename:
/<cell>.cdev
• Power-up decap files - contain the piecewise linear voltage relationships for intrinsic
decap, as well as for ESR and leakage current for each cell in the design, including
specified intentional decap cells. Default filename: /cell.pwcdev.
Individual Cell Characterization Files
Characterization Results
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Output Files
RedHawk User Manual
| 252
APL generates a set of result files in a default results directory. For each characterization
process APL generates cell results files with the following default filenames and
directories:
APL-DI Cell Results Files
• cells: <results_dir>/corner*/CURRENT/<cellname>.spiprof
• decaps: <results_dir>/corner*/CAP/<cellname>.cdev
• low power: <results_dir>/corner*/PWCAP/<cellname>.pwcdev
The default <results_directory> for these output files is APLDI_<time_stamp>/ under the
run directory.
APL-DD Cell Results Files
• cells: <results_dir>/CURRENT/<cellname>.spiprof
• decaps: <results_dir>/CAP/<cellname>.cdev
• low power: <results_dir>/PWCAP/<cellname>.pwcdev
The default <results_directory> for these output files is APLDD_<time_stamp>/ under
the run directory.
Using the APL configuration file keyword ‘APL_RESULT_DIRECTORY <results_dir>’
allows you to specify a different results directory for the output cell characterization files.
Cell Log Files
In the APL results directory there is also a cell log file for each cell that records all Info,
Warning, and Error messages recorded during characterization of that cell. These files
have the following default directories and filename formats:
APL-DI Cell Log Files
• current: <results_dir>/ corner*/CURRENT/<cellname>.current.<time_stamp>.log
• cap: <results_dir>/ corner*/CAP/<cellname>.cap.<time_stamp>.log
• pwcap: <results_dir>/ corner*/PWCAP<cellname>.pwcap.<time_stamp>.log
The default <results_directory> for these output files is APLDI_<time_stamp>/ under the
run directory.
APL-DD Cell Log Files
• current: <results_dir>/CURRENT/<cellname>.current.<time_stamp>.log
• cap: <results_dir>/CAP/<cellname>.cap.<time_stamp>.log
• pwcap: <results_dir>/PWCAP<cellname>.pwcap.<time_stamp>.log
The default <results_directory> for these output files is APLDD_<time_stamp>/ under
the run directory.
Using the APL configuration file keyword ‘APL_RESULT_DIRECTORY <results_dir>’
allows you to specify a different results directory for the output cell log files.
APL Results Checking and Processing
To check the general validity of APL results data, look at final statistics summaries from
the cell results files, or to convert formats or sort cell data, use the aplchk utility from a
Unix command line. The command evaluates data in the specified APL result file or
directory for data range and missing information, or filters and compiles data for particular
cells. It also checks the consistency of cell types (combinational /sequential) and their
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Output Files
RedHawk User Manual
| 253
transitions ( 0->0, 1->1, 0->1, 1->0) in the current profiles to ensure that current profiles
for sequential cells have all four transitions and combinational cells have only 0->1 and 1>0 transitions.The aplchk utility reports corrupted cells in the log file and continues to scan
cells. When all checks are completed, the list of failed cells is reported in the adsRpt/
aplchk.log file. The syntax of the command is:
aplchk <input_file/dir> ?-v ? ?-l <list_file>? ?-w <output_file>?
?-c? ? -pwc <pwcdev_file>? ? -conf <APL_config_filename> ?
?-spice <apl config file>?
where
<input_file/dir>: name of input file or directory containing switching current, cdev,
or pwcdev decap data to process. APLCHK can identify the checking object;
whether it is a single APL file or a directory, APLCHK checks all APL data in
that file or directory.
-v: prints warnings in std error format (verbose mode)
-l <list_file>: writes out result information on cells named in <list_file> to the
specified <output_file>
-w <output_file>: specifies an output filename
-c: specifies checking cdev decap files
-pwc: specifies the pwcdev characterization results file to be used by aplchk.
When both old format and new format pwcap files are to be merged, the
merged result is in the new format.
-lib <config_filename>: specifies APL config file containing APL results and LIB
files.
-spice <apl config file>: dumps spice waveforms to validate cdev modelling of an
instance.
The following is an example of an aplchk command:
aplchk -l listAB -w cellMN.current
which writes out data on the cells in listAB into the cellMN.current result file. The
aplchk.log file reports information such as the tool version, run path, starting time of run,
command used to run, and runtime/memory details, as well as aplchk results.
Keywords for Checking Limits
The aplchk utility supports global parameter check limits, cell type-based check limits and
cell name- based check limits. The following APL configuration file keywords can be used
to define global standard cell checking limits for aplchk:
IMAX_STDCELL_WARN <I_peak>
Specifies the max peak current warning limit for standard cells (uAmps). Default:
100,000uA
ITAIL_STDCELL_WARN <I_max_tail>
Specifies the max tail current warning limit for standard cells (uAmps). Default: 10uA or
0.3*Peak current value, whichever is larger.
SLEWMAX_STDCELL_WARN <max_trans_time>
Specifies the max output transition time (“slew”) warning limit for standard cells (ps).
Default: 3,000,000 ps
DELAYMAX_STDCELL_WARN <max_delay>
Specifies the max input-output delay warning limit for standard cells (ps). Default: 30,000
ps
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Output Files
RedHawk User Manual
| 254
FIREMAX_STDCELL_WARN <max_fire_time>
Specifies the max input-output firing time warning limit for standard cells (ps). Default:
30,0000 ps
CMAX_STDCELL_WARN <max_cap>
Specifies the threshold for allowable standard cell capacitance. The default allowable
capacitance value is 1000pf.
RMAX_STDCELL_WARN <max_ESR>
Specifies the threshold for allowable standard cell resistance. The default allowable
resistance value is 1000K Ohms.
LEAKMAX_STDCELL_WARN <Warning_leakage_threshold>
LEAKMAX_STDCELL_ERROR <Error_leakage_threshold>
Specifies the Warning and Error thresholds for allowable standard cell leakage current.
The default Warning leakage threshold is 10uA and the default Error leakage threshold is
1A
LEAKMAX_MEMORY_WARN <Warning_leakage_threshold>
LEAKMAX_MEMORY_ERROR <Error_leakage_threshold>
Specifies the Warning and Error thresholds for allowable memory leakage current. The
default Warning leakage threshold is 0.5A and the default Error leakage threshold is 1A.
PWC_VDD_MAX_WARN <Max_Vdd>
Specifies the Warning threshold for the maximum allowable Vdd value. The default
allowable Vdd value is 5.0V.
The following configuration file keyword and options can be used to set cell-specific
checking limits, defined the same as for the global limits above.
CELL_CHECK_LIMITS <cellname> {
IMAX_WARN <uAmps> Defaults: standard cell - 1.0e+5; memory cell - 1.0e+6
ITAIL_WARN <uAmps> Defaults: standard cell - 10; memory cell - 0.5e+6
SLEWMAX_WARN <ps> Defaults: standard cell - 30,000; memory cell - 30,000
DELAYMAX_WARN <ps> Defaults: standard cell - 30,000; memory cell - 30,000
FIREMAX_WARN <ps> Defaults: standard cell - 30,000; memory cell - 30,000
}
The following APL config file keywords can be used to define global memory and I/O cell
checking limits for aplchk:
IMAX_MEMORY_WARN <I_peak>
Specifies the max peak current warning limit for memory cells (uAmps). Default:
1.0e+6uA
ITAIL_MEMORY_WARN <I_max_tail>
Specifies the max tail current warning limit for memory cells (uAmps). Default: 0.5A or
0.3*Peak current, whichever is larger.
SLEWMAX_MEMORY_WARN <max_trans_time>
Specifies the max output transition time (“slew”) warning limit for memory cells (ps).
Default: 3,000,000 ps
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Output Files
RedHawk User Manual
| 255
DELAYMAX_MEMORY_WARN <max_delay>
Specifies the max input-output delay warning limit for memory cells (ps). Default:
3,000,000 ps
FIREMAX_MEMORY_WARN <max_fire_time>
Specifies the max input-output firing time warning limit for memory cells (ps). Default:
3,000,000 ps
CMAX_MEMORY_WARN <max_cap>
Specifies the max capacitance warning limit for memory cells (pf). Default: 10pf
RMAX_MEMORY_WARN <max_ESR>
Specifies the max effective power circuit resistance warning limit for memory cells
(Ohms). Default:1.0e5 Ohms
LEAKMAX_MEMORY_WARN <max_leakage>
Specifies the max leakage current warning limit for memory cells (Amps). Default: 1.0A
Resistance, Capacitance, and Leakage Histogram
A histogram of the distribution of capacitance (F), resistance (Ohms), and leakage current
(A) values is created for each aplchk run, for both logic low and logic high states. A
histogram file for an aplchk devcap invocation, such as:
aplchk -c <cell>.cdev
is shown in the following example:
Capacitance range:
<1.000000e-15
1.000000e-14
1.000000e-13
1.000000e-12
>=1.000000e-12
Resistance range:
<1.000000e+01
1.000000e+02
1.000000e+03
1.000000e+04
>=1.000000e+04
Leakage range:
<1.000000e-12
1.000000e-10
1.000000e-08
1.000000e-06
1.000000e-04
>=1.000000e-04
No. of cells c0
0
0
178
27
0
No. of cells r0
0
0
150
55
0
No. of cells leak0
0
29
176
0
0
0
No. of cells c1
0
0
172
33
0
No. of cells r1
0
0
140
65
0
No. of cells leak1
0
12
192
1
0
0
Reports of Cells with no APL Data or samples
Cells without APL current profiles are reported by RedHawk in the file adsRpt/
apache.inst.libCurrent.
Cells without decap information are reported in the file adsRpt/apache.refCell.noAplCap.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Importing and Merging Characterization Data Files in RedHawk
RedHawk User Manual
| 256
Cells without voltage-dependent decap information (for low power analysis) are reported
in the file adsRpt/apache.refCell.noAplPwcap.
A report file is generated during APL import, apache.refcell.noAplSample, identifying cells
with APLDI data, but no APL samples.
Importing and Merging Characterization Data Files in RedHawk
Importing APL Files
There are several ways of importing APL *.current and *.cdev files and AVM
characterization files into RedHawk. The recommended method is by specifying the files
by type using the GSR keyword APL_FILES, as follows:
APL_FILES {
<APL_binary_filename>
current
<APL_binary_filename>
cdev
<Avm.conf_filename>
avm
<AVM_binary_filename> current_avm
<AVM_binary_filename> cap_avm
<APL binary filename> pwcap
...
}
Another importing method is to use the TCL command
import apl <APL_file>
Note that ‘import apl <current-file>’ and ‘import apl -c <cdev-file>’
commands have accumulative effects. That is, subsequent multiple imports are merged.
The APL_FILES method is preferred because it can handle current/cap/leak/pwc files and
directories, while the GUI menu and TCL commands can only handle one current and cap
file at a time.
Note: If there is both an ‘import apl <file>’ in the command file and
APL_FILES in the GSR file, then the command takes over and APL_FILES is
ignored.
To allow control of improper file inputs, there are several checks that are made on
imported characterization files. RedHawk stops on some APL import errors, such as an
APL utilities returned error code, and provides ways to continue the RedHawk flow with
flexibility. You have the following options to control import errors:
• By default differences in model, Vdd, and temperature in input files are ignored.
• Ignore all types of errors with the command
gsr set ignore_apl_check 1
• Fix the data and re-run APL.
• To continue, type the TCL command
import apl
to redo importing from APL_FILES.
• Or, instead of using APL_FILES input, you can use the GUI command APL -> Import
menu command, and fill out the dialog form.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Importing and Merging Characterization Data Files in RedHawk
RedHawk User Manual
| 257
Merging APL Result Files
The ‘aplmerge’ utility, invoked from a Linux/Solaris command line, quickly checks the
compatibility of corner conditions (P, V, T) for similar types of APL files to be merged, such
as <cell>.current and <cell>.cdev, and, if they are compatible, merges them into a single
output file. The ‘aplmerge’ utility supports three types of input-source specifications:
• individual APL data
• a directory containing APL data
• a file containing a list of cells to be merged
and each input-source specification is independent of the others. If any of the input data is
not in the current working directory, its path must be specified.
Also, ‘aplmerge’ can merge <cell>.spcurrent files that have different resolutions, such as
50-point files and 400-point files.
The syntax of the command is:
aplmerge [-c] [-pwc] [-rep] [-l <cell_list_filename>]
[-im] [-t] [-o <output_file>] [-avm] [-ilimit]
[<file1> [<file2> [...]]] [<directory>] [-fl <list_file>]
aplmerge [-c] [-pwc] [-rep]
[ -l <cell_list_file> | <directory> | [<file1> <file2> ...] ]
[-im] [-t] [-o <output_file>] [-avm] [-ilimit]
where
-c: specifies merging intrinsic decap files
-pwc: specifies merging piecewise linear decap files for power-up analysis
-rep: specifies replacing all information on cells in <file1> with information on cells
with the same name in <file2>. Cell information not duplicated in the second
file remains the same in the output file.
-l <cell_list_file>: specifies the file that defines the cells to be included in the
merged output file. If the cell files are not in the run directory, the file path
should be specified. Used for .spiprof and .cdev files with one cell per file.
In the cell list file, list the cell names whose APL data need to be merged,
along with the full path to the data, in the following format, one line for each
entry: ‘<full or relative path>/<cellname>’. Do not specify the names of the
files or the directory.
Note that the option '-l' is independent of any <directory> specified at the end
of syntax line.
-im: specifies that model entry checking is to be ignored
-t: specifies turbo mode, which runs faster by skipping duplicate cell checks
-o <output_file>: defines the output file. Default: cell.spcurrent.merge
-avm: merge AVM current regardless of header differences
-ilimit: ignore checking limit
<file1> <flle2> ... : specifies files to be merged into the output file
<directory>: specifies a directory containing cells to be merged
-fl : allows users to specify a list file containing files to be merged. The format of
the list file is:
Cell1.spcurrent
Cell2.spcurrent
Cell3.spcurrent
Typical examples:
aplmerge -o <cellA>.current -l CellListABC
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
aplccs (CCS2APL) Library Characterization
RedHawk User Manual
| 258
aplmerge -o <cellB>.current CellDirEFG
You can also provide wildcard filenames with aplmerge, as in the following example:
aplmerge -o <cell>.current *.spiprof
which merges all input files with the extension *.spiprof into an output file called
<cell>.current.
aplccs (CCS2APL) Library Characterization
Introduction and Syntax
The ‘aplccs’ utility converts CCS library data to APL switching current data format.
The advantages of using CCS2APL are:
• transparent to RedHawk tools. You can generate CCS2APL DI library before a
RedHawk run.
• CCS2APL data are fully supported by APL utilities
• very fast conversion time.
• timing information in CCS2APL data are hard values
For standard cell conversion
• supports diagonal-type sparse cload table.
• multi-nominal Vdd value merging for a same cell is supported only when the same
slew normalization factor/temperature/pg_pins/states/samples are found among the
different nominal Vdd libraries.
• CCS lib has no cload concept for C00/C11 toggles. aplccs performs sample expanding
for C00/C11 toggles, which means for a C00/C11 toggle, the waveforms for a specific
slew value are all the same.
For memory, I/O and custom cells:
• supports characterization of cells that have C-load independent states by using a
default Cload value of 1 fF for such cells.
• supports multi output cell.
Syntax for invoking aplccs is as follows:
aplccs [-o <output_file>] -mstate_cells <cell_list_file>
-conf <aplccs_config_file> [-skip_ps]
where
-o <output_file> : specifies the output filename (default - ccs.current)
-mstate_cells : specifies a multi-state cell list file supporting multiple-state APL
current characterization data for standard cells
-conf: specifies a aplccs configuration file
-skip_ps : skips PowerStream run when PSLIB file .apache/apache.pslib is
generated.
Example when generating PSLIB apache/apache.pslib:
aplccs -skip_ps -o ccs.current
Example for no PSLIB:
aplccs apl.config -o ccs.current
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
I/O Cell Characterization
RedHawk User Manual
| 259
APLCCS Configuration File
The aplccs run-related configuration file keywords in apldi config file are shown following:
1.
LIB_FILES/ LIBS_DIRECTORY/ LIBS_FILE
See section "APL Configuration File Description", page 9-217.
2.
RETRY_VECTORLESS [ 0 | 1]
To be used when aplccs fails to convert the CCS lib to APL using the default
vectors, which is the same one used in APL characterization. Specify this keyword
to force the conversion using random vectors. Note that this may cause the inexact
comparison to APL.
3.
IGNORE_CELLS {
<cellname1>
...
}
Used to void the CCS2APL current generation failure due to some cells with unexpected CCS lib formats (corner case). Using this keyword ignores the failed cells
and generates the CCS2APL current file for the rest of cells in the library.
Importing the CCS Lib Directly
Instead of using the aplccs utility to do the conversion before a RedHawk run, the CCS lib
can be directly imported into RedHawk; CCS2APL conversion is transparent in the
RedHawk flow. The GSR keyword to turn on CCS lib import is “LIB_USE_CCS 1".
The keyword “CCS_OVERRIDE_APL 1" is only for cases in which CCS has a higher
priority than APL when both exist. “CCS_OVERRIDE_APL 1" works only when
“LIB_USE_CCS 1" is set.
There is also an aplccs keyword to convert the CCS lib (which contains intrinsic_parasitic
ESC/ESR and leakage_curernt) to APL cdev, as follows:
CONVERT_CCS_CAP [0|1]
The default is 0; set to 1, CCS=>CAP conversion is performed.
Note that the user has the responsibility to ensure that the meaning of CCS
intrinsic_parasitic ESC and ESR is the same as APLCAP. This feature is off by default.
I/O Cell Characterization
Input/output cells can inject a significant amount of noise into the core, especially if the
Vss is shared between I/O and core, and therefore I/Os should be included in dynamic
analysis. I/O cells are special, since they have multiple Vdd pins for the core and I/O
supply. Therefore, both core and I/O Vdd/Vss pins’ current must be characterized.
An I/O cell typically has multiple input or control pins, which must be accurately
characterized. The correct values for input and control pins are obtained by preparing an
input vector file for the I/O cell, as described in the section below, and in the section
"Custom Cell Characterization Data Preparation", page 9-240.
I/O Cell Characterization Procedure
1.
Define the I/O Vdd pin and its value. Note the I/O Vdd pin is defined in the SPICE
‘.subckt’ line, not in the .lib file.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
I/O Cell Characterization
RedHawk User Manual
| 260
dc <io_vdd_pin_name> <value>
2.
Define open pins for monitoring or scanning, where no connections are necessary.
openpin <open_pins>
3.
Define voltage source parameters and define the I/O Vdd pin value.
param vddo=1.5
param vref=1.2
dc VDDQ15 vddo
For input signals, you may let APL automatically generate the input stimuli, or use the
VECTOR statement.
4.
For automatic stimuli generation, define the ‘active_input’ pins. Do not use
automatic stimuli generation for differential I/O cells.
active_input clk
For user-generated stimulus, define the VECTOR statement as shown below. All
timing parameters use TUNIT as time unit. The values can be either “0” (low) or “1”
(high). APL assumes that the first signal is the active input pin.
VECTOR {
VNAME <signal_names>
TUNIT <ps|ns|us|ms>
VIH <input_high_value>
SLOPE <slope_value>
<time0> <value_pin1><value_pin2><...>
<time1> <value_pin1><value_pin2><...>
...
}
5.
Loading. An I/O cell usually drives large loads all the way to the board. Therefore, it
is often necessary to add an off-chip load to the I/O cell's output to obtain realistic
current profiles. This is realized by including the load circuitry and its respective
subcircuit definitions in the input vector file (<design>.inpvec), as shown below.
OUTPUT <output_pin_name> <output_load_subckt_name>
Following is an example use of the OUTPUT statement.
OUTPUT Y0 pkg_board_load
where the subcircuit, pkg_board_load, is defined in the included file called
pkg_board_load.subckt.
include pkg_board_load.subckt
whereas the included file, pkg_board_load.subckt, contains the following
subcircuit:
.subckt pkg_board_load chip_node
X1 chip_node bga_node pkg_load
X2 bga_node far_end_node board_load
.ends pkg_brd_load
.param P_DELAY=2
.subckt board_load nearend farend
*pc board
CLOAD1 nearend 0 0.5pF
TPCB nearend 0 L11 0 Z0=50 TD='180P*P_DELAY'
CLOAD2 L11 0 0.5PF
Rload L11 farend 5
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
I/O Cell Characterization
RedHawk User Manual
| 261
CLOAD3 farend 0 3.5pF
.ends board_load
* signal I/O package
.subckt pkg_load n1 n2
c1 n1 0 10f
L1 n1 n2 10pH r=5m
c2 n2 0 10f
.ends pkg_load
Additional Keywords for I/O Cells (Optional)
The following keywords are available to further customize I/O cell characterization.
TSTEP, TSTOP
TSTEP and TSTOP define the step size and stop time parameters for transient
simulation.
Syntax:
TSTEP <step size><unit>
TSTOP <stop time><unit>
Example:
TSTEP 0.1ns
TSTOP 50.0ns
OP
OP defines the dump time for decap characterization.
Syntax:
OP <time1><unit> <time2><unit>
where
<time1>: specifies the time output goes high
<time2>: specifies the time output goes low
Example:
OP 10ns 15ns
tranXX
The tranXX parameter defines switching window starting times. Note that the window
should be large enough to allow adequate sampling points.
Syntax:
tranXX <time><unit>
where
tranXX <time>: XX defines the output value change and <time><unit>
specifies the time of occurrence after t=0 and the time unit.
Example:
tran01 10.0ns
tran10 30.1ns
tran00 5.0ns
tran11 15.0ns
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 262
Note: tranxx also can be put at the end of the <time_step_num> line in the input
‘Vector’ section, in which case it has a higher priority than when specified by itself.
Refer to the section "Input Vector Files", page 9-241.
ioprobe
The ioprobe parameter defines the Vdd and/or Vss pins to probe and their current polarity.
Note that in Spice positive current direction is INTO the positive pin of a voltage source.
Syntax:
ioprobe <VDDname> <+|->
<VSSname> <-|+>
Example:
ioprobe VDD - VSS +
NOTE:
Only one representative sample is considered for an I/O cell.
Characterization of I/O Cells
To obtain the most accurate I/O cell characterization use the sim2iprof utility for current
profiles (see section "sim2iprof", page E-895) and the ACE utility for device capacitance
characterization (see section "ACE Decap and ESR Characterization", page 9-262). For a
much faster, but less accurate, process, use the AVM datasheet characterization utility
(see section "AVM Datasheet Characterization", page 9-270).
Memory and IP Characterization
To obtain characterization data for memory, custom IP and I/Os, the same as APL creates
for standard cells, there are two choices, depending on the need for either very accurate
current profiles or a fast run time and good current profile accuracy:
• Accurate sim2iprof and ACE characterization
The sim2iprof utility provides very accurate switching current profiles for memories
and I/Os, while ACE provides equivalent power circuit resistance, device capacitance,
and leakage current data.
• Fast AVM datasheet characterization
AVM is a rule-based utility for quick generation of power circuit characterization data
for memory and other types of IP. AVM converts a datasheet-based input specification
into triangle-based or trapezoidal current profiles, equivalent power circuit resistance,
device capacitance, and leakage current.
Sim2iprof Switching Current Characterization
For details on preparing the configuration file and running sim2iprof to generate memory
switching current profiles, see section "sim2iprof", page E-895.
ACE Decap and ESR Characterization
ACE estimates the P/G pin intrinsic and intentional decap values for all types of memory
and other complex IP blocks. It uses a unique tracing algorithm to find the P/G network in
a cell, and calls SPICE to characterize representative MOSFET's gate capacitance, and
generates various types of capacitance and effective resistance values for the cell in APL
format, as well as an estimate of leakage current. ACE also traces R elements in power/
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 263
ground nets using DSPF information (*|NET, *|I ...) to identify relevant capacitance. You
can then inspect, merge, and import ACE results into the RedHawk database to perform
DvD analysis.
ACE can recognize header/footer switches embedded inside a memory or a functional
block. This is especially useful for low-power design, since many cells come with the
switches built-in. Since ACE uses a net tracing algorithm, it runs extremely fast. For a
half-million MOSFET cell, the typical run time is approximately a minute on a Linux box.
Identifying tied-off devices as decaps
ACE automatically identifies tied-off devices as decaps, including the following
configurations of device connections:
For tied-off conditions, treat as decaps.
a.
nmos:
- source/gate ties to ground, drain to power.
- drain/gate ties to ground, source to power.
b.
pmos:
- source/gate ties to power, drain to ground.
- drain/gate ties to power, source to ground.
For the following combinations, assign zero current, but do not treat as decap:
a.
nmos:
- source/gate ties to ground, drain to signal.
- drain/gate ties to ground, source to signal.
b.
pmos:
- source/gate ties to power, drain to signal.
- drain/gate ties to power, source to signal.
Identifying special pins for PWCap characterization
ACE automatically identifies special pins, such as retention pins in power management
cells. These pins are identified from the Liberty attributes. The correct retention condition
for such cells is picked from the lib and used during pwcap characterization. This process
has no effect on current or cap characterization.
ACE Configuration File
ACE requires an input configuration file, using the keywords described on the following
pages (names are not case sensitive). The required keywords are:
• External_power_net
• External_ground_net
• Subckt
• Modelfile
Note that new nanometer device model libraries are often too complicated to be
specified using ‘Modelfile’. The libraries also can be encapsulated using the ‘Include’
keyword instead of ‘Modelfile’.
• VddValue
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 264
Other configuration file keywords are optional.
Ace_HSpice <path/binary>
Specifies that HSpice is used as the characterization simulator. You only need to
specify this keyword when HSpice is needed. The default simulator is NSpice.
Ace_Eldo <path/binary>
Specifies that ELDO is used as the characterization simulator. You only need to
specify this keyword when ELDO is needed. The default simulator is NSpice.
Ace_Spectre <path/binary>
Specifies that Spectre is used as the characterization simulator. You only need to
specify this keyword when Spectre is needed. The default simulator is NSpice.
ACE_OPTION {<options> }
Provides options to control ACE simulation, such as
SIMULATOR_COMMAND_OPTION -spectre
which invokes the '-spectre' option when using the Finesim simulator.
Decap_Subckt
Defines sub-circuit-based intentional decap instances in the Spice netlist. The
syntax and usage is described following.
DECAP_SUBCKT {
<decap_subckt_name1> <port_type_list1> param <param_list1>
<decap_subckt_name2> <port_type_list2> param <param_list2>
...
<decap_subckt_nameN> <port_type_listN> param <param_list3>
}
where
<decap_subckt_nameN>: describes the subcircuit name of the intentional decap
instance
<port_type_listN>: defines the type of subckt port connection, either power,
ground, or signal net, designated as 'power', 'ground', or 'na' in the port type
list ('na' designates a signal net connection)
Note that there must be one item in the <port_type_list> for each pin name.
param <param_list>: defines the parameters that determine the size of the
intentional decap instance. For example, in a Spice netlist as follows:
XDECAP1 PLUS MINUS NMOSCAP lr=6.3u wr=3.92u m=4 ...
XDECAP2 PLUS MINUS NMOSCAP lr=3.3u wr=1.92u m=8 ...
...
External_Power_Net <ext_power_pin> ...
Defines the external power pin(s) of the cell. Different power pins represent different
power domains. The power pin names must be Spice pin names declared in the
Spice subckt file. You must provide power pin names using this keyword for ACE to
trace the power nets inside the Spice subckts. See also Internal_Power_Net and
VP_Pairing keyword usage.
External_Ground_Net <ext_ground_pin> ...
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 265
Defines external ground pin(s) of a cell. Different ground pins represent different
ground domains. The ground pin names must be Spice pin names declared in the
Spice subckt file. You must provide ground pin names using this keyword for ACE to
trace the ground nets inside the Spice subckts. See also Internal_Ground_Net and
VP_Pairing keyword usage.
FINFET_UNIT_WIDTH <w_meters>
ACE identifies a unique length for transistors for cdev characterization. FinFET
transistors are defined by the number of fins (NFIN) and their length (L), instead of
device width and length. In 16nm technology ACE only traces the unique size
transistors with different lengths, and you must specify the fin width using this
keyword. In 16 nm FinFET technology the transistor width parameter no longer
exists.
FLIP_WELL
Using this keyword ACE can handle cells made from FDSOI technology, or the flipwell process. FLIP_WELL must be set to 1 to enable this feature.
Global <node_name> [<node_name> ... ]
Defines global nodes (nodes that are connected in all hierarchical levels).
Ignore_Decap_Subckt_Checking [ 0 | 1 ]
Allows you to control of whether ACE errors out or just prints a warning message
when a decap subckt is not instantiated. Set the keyword to 1 to prevent ACE from
erroring out. Default is 0.
Ignore_Subckt
Specifies capacitance contributions to be excluded from the specified subckt(s) and
their descendents. This is useful when you want to extract, for example, only the
capacitance contributed by the top level elements, and ignore subckt contributions.
The syntax is:
Ignore_subckt {
<subckt_name>
...
}
Include <file>
Used to include needed Spice files, such as a subckt definition, or Spice model file.
Internal_Power_Net <internal_power_pin> ...
Internal_Ground_Net <internal_gnd_pin> ...
Specifies separate internal P/G nets for header or footer switches in the ACE
configuration file. So for switch cases, internal nets have different entries in the
<>.mcap file. ACE handles hierarchical internal nets by using hierarchical power/
ground pin names, with “.” as a hierarchy divider. In this way you can include all RC
elements related to this net in ACE characterization, but this can be used only with
a hierarchical subcircuit netlist. Also, Cdev characterization for internal nets can be
performed using these keywords. The switch cap between external and internal
nets is ignored. The output Cdev contains entries for both external and internal
nets. Use also the keyword VP_PAIRING, as follows.
EXTERNAL_POWER_NET <external_power_pin/net> ...
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 266
EXTERNAL_GROUND_NET <external_gnd_pin/net> ...
INTERNAL_POWER_NET <internal_power_pin/net> ...
INTERNAL_GROUND_NET <internal_gnd_pin/net> ...
VP_PAIRING
<internal_net> <external_net>
? SWITCH_SUBCKT [<switch_subckt_name> |
<switch_filename>]?
An example subcircuit appears as follows:
.SUBCKT BLOCK in out vdd vss nd5
Xswitch ctrl vdd net_int SWITCH
Xinv net_int vss in out INV
.ends
.SUBCKT testckt in1 in2 out1 out2 vdd vss
Xblock1 in1 out1 vdd vss nd5 BLOCK
Xblock2 in2 out2 vdd vss nd5 BLOCK
.ENDS
Sample ACE configuration file settings are shown following:
EXTERN_POWER_NETS vdd
INTERNAL_POWER_NET Xblock1.net_int Xblock2.net_int
VP_PAIRING (Xblock1.net_int vdd) (Xblock2.net_int vdd)
EXTERN_GROUND_NETS vss
VDDVALUE vdd 0.85
switch_sub SWITCH
The output mcap file then contains Cdev entries for both external and internal nets.
An example aplreader output would be:
Info: Reading cdev file- 'testckt.mcap'
Info: cell= testckt
Info: pin= vdd cap= 0.389455 pf, res= 2.56772 ohm, leak= 20 uA
Info: pin=Xblock1.net_int cap= 13.866 pf, res= 0.072121 ohm, leak= 40 uA
Info: pin=Xblock2.net_int cap= 30.1777 pf, res= 0.03313 ohm, leak= 60 uA
Info: pin= vss cap= 16.2794 pf, res= 0.0615381 ohm, leak= 120 uA
K_GROUND_CAP/K_FLOAT_CAP
Using these keywords ACE can extract signal net capacitance from the DSPF
netlist, and adds its value in the cdev file generated (ACE classifies parasitic
capacitance into three types: P/G parasitic cap, grounded cap, and floating cap.)
K_GROUND_CAP defines the fractional contribution of grounded signal cap to P/G
parasitic cap, and K_FLOAT_CAP defines the fractional contribution of floating
signal cap to P/G parasitic cap. Their default value is 0.5, and their allowable range
is 0 to 1.0.
K_GROUND_CAP <value>
K_FLOAT_CAP <value>
Leakage_i
Specifies per-arc leakage current in Amps. Required when the low power ‘-pwc’
option is used in ACE, with the syntax:
Leakage_i {
<vdd_pin1> <gnd_pin1> <leakage_A>
...
}
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 267
Metal_Resistor/ Metal_Resistor_File
These keywords allow ACE to trace through resistors defined as subcircuits and
include transistors that are connected beyond the subcircuit resistors, which then
enables cap characterization of MOS transistors connected after the resistors. To
perform resistor trace-through, the subcircuit names must be defined using the
syntax:
METAL_RESISTOR <model_name1> <model_name2> ...
or
METAL_RESISTOR_FILE <path to metal resistor file>
The format of the contents of the specified METAL_RESISTOR_FILE is as follows:
<Resistor_model_name1>
<Resistor_model_name2>
<Resistor_model_name3>
...
ModelFile <file> <corner>
Specifies Spice device model library and process corner case.
MOS_Report [ 0 | 1 ]
When set to 1, produces a <cellname>.mos.report file, as shown in the following
example of a MOS report for a memory:
Mos Name W L Count Domain
psvtlp 0.875 0.06 12 vdda
nsvtlp 0.46 0.06 14 vss
psvtlp 2.5 0.06 12 vdda
NOMINAL_VDD <vdd_domain1> <v1> ?<vdd_domain2> <v2>?
Specifies the nominal Vdd value for each Vdd domain when they are different from
the value specified by the keyword VDD_VALUE, which is user-specified in the
APLMMX configuration file, or in the ACE input file. If 'NOMINAL_VDD' is not
specified when SIGNAL_PARASITIC_C is turned on, a warning is displayed and
the nominal Vdd value is assumed to be the same as specified by VDD_VALUE.
NMOS_Model_Name <model_name>
Defines the NMOS model name if a device model file is not specified.
PMOS_Model_Name <model_name>
Defines the PMOS model name if a device model file is not specified.
Option <Spice_option>
Specifies any standard Spice option to be passed to the Spice deck for ACE decap
characterization. Multiple OPTION definitions are allowed on separate lines.
Example: OPTION scale=1e-6
Option parhier=[ local | global ]
Specifies the priority of hierarchical parameter. The default value is ‘global’.
Preprocess_Subckt_File [ 0 | 1 ]
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 268
When set, improves handling of the configuration view Spectre netlist, which
contains the test bench setup, so that the “tran” statements in the test bench and
any other Include files that are not relevant for capacitance characterization are
automatically skipped, reducing overall ACE runtime (default 0).
Primary_Power_Net <pin_name>
Primary_Ground_Net <pin_name>
Supports PWL cap data for low power analysis using the ACE '-pwc' option. When
using the '-pwc' option, you must specify leakage values in the ACE configuration
file using keyword 'Leakage_i' to get an accurate value. If you specify the primary
pin names, ACE uses the specified arc to perform post-processing and generates
pwcap data. If you do not specify the primary pin name, ACE by default uses the
first P/G pins listed as the primary P/G pins.
SIGCAP_FACTOR <value>
Specifies the fraction of the signal net capacitance to be included in P/G pin cap
(<value> between 0 and 1). The default value is 0.5.
SIGNAL_PARASITIC_C [ 0 | 1]
When SIGNAL_PARASITIC_C is turned On, signal net Cload is added to P/G net
intrinsic capacitance. The default is 0, off.
Simulator_Command_Option <option>
Supports use of NSpice, HSpice, Eldo, and Spectre tools. Adding this parameter to
the ACE configuration file appends specified user options to the Spice simulation
command line.
SPICE_SIMULATOR <option>
Supports the '-spectre' option when invoking the “Finesim“ option simulator. In
addition, the following ACE configuration file keyword should be specified:
ACE_OPTION {
SIMULATOR_COMMAND_OPTION -spectre
}
Subckt <file>
Defines the Spice subckt netlist for the cell. The P/G pin names in the netlist must
be consistent with the pin names specified in External_Power/Ground_Net.
SweepValue <v1> <v2> ...
Specifies voltage sweep values for PWCAP data generation when the ACE ‘-pwc’
option is specified. If you do not specify voltage sweep values, ACE by default uses
11 standard Vdd values to do scaling (10%, 20%, ..., 100%, and 110% of Vdd).
Switch_Subckt [ <switch_subckt_name> | <switch_subckt_filename> ]
Defines the name of a header/footer switch subckt or a Spice-format switch
subcircuit filename. Note that the subckt(s) definition must be encapsulated in file(s)
specified by SUBCKT or INCLUDE constructs. For low power cells that have the
switch built-in, you must declare the switch subckt using this keyword. For cells that
do not have header/footer switches, you do not need to specify this keyword.
Temperature <value>
Specifies the temperature value for MOSFET characterization.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 269
Toggle_Rate_Assignment
Assigns different toggle rates to different sub-circuits inside a block or IP, in addition
to the top level. To use this feature, add the following in the ACE configuration file:
TOGGLE_RATE_ASSIGNMENT {
<subcircuit_1> <toggle_rate1>
<subcircuit_2> <toggle_rate2>
...
}
VP_Mapping (<LEF_pin> <Spice_pin>) [...]
Defines the P/G pin mapping between LEF and Spice netlists. If the P/G pin names
are different in LEF and Spice, you need to use this keyword to define the mapping
output result file. ACE uses Spice pins during characterization, and uses the LEF
pin name in the output result file.
VddValue <vdd_domain> <voltage> [ <vdd_domain> <voltage> ... ]
Specifies Vdd domain name(s) and corresponding value(s). These values are used
during MOSFET characterization. The Vdd domain names must be consistent with
those specified in External_Power_Net.
ACE supports multiple nominal Vdd characterization using the following syntax:
VDDVALUE <vdd_pin1 value1a> [<vdd_pin2 value1b>…]
VDDVALUE <vdd_pin1 value2b> [<vdd_pin2 value2b>…]
In this syntax <*value1a> and <*value1b> represent different voltage corners of
multiple nominal characterization.
VP_Pairing (<internal_net1> <external_net1>) ( ... )
Defines P/G pairs for internal and external nets. If there are any switches present in
the cell, you must specify the P/G pairs using this keyword. Otherwise this keyword
is not necessary. See also use of Internal/External_Power_Net and Internal/
External_Ground_Net keywords.
VTH_FACTOR <value>
The scaling factor VTH_FACTOR specifies whether signal capacitance is to be
added to Vdd pin intrinsic capacitance. When SIGNAL_PARASITIC_C is set to 1,
for each Vdd domain, if VDD_VALUE > VTH_FACTOR*NOMINAL_VDD, the signal
net Cload for that domain is added to P/G pin capacitance accordingly. The
VTH_FACTOR <value> must be a floating point number between 0 and 1. Default
is 0.5.
WRAPSUB <subckt_name> [... ]
When a subckt name is specified using this keyword, ACE looks for 'm' instead of 'x'
as the leading character in the element line, for instances in the HSIM-wrapper
processed netlist. This rule only applies to specified subckts. Other subckts still
follow the normal SPICE rule, which uses 'x' as the leading character for subckt
instances.
XMOS_INST_PARAM [ ON|OFF ]
When set, parses all instance parameters of the first XMOS instance in a table of
unique size listings. The default value is off.
XMOS_PARAM_MAPPING ? width <w>? ?length <l>?
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 270
Allows specification of “width” and “length” options for devices in the device model
file.
Running ACE Characterization
After preparing the ACE input configuration file as described above (<cellname>.smin),
the command for invoking ACE from a UNIX command line is:
ace [-d] [-o <output_file>] [-toggle_rate <On_fraction> ] [-pwc ]
<cellname>.smin
where
-o <output_file>: specifies output filename for the CDEV file
-toggle_rate <On_fraction>: controls the fraction of On time for intrinsic
MOSFETs, and thus their effective capacitance (ESC) value. The
<On_fraction> should be between 0 and 1. A larger toggle_rate results in a
smaller intrinsic ESC value, since it means more transistors are switching
and acting less like capacitance.
-pwc: specifies generation of PWL capacitance data for low power analysis.
Output Result Files
ACE generates three files in the APL result directory:
• <cellname>.mcap - default ACE output file, CDEV file format (pin-based
capacitance), to be imported into RedHawk
• <cellname>.ace.mmx - more detailed pin capacitance data (intentional, intrinsic,
parasitic) to be imported into MMX
• <cellname>.ace.decap - detailed intentional decap information, including a list of each
unique sized MOS decap, its sizes (W, L), model name, decap value, and the P/G pins
it connects to. Another list is the total decap contribution to each P/G arc, with each
decap cell's instance count.
AVM Datasheet Characterization
For dynamic analysis, if APL characterizations are not available for some memory cells,
RedHawk can automatically collect the necessary data from the design, LIB files and the
GSR and create an AVM (Apache Virtual Model) configuration file in adsRpt/avm.conf,
which describes parameters such as read/write/standby mode, power consumption,
access time, setup time, load information, and current waveform type, for each memory
type. RedHawk internally uses this config file to generate and use rule-based current
profiles, leakage current and decoupling capacitance for memory blocks. The AVM utility
then creates triangular current profiles for these memory cells that have no APL data.
The GSR keyword that invokes automated AVM characterization is:
LIB2AVM [ 0 | 1 | 2 | 3 | 4]
By default (1), a double triangular-shaped profile is provided (to accurately simulate
complicated profiles). When set to 2, a trapezoidal-shaped current profile is provided.
When set to 3, load-dependent triangular-shaped profile is provided. A value of 4 provides
load-dependent trapezoidal-shaped current profile. Any available APL memory
characterization data overrides internally-generated AVM data. A value of 0 turns off
automated AVM config file generation. Memories are identified based on the following
attributes in *.lib for AVM generation: ‘memory ( )’, or ‘timing( ){mode...}’. If
multiple internal power tables with different related pins are available, the Cpd value
calculation is prioritized as:
1.
active pins (VCD)
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 271
2.
if a related pin is a clock pin the power table with related pin clock will be used for
Cpd calculation.
3.
if none of the related pins is active and no clock pin the power table leading to the
highest Cpd will be used.
Some key features of AVM are:
• Can be run standalone, independent of the design (see next section).
• Applies to dynamic flow only.
• If Ipeak is specified, the base width is adjusted to honor both Ipeak and Cpd.
• Curve generation is enhanced to minimize the difference between the AVM results and
user-specified Ipeak and Cpd.
• The tail current is set to 0 for all curves.
• The % difference between the AVM results and user-specified Ipeak and Cpd values is
reported during the AVM run.
• To invoke the accurate characterization mode, include the following keyword:
CHARACTERIZATION_MODE ACCURATE
• To check the base width of the AVM current profile, use the keyword:
MAX_FREQ <frequency in Hz>
AVM base width at nominal Vdd should be < 1/MAX_FREQ.
• Memories with multi-state power values are intelligently handled by lib2avm, in that
only the states present in the VCD file are considered for power calculation. The
power values in the .lib corresponding to the Boolean state of the VCD determine the
total power of the instance. The GSR keyword ‘LIB2AVM_MSTATE 1’ should be set.
• AVM peak time is modified in accordance with any voltage derating that occurs. Peak
voltage derating maintains the same power level, which extends the time base and
peak of the triangular waveform.
Running AVM standalone
The LIB2AVM utility can be run standalone. By providing transition time and load
information, memory cells can be characterized separately, from the UNIX command line,
using the following syntax:
lib2avm <lib2avm_config_filename> -l <cell_list_filename>
You can specify the equivalent gate count for the block using the keyword
‘EQUIV_GATE_COUNT <count>’ in the LIB2AVM configuration file.
AVM Configuration File
Before running AVM characterization a configuration file must be prepared. The basic
AVM configuration file syntax, which supports multiple nominal Vdd/Vss domain cells, is
as follows:
<memory name> {
MEMORY_TYPE [ SRAM |BLOCK |DRAM |CAM |ROM |RegFile | MSRAM |IP | BLOCK
| IO | MEMORY ]
EQUIV_GATE_COUNT <count>
Cload <load_in_F>
VDD_PIN <VDD_pin1> <VDD_pin2> ...
GND_PIN <GND_pin1> <GND_pin2> ...
CHARACTERIZATION_MODE [ accurate | ultra_accurate | PWL |
PWL1 ]
PROCESS [SS | TT | FF ]
C_decap {
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
<VDD_pin_m> <GND_pin_n> <C_decap-ARC1>
<VDD_pin_o> <GND_pin_p> <C_decap-ARC2>
...
}
c_decap [ (<Volt_a2> <Volt_b2> ...) ] {
...
leakage_I [ (<Volt_a1> <Volt_b1> ...) ] {
<vdd_pin_m><gnd_pin_n> <leakage_i_ARC1>
<vdd_pin_o><gnd_pin_p> <leakage_i_ARC2>
...
}
leakage_I [ (<Volt_a2> <Volt_b2> ...) ] {
...
}
VDD <voltage1_VDD_pin1> <voltage1_VDD_pin2> {
ck2q_delay <delay_in_sec>
tr_q <time_in_sec>
tf_q <time_in_sec>
tsu <time_in_sec>
Cpd_read {
<VDD_pin_m> <GND_pin_n> <Cpd_read-ARC1>
<VDD_pin_o> <GND_pin_p> <Cpd_read-ARC2>
...
}
Cpd_write {
<VDD_pin_m> <GND_pin_n> <Cpd_read-ARC1>
<VDD_pin_o> <GND_pin_p> <Cpd_read-ARC2>
...
}
Cpd_standby {
<VDD_pin_m> <GND_pin_n> <Cpd_read-ARC1>
<VDD_pin_o> <GND_pin_p> <Cpd_read-ARC2>
...
}
}
VDD <voltage2_VDD_pin1> <voltage2_VDD_pin2> {
ck2q_delay <delay_in_sec>
tr_q <time_in_sec>
tf_q <time_in_sec>
tsu <time_in_sec>
Cpd_read {
<VDD_pin_m> <GND_pin_n> <Cpd_read-ARC1>
<VDD_pin_o> <GND_pin_p> <Cpd_read-ARC2>
...
}
Cpd_write {
<VDD_pin_m> <GND_pin_n> <Cpd_read-ARC1>
<VDD_pin_o> <GND_pin_p> <Cpd_read-ARC2>
...
}
Cpd_standby {
ANSYS INC - Apache Design Business Unit
| 272
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 273
<VDD_pin_m> <GND_pin_n> <Cpd_read-ARC1>
<VDD_pin_o> <GND_pin_p> <Cpd_read-ARC2>
...
}
...
}
Leakage_I {
<VDD_pin_m> <GND_pin_n> <Leakage_I-ARC1>
<VDD_pin_o> <GND_pin_p> <Leakage_I-ARC2>
...
}
...
}
where
<memory name>: name of memory macro as defined in LEF. Units follow the
same conventions as in the GSR file (see Appendix C).
MEMORY_TYPE [ SRAM | BLOCK |DRAM | CAM | ROM | RegFile | MSRAM | IP
| BLOCK | IO | MEMORY ]: identifies the type of item
If MEMORY_TYPE 'BLOCK' is specified, default values for 'tsu', 'tr_q', 'tf_q'
are 200 ps, and 'Cpd_standby' is set to 10 pF. The default values for
'Cpd_read' and 'Cpd_write' are set to 20 pF;
If MEMORY_TYPE 'IO' is specified, a single triangular shape is used as the
default;
If MEMORY_TYPE 'MEMORY' is specified, internally the same as SRAM,
this is the generic type for lib2avm purpose;
The default values can be changed by specifying different values for the
parameters in the AVM config file.
EQUIV_GATE_COUNT <count>: specifies the equivalent gate count, which can
be derived from the number of bit cells. For example, a 512x70 memory
should be 35840 equivalent gates.
Cload: loading capacitance on an output pin, in Farads. Default is 100 f F
VDD_PIN <VDD_pin1> <VDD_pin2>/ GND_PIN <GND_pin1> <GND_pin2>: By
default, VDD_PIN and GND_PIN are optional, and their default values are
VDD and GND respectively. If the power and/or ground names are different
or multiples, you must specify these keywords. The Cpd and decap must be
specified per power pin. If there is a single ground pin, the current profile of
the ground pin is the sum of all the Vdd pins. If there are multiple grounds,
the current profile is defined according to the P/G arc file described in the
section "P/G Arc Definitions in Custom LIB Files", page 3-20.
CHARACTERIZATION_MODE : set to ‘accurate’ creates a waveform with 400
time points (equally-spaced samples) to store the APL current profile.
‘ultra_accurate’ mode has 1000 time points (equally-spaced samples), and
PWL creates a Piece-Wise-Linear waveform. If set to PWL1, AVM can
handle “MEMORY_TYPE RegFile" For all other
CHARACTERIZATION_MODE, waveform is created as “MEMORY_TYPE
SRAM”.If CHARACTERIZATIOM_MODE is not set, the default waveform
generated by AVM has 50 time points (equally-spaced samples).
PROCESS : specifies a process type, where SS is slow, TT is typical, and FF is
fast. Required.
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 274
C_decap <VDD_pin_m> <GND_pin_n> <C_decap-ARCn>: specifies decap
values for all P/G pin arc combinations. <Volt_a1> and <Volt_b1> represent
different voltage corners for multiple nominal characterization, and
<vdd_pin_m> and <gnd_pin_n> represent the vdd-vss arc of the capacitance
value specified.
VDD <voltage1_VDD_pin1> <voltage1_VDD_pin2>: specifies voltage
combinations for various VDD pins
ck2q_delay: specifies clock-to-output pin delay (sec) for the associated VDD pin
voltages
tr_q: specifies output pin rising transition time (sec) for the associated VDD pin
voltages
tf_q: specifies output pin falling transition time (sec) for the associated VDD pin
voltages
tsu: specifies setup time (sec) for the associated VDD pin voltages
Cpd_read <VDD_pin_m> <GND_pin_n> <C_decap-ARCn>: specifies Cpd_read
values for all P/G pin arc combinations, in Farads
Cpd_write <VDD_pin_m> <GND_pin_n> <C_decap-ARCn>: specifies Cpd_write
values for all P/G pin arc combinations, in Farads
Cpd_standby <VDD_pin_m> <GND_pin_n> <C_decap-ARCn>: specifies
Cpd_standby values for all P/G pin arc combinations, in Farads
Additional optional AVM configuration file keywords are described below:
• Specifying voltage scaling factors:
AVM_VOLTAGES <num_voltages> <v_scale_factor1>
<v_scale_factor2> ...
• Specifying trapezoidal or triangular current profiles. Default is triangular.
WAVEFORM_TYPE [trapezoidal | triangular]
• Specifying leakage current, in Amps.
leakage_i {
<VDD_pin> <GND_pin> <current_in_Amps for ARC1>
<VDD_pin> <GND_pin> <current_in_Amps for ARC2>
...
}
• Specifying peak current values for Write, in Amps, for triangular waveform model.
Peak_I_Write {
<VDD_pin> <GND_pin> <current_in_Amps for ARC1>
<VDD_pin> <GND_pin> <current_in_Amps for ARC2>
...
}
• Specifying peak current values for Read, in Amps, for triangular waveform model.
Peak_I_Read {
<VDD_pin> <GND_pin> <current_in_Amps for ARC1>
<VDD_pin> <GND_pin> <current_in_Amps for ARC2>
...
}
• Specifying peak current values for Standby, in Amps, for triangular waveform model.
Peak_I_Standby {
<VDD_pin> <GND_pin> <current_in_Amps for ARC1>
<VDD_pin> <GND_pin> <current_in_Amps for ARC2>
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 275
...
}
• Specifying peak times for Write, in seconds, for triangular waveform model.
Peak_T_Write {
<VDD_pin> <GND_pin> <time_in_sec for ARC1>
<VDD_pin> <GND_pin> <time_in_sec for ARC2>
...
}
• Specifying peak times for Read, in seconds, for triangular waveform model.
Peak_T_Read {
<VDD_pin> <GND_pin> <time_in_sec for ARC1>
<VDD_pin> <GND_pin> <time_in_sec for ARC2>
...
}
• Specifying peak times for Standby, in seconds, for triangular waveform model.
Peak_T_Standby {
<VDD_pin> <GND_pin> <time_in_sec_ARC1>
<VDD_pin> <GND_pin> <time_in_sec_ARC2>
...
}
• Specifying minimum period of memory from starting edge for calculating Eff VDD, in
seconds.
TMIN <time_sec>
• Specifying delay derating factor for delta voltage:
Delay_Derating <factor range between 1 to 10>
• Specifying capacitance of the most primitive gate, such as an inverter:
Gate_cap <cap in F>
• Specifying design-dependent operating temperature in degrees C (default is 25):
TEMPERATURE <actual_temperature>
• Specifying average power for high block activity:
Avg_High_Power <power in Watts>
• Specifying average power for low block activity period:
Avg_Low_Power <power in Watts>
• Specifying operating frequency:
Freq <freq in Hz>
• Specifying the fraction of clock power consumption relative to total block power:
Cknt_Power_Ratio <power fraction>
• Specifying the fraction of sequential element power consumption relative to total block
power:
Seq_Power_Ratio <power fraction>
• Specifying charge_ratio value, for triangular waveform model.
CHARGE_RATIO <factor between 0.0 to 1.0>
Specifies the second triangular waveform's area (charge) divided by the total area
(charge). The default value is 0.7.
• Specifying the data version.
DATAVERSION [ 7v1 | pre7v1 ]
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 276
Specifies the data version of the vmemory.current file relative to RedHawk version
7.1. The default is pre7v1.
• Specifying the maximum frequency for checking the base width at nominal Vdd value;
the base width should be < 1/MAX_FREQ.
MAX_FREQ <freq>
The following is a sample avm configuration file:
Cell1 {
MEMORY_TYPE RegFile
EQUIV_GATE_COUNT 6663
Cload 2f
VDD_PIN VDDPR VDDP
GND_PIN VSS
C_decap {
VDDPR VSS 11.0022509561f
VDDP VSS 11.0022509561f
}
VDD 1.08 1.08 {
ck2q_delay 1537p
tr_q 30.194p
tf_q 27.621p
tsu 523.65p
Cpd_read {
VDDPR VSS 1158.88203017832647f
VDDP VSS 11.88203017832647f
}
Cpd_write {
VDDPR VSS 2213.82030178326475f
VDDP VSS 22.82030178326475f
}
Cpd_standby {
VDDPR VSS 409.293552812071331f
VDDP VSS 4.293552812071331f
}
}
VDD 1.32 1.32 {
ck2q_delay 2537p
tr_q 40.194p
tf_q 37.621p
tsu 623.65p
Cpd_read {
VDDPR VSS 2158.88203017832647f
VDDP VSS 18.88203017832647f
}
Cpd_write {
VDDPR VSS 3213.82030178326475f
VDDP VSS 13.82030178326475f
}
Cpd_standby {
VDDPR VSS 509.293552812071331f
VDDP VSS 9.293552812071331f
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Memory and IP Characterization
RedHawk User Manual
| 277
}
}
AVM Configuration File for Multi-state mode
If multiple state Boolean switching scenarios are specified, the configuration file must be
modified. Note that multi-state mode supports only memory/IP cells, and not combination
and sequential cells. If keywords ‘Cpd_write’, ‘Cpd_read’, ‘Cpd_standby’,
‘leakage_I_write’, ‘leakage_I_read’, ‘peak_I_write’, ‘peak_I_read’, ‘C_decap_write’,
‘C_decap_read’ are in the file, they are ignored. Two additional keywords should be
added to the multi-state AVM configuration file, as follows:
CUSTOM_STATE_FILE <filename> (see page E-902)
or
STATE_BOOLEAN <state_name>
clock_pin> ?<output_pin>?
...
<Boolean_eq>
<active_pin/
and
Cpd <state_name> {
<vdd_pin> <vss_pin> <arc_cap_F>
...
}
where
<state_name>: user-defined state name in CUSTOM_STATE_FILE
<vdd_pin> <vss_pin> : vdd/vss pins for specified state
<arc_cap_F>: capacitance for specified state and Vdd/Vss arc
In addition, several optional keywords for multi-state mode are available:
• Optional Peak current, in Amps.
peak_I <state name > {
<vdd_pin> <vss_pin> <arc_current_A>
...
}
• Optional peak time, in seconds.
peak_T <state name > {
<vdd_pin> <vss_pin> <peak_time_sec>
...
}
Sample AVM configuration file for multi-state
CUSTOM_STATE_FILE <custom_state_file>
ABC_Mem1 {
...
Cpd M0 {
VDD VSS 15pF
}
Cpd M1 {
VDD VSS 20pF
}
Cpd M2 {
VDD VSS 10pF
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Troubleshooting APL Problems
RedHawk User Manual
| 278
}
Cpd M3 {
VDD VSS 10pF
}
...
}
Running AVM
Once the AVM configuration file is created, run avm from the shell command:
avm <avm_configuration_file>
AVM Outputs
AVM generates the current profile (vmemory.current) and decap information
(vmemory.cdev) from the datasheet specification, and automatically incorporates it into
the RedHawk simulation. The percent difference between AVM results and user-specified
Ipeak and Cpd also are reported for the AVM run. Other AVM output files are avm.log,
avm.warning and avm.error.
Troubleshooting APL Problems
Checking the Configuration File
The following are recommended APL configuration file checks:
• Are all required keywords specified properly?
• Are Vdd values consistent with those in the GSR file?
• Are temperature values consistent with those in *.lib and the Tech files?
• Are specified names of Vdd and Gnd pins consistent with the Spice netlist?
• Are device sizes in the Spice netlist in um? If not, set the SIZE_SCALE keyword to a
value such that the result is microns, such as 1e-6.
Common Problems
• Vector information missing in .apache/adsLib.out.
- LIB file missing
- Function statement or state table missing inside LIB file
• Spice netlist missing.
• Incorrect Spice model file
- Missing parameter definitions
- Wrong scale parameters used
- Unsupported Spice cards used
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Sample APL Configuration File
RedHawk User Manual
| 279
• Trying to characterize unintended cells:
- Doing current characterization on tie-off cells, antenna diodes, etc.
- Doing characterization on decap cells without using the ‘–p’ option.
- Trying to characterize complex cells without the required custom vectors
• Vectors used in the simulation not causing a rise/fall transition at the output.
• Insufficient disk space. Watch TMP_DIR.
• Monitor and sample count.
Debugging Command Line APL Errors
• Try debugging only one cell at a time. Create a <cell>.list file containing only one cell.
• Run characterization in non-LSF mode. You can see STDOUT messages.
• For current characterization, make sure that .apache/adsLib.output has the required
vector data for the cell.
• Make sure that the Spice netlist exists for the cell in the SUBCKT file.
• Set DEBUG 1 flag in APL configuration file.
• Use verbose mode (-v) to get more detailed messages.
• Use debug mode (-d)
• Make sure that the function statement/state table is present in LIB file
• Look at the Spice netlist (.apache/APL/<cell_name>.sp)
• Look at the Spice waveforms using SV and make sure that you are seeing rise / fall
transitions.
• Create a small Spice deck for the cell. Run it in NSpice and see whether it is creating
the transitions.
- nspice cell.test.spi
• Look at whether the failures have some common aspects
- Look at the machine/platform/Queue of failing cells.
- Look at the cell type/functionality
• If APL characterization failed with the following NSpice error
##error## Isolated node (node name) detected. Simulation stopped.
which means there is no DC path between the node and ground, you can add
‘OPTION gshunt=1e-9’ in the APL configuration file to avoid simulation failure.
• If APL samples cannot be generated due to incomplete data, RedHawk lists the
names of the cells with missing data in the file adsRpt/apache.refCell.noAplSample,
and issues Warning message (ITG-022).
Sample APL Configuration File
The following is an example library APL configuration file, with comments explaining each
entry.
#Specify the APL run mode, design dependent or design independent
APL_RUN_MODE DI
#Specify .lib files
LIB_FILES {
/nfs/apl1/user_data/lib/IO.lib
ANSYS INC - Apache Design Business Unit
CHAPTER 9 — Characterization Using Apache Power Library
Sample APL Configuration File
RedHawk User Manual
/nfs/apl1/user_data/lib/ANALOG.lib
}
#Define design corner
DESIGN_CORNER {
{
TEMP 25
PROCESS TT
VDD 1.0
MODEL /nfs/apl1/model TT
}
{
TEMP 125
PROCESS FF
VDD 1.1
MODEL /nfs/apl1/model FF
}
}
#Specify parallel run platform
GRID_TYPE LSF
#Specify the job submit command for parallel run
BATCH_QUEUING_COMMAND bsub
#Specify LSF or Sun Grid job submit options
BATCH_QUEUING_OPTIONS -r -R select [type==any]
#Specify the path of the LSF or Sun Grid binaries
EXEC_PATH /appls/lsf/6.0/linux2.4-glibc2.3-x86/bin
# Specify LSF job submission mode: use bsub
LSF_SUBMIT_MODE 1
or LSF API
#Specify the maximum number of simultaneous jobs
JOB_COUNT 20
#Specify Spice subckt netlist file
SPICE_SUBCKT {
/nfs/apl1/user_data/spice/subckt/spice.lib
}
#Specify Spice Include files (netlist, option, model, etc)
INCLUDE
{
/nfs/apl1/model/model.typ
}
#Specify your working directory
WORKING_DIR /nfs/apl1/apldi_test
#Specify the transistor dimension scale factor
ANSYS INC - Apache Design Business Unit
| 280
CHAPTER 9 — Characterization Using Apache Power Library
Sample APL Configuration File
RedHawk User Manual
SIZE_SCALE 1
#Nominal Vdd value
VDD 1.5
#Vdd names
VDD_NAME VDD
#Ground names
GND_NAME GND1
#Specify the directory for temporary working files
TMP_DIR /nfs/apl1/apldi_test/temp
ANSYS INC - Apache Design Business Unit
| 281
CHAPTER 10 — Memory and I/O Modeling
Introduction
RedHawk User Manual
| 282
Chapter 10
Memory and I/O Modeling
Introduction
RedHawk determines a chip’s Dynamic Voltage Drop (DvD) using high time resolution
full-chip transient analysis, including package models, on-chip RLC extraction, and cell/
macro VDD/VSS switching current profiles. In 90 nm scale and beyond process
technologies, memories and I/O cells play an increasing role and are key contributors to
large switching currents
Embedded memories are taking an increasing share of real estate in SoC designs. Given
their increasing complexity and power consumption, it is necessary to model embedded
memory blocks accurately to consider their impact in a full-chip dynamic voltage drop
(DvD) analysis. Voltage drop inside memory blocks poses a problem for deep sub-micron
designs. Also, high power demand from memory instances can cause DvD in the
surrounding logic, thus impacting their timing and functionality. At a full-chip level, the
concern lies in ensuring that the memory blocks get adequate power based on their
specifications.
I/O cells are key contributors to the large switching currents in I/O VDD and I/O VSS.
While the I/O VDD is often isolated from the core VDD, I/O VSS can be shared with the
core VSS. If the VSS is shared, the large current from the simultaneous switching of the I/
O buffers can contribute significantly to the VSS bounce of the core, possibly resulting in
functional or timing failures for the chip. The I/O buffers are usually only available in LEF
and GDSII data.
RedHawk offers several options for modeling memories and I/Os, with varying levels of
abstraction--from fully detailed models for accurate block level analysis to more abstract
models for full-chip dynamic analysis. Table 10-1 highlights these different options.
Table 10-1
Model Option
RedHawk memory and I/O modeling options
Power
Grid
Sink, Cap
Locations
Memory Current,
Decap Values
I/O Current Values
Black-box
LEF /
Pin-based
At the pins
Based on .lib, AVM,
sim2iprof
specifications
Based on .lib / power
specified
Grey box - considering
power grid
As in layout
At the pins
Based on .lib, AVM,
sim2iprof
specifications.
Based on .lib / power
specified
White box - considering
power grid and internal
current sinks
As in layout
Distributed
internally
Using .lib, AVM,
sim2iprof
specifications.
Using .lib / power
specified / APL
This chapter describes RedHawk’s memory and I/O characterization flow, including input
data requirements, data preparation, and usage model. Memory modeling for use in
RedHawk is partitioned into two parts: (1) extraction of the power grid and assignment of
current sources and decaps, and (2) generation of the switching current profiles, leakage
currents, and decap values. For the first part, several utilities are available to perform the
extraction and current source/decap assignment for the required levels of abstraction. For
the second part, several methods are available to capture the power draw, average static
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Introduction
RedHawk User Manual
| 283
current, and dynamic switching current. Figure 10-1 illustrates this modeling methodology
for memory blocks.
Power
Grid
Extraction
Array
dec
ode
Sen
Array
r
se
S lic
/ IO
p
m
A
es
Identification
of core region
Assignm ent
of current
sources &
decaps
Figure 10-1
RedHawk modeling methodology for memories and I/P
Besides I/O buffers, there are VDD/VSS pads, gap filling pads, bumps, and RDL
(Redistribution Layer) data that often are only available in GDSII format, without any
detailed routing information in DEF. RedHawk can take the input data in GDSII form and
convert it to DEF using gds2def/gds2rh, as shown in Figure 10-2. See section "gds2rh/
gds2def", page E-848, and section "gds2rh -m and gds2def -m", page E-888 for details.
Figure 10-2
C4 bump and RDL layer converted from GDSII using the
gds2def/gds2rh utility
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Memory and I/O Modeling Methodology
RedHawk User Manual
| 284
Memory and I/O Modeling Methodology
Black-box Modeling
For the initial set of runs, especially at the full-chip level, it is a good idea to abstract all
memories, I/O cells and VDD/VSS pad cells, as black-boxes to ensure correct
connectivity and to debug data-related issues. Black-boxed memories and I/Os consume
significantly less physical memory and run much faster, allowing successive runs during
the initial data preparation stages.
To run memories and I/Os as black-boxed abstractions, no additional data preparation is
required. No design representation (that is, DEF information) for the memory blocks and I/
Os is required. However, LEF and LIB models should exist for all memory blocks and I/
Os. The power pins from the LEF files are considered in the memory and I/O models.
For black-box modeling, the memories are considered without their internal power grids
and all current demand is distributed among the power pins of the blocks as defined in
their LEF files.
Sometimes the black-box modeling of the I/Os and VDD/VSS pads have incomplete
geometry information on the pins, which can result in problems, such as VDD/VSS shorts
or very large static IR drop. In this case, use a more detailed level of abstraction for I/O
modeling.
Pin and Grid-Based Abstractions
In grid-based modeling, the memories and I/Os are considered with their internal power
grids. The current draw is distributed among the power pins of the block that connect to
the top level grid. This method of modeling is particularly useful in designs for which fullchip power grid connectivity is maintained through the power grid of the memory blocks
and I/Os. For example, if the top-level power grid of a design is in metal layers 3 and 4,
and the memory blocks and I/Os have power grids in metal layers 3 and 4, then the
inclusion of the memory blocks and I/Os along with their power grids will ensure
connectivity for the power routes in metal layers 3 and 4. If these blocks were blackboxed, then the continuity and connectivity of the power routes in these layers would be
lost. Figure 10-3 illustrates this situation for memories.
MEMORY BLOCK
Pins
METAL4 Power Lines
METAL3 Power Lines
Black boxed modeling
Loss in connectivity in
top level power gird
Figure 10-3
Pin and Grid based modeling
Continuity in top level grid
preserved from the inclusion of
block level PG network.
Modeling memories with and without their internal power
networks.
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed Memory Block Modeling
RedHawk User Manual
| 285
However, in a grid-based modeling framework, the current draw is considered at the pins
of the memory block. So it is useful when faster run-times are required or when memory
capacity is an issue. Considering the current demand inside the memories or I/Os down to
the lower levels of metals, as opposed to at the pins, adds significant overhead in
computation time and physical memory usage. But this method has the advantage over
the black-boxed modeling in that it considers the memory and I/O power grids during
analysis.
To abstract the memory and I/O power grids for grid-based modeling, use the gds2def/
gds2rh utility to create the necessary design files from the GDSII. The gds2def/gds2rh
utility requires the following input data:
• Configuration file. Please refer to the gds2def/gds2rh information for memories in
section "gds2rh -m and gds2def -m", page E-888, for details. Please refer to the
gds2def/gds2rh information for I/Os in the following section.
• Layer map file containing the information for mapping the GDSII layer numbers to the
corresponding layers defined in the LEF/DEF.
• GDSII file for the memory blocks and I/Os.
• LEF file for the memory blocks and I/Os (optional in GDSII flow). Needed for I/O cells
that draw current; but not needed for VDD/VSS pads that do not draw current.
The output from the utility gds2def/gds2rh is a DEF file (<toplevel>.def) containing the
power network information for the memory and I/O blocks . This DEF file should be
included in the list of DEF files given as input to RedHawk during dynamic analysis. In
addition, if the LEF file is available and defined, a new LEF file (<toplevel>_adsgds.lef)
containing information, such as the PINS section, is created.
Note: Neither the Spice-based flow nor the contact-based pin creation flow are
supported in GDS2RH. Customers should use the Totem transistor-level flow.
The next sections describe in detail the modeling of memory blocks and I/O cells.
Detailed Memory Block Modeling
Extraction
In detailed modeling, the power grid of a memory block is extracted and current sources,
along with decoupling capacitances, are placed at appropriate locations inside the
memory. This allows for an accurate consideration of current flow inside the memory
blocks. It also allows for modeling of a memory’s dynamic switching effect on its
surrounding logic.
For detailed modeling of memories, use the gds2def -m or gds2rh -m to generate the
detailed view. The gds2def -m/ gds2rh -m utility requires the following input data:
• Configuration file. Please refer to gds2def -m or gds2rh -m information in section
"gds2rh -m and gds2def -m", page E-888 for details.
• Layer map file containing the information for mapping the GDSII layer numbers to the
corresponding layers defined in the LEF/DEF.
• GDSII file for the memory blocks.
• LEF file for the memory blocks required for extracting pin information.
The output from gds2def -m / gds2rh -m is a set of DEF, LEF, and *.pratio files for each
memory block, which contain placement information for the current sources and created
decaps, power/ground routing geometries, cell abstraction, and each cell’s relative power
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed Memory Block Modeling
RedHawk User Manual
| 286
dissipation. The .pratio files specify weighting factors for the current distribution for P/G
pins in the memory. These files should be included as input files for RedHawk analysis.
For greater accuracy, you should provide the hierarchical SPICE netlist for the memory
block with x,y coordinate information for the transistors:
The size and location of the transistors in the Spice netlist control the placement and
properties of the current sources inside the memory model. For a full-chip transient
dynamic analysis, it is computationally impossible to include all transistors in the
simulation. Hence, gds2def -m / gds2rh -m groups transistors together, based on their
size and location, to form virtual cells that provide a level of abstraction without much loss
in accuracy.
The inclusion of the memory power grids and the consideration of current sources
connected to the bottom layers of metal allow for complete modeling at the full-chip level
and for an accurate transient dynamic analysis. Full-chip run-times or physical memory
usage is not affected when the number of memory blocks is small. However, run-time and
physical memory usage can be an issue for a large number of memory blocks. This is due
to the large number of nodes introduced from the inclusion of the lower levels of metals in
the block P/G networks and the creation of large number of passive elements. To
circumvent such scenarios, gds2def -m / gds2rh -m has some advanced features that
allow for selective extraction of metal layers. Two such procedures are described below.
• Extraction of specified layers only:
Users can choose to extract only certain layers from the memory GDSII file by using
the keyword
EXTRACTION_STARTING_LAYER <lowest_metal_layer> ? traceall?
in the gds2def -m / gds2rh -m configuration file. The P/G network in the starting layer
and higher layers, then are extracted. The current sources and decoupling
capacitances are hooked up to the lowest layer of specified metal.
If layers lower than the starting layer have been used to connect to higher layers, use
the ‘traceall’ option, which considers connected elements on all metal layers during
network tracing. However, if the option ‘traceall’ is specified, note that GDS2RH has
different behavior than GDS2DEF. GDS2DEF, after tracing through all metal layers,
discards all geometries below the specified EXTRACTION_STARTING_LAYER.
GDS2RH internally invokes the APACHE_PHYSICAL_MODEL approach, which does
not discard geometries at all layers below the EXTRACTION_STARTING_LAYER, but
keeps connections between the pins (current sources/sinks) created at the ESL layer,
through lower metal/via layers, for better voltage-drop modeling of the block.
• Selective extraction of metals from certain regions.
Typically, the current draw from the power grid inside the memory array regions is
small and can be ignored without much loss in accuracy for a voltage drop analysis,
especially at the full-chip level. If the geometries and segments from the lower metal
layers in the memory array regions only form local connections to the devices in the
array region, then their exclusion will not affect the full-chip analysis. Figure 10-4
shows the metal 2 geometries inside the memory core region of a memory block. As
evident from the figure, the metal 2 geometries do not form power routes, but serve
more as local interconnects. These geometries, if excluded from the analysis, do not
affect the power analysis accuracy, but can provide significant savings in the node
count, thereby allowing for considerable savings in physical memory usage and runtimes.
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed Memory Block Modeling
Figure 10-4
RedHawk User Manual
| 287
Metal 2 geometries in the memory core region of a memory
The gds2def -m / gds2rh -m utility can automatically identify the memory bit cell and
subsequently identify the memory array region from GDSII. It can then extract only certain
layers from the array region, while extracting all other layers from the other parts of the
memory. This helps to preserve all metal geometries in the high power consumption
regions, such as row decoders, drivers, and sense-amplifiers, while preserving the
connectivity of the memory block to the top-level power grids in all the layers.
To utilize these capabilities, the keyword CORE_EXTRACTION_STARTING_LAYER
<layer_name> should be specified in the gds2def -m / gds2rh -m configuration file. This
directs the gds2def -m / gds2rh -m utility to extract all layers including and above the
specified layer from the memory array region. For the rest of the memory block, the layer
specified in the keyword EXTRACTION_STARTING_LAYER is honored. If either of these
two keywords is not specified, then by default all layers, starting from the lowest layer
specified in the layer map file, are extracted in the respective regions. If
EXTRACTION_STARTING_LAYER is specified and
CORE_EXTRACTION_STARTING_LAYER is not, then the gds2def -m / gds2rh -m
utility extracts all layers starting two layers above the layer specified in
EXTRACTION_STARTING_LAYER.
To use the CORE_EXTRACTION_STARTING_LAYER option requires proper
identification of the memory array region, which can be achieved in following three
methods.
• By using the keyword MEMORY_CELL auto_detect <cellname>, for bit cells in the
Spice netlist, you can use the automatic cell detection capability built into gds2def -m
/ gds2rh -m.
• By using the keyword MEMORY_BIT_CELL auto_detect <cellname>, for bit cells in
GDSII, you can use the automatic bit cell detection capability built into gds2def -m /
gds2rh -m.
• You can specify the name(s) of the memory bit cell(s) using the keyword
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed Memory Block Modeling
RedHawk User Manual
| 288
MEMORY_BIT_CELL { } and gds2def -m / gds2rh -m identifies the memory array
region from the location of the specified bit-cells in the GDSII file.
• For certain complex memories, the auto-detection of the memory core region can be
incorrect. In this case, you can choose to explicitly specify the rectangular regions that
make up the memory core region through the keyword MEMORY_CORE_REGIONS
<file_name>, where the specified file lists all the rectangular regions.
Figure 10-5 illustrates the extraction of metal 1 P/G grid network of a memory for: (a) all
regions of the block, and (b) all regions except the array region of the memory block. Only
metal layer 3 and above are extracted.
Figure 10-5
Global and selective extraction of metal1 P/G network for a
memory block.
GDS2DEF/ GDS2RH Configuration File for Memories
This section summarizes the configuration file keywords needed for the memory modeling
modes described previously. See section "Creating the gds2rh/gds2def Configuration
File", page E-851, for more detailed information on keyword syntax and usage for
memories.
Required GDS2DEF/ GDS2RH keywords
• TOP_CELL
• GDS_FILE
• GDS_MAP_FILE
• LEF_FILE
• VDD_NETS
• GND_NETS
Optional GDS2DEF/GDS2RH keywords:
• OUTPUT_DIRECTORY
• DATATYPE
• NET_NAME_CASE_SENSITIVE 1
• EXTRACTION_STARTING_LAYER
• GENERATE_PLOC
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed Memory Block Modeling
RedHawk User Manual
| 289
• LEF_PIN_POWER
• USE_LEF_PINS_FOR_TRACING
• BUSBITCHARS
gds2def -m/ gds2rh -m Configuration File Syntax
The following section describes the gds2def -m / gds2rh -m configuration file keyword
syntax, both those that are required first to run the program, and then the optional ones.
Required keywords:
TOP_CELL $cell
GDS_FILE $cell.gds
GDS_MAP_FILE layer_map_file
LEF_FILE memory_lef_file
VDD_NETS
{
<power_net_name_to_be_used_in_output_DEF> {
<power_net_name> @ <gds_layer_number>
<gds_x_position> <gds_y_position>
(...)
<power_pin_name_in_LEF>
<power_net_name_in_GDS>
(...)
}
}
GND_NETS
{
<ground_net_name_to_be_used_in_output_DEF> {
<ground_net_name> @ <gds_layer_number>
<gds_x_position> <gds_y_position>
(...)
<ground_pin_name_in_LEF>
<ground_net_name_in_GDS>
(...)
}
}
Optional keywords:
DATATYPE
NET_NAME_CASE_SENSITIVE 1
SPICE_NETLIST
SPICE_XY_SCALE
MEMORY_CELL [ auto_detect | OFF ]
MEMORY_CELL {
<names of memory cell subcircuit in core array>
}
NMOS_MODEL_NAME {
<NMOS model names in Spice netlist>
}
...
PMOS_MODEL_NAME {
<PMOS model names in Spice netlist>
}
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed Memory Block Modeling
RedHawk User Manual
| 290
...
WORD_LINE_DIMENSION <number of word lines>
BUSBITCHARS <char>
USE_LEF_PINS_FOR_TRACING 1
MEMORY_CORE_REGIONS <file name>
MEMORY_BIT_CELL [ auto_detect | OFF ]
MEMORY_BIT_CELL {
<names of the memory bit cell(s) in core array>
}
EXTRACTION_STARTING_LAYER <lowest metal layer> [traceall]
CORE_EXTRACTION_STARTING_LAYER <lowest metal layer-memory>
The following keywords are related to Switch Memory modeling:
• DEFINE_SWITCH_CELLS - see usage in section "DEFINE_SWITCH_CELLS", page
E-873
• EXTRACT_SWITCH_CELLS - see usage in section "EXTRACT_SWITCH_CELLS",
page E-873
• LEF_FILES
• SWITCH_CELLS
• VP_PAIRS
Current Profile Generation
Static Analysis
For static analysis, a power number is required to estimate the current drawn in the
memories. RedHawk can estimate the number directly from the library models of the
memories, or you can choose to specify the power numbers through the GSR keyword,
BLOCK_POWER_FOR_SCALING. The triangular waveform based on .lib power data is
scaled according to the value of BLOCK_POWER_FOR_SCALING.
You can estimate the power of the memory from (a) datasheets of the memory blocks, (b)
the memory vendor or memory design teams, or (c) other power estimation tools. The
power you estimate should consider different modes of operation of the memory block
and should also include the memory leakage current.
Dynamic Analysis
Dynamic analysis in RedHawk is a true transient analysis. Thus for every instance,
current profiles are needed as a function of time for each mode of operation. There are
four different ways current profiles can be generated for memories.
• Triangular profiles using static average power values. This form of modeling is the
least accurate, but requires less effort and can be used if the other more accurate
means of providing the current profiles are not available. Based on the static average
power number, RedHawk generates single or double triangular current profiles.
• Rule-based switching current profile generation. The AVM (Apache Virtual
Memory) utility generates switching current profiles for different modes of operation.
This utility requires a configuration file, which is described in the section "Memory and
IP Characterization", page 9-262. The configuration file describes power consumption,
access time, setup time, and load information for each of the different operation
modes. AVM generates rule-based current profiles that are tailored for different
families of embedded memories such as SRAMs, Register Files, or DRAMs. This
utility also generates leakage current and the decoupling capacitance information for
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed I/O Cell Modeling
RedHawk User Manual
| 291
the memory blocks. AVM can be run either outside RedHawk using the command
avm <avm_configuration_file>
or within RedHawk through the GUI or TCL interface.
• Accurate switching current profile generation. The sim2iprof utility uses third-party
simulation output files, such as fsdb, hout, tr0, or pwl format files as inputs to obtain
Read/Write/Standby mode data for memories, and generates accurate current profiles
in a cell.current file for RedHawk power analysis. For details on using sim2iprof, see
section "sim2iprof", page E-895.
Detailed I/O Cell Modeling
Extraction
In detailed modeling, the power grid of an I/O block is extracted and current sources along
with decoupling capacitances, are placed at appropriate locations inside the I/O. This
allows for an accurate consideration of current flow inside the I/O blocks. It also allows for
modeling of an I/O’s dynamic switching effect on its surrounding logic.
Detailed modeling of I/Os is similar to memories and requires the gds2def/gds2rh utility to
generate the detailed view. The gds2def/gds2rh utility requires the following input data:
• Configuration file. Please refer to Chapter 8 for details.
• Layer map file containing the information for mapping the GDSII layer numbers to the
corresponding layers defined in the LEF/DEF.
• GDSII file for the I/O blocks.
• LEF file for the I/O blocks required for extracting pin information.
The output from gds2def/gds2rh is a set of DEF, LEF, and *.pratio files for each I/O block
containing placement information for the current sources and created decaps, power/
ground routing geometries, cell abstraction, and each cell’s relative power dissipation.
The .pratio files specify weighting factors for the current distribution among P/G pins in
memory. These files should be included in input files for RedHawk analysis.
For greater accuracy, you should provide the following additional information.
• Hierarchical SPICE netlist for the I/O block, with x,y coordinate information for the
transistors:
• The size and location of the transistors in the Spice netlist control the placement and
properties of the current sources inside the I/O model. For a full-chip transient
dynamic analysis, it is computationally impossible to include all transistors in the
simulation. Hence, gds2def/gds2rh groups transistors together, based on their size
and location, to form virtual cells that provide a level of abstraction without much loss
in accuracy.
• The inclusion of the I/O power grids and the consideration of current sources
connected to the bottom layers of metal allow for complete modeling at the full-chip
level and for an accurate transient dynamic analysis. Full-chip run-times or physical
memory usage is usually not affected much when including all the I/Os if the number
are not more than hundreds.
GDS2DEF/GDS2RH Configuration File for I/Os
This section describes configuration files needed for the I/O modeling modes described
earlier. The GDS2DEF/GDS2RH utility also can extract P/G grids from bump or RDL
layers to be included in RedHawk analysis.
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed I/O Cell Modeling
RedHawk User Manual
| 292
To prepare to run GDS2DEF/GDS2RH, create a configuration file, including the keywords
described in this section, as needed. The I/O configuration file keywords are listed below.
For descriptions and syntax of the keywords, see section "Creating the gds2rh/gds2def
Configuration File", page E-851.
Required GDS2DEF/GDS2RH Keywords
• TOP_CELL
• GDS_MAP_FILE
• VDD_NETS
• GND_NETS
• GDS_FILE
Optional GDS2DEF/GDS2RH Keywords for I/Os
• APACHE_PHYSICAL_MODEL
• ADJUST_POLYGON
• BUSBITCHARS
• CREATE_LEF_MACRO_FOR_BOX_CELLS
• CREATE_LEF_MACRO_FOR_BOX_CELLS
• DEF_FILE_DEFINITIONS
• EXTRACTION_STARTING_LAYER
• GENERATE_PLOC
• INTERNAL_DBUNIT
• LEF_FILE
• LEF_PIN_POWER
• MULTI_TASKS
• NET_NAME_CASE_SENSITIVE
• OUTPUT_DIRECTORY
• USE_LEF_PINS_FOR_TRACING
Current Profile Generation
Static Analysis
For static analysis, a power number is required to estimate the current drawn in the I/Os.
RedHawk can estimate the number directly from the library models of the I/Os, or you can
choose to specify the power numbers using the GSR keyword,
BLOCK_POWER_FOR_SCALING.
Dynamic Analysis
Dynamic analysis in RedHawk is a high time resolution true transient analysis. Thus, for
every instance, current profiles should be provided as a function of time for each mode of
operation. The following describes the different ways that the current profiles as a function
of time can be generated.
• Triangular profiles using static average power values. This form of modeling is the
least accurate, but requires less effort and can be used if the other means of providing
the current profiles are not available. Based on the average static power, RedHawk
will generate the triangular current profiles.
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed I/O Cell Modeling
RedHawk User Manual
| 293
• SPICE profiles using APL. If you prefer to use SPICE-based current profiles in your
RedHawk analyses you can use APL to characterize the I/O blocks. APL automatically
generates the input vectors based on the parameters defined in the input configuration
file. Using these input vectors, APL characterizes the I/O blocks using NSPICE.
Currently, core VDD and VSS current profiles are captured during APL
characterization. If the core VSS is shared with I/O VSS, the current in core VSS is
much larger than the current in core VDD of the I/O cells. RedHawk is able to take in
asymmetric current profiles in VDD and VSS for dynamic analysis. With the large
capacity and fast run-time capabilities of NSPICE, the characterization of I/O blocks is
typically not an issue. Please see Chapter 9, "Characterization Using Apache Power
Library", for more details on APL.
Results and Analysis Including I/Os
With the inclusion of I/Os, the following demonstrates some of RedHawk’s capabilities for
analyzing results. Figure 10-6 shows the power density map of a chip without the
simultaneous switching I/O buffers, while Figure 10-7 shows a power density map with
switching I/O buffers. After DvD analysis, the power density map shows the instances in
which actual switching occurs. Power density is defined as the power dissipated per unit
area. Power density is a good indication of potential problem regions, since a higher
power density indicates more power demand is concentrated in a small region.
Figure 10-6
Power density map without simultaneous switching I/Os
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed I/O Cell Modeling
Figure 10-7
RedHawk User Manual
| 294
Power density map with simultaneous switching I/Os
Figure 10-8 shows the static IR drop of the VSS network. However, with dynamic voltage
drop, the VSS bounce can be much higher, as seen in Figure 10-9 (without switching I/
Os) and Figure 10-10 (with switching I/Os). Equally important is that the regions with high
static IR drop can be completely different than the regions with high dynamic voltage drop.
This demonstrates that I/O switching-induced VSS bounce can no longer be ignored,
especially when VSS is shared between the I/O and the core.
Figure 10-8
Static IR-drop with simultaneous switching I/Os; Maximum
ANSYS INC - Apache Design Business Unit
CHAPTER 10 — Memory and I/O Modeling
Detailed I/O Cell Modeling
RedHawk User Manual
| 295
VSS at 30mV
Figure 10-9
Dynamic voltage drop (DvD) without simultaneous switching
I/Os; Maximum VSS bounce at 150mV
Figure 10-10
DvD with simultaneous switching I/Os; Maximum VSS
bounce at 200mV
ANSYS INC - Apache Design Business Unit
CHAPTER 11 — Hierarchical Cell Modeling
Introduction
RedHawk User Manual
| 296
Chapter 11
Hierarchical Cell Modeling
Introduction
Designs that include blocks instantiated multiple times, such as memory and place and
route (PNR) blocks, can require a significant amount of runtime and peak memory use.
There are two methods of modeling these blocks in an efficient way: Extracted Reusable
View (ERV) models and Custom Macro Models (CMM).
Extracted Reusable View (ERV) models are created for PNR IPs and are used in top-level
analysis targeted for aggressive performance improvement. ERVs can provide significant
node reduction (70-90% reduction inside blocks). Wire/via geometries are not saved
inside this compact model, but their RLC components are saved. ERV models achieve
performance reduction through techniques such as: the following:
• network optimization
• extraction reuse
• repetitive instantiations of the same cell
Custom Macro Modeling (CMM) is designed to allow using hierarchical data modeling in
RedHawk analysis to help improve runtime and memory usage (a 20-30% reduction is
possible, typically). CMMs are simulation-ready design blocks that can be reused in the
RedHawk analysis flow for different designs.And since CMMs contain detailed data from
the original design, RedHawk analysis with CMMs produces results with accuracy
comparable to that of traditional “flat” analysis methodology.
ERV models are created in RedHawk, and CMMs are created in Totem. The following
sections describe the creation and usage of ERV models, and the usage of CMMs in
RedHawk design analysis.
Extracted Reusable View (ERV) Models
Overview
ERV hierarchical models are used for PNR IPs in top-level analyses. Node reduction for
different types of designs can range from 30% to 90% compared to the flat design. ERV
models have the following characteristics:
• Provide significant performance improvement.
• Can provide aggressive node reduction (70-90% reduction within the block).
• Wire/Via geometries are not saved inside the compact model, but their RLC
components are saved.
ANSYS INC - Apache Design Business Unit
CHAPTER 11 — Hierarchical Cell Modeling
Extracted Reusable View (ERV) Models
RedHawk User Manual
| 297
The ERV creation flow for blocks is shown in Figure 11-1.
Figure 11-1
ERV Creation Flow for Blocks
Input Files
The TECH file used in the ERV creation run and in the top level run should be the same.
An ERV GSR file outline is shown below:
VDD_NETS {
...
}
GND_NETS {
...
}
TECH_FILE
...
LEF_FILES {
...
}
LIB_FILES {
...
}
DEF_FILES {
...
}
ERV_MODEL_CREATION 2
ERV_CREATE_PINS 1
A sample ERV command file is shown below:
import gsr …
setup design …
perform extraction …
create ERV -path <dir>
To include ERV models in the top level run, use the following GSR keyword:
ERV_CELLS {
<cell_name1> <ERV_model_path1>
ANSYS INC - Apache Design Business Unit
CHAPTER 11 — Hierarchical Cell Modeling
Extracted Reusable View (ERV) Models
<cell_name2> <ERV_model_path2>
...
}
ANSYS INC - Apache Design Business Unit
RedHawk User Manual
| 298
CHAPTER 12 — Package and Board Analysis
Introduction
RedHawk User Manual
| 299
Chapter 12
Package and Board Analysis
Introduction
High quality models of off-chip RLC circuit elements such as the package and board can
be very significant in achieving an accurate simulation of circuit power. This chapter
describes the procedures for creating the required package and board-related circuit
models and mapping package port names to die pad names.
RedHawk can perform chip-package thermal co-analysis using the integrated Chip
Package Analysis (CPA) GUI. Thermal analysis of the package with Chip Thermal
Modeling (CTM) is natively supported in RedHawk. You can perform CTM generation,
and CTM+package thermal analysis in the same RedHawk session. See Chapter 20,
"Chip-Package Analysis (CPA)".
Package and Board Models
Three types of package models are available, a simple model in which all power pads
have the same RLC values and all ground pads have the same RLC values. More
complicated package modeling, in which different values can be assigned to each pad,
are provided by a Spice subcircuit model or an S-parameter model. These three types of
models are described in the following sections.
Simple Package RLC Model
A simple package circuit model representation in RedHawk is shown in Figure 12-1.
Package parasitics represent RLC values associated with the package substrate itself.
The wirebond represents the bondwire (lead frame to bondpad connection) parasitics. For
Flip Chip designs, where there is no lead frame, this can be included as a part of package
parasitics. Padwire parasitics represent the parasitics of the pad (or bump) wire routing
(bondpad/bump to I/O pad cell connection). If this routing is already included in the DEF,
RedHawk extracts the information automatically; you do not need to specify these values.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
Figure 12-1
RedHawk User Manual
| 300
simple package RLC model
The simple model annotates single RLC values for all pads in the design using TCL
commands. This can be done separately for power pads and ground pads. All power pads
and all ground pads have the same parasitic values with this command.
The commands used for annotating simple RLC package values are:
setup package -r <in Ohm> -c <in pF> -l <in pH>
setup wirebond -power/-ground -r <in Ohm> -c <in pF> -l <in pH>
setup pad -power/-ground -r <in Ohm> -c <in pF>
Note that asymmetric power and ground package models are supported, and wirebond
and pad constraints can be annotated separately for power and ground. Also, an
inductance value is not annotated with pad parasitics, as this routing is significantly small,
and generally is considered to be zero in simulation.
An example of the simple model specification follows:
setup pad -power -r 0.010000 -c 0.5
setup pad -ground -r 0.010000 -c 0.5
setup wirebond -power -r 0.245000 -l 1420 -c 5
setup wirebond -ground -r 0.245000 -l 1420 -c 5
setup package -r 0.001000 -l 10 -c 10
RedHawk also supports more detailed distributed RLCK and S-parameter package and
board models for simulation; these models are described in the following sections.
Distributed RLCK Package and Board Subcircuit Model
For RLCK package subcircuit models to accurately analyze the dynamic voltage drop
associated with these variations, the package parasitics must be in the form of a
subcircuit description following conventional SPICE syntax. Ideal voltages are applied at
the package balls through the subcircuit, which is connected to the die during analysis.
The list of ports in the subcircuit definition may include signal, power and ground ports.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 301
Note that asymmetric power and ground models are supported. The following circuit
elements in the subcircuit netlist are supported.
Symbol
Element
R
Resistance
L
Self inductance
Kxx
Mutual inductance
C
Capacitance
H
Current-controlled voltage source
I
Current source
V
Voltage source
E
Linear voltage-controlled voltage source
F
Linear current-controlled current source
G
Linear voltage-controlled current source
H
Linear current-controlled voltage source
All elements must be fixed, with no dependencies on any other parameter.
In addition, the following functions in the subcircuit netlist are supported. .
Function
.inc
or .include
subckt
Purpose
Inclusion of other SPICE-compatible files
Definition of additional subcircuits.
The entire off-chip network must be captured in a SPICE subcircuit netlist named
‘REDHAWK_PKG’. In addition, the power and ground ideal sources must be defined in
the top-level netlist. All definitions and instantiations in the netlist must follow conventional
SPICE syntax.
Note: Voltage values provided in the package netlist are used in RedHawk analysis
and the voltages specified in the GSR file are overridden.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 302
Figure 12-1 is an illustration of the way package and board parameters are modeled in
RedHawk. Each port of the REDHAWK_PKG subcircuit can be connected to one or more
pads on the die (note that no node can have “0” as a name).
REDHAWK_PKG subcircuit
Die
Domain A
Ppcb_A
Pkg Subckt - Vdd_A
PvddA1
PAD_A1
RLC1
VA +_
_
PvddA2
RLC2
RLCn
Ppcb_B
VB
PvddAn
Domain B
PvddB1
PAD_A3
PAD_An
PAD_B1
Pkg Subckt - Vdd_B
+
__
Ppcb_vss
PAD_B2
PvddBn
Domain Vss
PAD_Bn
Pvss1
PAD_Vss1
Pkg Subckt - Vss
Vss
PAD_A2
+
_
Pvssn
Pkg Subcircuit Wrapper
Figure 12-1
Spice
subckt
port
names
PAD_Vssn
Die
pad
names
in PLOC
file
Modeling package parameters in RedHawk
Support for Package K-parameters
RedHawk supports package subcircuit models to more accurately analyze the dynamic
voltage drop with off-chip package and board effects. The mutual inductor coefficient K is
supported, in addition to basic Spice circuit components (RLC). The mutual inductor
coefficient represents the coupling effects among inductors. If the mutual inductance
between inductors L1 and L2 is M12, the coefficient K is defined as ‘M12 / sqrt(L1*L2)’. In
the package Spice netlist it appears as:
K_L1_L2
L1
L2 0.5
The mutual inductance coefficient must have an absolute value between 0 and 1.0. You
can specify the K parameter for each pair of inductors for an inductor group (i = 1...N). So
the self inductances L11 to LNN, along with mutual inductances Mij (i = 1...N, j = 1...N)
constitutes an inductance matrix. In package modeling, such an inductance matrix is
usually extracted by field solvers.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 303
Following is an example of a package Spice netlist, top.sp, in a single file, for the model
illustration above, including mutual inductance between inductors, K12:
* Top level subcircuit
* The file name must be specified with a GSR keyword
* All ports are mapped (i.e, connected) to RedHawk pads defined
* in the *.ploc file.
* The subcircuit must be named REDHAWK_PKG
.subckt REDHAWK_PKG PvddA1 PvddA2 PvddB1 PvddB2 Pvss1 Pvss2
* PCB voltage supplies
Va Ppcb_A 0 1.1v
Vb Ppcb_B 0 1.0v
Vvss Ppcb_vss 0 0v
* Instantiate domain subcircuits. Connect them to the
* corresponding PCB voltage supplies and output ports of
* REDHAWK_PKG
XVDDA_RLC Ppcb_A PvddA1 PvddA2 VDDA_RLC
XVDDB_RLC ...
XVSS_RLC ...
.ends
* Package RLC for each voltage domain can be captured in a
* separate subcircuit
.subckt VDDA_RLC Ppcb Pdie1 Pdie2
R1 Ppcb N1 1e-9
L1 N1 Pdie1 1e-12
K12 L1 L2 0.3
C1 Pdie1 0 1e-10
R2 Ppcb N2 0.5e-09
L2 N2 Pdie2
.ends
.subckt VDDB_RLC Ppcb Pdie1 Pdie2
...
.ends
.subckt VSS_RLC Ppcb Pdie1 Pdie2
...
.ends
In order for RedHawk to include the subcircuit model in the simulation, the top-level
SPICE netlist must be specified in the RedHawk GSR file, as follows:
PACKAGE_SPICE_SUBCKT top.sp
Linear Current- and Voltage-Controlled Source Models
The following Spice linear current- and voltage-controlled sources are available for
package modeling in RedHawk:
• Type “E” - Linear Voltage-Controlled Voltage Source
• Type “F” - Linear Current-Controlled Current Source
• Type “G” - Linear Voltage-Controlled Current Source
• Type “H” - Linear Current-Controlled Voltage Source
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 304
The syntax for describing these linear source models is given below. Note that Spice
source-type keywords, such as ‘VCVS’ and ‘CCCS’, are optional in the RedHawk syntax.
Linear Voltage-Controlled Voltage Source (E )
E* N+ N- ?VCVS? NC+ NC- VGain
where
E*
name of the source, starting with E
N+
name of positive node
N-
name of negative node
NC+
name of positive controlling node
NC-
name of negative controlling node
VGain
voltage gain
Linear Current-Controlled Current Source (F)
F* N+ N- ?CCCS? Vname IGain
where
F*
name of the source, starting with F
N+
name of positive node
N-
name of negative node. Current flows from the positive node through
the source to the negative node
Vname name of the voltage source through which the controlling current flows.
IGain
current gain
Linear Voltage-Controlled Current Source (G )
G* N+ N- ?VCCS? NC+ NC- TransC
where
G*
name of the source, starting with G
N+
name of positive node
N-
name of negative node
NC+
name of positive controlling node
NC-
name of negative controlling node
TransC transconductance (voltage to current conversion factor)
Linear Current-Controlled Voltage Source (H)
H* N+ N- ?CCVS? Vname TransR
where
H*
name of the source, starting with H
N+
name of positive node
N-
name of negative node
Vname name of the voltage source through which the controlling current flows
TransR trans-resistance in Ohms (current to voltage conversion factor)
Note: The dummy sources for types “F” and “H” must have a voltage of 0.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 305
S-Parameter Package and Board Modeling for Static Analysis
S-parameter package models or PCB models in REDHAWK_PKG subcircuit support
static analysis in RedHawk. The same package and PCB models that are used in
dynamic analysis can be used in static analysis.
The procedure to use S-parameter models in static analysis follows:
1.
Make sure that S-parameters data is available at a sufficiently low frequency,
ideally at DC (f=0). Sufficiently low frequency for any design depends on the
electrical length of the structure, and the values of decoupling capacitances
present on the PCB. For example, for a package model, 1 KHz would be a
sufficiently low frequency. For a PCB model with large decoupling capacitors, f <=
10 Hz would be required. Having an S-parameter model outside of these
guidelines could cause modeling problems. Using DC (f=0) data is recommended.
2.
Instantiate the S-parameter models in the REDHAWK_PKG subcircuit using the
same syntax as used for the dynamic simulation.
Note that there are no practical limitation on the number of ports, and the memory and
runtime requirements are low. The approach involves converting the S matrix at DC to a Y
matrix, and synthesizing the Y matrix as a network of resistors.
A general S-parameter modeling diagram is shown in Figure 12-2 for both static and
dynamic analysis. Note that multiple ports on the BGA/VRM side are allowed.
Port 1
Port 2
PLOC
S-Parameter
Port N+1
V
Package/PCB Model
Port N
Figure 12-2
General S-parameter diagram, static and dynamic analysis
S-Parameter Package and Board Modeling for Dynamic Analysis
As the clock frequency of the chip increases, so does the importance of capturing
accurate frequency behavior of the package and PCB over the multi-GHz range.
Designers typically utilize full-wave electromagnetic solvers, which create frequencydependent scattering (S) parameters. The resulting package/PCB model is represented
by a frequency-domain S-parameter model, in Touchstone format. This feature allows you
to utilize the results of the full-wave EM solvers in RedHawk dynamic simulations. For
clock frequencies above 500 MHz, S-parameter modeling should be used to achieve
accurate results.
Modeling Methodology
The S-parameter model describes, at each specified frequency point, the voltage and
current relationships among all the “ports” of a black-box network. Conceptually, the Sparameters model the transfer of power from the source to the load, in terms of the
incident (a) and reflected (b) waves, b =Sa at a particular frequency. Both a and b are
vectors of size N, and S is a complex N x N matrix, where N is the number of ports.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 306
The k-th component of the incident wave ak and the k-th component of the reflected wave
bk is related to the port voltages Vk and currents Ik through the relationships:
Vk + Z0 Ik
a k = -----------------------2 Z0
Vk – Z0 Ik
b k = ----------------------2 Z0
The definition of the S-parameters includes the value of the normalization (reference)
impedance Zo, as shown in an example below in Touchstone format (Zo=2 Ohms in this
example):
# HZ S RI R 2.000
RedHawk presently only supports the scalar reference impedance, thus all ports have the
same reference impedance.
In order to perform dynamic modeling of package and PCB using S-parameters, ports
need to be defined at the package die pad, BGA pad locations, and/or board voltage
regulator module (VRM) location. In package/PCB power delivery network modeling, a
port is usually defined across a set of Vdd (power) nodes and a set of Vss (ground)
nodes. In network analysis terminology, the Vss nodes are called the “reference” nodes of
the defined port.
A typical port setup scheme for a flip-chip package is as follows:
1.
Partition the package die pad area into N partitions.
2.
Set up a port in each partition between Vdd nodes and Vss nodes.
3.
On the package BGA side, set up ports as required between all Vdd nodes and
Vss nodes.
Note that automatic pre-simulation time determination is provided with S-parameter
packages and PCB models, the same way for RLCK models, but only in the vectorless
(DvD) flow. The presim time determined in this way has an upper limit of 120 ns and a
lower limit of 3.5 ns.
Connecting S-parameter models in the REDHAWK_PKG subcircuit
There are two modes of connection, common reference (ports referred to global ground),
and differential (floating) reference. In practice, differential connection is used more often,
as most EM solvers produce package /PCB models for ground nets with differential port
definitions (between the node pairs, and not referred to global ground).
S-parameter models with a common reference node
The most intuitive way of connecting the S-parameter models is with all ports referred to
global ground (SPICE node 0). In this case, each port is defined between a node Nk and
the global ground. The use model for the S-parameters is essentially the same as for
RLCK models. Specifically, the absolute node voltages (those with respect to the global
ground) make sense, and there is no condition imposed on port currents. The sum of the
port currents does not have to be zero, as there is also the reference current Iref.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
Figure 12-3
RedHawk User Manual
| 307
Basic global ground connection S-parameter model
Figure 12-3 shows the use of S-parameter models with all ports defined between a node
and global ground (SPICE node 0). In this case the simplest possible package is a 4-port
S-parameter model. From a user standpoint, there is no difference between using an
RLCK package model and using an S-parameter model.
However, there are several problems in using S-parameters with ports referred to global
ground:
• Many industrial EM solvers cannot extract S-parameters with ports referred to the
global ground, as sometimes the definition of “global ground” or a common reference
node is not clear.
• The number of ports is twice the number for the differential connection method
described below.
• RedHawk simulation uses decoupled methodology by default, so having S-parameters
with global ground as reference causes additional inaccuracy, as the RC branches
connected to the global ground get shorted by the package.
So to use S-parameters with the ports referenced to the global ground, you must use the
coupled mode (GSR keyword 'DYNAMIC_SOLVER_MODE 1') in simulation. For these
reasons using differential connection of S-parameters is recommended, as described in
the following section.
Differential connection of S-parameter models
RedHawk automatically detects differential connection of the S parameter packages and
PCB models, and disables log reports of absolute voltages ( Vdd/Vss), which are not valid
for S-parameter models with differential connections.
For differential connection of S-parameters, each port voltage is defined between a pair of
non-ground nodes, k(pos) and k(neg), where k is the node number. Thus an N-port Sparameter model is connected between 2N nodes. The simplest example, with 2 ports
and 4 nodes, is shown in Figure 12-4, with differential voltages. All VDD pads are grouped
together, and all VSS pads are grouped together.
Only the differential voltages are defined: (V1=V1(pos)-V1(neg) and V2=V2(pos)V2(neg)). S-parameters also force a zero sum of currents I(VDD)=-I(VSS) by
construction. The S-parameter model in the differential connection does not provide any
DC path to global ground that would normally be available through the package and
supply voltage sources.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
Figure 12-4
RedHawk User Manual
| 308
Basic differential connection S-parameter model
RedHawk considers an S-parameter model to have differential connections unless one of
the following conditions is satisfied, indicating a common reference.
• The negative node of all ports is global ground, Spice node 0, which is the
recommended method for S-parameter models with ports referred to a common
reference.
• The negative nodes of the ports are connected to global ground with R < 1.2e-5
Ohms.
• The negative nodes of the ports are connected to global ground with a zero-volt ideal
voltage source.
In these cases, a message is written to the log file that indicates that the S-parameter
model has connections with a common reference.
Specifying S-parameter models in RedHawk
RedHawk treats an N-port S-parameter model as a 2N terminal device. In general, an Nport S-parameter network can be described in the following format:
Nxxxx S(N) n1p n1n n2p n2n …… nNp nNn <modelname>
where Nxxxx is the network's name, 'n1p' and 'n1n' are the nodes for port 1, 'n2p', 'n2n'
are the nodes for port 2, and 'N' is the number of ports in the network. The <modelname>
parameter is the model statement name that contains the S-parameter data.
The model statement for an S-parameter model is defined as follows:
.model <modelname> nport file = “<filename>” np = <N_value>
where 'nport file' and 'np' are the keywords. The <filename> parameter is the name of the
S-parameter data file, and <N_value> specifies the number of ports.
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 309
Figure 12-5 shows a method of partitioning flip chip bumps, where Vdd elements are red
and Vss elements are black. Each partition would be represented by one port in the Sparameter model.
Figure 12-5
Partitioned bump model for flip chip package
The following GSR keyword SPARAM_HANDLING is used to control the behavior of the
S-parameter model:
SPARAM_HANDLING 2 - enables full passivity enforcement (default)
SPARAM_HANDLING 0 - fits an RLCK model accurate at low frequencies
The following is the simplest example RedHawk package SPICE netlist, including a twoport s-parameter model:
.subckt REDHAWK_PKG pVdd pVss
Npkg S(2) pVdd pVss bgaVdd bgaVss PKG_MODEL
.model PKG_MODEL nport file = "pkg.s2p" np = 2
Vvdd bgaVdd
Vvss bgaVss
.ends
0
0
1.2
0.0
Note that multiple S-parameter models in the same REDHAWK_PKG are supported.
DC voltages at package nodes are included in the file adsRpt/Dynamic/Vdc.txt, which
enables debugging package connectivity problems before finishing transient simulation.
Saving/reuse of rational approximation and passivity enforcement results
For a large number of ports, processing an S-parameter model may take significant time
and hence the results of this processing are saved in a subdirectory called SparmCache
in the run directory. These results are then available for reuse. The SparmCache directory
contains a copy of the original user-specified Touchstone file (*.s#p), and also the file
containing the results of rational approximation / passivity enforcement, called *.r#p.
If a separate run directory is used, you can copy the SparmCache directory, and the
results of the rational approximation passivity enforcement is reused.
Recommendations and limitations in using S-parameter models
1.
The number of ports should not exceed 100, with 50 to 60 ports being a practical
limit for improved runtime / reliability.
2.
Only one reference impedance for all ports is supported (the vector of reference
impedances is not supported at this time).
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 310
3.
Touchstone 2.0 format is not yet supported.
4.
The touchstone file should contain the S-matrix, not Y or Z matrices. The second
keyword in the header of touchstone files should be 'S' for S-matrix :
# HZ S RI R 2.000
5.
RedHawk’s automatic presim time determination does not currently support Sparameter models. The presim time can be determined through a transient Spice
analysis of CPM + Pkg + Board models.
Usage summary and example
1.
Make sure the GSR keyword 'SPARAM_HANDLING 2' is set (default).
2.
Perform a basic check of the S-parameter model: In the SUtility, check that at low
frequencies there is transmission between ports that have DC connections. For
example, if ports 1 and 6 are connected at DC, and no other ports have DC
connection to ports 1 and 6, S(1,6) should approach 1 (0 dB) at DC.
If a VRM port connects to 10 other ports, the corresponding transmission
term will be around 0.1 in magnitude (-20 dB).
3.
Do not combine multiple S-parameters models into one. Multiple S-parameter
models in Redhawk_PKG subcircuit are supported.
4.
Create the REDHAWK_PKG subcircuit (required), which defines the ports of the Sparameter models between a node pair (for the differential connection of Sparameters). See the 21-port example following.
S-parameter differential model example (21 ports)
.subckt REDHAWK_PKG
+ bg0_VDD bg0_VSS
+ bg1_VDD bg1_VSS
+ bg2_VDD bg2_VSS
+ bg3_VDD bg3_VSS
+ bg4_VDD bg4_VSS
+ bg5_VDD bg5_VSS
+ bg6_VDD bg6_VSS
+ bg7_VDD bg7_VSS
+ bg8_VDD bg8_VSS
+ bg9_VDD bg9_VSS
+ bg10_VDD bg10_VSS
+ bg11_VDD bg11_VSS
+ bg12_VDD bg12_VSS
+ bg13_VDD bg13_VSS
+ bg14_VDD bg14_VSS
+ bg15_VDD bg15_VSS
+ bg16_VDD bg16_VSS
+ bg17_VDD bg17_VSS
+ bg18_VDD bg18_VSS
+ bg19_VDD bg19_VSS
* Instantiate package model
*! Port[1] = bg0
*! Port[2] = bg1
*! Port[3] = bg2
*! Port[4] = bg3
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
*!
RedHawk User Manual
| 311
Port[5] = bg4
Port[6] = bg5
Port[7] = bg6
Port[8] = bg7
Port[9] = bg8
Port[10] = bg9
Port[11] = bg10
Port[12] = bg11
Port[13] = bg12
Port[14] = bg13
Port[15] = bg14
Port[16] = bg15
Port[17] = bg16
Port[18] = bg17
Port[19] = bg18
Port[20] = bg19
Port[21] = bottom
Npkg S(21)
+ bg0_VDD bg0_VSS
+ bg1_VDD bg1_VSS
+ bg2_VDD bg2_VSS
+ bg3_VDD bg3_VSS
+ bg4_VDD bg4_VSS
+ bg5_VDD bg5_VSS
+ bg6_VDD bg6_VSS
+ bg7_VDD bg7_VSS
+ bg8_VDD bg8_VSS
+ bg9_VDD bg9_VSS
+ bg10_VDD bg10_VSS
+ bg11_VDD bg11_VSS
+ bg12_VDD bg12_VSS
+ bg13_VDD bg13_VSS
+ bg14_VDD bg14_VSS
+ bg15_VDD bg15_VSS
+ bg16_VDD bg16_VSS
+ bg17_VDD bg17_VSS
+ bg18_VDD bg18_VSS
+ bg19_VDD bg19_VSS
+ BGA_VDD BGA_VSS
+ PKG_MODEL
.model PKG_MODEL nport file = "package.s21p" np=21
* finally, we need a power supply to drive all this stuff* core supply
V_vdd BGA_VDD 0 1.2
V_vss BGA_VSS 0 0.000
.ends
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Package and Board Models
RedHawk User Manual
| 312
Note: the supply sources on the BGA side should be between a node and ground (SPICE
node 0), as shown in bold type above. Also note that presim time is automatically
determined.
Recommendations for best S-parameter model extraction
The success of RedHawk dynamic simulation depends on having S-parameter models
that accurately describe the behavior of the package and/or PCB in the frequency range
of interest, with sufficient resolution in the frequency domain. The guidelines for achieving
this are given below:
1.
Frequency range in the Touchstone file: recommend fmin=0 (DC) or sufficiently
close; fmax=2.5 GHz to 5 GHz. The log grid of frequency points should be used
from 1 Hz to 100 MHz, then linear grid above that.
2.
For PCBs with large decoupling capacitors (tens of microfarads), start at a very low
frequency (f=1 Hz, for example), and use 15 to 20 points per decade for the log
grid part.
3.
Number of frequency points in the Touchstone file: typically around 250 to 500,
depending on how complicated the frequency dependence is. For complicated
frequency dependencies, 1000 to 2000 frequency points may be needed.
4.
Reference impedance : Zo=2 Ohms. A good choice of reference impedance
improves the accuracy of the results. For power/ground networks, the classic
reference impedance of 50 Ohms is too large. Extracting S-parameters with a
reference impedance of Zo=2 Ohms is the best approach, since this is the value
used by default in RedHawk.
5.
Number of significant figures to use in Touchstone file data: 12 to 14 decimal
places are recommended. There is no penalty for extra decimal places, but having
too few could be a problem.
6.
Maximum number of ports: While the absolute maximum is 100 ports, limiting the
number of ports to 50-60 is best.
Analysis of the Simulation Results
Special care is required when analyzing simulation results obtained with S-parameter
models with the differential connections. Remember that only differential voltages (voltage
differences) are meaningful using this method. For this reason when displaying voltage
waveforms, only display differential voltages, V(vdd)-V(vss), not single-ended voltages
V(vdd) and V(vss). In Signal Viewer (sv), you can use the Calculator function to
generate the differential waveform V(vdd)-V(vss) from the two waveforms V(vdd) and
V(vss). For pad voltages, you can use the plotting utility 'gnuplot' and the file adsRpt/
Dynamic/Vpad.data that is created when a package model is present.
No such transformation is needed for current values; currents are always “absolute”, and
wire voltages should be ignored. The following results retain significance:
• Differential voltages at the pads V(vdd)-V(vss) . You can plot the voltage difference at
a pair of pads of dynamic simulation results, as follows:
plot voltage -pad_pair {<pad1_name> <pad2_name> }
-sv -o <file_name>
Example:
plot voltage -pad_pair {VDD1 VSS90} -sv -o vdrop.txt
Note that pad names are specified inside curly brackets, with no comma between
pad names.
• Pad currents and battery currents
• Instance voltage drops
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Mapping Package Port Names to Die Pad Names in the PLOC File
RedHawk User Manual
| 313
• Worst VDD-VSS voltage report.
Mapping Package Port Names to Die Pad Names in the PLOC File
Mapping of ports on the package to one or more pads on the die is achieved using
definitions in the PLOC file. Some package vendors have protocols that can be used in
mapping ports and pads. If a protocol is not available, the port/pad locations must be
mapped manually.
Following is the syntax for a standard *.ploc file with no package model:
<die_pad_name> <X-coord> <Y-coord> <layer> <POWER | GROUND>
If you want to include a package subcircuit model, then the syntax of the .ploc file should
be modified as follows:
<die_pad_name> <X-coord_um> <Y-coord_um> <layer>
<power/ground_domain_name> <Spice_pkg_port_name>
where the power/ground domain name is the name specified in the VDD_NETS GSR
keyword, and none of the ports can be named “0’. Signal ports in the package subcircuit
can be floating. Multiple pads can be connected to a single port of the package. For
example, in the package model provided multiple Vdd_A domain pads can be connected
to port PvddA1.
The following is a sample .ploc file corresponding to the example design and package:
Pad_A1 3125 4340 metal6 VDD_A PvddA1
Pad_A2 3225 4340 metal7 VDD_A PvddA1
Pad_A3 3325 4340 metal6 VDD_A PvddA2
Pad_A4 3425 4340 metal6 VDD_A PvddA2
Pad_B1 5125 4340 metal7 VDD_B PvddB1
Pad_B2 5225 4340 metal7 VDD_B PvddB1
Pad_B3 5335 4340 metal6 VDD_B PvddB2
Pad_B4 5335 4340 metal6 VDD_B PvddB2
Pad_VSS1 6125 4340 metal7 VSS Pvss1
Pad_VSS2 6225 4340 metal6 VSS Pvss1
Pad_VSS3 6325 4340 metal7 VSS Pvss2
Pad_VSS4 6425 4340 metal7 VSS Pvss2
...
The *.ploc file is imported into RedHawk using standard procedure.
Chip-Die Mapping Using Package Compiler
Overview
Accurate analysis of chip designs require a model of the associated package, in terms of
an accurate RLCK Spice subcircuit. The RedHawk Package Compiler can provide this as
an extension of the Chip Package Protocol (CPP) header. The Package Compiler has
several functions:
• wrap the package Spice model into RedHawk-compatible format.
• match die and package pins and create an annotated PLOC
• compute effective inductance
• calculate effective package Inductance for each voltage domain
• perform RLCK passivity checks
• perform package Spice syntax checks
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Chip-Die Mapping Using Package Compiler
RedHawk User Manual
| 314
RedHawk Package Compiler makes use of the Chip Package Protocol (CPP) header
information to determine the following:
• identifies package and die pins
• identifies which nodes belong to the die side and which belong to the PCB side
• uses CPP header data to differentiate between power nets and ground nets
If Package Compiler has already been run, if invoked again it identifies the alreadywrapped RedHawk package model and the already-annotated PLOC file, and reruns the
same set of checks on the output files for completeness and correctness.
An overview of the Package Compiler process and data flow is shown in Figure 12-6.
The key features of Package Compiler is “wrapping” the package Spice model subcircuit
into one that is RedHawk-compatible, as well as calculating effective inductance for each
voltage domain and matching die and package pins.
•Package Spice Syntax check
Ploc File
Paksi‐E
 Check RLCK passivity
Spice
Package
Model
with CPP
Header
 Calculate effective Inductance for each
voltage domain.
 Match Die and Package pins to create an
annotated ploc file
Wrapped Spice
netlist for use
in RedHawk
Modified
Ploc file
RedHawk
Figure 12-6
Overview of Package Compiler flow
Inputs
The require inputs are:
• PLOC file - pin location file to be annotated (*.ploc). The format of the PLOC file is as
follows:
<pin/pad_name> <x_loc> <y_loc> <layername> <P/G_domain_name>
Note that the last column should not be “Power” /”Ground”, but the domain name.
• package Spice file - target package Spice model with Chip Package Protocol (CPP)
header to be mapped, wrapped, syntax checked, passivity checked, and effective
inductance calculated.
• GSR file : standard RedHawk GSR file that contains information about the voltages to
apply to each die power and ground net, specified with keywords
VDD_NETS {
<die_VDD_name> <voltage>
...
}
GND_NETS {
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Chip-Die Mapping Using Package Compiler
RedHawk User Manual
| 315
<die_VSS_name> <voltage>
...
}
Command Syntax
The syntax for using package compiler from a UNIX command line is:
compile_pkg
[ -m <pkg_model_file>] [ -p <ploc_file> ] [-n <p_n_t_file>]
[ -t <transform_file> ] [ -vv <port_value_file> ]
[ -vg <gsr file> ] [ -g <generic_pkg_file> ]
[ -c ] [ -nma <#_of_match_iter> ] [ -no_leff_calc ]
[ -op <output_ploc_file> ] [ -om <wrapped_model> ]
[ -ow <working directory> ] [ -icf <input_config_file> ]
[ -start_tol <min_dist> -end_tol <max_dist> ]
[-snap ] [ -ee]
where
-m <pkg_model_file> : specifies the package model Spice file.
-p <ploc_file> : specifies the die pin locations and corresponding die nets.
-n <p_n_t_file>: specifies the file defining the package net types
-t <transform_file> : specifies the transformation operations to use for die/
package pin matching.
-vv <port_value_file> : specifies the voltages to assign to package power/ground
PCB pins.
-vg <gsr file> : reads the die net voltages from the GSR file.
-g <generic_pkg_file>: If no -m file supplied, this file can be used to indicate
package pin locations and corresponding package nets.
-c : Checks the data between the already annotated ploc file and -m pkg file.
-nma <#_of_match_iter> : specifies the maximum number of matching attempts.
-no_leff_calc : the effective inductance is not calculated, which reduces runtime.
-op <output_ploc_file> : specifies the name of the output PLOC file.
-om <wrapped_model> : specifies the name of the wrapped Spice model
-ow <working directory> : specifies the working directory for the intermediate files
-icf <input_config_file> : specifies the file that contains input arguments to this
utility
-start_tol <min_dist> -end_tol <max_dist> : specifies the minimum and maximum
separation distance in mapping die and package pins (meters)
-snap : snaps each die pin to the package pin closest to it, even if outside the
tolerance radius.
-ee : forces die ground pins to attach only to package ground pins and die power
pins to attach only to package power pins
Note that if you run Package Compiler without the ‘–ee’ and ‘–snap’ options, a file with a
list of unmatched ploc pins, called adsPackage/unmatchedPlocPins.txt, is generated, with
entries such as the following:
+ Best Match: 1/3126 pins lying outside of tolerance 1.8um,
with greatest offset of 264.552452um
+ The list of unmatched ploc pins: [ adsPackage/
unmatchedPlocPins.txt ]
!! NOTE: Since -snap option was NOT specified, all pins
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Chip-Die Mapping Using Package Compiler
RedHawk User Manual
| 316
lying outside of the tolerance will be commented out in the
annotated ploc file.
Using the ‘–ee’ and ‘–snap’ options, Package Compiler snaps any PLOC points lying
outside of the tolerance threshold to the closest related package point and no
unmatchedPlocPins.txt file is generated.
Outputs
The primary output is the conversion of the original package Spice netlist, <pkg_spice>,
of the form:
subckt pkg die1 die2 pcb1 pcb2
...
.ends
into the “wrapped” RedHawk-compatible package Spice netlist, redhawk_pkg, that has
the format:
include <pkg_spice>
.subckt redhawk_pkg die1 die2
V1 pcb1 0 1.2
V2 pcb2 0 0
Xpkg die1 die2 pkg
.ends
Note that the new Spice file includes the original package Spice file. The subckt netlist
excludes the nodes on the side of the PCB, which are assigned appropriate voltages
described by the voltage file.
Additional outputs are described following:
• <ploc_file>.1 - fully-annotated ploc file after successful die and package pin pair
mapping.
• standard checks of circuit syntax, such as:
• annotated Spice nodes and nets exist in the package Spice model
• annotated Spice nodes belong to the correct package net
• die side Spice nodes are not used as voltage sources in the Spice file
• Spice nodes do not have multiple types
• Spice nodes do not belong to multiple nets in CPP header
• PLOC file is fully annotated
• PCB Spice nodes have valid voltages
• passivity check - checks RLCK passivity for the package Spice model
• package net types file (*.pnt) - automatically created upon successful pin-pair
mapping, and required for effective inductance calculation. In the event that the file is
unavailable (if Package Compiler has not been run yet), it can be provided by using
the ‘–n’ option. The file format is:
.POWER
<pkg_net1>
<pkg_net2>
...
.GROUND
<pkg_neta>
<pkg_netb>
...
ANSYS INC - Apache Design Business Unit
CHAPTER 12 — Package and Board Analysis
Known Restrictions
RedHawk User Manual
| 317
• effective inductance calculation for each Power and Ground net pair. The Package
Compiler makes use of the CPP (Chip Package Protocol) header to gather information
needed for the calculation. To determine which package nets are power and which are
ground, it makes use of the file, which is automatically created upon successful pinpair mapping. For example, for the sample PNT file above, it calculates the
inductances:
<pkg_net1> to <pkg_neta>
<pkg_net1> to <pkg_netb>
<pkg_net2> to <pkg_neta>
<pkg_net2> to <pkg_netb>
A testbench is created for each calculation, named:
<pkg_model>.<power_name>_<gnd_name>.leff.sp
for example, model.sp.pkg_net1_pkg_neta.leff.sp.
By default, the utility uses the NSpice binary to extract the effective impedance
($APACHEROOT/bin/nspice)
You can use the ‘sv’ waveform viewer to view the waveform file generated [*.aa0].
• <ploc_file>.map.1 file - contains the list of die -to -package pin mappings.
• <ploc_file>.T file - contains the transformation parameters (rotation, mirror,
translation) used to match the die to the package
• *.leff.sp files - testbench Spice files used to extract the effective inductances between
power and ground package net pairs.
• *.leff.aa0 files - contain the effective inductance graphs that can be viewed with the
‘sv’ viewer.
Known Restrictions
The following restrictions must be observed in package models:
• Only the previously-described SPICE keywords are supported.
• Mapping the nodes of the package to their locations on-chip is currently supported
only through the .ploc file.
• The user-created top-level SPICE netlist must use the ‘REDHAWK_PKG’ keyword as
the subcircuit model.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Introduction
RedHawk User Manual
| 318
Chapter 13
Low Power Design Analysis
Introduction
VLSI designs, especially those manufactured in a 90nm scale process or smaller, and
those targeted for wireless, mobile computing, and other low-power applications, are
employing power saving modes for extended battery performance, greater control over
the speed-versus-power trade-off and better thermal performance. Sub-micron designs
suffer from increased device leakage currents, less control of threshold voltage levels
from negative bias temperature instability (NBTI), increased current drive strengths, and
higher device densities. Designers are becoming increasingly aware of the need to make
their designs “power-aware” at several levels – system, architectural, design, and
technological. Though the most significant impact on power saving may be achieved
through changes at the system or architectural levels, most of the visible efforts are
focused on design and technological level changes to mitigate the harmful effects of
higher power consumption in today’s designs.
Some commonly employed power saving design techniques, include:
• Multiple Vdd/Vss domains
• Power gating, in which Vdd /Vss supplies for selected areas of the circuit, or individual
cells are controlled by one or more switches or sleep transistors. Techniques such as
this are also sometimes referred to as “MTCMOS”.
• Clock gating, which controls the clock signals supplied to selected storage elements in
a design
• Voltage islands, in which selected areas of the design are driven by different voltage
supplies
• Multi-Vth (threshold voltage) circuit design styles, in which higher Vth transistors are
strategically placed in the circuit to reduce leakage without adversely affecting critical
path delay
• Active gate (body) back-biasing technique, in which Vth levels are dynamically
controlled to minimize leakage power
• Retention flip-flops, in which data/states for sections of the circuit are preserved during
temporary power-down periods
RedHawk™ can provide accurate dynamic power analysis for designs using the power
saving techniques described above. Designers can perform full-chip and block-level
transient dynamic voltage analysis and average static voltage drop analysis by accurately
modeling one or more of the above power saving modes in their designs. They can use
the textual result reports and the graphical displays, including time point based movie
mode display of dynamic voltage drop results, to analyze and improve their designs.
Analysis of Multiple Vdd/Vss Domain Designs
One of the popular techniques in designing low power chips is to use multiple voltage
sources. RedHawk supports design techniques based on multiple VDD domains. The
input of multiple VDD domains is accomplished by specifying the multiple VDD domain
(net) in the .gsr file, as shown in the following example:
VDD_NETS
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Multiple Vdd/Vss Domain Designs
RedHawk User Manual
| 319
{
VDD0 1.8
VDD 1.6
}
You can have any number of VDD domains, but you can specify a maximum of eight
different voltage values. One instance connected to multiple VDD nets is supported by
defining power distribution among multiple VDD/VSS domains using P/G arc definitions.
Power/ground arcs for multiple VDD/VSS designs are defined in section "P/G Arc
Definitions in Custom LIB Files", page 3-20, and section "Cell Characterization Data
Preparation", page 9-216.
Also, if the instance is an I/O cell connected to I/O VDD, core VDD, and I/O VSS (which
can be the same as core VSS), RedHawk can handle it with an asymmetric current
profiles in dynamic analysis. This is how I/O cells’ impact on core VDD and VSS is
handled.
To view the results of a particular net analysis, you can select a net from View -> Nets.
Figure 13-1 shows the voltage drop color map when all nets are selected. Figure 13-2
shows when only one VDD net is selected.
Figure 13-1
Viewing multiple VDD domain nets
Figure 13-2
Viewing only one VDD net
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Multiple Vdd/Vss Domain Designs
RedHawk User Manual
| 320
You can zoom in and click on the node on a net to view the voltage at that location, as
shown in Figure 13-3.
Figure 13-3
Zooming in on a net to view voltage drop information
The following are sample results shown in the message window:
Net: VDD
Wire: M2
LowerLeft = (3710.510, 4388.160)
Length: 101 um
Width: 1.46 um
Resistance: 6.95 Ohm
Voltage at query position: 1.595129 V
Current at query position: 0.000168779 A v
You can click on an instance, as shown in Figure 13-4, to view the information on that
instance.
Figure 13-4
Zooming in on an instance to view voltage drop information
Following are the results shown in the message window.
Instance: Test/U594
Cell: test1
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 321
LowerLeft = (3713.860, 4482.880), Width/Height = 5.220 / 4.639
Total Load Cap: 0.131 pF
Intrinsic Cap 0: 0 pF
Intrinsic Cap 1: 0 pF
Static Vdd-Vss: 1.592 V (domain vdd: 1.6000)
Average Pwr: 6.72e-10 W
You can also select Results -> List of Worst IR instance for Static Simulation or List
of Worst DvD instance for Dynamic Simulation to view up to 1000 instances with the
highest voltage drop. In the ‘Report of Worst IR Instance’ window, you can select a net of
interest from the combo box Vdd Domain, and click Apply. The default is All, for which
the report prints the instances with the highest voltage drop on the full chip.
The report contains the following five fields.
1.
The instance rank (top 1000 instances with the highest voltage drop)
2.
The lowest VDD-VSS differential for the instance
3.
Ideal VDD value
4.
Location (x, y)
5.
Instance name
Analysis of Power Gating Designs
This section describes the data preparation steps for using RedHawk in analyzing designs
employing power gating techniques. Two levels of power gating can be analyzed--the full
chip level involving blocks that are powered up and powered down, and also each block
may contain subcircuits with independent power gating switches. The basic analysis
procedure includes the following steps, and is shown in Figure 13-5:
1.
Create and configure individual power gating switch models for ON, OFF, and
Power-up conditions using configuration (.conf) file, and Spice netlists/models.
2.
Perform APL characterization of switch models using aplsw utility.
3.
Define chip-level block On-Off switching with GSC file and STA timing window
information.
4.
Use the APL utility apldi -w -s2 to characterize all cells in the design and generate
the required PWL models.
5.
Import switch definitions and block power conditions into RedHawk using the GSR
file.
6.
Import standard design information into RedHawk database using the Apache Tech
file, and GSR file (LEF, DEF, LIB, GDSII).
7.
Perform accurate, SPICE-based full-chip static and transient dynamic analysis in
RedHawk.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 322
These steps are described in the following sections.
Design Database
Switch Model
Characterization
APL-SW
Standard RH
User Input
APL Cell
Characterization
RedHawk
Dynamic
Analysis
Power Gating
Analysis
Figure 13-5
PowerUp/Down
Block Char
APL-PWL
PowerUp/Down
Block Timing
GSC file
Flow for Power Gating and Switch Analysis
Types of Power Switches
There are two types of power gate switches that can be used in low power designs:
• charge switches - large high-current switches that are used to insure that the supply
voltage for associated functional switches have reached the proper threshold voltage
before the first functional switch is turned on
• functional switches - standard switches used in power gating designs
For designs that use charge switches, the cell names and their threshold voltage must be
declared using the GSR keyword CHARGE_SWITCH. For a description of its use, see
section "CHARGE_SWITCH", page C-695.
Low Power Analysis Switch Modeling
Some designs include circuitry that provides the ability to turn power to a cell, block or
subcircuit ON or OFF as needed. This is usually accomplished through the addition of a
switch circuit in series with the power or ground net serving the subcircuit. An example of
such a network is shown in Figure 13-6, with the external VDD supply connected to the
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 323
power supply internal to the subcircuit through a switch circuit. This type of switch is
commonly referred to as a header switch.
VDD
Vdd_ext
Header Switch
Control Pins
Vdd_int
BLOCK
VSS
Figure 13-6
Example of a design using VDD power switching through a
header switch.
When a switch controls the conduction path between the external and internal ground
network, it is commonly referred to as a footer switch, shown in Figure 13-11. A particular
subcircuit or block typically would have only one or the other type of power gating, but it
could have both if there was a design reason.
During the power-up sequence of a design, the switches may be turned on or off all at
once or one at a time, and may take several clock cycles to reach full On or Off state.
Usually the individual power gated circuits are not turned off or on simultaneously, to
reduce the associated large transient current flow and complications of simultaneously
switching output (SSO) and voltage drop noise. RedHawk accurately considers the
powerup sequence of blocks and individual switches , allowing designers to estimate the
number of cycles needed for powerup in order to avoid large transient current spikes. It
models the switch behavior in a way that reflects their turn-on and turn-off mechanisms.
To provide accurate analysis, there are continuous power-up sequences for each
switched section of the circuit that must be adequately modeled. Each switched section of
the design requires four different analysis modes: ON, OFF, and POWERUP, and
POWERDOWN. The switch models and methods needed to perform detailed analysis of
these four conditions are described in the following sections. It is assumed that the switch
contains at least one transistor, but the actual design can be determined by the user to
maximize speed and minimize leakage.
ON State
During the ON-state, the header and footer switches form a low resistance element
between the “external” and “internal” power networks. Regular dynamic and static
analysis of a design can be performed in this mode. RedHawk reports the voltage across
the switches and the current through the switches from the dynamic and/or static
analyses.
Figure 13-7 shows the equivalent circuit model for a header switch in the ON state, which
is characterized using the aplsw utility, which automatically generates a switch model file
containing switch performance data for ON, OFF and PowerUp states. The UNIX shell
command syntax is:
aplsw [-c] [-d] [-o <output_file>] <sw_config_list.conf>
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 324
where
-c : check generated result
-d : debug mode
-o <output_file> : output file name
<sw_config_list.conf> : switch configuration list file
The key components of the On model are a small saturation R value, some capacitance,
and a small leakage current that is relatively independent of the voltage applied or the
internal resistance.
VDD_Ext
R,, C,
I , ION
RON
CON
On State
VDD_Int
Figure 13-7
‘ON’ state electrical model for a header switch
Adaptive ON Resistance
For improved accuracy, RedHawk supports adaptive modification of the switch On
resistance (Ron) based on the supply voltage variation seen at the control pin of the PFET
(header) or the NFET (footer). For example, for a footer-based device, if the supply
voltage variation at the gate during transient simulation is significant compared to a
particular threshold, then RedHawk chooses the appropriate switch Ron for that particular
combination of terminal voltages at the simulation time point. The gate voltage is obtained
by monitoring the appropriate voltages (VDD for headers and VSS for footers) during an
ON-state dynamic analysis in the neighborhood of the switch cells. Then RedHawk uses
this gate voltage relationship to determine the appropriate switch Ron from the switch
model file (see section "Switch Model Generation", page 13-331), This feature is activated
using the GSR keyword:
DYNAMIC_ADAPTIVE_RON [0|1] <variation_threshold_%>
For example, 'DYNAMIC_ADAPTIVE_RON 1 8' specifies that the threshold for Ron
change is an 8% variation in power or ground voltage. The default value is 0 (Off).
The power switch should ideally be characterized using the APLSW keyword 'MD_PWL 1'
to use the multi-dimensional switch model file, which provides the most accurate electrical
representation of the switch. If the default switch model is used, RedHawk uses internal
heuristics to scale the switch Ron.
OFF State
In the Off state, the voltage levels in the power and ground networks are determined from
the equilibrium reached between the leakage currents in the instances in the design and
the leakage currents through the switches. Figure 13-8 shows the equivalent circuit model
for a header switch in the OFF state, which is characterized using the aplsw utility and
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 325
the header switch model file. The key components are a capacitance and a small voltagedependent leakage current.
VDD_Ext
CC,
, I O FF (v)
O FF
I(v)
O ff
State
VDD_Int
Figure 13-8
‘Off’ state electrical model for a header switch
RedHawk allows for the accurate determination of the OFF state equilibrium voltage in the
internal power or ground networks, which in turn helps to determine the leakage current
flowing in the design in the Off mode. As shown in the Figure 13-9 below, APL considers
only the current Isw_leak for leakage current characterization of the switch cell. The OFF
state analysis is required to determine the initial voltage for a power-up sequence.
Figure 13-9
Leakage switch model in OFF state
PowerUp and PowerDown States
A design employing header switches, during power-down the internal power network,
which is initially close to the supply voltage, settles to a low voltage level. The final Off
voltage is determined by the leakage in the instances connected to the internal power
network and the leakage current through the header switches that control the voltage of
that network.
Conversely, for a design employing footer switches, during power-down the internal
ground network rises to a voltage value determined by the leakage in the instances
connected to the internal ground network and the leakage current through the footer
switches that control the voltage of the internal ground network.
Powerup reverses these conditions and returns the circuit to the original On state over
some period of time that is determined by the characterization process. RedHawk allows
for the accurate determination of power up and power down conditions.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 326
The equivalent model used to characterize a switch during power-up periods is shown in
Figure 13-10.
VDD_Ext
RON(v)
Power On
Or Off State
VDD_Int
Figure 13-10
‘PowerUp’ and ‘PowerDown’ state electrical model
Control of Power Gating Switches
Control pins are used to manage when power is applied to the block or subcircuit and
when it is removed. Pins required to connect and control a header switch have the
following types: control (one or several), vss supply, vdd_external/supply, vdd_internal,
vdd_high/bias. A corresponding set of pin types are needed for a footer switch: control
(one or several), vdd supply, vss_external/supply, vss_internal.
Enhanced mode switch characterization takes enable pin transitions into account.
VDD
Control Pins
BLOCK
Vss_int
Footer Switch
Vss_ext
Figure 13-11
VSS
General power gating circuit using a footer switch
The next section describes the configuration and characterization process that defines
the actual pin names, how they are controlled, and the voltage levels associated with
each condition.
Checking Switches with Two Enable Pins
When one power switch is controlled by two enable pins, you need to make sure that the
proper threshold voltage is reached when the second pin is enabled. Using the GSR
keyword CHECK_SWITCH_POWERON ensures the proper working of the switch. The
syntax for the keyword is:
CHECK_SWITCH_POWERON {
[ THRESHOLD <threshold_all_V> |
<cellname> <cell_threshold_V> ]
...
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 327
}
where
<threshold_all_V> : specifies the threshold voltage (Volts) for all switch cells
<cellname> <cell_threshold_V> : specifies the threshold voltage (Volts) for switch
cells of type <cellname>
A report, switch_poweron.rpt, lists the switches in the design by threshold voltage and
identifies any violations, as shown in the sample report in Figure 13-12. In this example,
for a timing window of 2.2 ns, the footer switch ‘sw_inst1’ only discharges to a value of
0.272049 V, while it should reach 0.1 V for proper operation, so a threshold violation is
reported.
Figure 13-12
Sample switch_poweron.rpt for a footer switch
Characterization and Implementation
The header or footer switches need to be characterized to model their electrical
properties for the different analysis modes. Three different characterizations are
performed to determine switch properties for the following modes: On, Off, PowerUp, and
PowerDown.
Switch Configuration Files
A configuration file must be created for each switch type to specify the different pins in the
switch and their voltage settings. The following are examples of the keyword settings
required in the switch configuration file, along with a definition and the proper syntax. Note
that multiple voltage switch characterization can be performed, and that in this case 'pin
<valueN>' settings for all the states must be consistent with the VDDVALUE specification.
See section section "APL Configuration File Description", page 9-217, for more details on
keyword use.
SWITCH_TYPE HEADER
Specifies either header or footer switch type. Syntax:
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 328
SWITCH_TYPE [HEADER | FOOTER]
DEVICE_MODEL_LIBRARY 0.13um.lib TT
Defines SPICE device model library. Syntax:
DEVICE_MODEL_LIBRARY <model_file> <process_corner>
TEMPERATURE 25
Defines characterization temperature. Syntax:
TEMPERATURE <temperature_degreesC>
SPICE_NETLIST my_switches.sp
Defines switches’ Spice netlist file. Syntax:
SPICE_NETLIST <switch_name.sp>
INCLUDE spice.models
Defines Spice model card file. Syntax:
INCLUDE <model_card_name>
EXT_PIN vdd_ext
Defines switch input (supply connection) pin name. Syntax:
EXT_PIN <pin_connection_to_external_supply>
INT_PIN vdd_int
Defines switch output (circuit connection) pin name. Syntax:
INT_PIN <pin_connection_to_cell>
GND_PIN_NAME vss
Defines GND pin name -- for HEADER switches ONLY. Syntax:
GND_PIN_NAME <gnd_pin_name>
VDD_PIN_NAME vdd
Defines VDD pin name -- for FOOTER switches ONLY. Syntax:
VDD_PIN_NAME <vdd_pin_name>
VDDVALUE 1.1
Defines one or more VDD supply values. Syntax:
VDDVALUE <value1> [<value2> ...]
ON_STATE {
ENABLE1 0
ENABLE2 1.1
}
Defines the voltages on control pins needed to turn the switch fully ON. Syntax:
ON_STATE {
<control_pin> <ON_V1> [<ON_V2> ...]
}
OFF_STATE {
ENABLE1 1.1
ENABLE2 0
}
Defines the voltages on control pins needed to keep the switch OFF. Syntax:
OFF_STATE {
<control_pin> <OFF_V1> [<OFF_V2> ...]
}
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 329
POWER_UP {
ENABLE1 0
ENBALE2 1.1
}
Defines the voltages on the control pins needed to turn ON the switch. Syntax:
POWER_UP {
<control_pin> <Up_V1> [<Up_V2> ...]
}
Note that when there are two control pins, the value of one of the control pins in the
POWER_UP state must equal its value in OFF_STATE, then this control pin is
considered to fire second in operation. Without this information, the pin firing order
cannot be decided. For example:
OFF_STATE {
Control2 0
Control1 0
}
POWER_UP {
Control2 0.99
Control1 0
}
In this example, pin ‘Control2’ fires first.
POWER_DOWN {
PinA Va
PinB Vb
}
Defines the voltages on control pins needed to turn OFF the switch. Syntax:
POWER_DOWN {
<control_pin> <Down_V1> [<Down_V2> ...]
}
Note that when there are two control pins, the value of one of the control pins in the
POWER_DOWN state must equal its value in ON_STATE, then this control pin is
considered to turn off second in operation. Without this information, the pin firing
order cannot be decided. For example:
ON_STATE {
Control2 1
Control1 0
}
POWER_DOWN {
Control2 0
Control1 0
}
In this example, pin ‘Control 2’ turns off first.
SIM_ON_STATE_ONLY
Enables only on-state simulation while characterization of switch cells. Syntax:
SIM_ON_STATE_ONLY
ANSYS INC - Apache Design Business Unit
[ 0 | 1 ]
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 330
CONTROL_PIN ENABLE1 R F
CONTROL_PIN ENABLE2 R F
Specifies the control pin names and the transitions (rise or fall) that turn the switch
On. This uses the proper transitions in the STA file during RedHawk analysis. For
no rise or fall spec, use “-”. (don’t care). Syntax:
CONTROL_PIN <subckt_pin_name> [for ramp-up: R | F | - ]
[for ramp-down: F | R | - ]
DC_BIAS vdd_high 1.1
Defines input control pins’ required DC value. Syntax:
DC_BIAS <subckt_pin_name> <value>
OPENPIN open1
Defines pins that should be kept open. Syntax:
OPENPIN <subckt_pin_name>
SPICE2LEF_PIN_MAPPING {
abcd fghi
}
Defines Spice to LEF pin mapping. Can be applied to match the switch LEF pin
names in the physical model: <macro_name>_adsgds1.lef. Syntax:
SPICE2LEF_PIN_MAPPING {
<subckt_pin_name> <LEF pin name>
...
}
SWITCH_TIMING_CHAR 1
Turns on switch timing characterization. Syntax:
SWITCH_TIMING_CHAR [0 | 1]
EXTERNAL_CONTROL_PIN poweron_ads
Defines external control pin; required keyword for timing characterization. Syntax:
EXTERNAL_CONTROL_PIN <external control pin name>
INTERNAL_CONTROL_PIN poweron_ads_int
Defines internal control pin; required keyword for timing characterization. Syntax:
INTERNAL_CONTROL_PIN <internal control pin name>
CONTROL_SLEW 2 100p 200p
Defines transition times in ps (default, 100 ps ). Syntax:
CONTROL_SLEW <number of values> <transition time 1>
[ <transition time 2> ..]
INT_TIMING_ON2OFF POWERON_ADS F
4.18423e-11 4.64905e-11 6.99287e-11 5.5511e-11
Specifies internal pin timing for On-to-Off transitions. Syntax:
INT_TIMING_ON2OFF <external_ctrl_pin> [R | F]
< In>Out delay in S for transition 1 >
<internal slew in S for transition time 1>
[< In>Out delay in S for transition 2 >
<internal slew in S for transition time 2>...]
where [R | F] specify the <external_ctrl_pin> waveform is rising or falling to make
the switch OFF2ON or ON2OFF.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 331
INT_TIMING_OFF2ON POWERON_ADS R
4.16594e-11 4.44381e-11 7.21476e-11 5.44803e-11
Specifies internal pin timing for Off-to-On transitions. Syntax:
INT_TIMING_OFF2ON <external_ctrl_pin> [R | F]
< in>out delay in S for transition time 1>
<internal slew in S for transition time 1>
[< in>out delay in S for transition time 2>
<internal slew in S for transition time 2> ...]
Advanced Switch Characterization
Note: if all switch enable waveforms are relatively fast and linear, with transition
times on the order of a few picoseconds, the advanced switch characterization
described in this section is not required.
For switches that have multiple control pins, significant transition times (for example, a
single driver might be controlling a group of switches), or non-linear behavior, using the
‘MD_PWL 1’ keyword setting in the switch configuration file is recommended.
Using the keyword SPLIT_MD_PWL [0 | 1] controls whether simulation runs serially or in
parallel (keyword "MD_PWL 1" must be set). The default is “0”, which means the
simulations run in serial. If it is set to “1”, the simulations run in parallel, so
characterization is faster.
The behavior of non-linear or slow transition control pin waveforms can be specified in the
GSR using the keyword ‘PIECEWISE_SWITCH_INPUT <filename>’, which specifies a
switch input file that describes the input waveforms for the required switch pins in
piecewise linear detail. The format of the switch input file is as follows:
<switch_inst_name> <ctrl_pin_name> ( <t1> <volt1> <t2> <volt2> ... )
...
where times are in seconds and voltages are in volts.
Switch Model Generation
Once a configuration file is created for each switch, list the location of all configuration
files in another master configuration file, one configuration file per line, along with the
name of the switch cell (should be the same as that specified in the configuration file and
as specified in the Spice netlist). For example, a design with two switches, switch_ab and
switch_cd needs two configuration files, such as switch_ab.conf and switch_cd.conf. The
location of the individual switch configuration files must be listed in a master configuration
list file, with the following internal format:
switch_ab <path to config file ab>/switch_ab.conf
switch_cd <path to config file cd>/switch_cd.conf
The APL utility, aplsw, is then executed on the master switch configuration list file to
generate the switch models used in low power analysis, using the syntax:
aplsw [-c] [-d] [-o <output_file>] <sw_config_list.conf>
where
-c : check generated result
-d : debug mode
-o <output_file> : output file name
<sw_config_list.conf> : switch configuration list file
Non-ideal piecewise linear control pin inputs can be accommodated in the current
modeling.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 332
After aplsw completes execution, a switch model file, called aplsw.out by default, is
automatically generated, containing data for each switch model in the APL run directory.
The aplsw.out file contains a header to identify the nature of the contents, which includes
the pin connections and the electrical parameters for each of the four switch states, as
well as the voltage and leakage current relationships for a specified number of data points
for each condition. Leakage current outputs are provided by 2D or 3D table lookup for up
to two control pin inputs, as well as Vdd, so if piecewise linear control pin voltages are
available, this additional characterization accuracy can be used.
Note: Users should not attempt to edit the switch model files.
Defining Block Switching Status with the GSC File
The state of instances in a block for low power analysis must be defined in the GSC file.
You have three options to specify the state in low power analysis:
1.
Specify the state of BOTH switch instance and power-gated block/instance:
<switch_instance> POWERUP
<gated_block> POWERUP
2.
Specify domain_name to include everything in that domain:
* <domain_name> POWERUP
3.
Combine 1 and 2 for more specifically defined case:
<switch_instance> <domain_name> POWERUP
<gated_block> <domain_name> POWERUP
Wildcards (*) can be used for defining sets of blocks and instances.
For information setting states for switches by using the GSC file, see the section "Global
Switching Configuration (GSC) File", page C-548.
Obtaining STA Timing Window Data
Information about the time-dependent behavior of a block is obtained from the timing
window data in the STA file. See Chapter 19, "Timing File Creation Using Apache Timing
Engine (ATE)" for details of how to generate the STA output file, and how to get STA file
data for switch enabled pins. The following three special PT variables are used during
STA file generation:
• ADS_CELLS_NEED_INPUT_TW
• ADS_INPUT_PINS_NEED_TW
• ADS_PINS_NO_TW
Importing Switches into RedHawk
Use the following GSR entry to import the switch models generated by the aplsw utility
into RedHawk:
SWITCH_MODEL_FILE {
<switch_model_file>
}
You must ensure that all external power and ground networks that are connected through
the switches and need to be simulated by RedHawk are listed in VDD/GND_NETS, along
with their associated voltage values. As long as the EXTRACT_INTERNAL_NET GSR
keyword is set to 1 (default), internal nets do not have to be listed. Following is an
example of the referenced GSR keywords.
VDD_NETS {
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 333
VDD_EXT 1.08
}
GND_NETS {
VSS_EXT 0
}
For proper consideration of switch models in RedHawk analysis, the following data
requirements must be satisfied:
1.
Define each switch in one of the LEF files, using the same name as in the switch
model file.
2.
Instantiate the switch in one or more of the DEF files.
3.
Define the switches used to switch a block in the DEF file for that block.
4.
Define the INT_PIN of the switch in LEF file with direction OUTPUT or INOUT.
5.
Define the EXT_PIN of the switch in LEF file with direction INPUT or INOUT.
6.
Timing window information for switch controls from the STA file.
Once the switch models are read in and the database is set up, connections are made
between the external power and/or ground networks through the header and/or footer
switches, respectively, using the electrical parameters defined in the switch models.
Note that a new switch model file with different switch models can be substituted during a
RedHawk run using the TCL command
gsr set SWITCH_MODEL_FILE <switch_model_filename>
which overrides the existing switch model file. Then design extraction and analysis can be
easily rerun with different switch models specified in the new file.
Adding and Deleting Power Switches
Power gating switches can be added and deleted using the TCL commands ‘eco add
switch’ and ‘eco delete switch’. See section "eco", page D-742, for details on command
usage.
Reporting on Switches in the Design
RedHawk reports the switch names traced in a separate file, adsRpt/
apache.memsw.info. The redhawk.log file points to the file adsRpt/apache.memsw.info
containing the names of the macros containing switches, the switch master names, the
switch count, and the switch internal domains.
Design Characterization for Power-up Conditions
Accurate power-up simulation using header or footer switches requires characterization of
the cells in the design to get the piecewise linear models for intrinsic capacitances,
leakage currents, and effective series resistance, as a function of voltage.
The APL utility, apldi -w -s2, is used to characterize all cells and decap present in the
design to generate the required PWL model. The UNIX shell command syntax is:
% apldi -w -s2 [-l <cell_list_file>] <apl_config_file>
and
% apldi -w -s2 [-p <decap_list_file>] <apl_config_file>
Use the same configuration file as for other APL characterizations.
The output file from the above characterization can be included for a subsequent
RedHawk analysis by using the GSR keyword:
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 334
PIECEWISE_CAP_FILE <name_of_PWL_cap_file>
Following the generation and importation of the switch models and the design database
files, RedHawk static and dynamic power analysis can be performed.
Running RedHawk Low Power Analysis
ON State Analysis
ON state analysis is run the same as for normal RedHawk power analysis except for two
additional steps:
1.
The switch models must be defined using the GSR keyword
SWITCH_MODEL_FILE.
2.
External and internal P/G nets associated with header and footer switches must be
defined using GSR keywords VDD_NETS and GND_NETS.
Ramp-up Analysis
For ramp-up analysis, the following steps must be performed in addition to normal power
analysis steps.
1.
The switch models must be defined using the GSR keyword
SWITCH_MODEL_FILE.
2.
External and internal P/G nets associated with header and footer switches must be
defined using GSR keywords VDD_NETS and GND_NETS.
3.
Instances that are powering up must be defined in the GSC file. See section
"Global Switching Configuration (GSC) File", page C-548.
4.
The piecewise linear capacitance file must be defined using either the GSR
keyword
PIECEWISE_CAP_FILE <filename>
or
APL_FILES {
<filename> pwcap
}
If there is no PWL capacitance file, use the GSR keyword
RAMPUP_OFFSTATE_VOLTAGE to define initial voltage conditions.
5.
The STA timing file must specify the timing window for the control pins of the switch
instances.
Sample Command File for Ramp-up Analysis
For rush current simulations, the following command sequence is recommended:
setup analysis_mode lowpower
import gsr <filename>
setup design
perform pwrcalc
Note: the ‘setup analysis_mode lowpower’ command uses certain optimizations that
enable faster run-times specifically for low power analysis.
perform extraction –power –ground –c
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Power Gating Designs
RedHawk User Manual
| 335
perform analysis –lowpower
Running in Mixed Mode
Low power analysis can be performed in mixed mode, with both VCD and Vectorless
inputs. To invoke mixed mode for low power analysis, use the TCL commands 'setup
analysis_mode lowpower' and also 'perform analysis -dynamic'. A sample TCL file for
mixed mode is shown below:
setup design GENERIC.gsr
perform pwrcalc
setup analysis_mode lowpower
perform extraction -power -ground -c
setup package
setup wirebond
setup pad
perform analysis -dynamic
l
Power Gating Results
switch_static. rpt File
Following RH static analysis, the adsRpt/Static/switch_static.rpt file is generated. This
lists the voltage at the internal node of all the switches, the voltage drop across them, and
the current through them, as seen in the static analysis. The report has the following
format:
#6.1.RD (Oct 31 10:09:57 2006)
#Report static results of switch voltage and current (milli-amperes)
#instance_name type internal_node_volt volt_across_switch avg_current
SW/FSW10
footer 1.946112e-05 1.515508e-05 2.117815e-04
SW/FSW20
footer 1.857796e-05 1.482933e-05 2.072293e-04
SW/FSW30
footer 1.940953e-05 1.542746e-05 2.155878e-04
SW/FSW40
footer 1.888943e-05 1.490737e-05 2.083198e-04
SW/FSW50
footer 1.862162e-05 1.502620e-05 2.099804e-04
switch_dynamic.rpt File
Following RH dynamic analysis, the adsRpt/Dynamic/switch_dynamic.rpt file is
generated, which lists the peak current through active header and footer switches for
ramp-up analysis (in Amps). The report has the following format:
#Report dynamic results of switch voltage and current
#instance_name
type maximal_Isw(Amp)
SW/FSW1
footer OFF
SW/FSW2
footer 3.139074e-03
SW/FSW9
footer OFF
SW/FSW3
footer OFF
SW/FSW2
footer 3.137452e-03
SW/FSW7
footer OFF
charge_switch.rpt File
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of IP Block Designs with Switched Power
RedHawk User Manual
| 336
For designs using charge switches, which insure that a correct threshold voltage is
reached before functional switch activation, adsRpt/Dynamic/charge_switch.rpt is
created, to report on charge switch and functional switch performance, with a format as
follows:
#Initial Function Switch Rampup Time (IFSRT): 10000
***** Charge Switch Report *****
---------------------------------------------------------------[instance_name] [threshold] [voltage@IFSRT] [time_reach_SRT]
[violation]
---------------------------------------------------------------inst_CSW_VDD
0.7 0.293019 12970 Y
***** Functional Switch Report *****
#Time of last charge switch reaching SRT: 12970
----------------------------------------------[instance_name] [rampup_time] [violation]
----------------------------------------------fsw_inst_VDD-1
15000 N
fsw_inst_VDD-2
15000 N
fsw_inst_VDD-3
15000 N
fsw_inst_VDD-4
15000 N
fsw_inst_VDD-5
15000 N
fsw_inst_VDD-6
15000 N
...
where
Initial Function Switch Rampup Time (IFSRT): turn-on time for the switch (ps)
Charge Switch Report section:
instance_name: the instance name for charge switches
threshold: required threshold voltage to be provided by the charge switch (V)
voltage@IFSRT : the internal charge switch node voltage at rampup time
time_reach_SRT: time for switch to achieve rampup threshold voltage
violation: “Y” indicates charge switch rampup time that exceeds specification
Functional Switch Report section:
instance_name: the instance names for the functional switches
rampup time: max time allowed for functional switch to meet specification
violation: “Y” indicates functional switch rampup time that exceeds specification
The GSR keyword CHARGE_SWITCH specifies the names of the charge switches used
in the design and their threshold voltages.
Analysis of IP Block Designs with Switched Power
Introduction
A diagram representing the elements of a typical macrocell power switching scheme is
given in Figure 13-13.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of IP Block Designs with Switched Power
RedHawk User Manual
| 337
IP_cell
PUP
VDD1
vdd_ext
VDD_EXT
PWRUP_ADS
VDD_EXT
PWRUP_ADS
…
vdd_int
PWRON
VSS
PON
VDD_INT
sw1_inst1
Figure 13-13
PWRON
VDD1
…
Memory/
macro cell
sw1
VDD_INT
VSS
VDD2
vss
sw1_inst2
…
IP_cell
Power switching diagram for IP macrocell
Data Requirements
In order to perform an analysis of internally-switched IP blocks, the following data rules
must be met:
• have hierarchical GDS with the switches defined as placed master cells.
• have SPICE for the memory with switch subckt names matching GDS cell names
• have external and internal (virtual) P/G name mapping between LEF/GDS view and
SPICE view
• have top-level and cell-level switch control definitions (similar to current PowerGate)
for characterization
Flow Overview
There are two different GDS2DEF flow steps, depending on whether the design has
voltage domain text labels or not. If it does not have domain text labels, several extra
steps are required, including two GDS2DEF runs. The Figure 13-14 and Figure 13-15
diagrams describes the two flows, which are only different in that if you have domain text
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of IP Block Designs with Switched Power
RedHawk User Manual
| 338
labels, only one GDS2DEF run is required, as shown in Figure 13-14. These flows are
described in the following sections.
Hier IP GDSII
Layer map
GDS2DEF
<IP_cell>_adsgds.lef
<IP_cell>.def
<IP_cell>_adsgds1.lef
qswitch
Hier SPICE
PG net info
switch SPICE
extraction
qswitch_<IP_cell>.subckt
aplsw
ACE
switch char
<IP_cell>.mcap
RedHawk
ON/OFF/POWERUP
Macro Pin state
and timing
Figure 13-14
<sw_cell>.sw
Flow for analysis of switched IP design, with text labels
G D S2DE F
sw itches
H ier IP G DS II
Layer m ap
<sw _cell>..def
<sw _cell>_adsgds.lef
G D S 2DEF
m acro
<IP_cell>_adsgds.lef
<IP_cell>.def
<IP_cell>.sw info
qsw itch
H ier SP IC E
PG net info
sw itch S PIC E
extraction
qsw itch_<IP_cell>.subckt
aplsw
AC E
sw itch char
<IP_cell>.m cap
M acro P in state
and tim ing
Figure 13-15
<sw _cell>.sw
R edH aw k
O N /O FF/P O W E R U P
Flow for analysis of switched IP design, no text labels
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of IP Block Designs with Switched Power
RedHawk User Manual
| 339
GDS2DEF Processing
Domain Text Labels Available
1.
Run a single gds2def run, using the following keywords in the configuration file:
DEFINE_SWITCH_CELLS - see usage in section "DEFINE_SWITCH_CELLS",
page E-873
EXTRACT_SWITCH_CELLS - see usage in section
"EXTRACT_SWITCH_CELLS", page E-873
2.
The VDD_NETS and GND_NETS definition statements in the GDS2DEF
configuration file must specify the names of all the nets (internal and external) that
you plan to extract using the “text label GDS” flow.
The <IP_cell>_adsgds1.lef output file contains the LEF for all switches extracted.
3.
Skip the following section, and go to section "Switch Subcircuit Extraction", page
13-341.
No Domain Text Labels Available
If your design has no domain text labels, the remainder of this section describes the
proper flow. Some important aspects of this flow are:
• GDS2DEF can extract the LEF for the switch automatically
• QSWITCH extracts the Spice sub-circuit of the switch
• APLSW characterize the switch model
• unique virtual domain device capacitance is created for the switched macro
• each power domain can have only one kind of master switch cell
The following sections describe the steps in the switch analysis.
LEF Extraction
If the LEF for the embedded switches is not available, then you can use gds2def to create
a LEF model for use in the flow. The following example of a basic configuration file, and
the embedded comments, explain the procedure.
TOP_CELL <switch cell> # ---> switch cell name in the GDS file
GDS_FILE <IP cell GDSII file>
GDS_MAP_FILE <layer map file>
VDD_NETS {
# < list the texted nets connected to the switch; examples below >
<VDD_EXT>
<VDD_INT>
}
GND_NETS {
<VSS>
}
OUTPUT_DIRECTORY .
GENERATE_LEF_PINS 1 # ‘_ADS’ is added to each pin name
OUTPUT_APACHECELL 0 # '0' means to extract the LEF file
Extract the LEF file with the command
gds2def <config_file>
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of IP Block Designs with Switched Power
RedHawk User Manual
| 340
After running gds2def, the switch LEF file, <cellname>_adsgds.lef, is generated. Repeat
this process for each unique switch master cell in the switched IP GDS file. A switch
model is shown in Figure 13-16.
(input_pin)
External VDD net
(output_pin)
VDD_INT
VSS
Figure 13-16
internal VDD net
switch model
Creating the Switch Macro Model
The following four keywords added to the basic gds2def configuration file provide the
information needed to build the switch IP block model:
• LEF_FILES - defines input block and switch LEF files provided by user or generated
from previous step
• SWITCH_CELLS - maps cellnames to output_pin_names and input_pin_names,
based on pin names in the switch LEF files, and generates a file called
<macro_name>.swinfo, which is used in the follow-on step to extract the switch
subcircuit for characterization.
• VP_PAIRS - maps internal_net_name to external_net_name
• USE_LEF_PINS_FOR_TRACING - when set to 1, uses geometries defined in the
PINS section of the LEF file of the block being extracted to start tracing its power and
ground nets during GDS translation. No text or label-based extraction is performed.
However, user-specified coordinates are honored.
The syntax for these configuration keywords is as follows:
LEF_FILES {# input LEF files
<IP LEF file>
<switch_cell_1>_adsgds.lef
<switch_cell_2>_adsgds.lef
...
}
USE_LEF_PINS_FOR_TRACING [ 1 | 0 ]
SWITCH_CELLS {# cellname output_pin_name input_pin_name
<sw1 cellname> <VDD1_INT>_ADS <VDD1_EXT>_ADS
<sw2 cellname> <VDD2_INT>_ADS <VDD2_EXT>_ADS
}
VP_PAIRS {# internal_net_name external_net_name
<vdd1_int> <vdd1_ext> <vdd2_int> <vdd2_ext>
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of IP Block Designs with Switched Power
RedHawk User Manual
| 341
An example of the steps to create the IP switch LEF file, <IP_cell>.swinfo, using the
gds2def command is shown in Figure 13-17 below.
run command:
extract_sw.cfg
% gds2def extract_sw.cfg
<sw_cell>_adsgds.lef
Hier IP GDSII
Layer map
GDS2DEF
macro
<IP_cell>_adsgds.lef
<IP_cell>.def
<IP_cell>.swinfo
VDD1
VDD2
…
adsU1
sw1
adsU1
sw2
adsU3
adsU4
…
gds2def’s <IP cell>.def
#sw_cellname inst# int_netname output_pinname ext_netname input_pinname
TOP_CELL <IP cell name>
GDS_FILE <IP cell gdsii file >
GDS_MAP_FILE <gds layer map file>
VDD_NETS {
<vdd1_int>
<vdd1_ext>
…
}
GND_NETS {
<vss>
…
}
LEF_FILE {
<IP LEF>
<sw1_cell>_adsgds.lef ---> sw lef generated from previous step
<swi_cell>_adsgds.lef
…
}
USE_LEF_PINS_FOR_TRACING 1
SWITCH_CELLS {
# cellname output_pin_name input_pin_name
<sw1 cellname> <VDD1_INT>_ADS <VDD1_EXT>_ADS
<sw2 cellname> <VDD2_INT>_ADS <VDD2_EXT>_ADS
}
VP_PAIRS {
#internal_net_name external_net_name
<vdd1_int> <vdd1_ext>
<vdd2_int> <vdd2_ext>
}
OUTPUT_DIRECTORY .
BUSBITCHARS "()"
sw1 34 vdd1_int VDD1_INT_ADS vdd1_ext VDD1_EXT_ADS
sw2 34 vdd2_int VDD2_INT_ADS vdd1_ext VDD2_EXT_ADS
…
Figure 13-17
Creating the switch block LEF file
Switch Subcircuit Extraction
The switch SPICE subckts can be extracted from the top level IP SPICE netlist if you do
not have the SPICE for each of the switches. A program called ‘qswitch’ uses a
configuration file with the ‘vp_mapping’ keyword to extract the switch subcircuits. The
‘vp_mapping’ keyword describes the mapping between the GDS/LEF power domain and
Spice netlist node name. The ‘switch_info’ keyword defines the file generated from the
gds2def run. An example ‘qswitch’ configuration file follows:
# example configuration file for generating <IP_cell>.smin
vp_mapping <GDS/LEF_power_domain> <Spice_netlist_node_name>
vp_mapping <vdd1_int> <vdd1_int_sp>
vp_mapping VDDPR vddpr
vp_mapping VDDA vddar
vp_mapping VDDAR vddarchip
switch_info <IP_macro>.swinfo
subckt <IP_macro>.nsp
include <model files>
# if needed include SPICE options
option scale=1e-6
...
To run qswitch, use the command
qswitch <IP_cell>.smin
After running qswitch the subcircuit file, <IP_macro>.subckt, for each switch is
generated. With these subcircuit files, you can run the aplsw utility to generate the switch
model file for RedHawk. A sample switch IP subckt file follows:
*-- qswitch extraction tool
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of IP Block Designs with Switched Power
RedHawk User Manual
| 342
*-- extracted switch subckt for cell ‘sw1'
.SUBCKT sw1 VDD1_EXT_ADS VDD1_INT_ADS PWRUP_ADS PWRON_ADS M0
+ VDD1_EXT_ADS POWERUP_ADS VDD1_INT_ADS VDD1_INT_ADS PCH L=0.3W=0.35
+ M=1 M1 VDD_ADS POWERUP_ADS
...
*--- Switch Subckt for cell 'sw2'
.SUBCKT sw2 VDD2_INT_ADS VDD2_EXT_ADS PWRUP_ADS PWRON_ADS
+ M3 VDD2_EXT_ADS PWRUP_ADS VDD2_EXT_ADS VDD2_EXT_ADS PCH
+ L=0.085 W=0.2 M=1…
*-- user specified options
.option scale=1e-6
.inc ../../lib.model
IP Switch Characterization with the aplsw Utility
The APL utility aplsw is used to characterize the IP switches for RedHawk analysis. See
section "Characterization and Implementation", page 13-327, for more details on syntax
and an example aplsw configuration file.
An example of the aplsw output and the characterized model is shown in Figure 13-18.
VDD_EXT_ADS
PWRUP_ADS
PWRON_ADS
VDD_INT_ADS
VSS
sw1
Figure 13-18
SWITCH_CELL sw1 {
SWITCH_TYPE: HEADER
EXT_PIN: VDD_EXT_ADS
INT_PIN: VDD_INT_ADS
CTRL_PIN: PWRUP_ADS F CTRL_PIN: PWRON_ADS F ON:
R 30.1234
I 6.08777e-10
C 5.02222e-14
IDSAT 0.011111
OFF:
C 2.121212e-18
PWL_CURRENT: 3
#V <VDD_EXT_ADS> <all in & out pins> <# of voltage sampling points>
V VDD_EXT_ADS VDD_INT_ADS 12
0 0.09 0.19 0.29 0.39 0.49 0.58 0.68 0.78 0.88 0.98 1.08
aplsw model of IP switch
ACE Characterization
The ACE utility provides equivalent power circuit resistance, device capacitance, and
leakage current data. For details on running ACE, see section "ACE Decap and ESR
Characterization", page 9-262.
Running RedHawk with Switch IP models
Running RedHawk with switched IP blocks is similar to other RedHawk analyses using
gds2def modeled blocks. You should identify the gds2def models using the GSR keyword
GDS_FILE. along with the following two additional keywords:
EXTRACT_INTERNAL_NET 1
When set to 1 this keyword means the user does not need to specify the internal nets
in VDD_NET_LIST; RH automatically traces the internal power nets and extracts
them. The Virtual Power control file must be included.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 343
VP_CONTROL {
<control_filename>
}
The VP_CONTROL keyword specifies a file that describes the controlling pin information for switch IP macros. See section "VP_CONTROL", page C-699, for details
on the contents, format and usage of the file.
Analysis of Switched RAM Designs
Introduction
Switched RAM designs are different than other types of power switching designs in that
the switches are an integral part of the RAM blocks and therefore they must be extracted
in a different manner. This section describes the methodology for handling various types
of switched RAM designs for On-state static IR and DvD analyses and also for Ramp-up
analysis.
Types of Switched RAM Supported
The following four types of switched RAM can be analyzed in RedHawk:
• Case 1 - single external/internal P/G net pair connected by a switch cell
• Case 2 - multiple external/internal P/G net pairs connected by an unique switch cell
respectively
• Case 3 - single external P/G net connecting to multiple internal P/G nets by the same
switch cell
• Case 4 - single external P/G net connecting to multiple internal P/G nets by the
different switch cells
These types of supported switch arrangements are shown diagrammatically in Figure 1319.
Case 1:
Case 2:
Case 3:
Case 4:
ext_vdd1
sw1
ext_vdd1
sw1
int_vdd1
ext_vdd2
sw2
int_vdd2
ext_vdd1
ext_vdd1
sw1
int_vdd1
sw1
int_vdd2
sw1
sw2
Figure 13-19
int_vdd1
int_vdd1
int_vdd2
Supported switched RAM configurations
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 344
The following switched RAM configurations represent design violations and are not
supported in RedHawk analysis:
• Cases 5 and 6 - multiple external P/G nets connecting to a single internal P/G net
These types of unsupported switch arrangements are shown diagrammatically in Figure
13-20.
Case 5:
Case 6:
Figure 13-20
Ext_vdd1
sw1
Ext_vdd2
sw2
Ext_vdd1
sw1
Ext_vdd2
sw1
int_vdd1
int_vdd1
Unsupported switched RAM configurations
Overview of Switched RAM Analysis
Analysis of Static, Dynamic Voltage Drop (DVD) and Ramp-up conditions in switched
RAM designs can be performed by RedHawk as needed. Overviews of the data flows for
each of these types of analyses are shown on the following pages in Figure 13-21, Figure
13-22, and Figure 13-23.
Apache tech
LEF/DEF
IP
model
Optional – improves accuracy
lib
SPEF/DSPF
IP physical model
generated by GDS2DEF flow
Additional keywords in GSR:
LEF_FILES (including switch
LEF), GDS_CELLS,
SWITCH_MODEL_FILE,
EXTRACT_INTERNAL_NET 1,
# Import data
import gsr GENERIC.gsr
setup design
# Calculate power
perform pwrcalc
# Power/Ground grid extraction
perform extraction -power -ground
# Static IR analysis
perform analysis -static
Reports
Figure 13-21
Voltage drop
and other maps
Static IR analysis in switched RAM flow
ANSYS INC - Apache Design Business Unit
STA
(slew/clocks)
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
Lef/Def def/gds
Apache tech
STA
slew/clocks/timing
IP
model
Optional
APL
SPEF/DSPF
IP physical model
generated by gds2def flow
Additional keywords in
GSR:
LEF (including switch LEF)
GDS_CELLS,
SWITCH_MODEL_FILE,
EXTRACT_INTERNAL_NE
T 1,
APL (current and cdev),
STA ( IP TW) , GSC
setup design GENERIC.gsr
perform pwrcalc
perform extraction -power –ground -c
perform analysis -vectorless
Reports
Figure 13-22
VCD
(RTL /
gate level)
Voltage drop
and other maps
Dynamic DvD analysis in switched RAM flow
Apache tech
Lef/Def
DEF/GDS
IP
model
STA
Switch instance timing
IP physical model
generated by gds2def flow
Setup design GENERIC.gsr
Additional keywords in
GSR:
LEF (including switch LEF)
GDS_CELLS,
SWITCH_MODEL_FILE,
EXTRACT_INTERNAL_NE
T 1, APL(pwcap),
STA (switch TW), GSC,
VP_CONTROL_FILE
setup analysis_mode lowpower
perform pwrcalc
perform extraction -power –ground -c
perform analysis -lowpower
Reports
Figure 13-23
Voltage drop
and other maps
Ramp-up analysis in switched RAM flow
ANSYS INC - Apache Design Business Unit
APL
| 345
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 346
Model Generation
GDS Data Preparation
GDS2DEF flow supports two types of physical model generation, an On-state model and
a Ramp-up model. The On-state model is used in static IR and dynamic analyses, while
the ramp-up model is used for turn-on conditions. The GDS2DEF physical model flow is
shown in Figure 13-24.
Input Files
Design LEF
GDS and GDS_MAP
Invocation
GDS2DEF flow
Command: gds2def –m <config file>
Output
Macro models:
<macro_name>_adsgds.lef
<macro_name>_adsgds.def
<macro_name>_adsgds.pratio
Figure 13-24
Switch model:
<macro_name>_adsgds1.lef
GDS2DEF model flow
On-State Model
A diagram of the On-state physical model is shown in Figure 13-25.
Array0
(vss_int0)
Array
d ec
Array
ode
r
S
A mp
e n se
Array1
(vss_int1)
Array2
(vss_int2)
Global PG
Switch instance
placement
/ IO
s
Slice
……………
I/O Slices
Global P/G
……………
Switched RAM
Device virtual pin instances
connected to the external and
internal P/G nets
Figure 13-25
Macro external and internal P/G
net physical layers that are
extracted from GDS
On-state physical model
The On-state model files include:
• the DEF file, which contains the switch instance placement data, all the internal and
external P/G net physical layers, the P/G pin logical connectivity of the switch
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 347
instances, and virtual pin instances
• the LEF file, which contains the device virtual pin instances that are connected to the
internal and external P/G nets
• the Pratio file, which contains the relative strength data for device virtual pin instances
Ramp-up Model
A diagram of the ramp-up physical model is shown in Figure 13-26.
Array0
(vss_int0)
Array1
(vss_int1)
Array2
(vss_int2)
Global P/G
Switch
instance
placement
dec Array
ode
r
Array
es
O Slic
p/I
m
A
e
Sens
I/O Slices
……………
Global P/G
Switched RAM
Internal net physical
pins in LEF connecting
to switch instances
Figure 13-26
ONLY device virtual pin
instances that are
connected to the
external P/G nets
Macro external net
physical layers
that are extracted
from GDS
Ramp-up physical model
The ramp-up model has reduced output data (compared to the On-state model), for better
ramp-up flow performance. It can also be used in the On-state flow.
The ramp-up model files include:
• the DEF file, which contains the switch instance placement data, only the external P/G
net physical layers, the P/G pin logical connectivity (applied to the switch instances
and external domain virtual pin instances, but NOT the internal domain pin instances)
• the LEF file, which contains only device virtual pins connected to external P/G nets
and internal domain pins (which are connected to the switch instances)
• the Pratio file, which contains the relative strength data for the device virtual pin
instances
General GDS2DEF Configuration File Setup
The ‘EXTRACT_SWITCH_CELLS’ and ‘DEFINE_SWITCH_CELLS’ configuration file
keywords are required for ramp-up analysis, but optional for On-state mode. The
keywords must be used together, with the following syntax:
EXTRACT_SWITCH_CELLS {
<switch name> [HEADER | FOOTER] <extern_net_name>
<intern_net_name>
...
}
DEFINE_SWITCH_CELLS {
<switch_name> [HEADER|FOOTER] <input/ext_LEF_pin_name>
<output/int_LEF_pin_name>
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 348
<control pin 1> <control pin 2> ... <control pin N>
}
RedHawk supports multiple domain switching by the same switch cell (case 3), as follows:
EXTRACT_SWITCH_CELLS {
sw1 HEADER ext_vdd1 int_vdd1
sw1 HEADER ext_vdd2 int_vdd2
}
To set up for ramp-up model analysis, you must specify internal P/G domains using the
keywords VDD_NETS and GND_NETS in all cases, and also set the keyword
‘SWITCH_MODEL_MODE RAMPUP’.
To set up for the On state modeling, you do not need to specify internal nets in VDD/
GND_NETS , EXTRACT_SWITCH_CELLS and DEFINE_SWITCH_CELLS, unless you
want to perform internal domain simulation. If the EXTRACT_SWITCH_CELLS and
DEFINE_SWITCH_CELLS keywords are specified, the internal nets must be specified in
VDD/GND_NETS. Also insure that ‘SWITCH_MODEL_MODE ONSTATE’ is set (the
default value).
A sample GDS2DEF configuration file for the general case is shown below:
TOP_CELL <design_name>
GDS_FILE <gds_pointer>
GDS_MAP_FILE <layer map_pointer>
VDD_NETS {
<External_Power_net_group_name> {
VDD:
VDD_ext
}
<Internal_Power_domain_name> {
Vint:
Vint @ <layer_id> <x_coord_um> <y_coord_um>
}
}
GND_NETS {
<Ground_net_group_name> {
VSS
}
}
LEF_FILE {
<design_LEF_file_pointer>
}
USE_LEF_PINS_FOR_TRACING 1
EXTRACT_SWITCH_CELLS {
<switch name> <HEADER | FOOTER>
<external net name> <internal_net_name>
}
DEFINE_SWITCH_CELLS {
<switch_name> <HEADER|FOOTER> <ext_LEF_pin>
<int_LEF_pin> <control_pin1> ... <control_pinN>
}
CHECK_TRACING 1
SWITCH_MODEL_MODE [RAMPUP|ONSTATE]
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 349
Note that ‘Vint @ <layer_id> <x_coord_um> <y_coord_um>’ syntax is used for P/G net
tracing using location, and ‘<Ground net group name> {VSS ...}’ syntax is used for P/G
net tracing using text labels.
Remove the keyword ‘USE_LEF_PINS_FOR_TRACING 1’ if the Text tracing method is
used. The keyword ‘DEFINE_SWITCH_CELLS’ is required for switch LEF generation.
Note: the control pin name must match the one in the APL switch model.
Case 1 - GDS2DEF Configuration File
Single external/internal P/G net pair connected by a switch cell:
EXT_VDD1
sw1
INT_VDD1
Case 1 configuration switches should have a GDS2DEF configuration file as follows:
TOP_CELL <design_name>
GDS_FILE <gds_pointer>
GDS_MAP_FILE <layer_map_pointer>
VDD_NETS {
Ext_VDD1
Int_VDD1
}
GND_NETS {
VSS
}
EXTRACT_SWITCH_CELLS {
sw1 HEADER EXT_VDD1 INT_VDD1
}
DEFINE_SWITCH_CELLS {
sw1 HEADER VDD_EXT VDD_INT EN1
}
# For Net tracing using LEF pins
LEF_FILE {
<design_LEF_file_pointer>
}
USE_LEF_PINS_FOR_TRACING 1
SWITCH_MODEL_MODE [RAMPUP|ONSTATE]
For case 1 switches, configuration file specifications for EXT_VDD1 and INT_VDD1 are
optional for ‘SWITCH_MODEL_MODE ONSTATE’ and mandatory for
‘SWITCH_MODEL_MODE RAMPUP’.
Case 2 - GDS2DEF Configuration File
Multiple external/internal PG net pairs connected by an unique switch cell respectively:
EXT_VDD1
sw1
INT_VDD1
EXT_VDD2
sw2
INT_VDD2
Case 2 configuration switches should have a GDS2DEF configuration file as follows:
TOP_CELL <design_name>
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 350
GDS_FILE <gds_pointer>
GDS_MAP_FILE <layer_map_pointer>
VDD_NETS {
Ext_VDD1
Ext_VDD2
INT_VDD1
INT_VDD2
}
GND_NETS {
VSS
}
EXTRACT_SWITCH_CELLS {
sw1 HEADER EXT_VDD1 INT_VDD1
sw2 HEADER EXT_VDD2 INT_VDD2
}
DEFINE_SWITCH_CELLS {
sw1 HEADER VDD_EXT VDD_INT EN
sw2 HEADER VDD_EXT VDD_INT EN
}
# For Net tracing using LEF pins
LEF_FILE {
<design LEF file pointer>
}
USE_LEF_PINS_FOR_TRACING 1
SWITCH_MODEL_MODE [RAMPUP|ONSTATE]
For case 2 switches, configuration file specifications for sw1 ... swN pins EXT_VDDn and
INT_VDDn are optional for ‘SWITCH_MODEL_MODE ONSTATE’ and mandatory for
‘SWITCH_MODEL_MODE RAMPUP’.
Case 3 - GDS2DEF Configuration File
Single external P/G net connecting to multiple internal P/G nets by the same switch cell:
EXT1_VDD1
sw1
INT_VDD1
sw1
INT_VDD2
Case 3 configuration switches should have a GDS2DEF configuration file as follows:
TOP_CELL <design_name>
GDS_FILE <gds_pointer>
GDS_MAP_FILE <layer_map_pointer>
VDD_NETS {
Ext_VDD1
Ext_VDD1
Int_VDD1
Int_VDD2
}
GND_NETS {
VSS
}
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 351
EXTRACT_SWITCH_CELLS {
sw1 HEADER EXT_VDD1 INT_VDD1 EN1
sw1 HEADER EXT_VDD1 INT_VDD2 EN1
}
DEFINE_SWITCH_CELLS {
sw1 HEADER VDD_EXT VDD_INT EN
}
For case 3 switches, configuration file specifications for sw1 pins EXT_VDDn and
INT_VDDn are optional for ‘SWITCH_MODEL_MODE ONSTATE’ and mandatory for
‘SWITCH_MODEL_MODE RAMPUP’.
Case 4 - GDS2DEF Configuration File
Single external P/G net connecting to multiple internal P/G nets with different switch cells:
Case 4 configuration switches should have a GDS2DEF configuration file as follows:
TOP_CELL
< design name >
GDS_FILE
< gds pointer >
GDS_MAP_FILE
< layer map pointer>
VDD_NETS {
Ext_VDD1
Int_VDD1
Int_VDD2
}
GND_NETS {
VSS
}
EXTRACT_SWITCH_CELLS {
sw1 HEADER EXT_VDD1 INT_VDD1 EN1
sw2 HEADER EXT_VDD1 INT_VDD2 EN2
}
DEFINE_SWITCH_CELLS {
sw1 HEADER VDD_EXT VDD_INT EN
sw2 HEADER VDD_EXT VDD_INT EN
}
# For Net tracing using LEF pins
LEF_FILE {
<design LEF file pointer>
}
USE_LEF_PINS_FOR_TRACING 1
SWITCH_MODEL_MODE [RAMPUP|ONSTATE]
For case 4 switches, configuration file specifications for sw1 ... swN pins EXT_VDDn and
INT_VDDn are optional for ‘SWITCH_MODEL_MODE ONSTATE’ and mandatory for
‘SWITCH_MODEL_MODE RAMPUP’.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 352
APLSW Data Preparation
To prepare the APLSW data perform the following steps.
• Check the switch cell name and switch pin name consistency in the APL switch
models generated from the Spice netlist and the physical models from GDS.
• To ensure switch pin name matching, use the SPICE2LEF_PIN_MAPPING keyword
for switch model characterization.
• Set up APLSW configuration file keywords. See an example set of keywords in section
"Switch Configuration Files", page 13-327, and detailed descriptions of each keyword
in section "APL Configuration File Description", page 9-217.
On-state Analysis - Static IR and DvD Conditions
A diagram of the analysis for Static IR and DvD conditions are shown in Figure 13-27.
Figure 13-27
On-state analysis scheme
The following are key elements of switched RAM On-state analysis:
• Supports standalone macro on-state analysis.
• Switched cell APL model must be specified.
• Only the external nets must be specified with VDD_NETS or GND_NETS keywords.
• By setting EXTRACT_INTERNAL_NET 1, flow automatically traces the internal nets.
• Optional power ON control using VP_CONTROL keyword to assign internal delay to
the block switching time.
• Results checking:
• Make sure the power is successfully calculated.
• Check the connectivity of the P/G pin instances.
• Perform ‘plot current –net –name <internal net>’ command to make sure
appropriate current is assigned.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 353
GSR Keyword Settings - Static IR Analysis
The following are the key GSR keywords that must be defined for On-state switched RAM
analysis for Static IR conditions. See the descriptions in Appendix C for more details on
their syntax.
• TECH_FILE <tech file >
Defines the tech file.
• VDD_NETS {
<VDD net name> <VDD voltage>
}
Defines Vdd nets and voltages-- internal nets should not be included.
• GND_NETS {
<VSS net name> <VSS voltage>
}
Defines Ground nets and voltages-- internal nets should not be included.
• BLOCK_POWER_FOR_SCALING {
<Block_power data>
}
Defines block power data. See Appendix C description for details.
• LIB_FILES {
<lib file names>
...
}
Defines LIB files.
• LEF_FILES {
<user IP LEF file>
<gds2def path>/<macroname>_adsgds1.lef
}
Defines switch LEF file generated in gds2def flow.
• DEF_FILES {
<DEF file>
...
}
Defines LEF files.
• GDS_CELLS {
<cellname> <gds2def path for the on-state physical model>
...
}
Defines the GDS cells included in the analysis.
• FREQ <frequency>
Defines the operating frequency.
• SWITCH_MODEL_FILE {
<APL switch model file >
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 354
}
• PAD_FILES {
<pad files>
...
}
Defines pad files.
• EXTRACT_INTERNAL_NET 1
Sets internal net extraction.
GSR Keyword Settings - DvD Analysis
The following are the key GSR keywords that must be defined for On-state switched RAM
analysis for Dynamic Voltage Drop conditions. See the descriptions in Appendix C for
more details on their syntax.
• TECH_FILE <tech file >
Defines the tech file.
• VDD_NETS {
<VDD net name> <VDD voltage>
}
Defines Vdd nets and voltages-- internal nets should not be included.
• GND_NETS {
<VSS net name> <VSS voltage>
}
Defines Ground nets and voltages-- internal nets should not be included.
• APL_FILES {
<current_model> current
<cap_model> cap
...
}
Defines APL current and capacitance data. See Appendix C description for
details.
• LIB_FILES {
<lib file names>
...
}
Defines LIB files.
• LEF_FILES {
<user IP LEF file>
<gds2def path>/<macroname>_adsgds1.lef
}
Defines switch LEF file generated in gds2def flow.
• DEF_FILES {
<DEF file>
...
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
}
Defines DEF files.
• GDS_CELLS {
<cellname> <gds2def path for the on-state physical model>
...
}
Defines the GDS cells included in the analysis.
• FREQ <frequency>
Defines the operating frequency.
• SWITCH_MODEL_FILE {
<APL switch model file >
}
• DYNAMIC_SIMULATION_TIME <sec>
Defines dynamic simulation time.
• PAD_FILES {
<pad files>
...
}
Defines pad files.
• EXTRACT_INTERNAL_NET 1
Sets internal net extraction.
• GSC_FILE <GSC file>
Defines GSC filename. GSC content format:
<instance name> [ HIGH | LOW ]
Example: mem_inst HIGH
• STA_FILE {
<design name> <timing file>
}
Defines STA timing data file.
• POWER_MODE APL
Defines APL power mode.
• VP_CONTROL {
<Switch timing control file>
}
Defines optional control file.
Ramp-up Analysis
A diagram of the analysis for Ramp-up conditions are shown in Figure 13-28.
ANSYS INC - Apache Design Business Unit
| 355
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
Figure 13-28
RedHawk User Manual
| 356
Ramp-up analysis scheme
The following are key elements of switched RAM ramp-up analysis:
• The VP_CONTROL keyword is a mandatory setting in the GSR file, which is used to
specify the internal delay of the switch control pin inside the memory block. This delay
is added to the timing value from the STA file to form the final switch TW.
• For multiple-domain ramp-up flow, only the device capacitance (cdev) APL model is
supported. You can use RAMPUP_OFFSTATE_VOLTAGE keyword to specify the
initial off-state voltage in the ramp-up simulation. The default value is 1/3 of nominal
voltage specified in VDD_NETS.
• For single-domain ramp-up flow, you can use either the cdev or pwcap model. Use the
aplcdev2pwl utility to convert cdev to pwcap.
• Only the external nets must be specified in the VDD_NETS or GND_NETS keywords.
• By setting EXTRACT_INTERNAL_NET 1, the flow automatically traces the internal
nets.
• The switch cell APL model must be specified.
• Capacitance is connected to the switch instances, which are logically connected in the
ramp-up simulation.
• Does not support standalone macro ramp-up flow. In order to run macro analysis, a
dummy top DEF must be created to instantiate the macro.
• Supports automated daisy-chain delay assignment using the VP_CONTROL keyword
• .After the proper GSR keywords are set (see the following section), ramp-up analysis
is invoked with the following command:
-perform analysis -lowpower -alp3d"
The -alp3d option provides approximately 3X overall speed-up for ramp-up analysis,
with an accuracy impact of only 10-15%. Note that the time step must be <= 150 ps.
GSR Keyword Settings - Ramp-up Analysis
The following are the key GSR keywords that must be defined for Ramp-up switched
RAM analysis. See the descriptions in Appendix C for more details on their syntax.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
• TECH_FILE <tech file >
Defines the tech file.
• VDD_NETS {
<VDD net name> <VDD voltage>
}
Defines Vdd nets and voltages-- internal nets should not be included.
• GND_NETS {
<VSS net name> <VSS voltage>
}
Defines Ground nets and voltages-- internal nets should not be included.
• APL_FILES {
<pwcap APL model> pwcap
...
}
Defines APL pwcap or cdev model data.
• LIB_FILES {
<lib file names>
...
}
Defines LIB files.
• LEF_FILES {
<user IP LEF file>
<gds2def path>/<macroname>_adsgds1.lef
}
Defines switch LEF file generated in gds2def flow.
• DEF_FILES {
<DEF file>
...
}
Defines DEF files.
• GDS_CELLS {
<cellname> <gds2def path for the on-state physical model>
...
}
Defines the GDS cells included in the analysis.
• FREQ <frequency>
Defines the operating frequency.
• SWITCH_MODEL_FILE {
<APL switch model file >
}
• DYNAMIC_SIMULATION_TIME <sec>
ANSYS INC - Apache Design Business Unit
| 357
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
RedHawk User Manual
| 358
Defines dynamic simulation time.
• PAD_FILES {
<pad files>
...
}
Defines pad files.
• EXTRACT_INTERNAL_NET 1
Sets internal net extraction.
• GSC_FILE <GSC file>
Defines GSC filename. GSC content format:
<instance name> <internal net> <POWERUP>
Example: mem_inst1 vdd_int POWERUP
• STA_FILE {
<design name> <timing file>
}
Defines STA timing data file.
• POWER_MODE APL
Defines APL power mode.
• VP_CONTROL {
<Switch timing control file>
}
Defines the optional control file. Refer to the next section for details.
Switched RAM Analysis Timing Control Settings
Switched RAM analysis provides as much flexibility as possible in controlling the turn-on
sequence of memories that have power gating built-in. To do this RedHawk honors the
memory ENABLE/Control pin timing window as a starting point. Based on an optional
user-specified time, call it “delta”, turns on RedHawk-selected switches at TW,
TW+1*delta, TW+2*delta, and so on. If delta=0 (no user-specified delta value), then all
switches turn on at TW.
Typically during ‘gds2def’ translation, the DEF created does not have the relationship
between the switches. So the turn-on order is not well controlled. So to solve this issue
you can specify the switch turn-on delay (delta), either a global or an instance-specific
(adsU<>) value that is created in the GDS2DEF flow to control the timing of the specific
switches, as described below.
VP_CONTROL is a mandatory keyword for the ramp-up flow, to specify the timing of
switch instances inside memory macros. VP_CONTROL contains MACRO-based
models. There are two methods of specifying the timing, global and instance-specific.
Global Timing Assignment
For global timing assignment, you can set the POWERUP and POWERON (optional)
keywords. The format of the global timing setting is shown below:
<macro name> {
POWERUP <block ctrl pin1> <int domain1> < powerup_time_sec>
?<daisy delay_sec>?
...
POWERUP <block ctrl pinN> <int domainN> <powerup_time_sec>
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Switched RAM Designs
?<daisy delay_sec>?
POWERON <block ctrl pin1> <int domainN>
...
POWERON <block ctrl pinN> <int domainN>
}
RedHawk User Manual
| 359
<poweron_sec> (optional)
<poweron_sec> (optional)
For example:
Mem1 {
POWERUP ctrl vdd_int 1e-9
}
In this example, all switch instances inside IP instances with master cell ‘mem’ switch at:
T=TW_of_ctrl+1ns
The block control pin in the POWERUP setting is used in the ramp-up flow to extract the
external macro switch timing from the STA timing file.
Instance-based Timing Assignment
For instance-based timing assignment the POWERUP, POWERON (optional) and
SWITCH_RAMPUP_TIMING keywords must be used together. The format of the
instance-specific timing specifications is shown below:
<macro name> {
POWERUP <block ctrl pin1> <int domain1> < powerup_time_sec>
...
POWERUP <block ctrl pinN> <int domainN> < powerup_time_sec>
POWERON <block ctrl pin1> <int domain1> <poweron in sec>
(optional)
...
POWERON <block ctrl pinN> <int domainN>
<poweron_sec>
(optional)
SWITCH_RAMPUP_TIMING <switch inst name adsU#>
<powerup_time_sec>
?<poweron_time_sec>?
SWITCH_RAMPUP_TIMING <switch inst name adsU#>
<powerup_time_sec>
?<poweron_time in sec>?
}
The block control pin in the POWERUP setting is used in the ramp-up flow to extract the
external-macro switch timing from the STA timing file.
For switch instances whose timing is not specified in SWITCH_RAMPUP_TIMING, the
timing in POWERUP is used. For example, if there are three switch instances in the
design, namely adsU[2-4]:
mem1 {
POWERUP ctrl vdd_int 500e-12
SWITCH_RAMPUP_TIMING adsU2 1e-9
}
Then adsU2 and adsU3 in mem1 will switch at:
T=TW_of_ctrl+1ns
The switch adsU4 in mem1 will switch at:
T=TW_of_ctrl+500ps
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
RedHawk User Manual
| 360
Analysis of LDO Low Power Designs
Overview
To support advanced techniques related to supply voltage control, such as multi-supply
multi- voltage (MSMV), and dynamic voltage and frequency scaling (DVFS), on-chip low
drop-out regulators (LDOs) are widely used to control each power domain. So LDO-aware
voltage drop analysis has become significant for verifying the stability of the voltage
supplied from the LDOs. This section describes the generation of LDO models and how to
use them in RedHawk to perform static and dynamic voltage drop analysis that accurately
capture the response of on-chip LDOs. The LDO-based flow in RedHawk is shown in
Figure 13-29.
Figure 13-29
LDO analysis flow
LDO design modeling
Figure 13-30 shows a schematic of a typical LDO used in designs. To generate the LDO
model, get DC biasing information for all the inputs to the LDO netlist.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
Figure 13-30
RedHawk User Manual
| 361
Typical LDO schematic
There are three types of LDO models generated by RedHawk, as follows:
• ideal LDO model with constant output voltage
• static models are current-controlled DC transfer voltage sources (first order
approximation)
• dynamic/transient models also capture the transient behavior of LDOs, which account
for the instantaneous drop in the voltage caused by high current demand (most
accurate).
The LDO-based data flow is shown in Figure 13-31. The details of the procedure are
given in the following paragraphs.
Figure 13-31
LDO data flow
There are four basic steps in LDO-based dynamic flow. In the LDO DC-based flow, only
the first two steps are required.
1.
Generate an LDO DC model using the APLDO utility (see section "Analysis of LDO
Low Power Designs", page 13-360).
2.
a. Generate a CPM model that includes the LDO input/output ports and possibly
some internally-probed nodes.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
RedHawk User Manual
| 362
To use LDO models, the following keyword must be in the GSR file:
LDO_MODEL_FILE {
<ldo_model_file_from_APLDO>
}
The keyword ‘DECOUPLE_LDO_GROUND 1’ must be set in both the GSR and in
the LDO configuration file for the LDO-based flows. When running the LDO flow in
RedHawk and ‘DECOUPLE_LDO_GROUND 0’ is used, the LDO output voltage
subtracts the Vss voltage at each time point, but ground bounce can be a problem.
If ‘DECOUPLE_LDO_GROUND 1’ is specified, the original LDO output voltage is
reported, which is usually desired. The default is 0.
Also, for LDO analysis the following keyword should be set in the gds.config file if
an LDO is present in GDS:
WHITE_BOX_CELLS {
<ldo_cell>
}
b. Use the generated DC LDO model in the RedHawk to create a CPM-LDO of the
die, using the following command:
perform powermodel -nx <num_x_partitions> -ny
<num_y_partitions> -vcd -pincurrent -global_gnd -o CPM_LDO
-probe -reportcap
where
-probe : reads the <probe_node_file> defined in the PROBE_NODE_FILE GSR
keyword, which is required if you want to check the DvD of the nodes in
CPM+LDO_xtor+pkg runs outside of RedHawk. The format of
<probe_node_file> is the following:
<x in um> <y in um> <layer> <node_name>
For full syntax description, see section "‘perform powermodel’", page D-765.
3.
For dynamic models, generate an AC LDO model, either for a load regulation
dynamic model considering load variation, or for a line regulation dynamic model
considering input variation as well, with CPM+LDO_xtor [+pkg] with APLDO (see
the APLDO section for details).
4.
Run RedHawk again with the AC LDO model for either VCD-based or vectorlessbased analysis, to get accurate LDO output voltage/current responses depending
on the load.
Controlling LDO switching state using GSC file
RedHawk can turn on/off LDO instances in dynamic analysis based on the settings in
GSC file.
1.
User can decide on-state or off-state for each LDO instance based on GSC setting.
The state for a LDO instance cannot be changed during dynamic analysis.
Wildcard(*) characters are accepted in this case.
Syntax:
<LDO instance name> [DISABLE|ENABLE]
Example:
LDO_* DISABLE
LDO_1 ENABLE
It means that all LDO instance with name matching LDO_* will be off-state, except for
LDO_1, which will be on-state.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
2.
RedHawk User Manual
| 363
User can change any state for a LDO instance during dynamic analysis. This
usage does not support wildcard(*) characters. The two new GSC file keywords
'LDO_INST_CONFIG' and 'END_LDO_INST_CONFIG' should be specified as in
below format to enable this.
Syntax:
User should add comments using "#" before these 2 keywords.
# LDO_INST_CONFIG
<LDO instance name> [disable|enable] <time:pico sec.>
[disable|enable] <time:pico sec.> [disable|enable]
<time:pico sec.> ………...
# END_LDO_INST_CONFIG
Example:
# LDO_INST_CONFIG
LDO_3 enable 10000 disable 15000 enable 20000 disable 25000
# END_LDO_INST_CONFIG
Example for Case1 + Case 2:
This usage doesn't support wildcard(*). Assuming that there are 4 LDO instances :
LDO_1 DISABLE
LDO_2 ENABLE
LDO_4 DISABLE
# LDO_INST_CONFIG
LDO_3 enable 10000 disable 15000 enable 20000 disable 25000
# END_LDO_INST_CONFIG
To check the state of an LDO instance, user can run "plot current -ldo -name
<LDO instance name>" . The file adsRpt/Dynamic/ldo.current will be impacted
by this feature.
Outputs generated in LDO-based analysis
The following outputs are generated in LDO-based analysis in the directory adsRpt/
Dynamic.
• ldo.current (output current waveforms)
• ldo.voltage (output voltage waveforms)
• ldo_dynamic.rpt
• Min/Max load current value
• Min/Max output voltage value
• Min/Max input voltage value
• Min/Max load current di/dt value
LDO Modeling with APLDO
APLDO is the LDO modeling utility that generates behavioral LDO models used by
RedHawk. The following are the inputs and outputs for running APLDO:
• Input Data
• Spice netlist and model parameters
• proper configuration (keywords to enable modeling features and parameters)
• CPM file (optional for optimal dynamic LDO models)
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
•
RedHawk User Manual
| 364
package (optional when package decap data available for LDO output net)
• Output Data
• encrypted LDO model file (NSpice/HSpice accept it as a subckt)
• DC model - I-V table
• transient model - RLC & control sources
Following are example configuration templates for the generation of DC, load regulation
dynamic, and line regulation dynamic LDO models used in the APLDO utility:
LDO DC model example configuration file
# users can control the duration of the current ramp using this keyword
# (default is 300us). During LDO model creation, the I-V characteristics are
# extracted by simulating LDO using a current ramp.
DC_RAMP_TIME <load current ramp-up time>
# name of the LDO cell (required)
LDO_CELL LDO_cell
# name of output file (optional with default <ldo_cell>_apldo.mdl>)
#OUTPUT_FILE
# Spice netlist containing subcircuit definitions. Can be more than one
SPICE_NETLIST ../totem/netlist_subckt_vcc
# temperature condition (optional with default value 25 degree C)
TEMPERATURE 25
# DEVICE_MODEL_LIBRARY defines Spice device model (optional)
DEVICE_MODEL_LIBRARY ./user_data/SPICE/device.lib TT
# include files (optional)
INCLUDE ./totem/tt
# special Spice options (optional)
OPTION GSHUNT=1e-12
# path to the Spice executable (optional -- NSpice is used by default).
# SPICE_SIMULATOR hspice /appls/synopsys/C-2009.09-SP1/hspice/linux/hspice
# minimum idle current (required)
# start current value in the model
MIN_IDLE_CURRENT 1.0mA
# minimum load current (A) (required)
# the minimum load current in the application
# generally, may set it the same as MIN_IDLE_CURRENT
MIN_LOAD_CURRENT 1.0mA
# maximum load current (A) (required)
MAX_LOAD_CURRENT 320mA
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
RedHawk User Manual
| 365
# dc current sweep step
DC_CURRENT_SWEEP_STEP 2mA
# output power pin name and ideal voltage (required)
POWER_OUTPUT_PIN vccr 2.2
# minimum output voltage (optional)
# MIN_OUTPUT_VOLTAGE 1.08
# minimum input voltage (optional)
# MIN_INPUT_VOLTAGE 2.40
# analog power input pin name (required)
POWER_INPUT_PIN vcc_in 3.0
# general ground pin name (required)
GROUND_PIN gnd 0
# dc bias
# <pin_name> <voltage>
DC_BIAS vcc_in
3.00
DC_BIAS gnd
0.0
DC_BIAS vbgr
1.25
APLDO example configuration file for load regulation dynamic model
# name of the LDO cell (required)
LDO_CELL LDO_cell
# name of output file (optional with default <ldo_cell>_apldo.mdl>)
#OUTPUT_FILE
# Spice netlist containing subcircuit definitions. Can be more than one.
SPICE_NETLIST ../totem/netlist_subckt_vcc
# temperature condition (optional with default value 25 degrees C)
TEMPERATURE 25
# DEVICE_MODEL_LIBRARY defines Spice device model (optional)
DEVICE_MODEL_LIBRARY ./user_data/SPICE/device.lib TT
# include files (optional)
INCLUDE ./totem/tt
# special Spice options (optional)
OPTION GSHUNT=1e-12
# path to the Spice executable (optional -- NSpice is used by default).
#SPICE_SIMULATOR hspice /appls/synopsys/C-2009.09-SP1/hspice/linux/hspice
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
RedHawk User Manual
# minimum idle current (required)
# the start current value in the model
MIN_IDLE_CURRENT 1.0mA
# minimum load current (A) (required)
# the minimum load current in the application
# generally, may set it the same as MIN_IDLE_CURRENT
MIN_LOAD_CURRENT 1.0mA
# maximum load current (A) (required)
MAX_LOAD_CURRENT 320mA
# dc current sweep step
DC_CURRENT_SWEEP_STEP 2mA
# output power pin name and ideal voltage (required)
POWER_OUTPUT_PIN vccr 2.2
# transient model characterization for multiple output ground arcs.
POWER_ARC {
POWER_OUTPUT_PIN <vdd_pin1> <voltage>
...
}
POWER_ARC {
POWER_OUTPUT_PIN <vdd_pin2> <voltage>
...
}
# minimum output voltage (optional)
# MIN_OUTPUT_VOLTAGE 1.08
# minimum input voltage (optional)
# MIN_INPUT_VOLTAGE 2.40
# analog power input pin name (required)
POWER_INPUT_PIN vcc_in 3.0
# general ground pin name (required)
GROUND_PIN gnd 0
# dc bias
# <pin_name> <voltage>
DC_BIAS vcc_in
3.00
DC_BIAS gnd
0.0
DC_BIAS vbgr
1.25
# Defines the top level subckt name of CPM + LDO test bench (required)
CPM_LDO_MODEL adsPowerModel
# CPM_LDO_FILE <file name>
ANSYS INC - Apache Design Business Unit
| 366
CHAPTER 13 — Low Power Design Analysis
Analysis of LDO Low Power Designs
RedHawk User Manual
| 367
# To specify filename of the CPM + LDO test bench (required)
CPM_LDO_FILE ./power_model_CPM-LDO
# CPM_LDO_PORT <port name> <value>
# Defines the bias conditions for CPM_LDO_MODEL. Users must check the
# PLOC and set the corresponding pad value to the ports of CPM_LDO_MODEL.
# Wildcards supported to specify the port name of CPM_LDO_MODEL (required)
CPM_LDO_PORT *:VCC 3.0
CPM_LDO_PORT *:VSS 0
# CPM_OPEN_PORT <port name>
# Defines the open ports of CPM_LDO_MODEL. The defined ports remain floating
# while characterizing the LDO model. Wildcards are supported to specify the
# port name (optional)
CPM_OPEN_PORT VBB:*
# CPM_LDO_TRANSIENT_TIME <time>
# Defines the transient simulation time in APLDO characterization.
# Users may refer to the RedHawk simulation time for CPM model generation
# and specify the same in CPM_LDO_TRANSIENT_TIME for LDO models (optional).
CPM_LDO_TRANSIENT_TIME 120ns
# the subckt name of PKG model (optional)
# but is required when CPM_LDO_PORT is not specified
# PACKAGE_MODEL <subckt name>
PACKAGE_MODEL REDHAWK_PKG
# the PKG model filename (optional)
# it is required when PACKAGE_MODEL is given
# PACKAGE_FILE <pkg_file_name>
PACKAGE_FILE redhawk_pkg_0.spi
Generating the DC LDO model
Use the following command to generate the DC LDO model:
% apldo apldo.config
For APLDO debugging help, set “DEBUG 1" in configuration file, which keeps the
.apache/APLDO directory for the following files:
• ldo_dc_vdd.cir (for dc sweep simulation)
• ldo_ac_vdd.cir (for ac sweep simulation)
Testing LDO models
Generated LDO models are encrypted, so you can perform sanity checking on the model
by running Spice simulations on the <>_LOAD_REGULATION_TEST_BENCH.sp file in the
apldo working directory.
Also, the command ‘aplreader -ldo <LDO model>’ can be used to plot LDO output I-V
curves.
ANSYS INC - Apache Design Business Unit
CHAPTER 13 — Low Power Design Analysis
Analysis of Gated Clock Designs
RedHawk User Manual
| 368
Other practical LDO applications
The LDO methodology described not only analyzes voltage drop, but also can assist in
adjusting the on-chip LDO size (that is, the drive strength) and the locations for power
reduction and chip shrink. For example, by replacing a normal-sized on-chip LDO with
one that is half-sized, designers can compare the two voltage waveforms at the output pin
of those LDOs, as shown in Figure 13-32. If the half-sized one meets design constraints in
voltage drop, designers can use it instead of the normal-sized one. This means that as
another application, this method provides a what-if analysis for adjusting on-chip LDO
size. Moreover, designers can adopt the method without any modifications to low power
techniques such as MSMV and DVFS. And designers have other advantages in chip
modeling, such as Chip Power Model (CPM), for chip-package co-design, using this
method.
Figure 13-32
LDO output voltage for normal and half drive strength
Analysis of Gated Clock Designs
In order to support the many mobile and high-density applications, low power
consumption has become a necessity in today's IC design. One type of low power design
turns on only parts of the circuit at a time. These power modes can be switched in and out
by turning different clock domains on/off along with their corresponding logic. The multiple
clock domains are usually controlled by multiplexing logic and clock control inputs,
referred to as “gated clock” design.
From a power analysis point of view, it is unrealistic to analyze the whole chip with all
clocks on. The key is to identify the various power modes, and analyze the critical ones in
terms of dynamic voltage drop and impact on timing. For details on performing Gated
Clock design analysis, see section "Gated Clock Dynamic Analysis", page 5-94.
It is important to recognize that for gated clock designs, each “mode” must to be analyzed
separately, with its mode-specific static timing analysis file.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
Introduction
RedHawk User Manual
| 369
Chapter 14
Chip Power Modeling (CPM)
Note: The generation of CPM is considerably more complex than regular dynamic
voltage drop analysis, since the CPM generation process must preserve both the
time and frequency domain response of the underlying circuit for a wide range of
frequency points (DC to multi-GHz). However, the typical usage model of CPM
creation assumes a continuation of a dynamic voltage drop analysis, whose settings
and network formulation may not be appropriate for CPM generation, resulting in
additional complexities.
Starting in version 12.2, RedHawk requires users to use a separate CPM creation
flow (using the GSR keyword setting: GENERATE_CPM 1), which ensures that the
CPM generation flow is distinct from dynamic voltage drop analysis. This provides
RedHawk the flexibility to provide additional optimization necessary for CPM creation
without affecting standard dynamic voltage drop analysis.
Introduction
Chip package and printed circuit board (PCB) designers need an accurate and relatively
simple IC power model to design and optimize effective chip packages and boards -including key parameters such as impedance and resonant frequencies of the global
power delivery network (PDN). An equivalent circuit for the chip PDN must provide not
only an accurate multiple-terminal impedance model, but also accurate current
waveforms to represent a realistic worst-case switching scenario for the chip.
Apache's Chip Power Model (CPM) enables die-package-board co-design and coverification for dynamic power integrity. Built on the RedHawk full-chip dynamic power
integrity platform, CPM generates a compact and accurate model of the full-chip power
delivery network at various key stages of chip and package design.
CPM supports the VectorLess™ clock gating switching mode, in addition to the default
vectorless and VCD modes. In clock gating Vectorless mode, RedHawk generates a
switching scenario that mimics the transition from one clock gating mode to another
during multi-cycle transient analysis. A CPM created in this mode captures the current
transitions when this clock gating scenario change occurs. This change in current
demand is particularly useful to understand the associated Ldi/dt effect in package and
board level analyses. CPM has a Resonance Frequency Aware Excitation Mode, in which
the RedHawk VectorLess engine generates a multiple-cycle switching scenario for the
current signature that introduces most of the energy around the chip-package-system
resonance frequency. You only need to specify the system resonance frequency when
creating the model, and the CPM technology automatically creates the frequency-based
form of on-die excitation, while maintaining the logic and timing properties of the circuit.
CPM bridges the design of the power delivery network between the IC and the associated
package and PCB. System designers can use CPM to guide and verify the off-chip PDN
design by evaluating the impact of on-die parasitics over the global PDN impedance,
diagnose potential chip-package LC resonance, validate the package/board dynamic
voltage noise margin, as well as to optimize the off-chip decoupling capacitor placements.
Both current signatures and parasitic network are distributed across a multiple-terminal
equivalent circuit to reflect their temporal and spatial dependencies. The simplest element
of the CPM model can be considered to be a serially-connected RDIE and a CDIE, in
parallel with a current switch, as shown in Figure 14-1.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
Design Flow
Figure 14-1
RedHawk User Manual
| 370
Power Delivery Network and simple Chip Power Model
SPICE-compatible CPM includes parasitics of non-linear switching and non-switching
devices, parasitics of power/ground wires, decoupling capacitors, and effective RC's of
the loading capacitors from signal interconnects. In addition, CPM contains full-chip
switching current signatures based on transistor-level SPICE simulations.
Design Flow
CPM technology can be useful at all stages of the package-IC system co-design process,
as shown in the Figure 14-2 flow diagram.
Synthesis
Synthesis
Floor
Floor&&Power
PowerPlan
Plan
Early-stage CPM
PG prototyping
Pkg/Brd
Pkg/Brdprototyping
prototyping
Refined CPM
Refining
Refining&&Optimizing
Optimizing
Final CPM
Die-Pkg-brd
Die-Pkg-brdSign-off
Sign-off
Placement
Placement&&Routing
Routing
Timing
Timingclosure
closure
De-cap
De-capInsertion
Insertion
Physical
PhysicalVerification
Verification
DRC
DRCLVS
LVS
Figure 14-2
CPM-based IC system co-design process
The generation of CPM is considerably more complex that regular dynamic voltage drop
analysis, since the CPM generation process must preserve both the time and frequency
domain response of the underlying circuit for a wide range of frequency points (DC to
multi-GHz).
An improved CPM creation flow using the required GSR keyword ‘GENERATE_CPM 1’
ensures that the CPM generation flow is distinct from the dynamic voltage drop analysis
flow, and provides RedHawk the flexibility to optimize CPM creation without affecting
dynamic voltage drop analysis.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
RedHawk Modeling of Chip Power Delivery Network
RedHawk User Manual
| 371
RedHawk Modeling of Chip Power Delivery Network
A chip power delivery network can be modeled in several ways by CPM, depending upon
the number of power/ground pads involved and also the desired trade-off between speed
and accuracy of analysis.
Modeling Choices Based on Number of Pads
If a large number of die pads are involved, such as several thousand in a typical flip chip
package design, the die pad area is partitioned into smaller rectangular areas and CPM
generates a set of terminals corresponding to each Vdd and Vss net within each partition.
For wirebond designs with a large number of pads, they also can be grouped into
individual partitions of pads for better analysis based on the Spice node name
specification in the PLOC file. For designs with a smaller manageable number of power/
ground pads, all pads are represented individually by CPM terminals.
All significant sources of capacitance in a chip, including parasitics and decoupling, are
included in the RedHawk chip model, as shown in the circuit of Figure 14-3:
• Intentional de-caps, from RedHawk characterization
• Intrinsic device de-caps, from RedHawk characterization
• Signal loading capacitance, from SPEF (StarRC)
• Coupling capacitance between power and ground wires, from RedHawk extraction
i (t)
Vdd Pad
L
Rpg
is(t)
+
v (t)
Cload
Vss Pad
Rdecap
Rload
Cdecap
Cmacro Cpg
Switching instance
Figure 14-3
Cdev
Rmacro
Cload
Non-switching instance
Output: 1->1
RedHawk chip power modeling circuit
CPM for Flip Chip Designs
For flip chip designs, the chip bump area can be partitioned into N x M tiles. Assuming
there are K power/ground nets (that is, one or more Vdd nets and one or more Vss nets),
then the maximum number of external terminals of the resulting CPM will be K x N x M.
Figure 14-4 shows a flip chip example with one VDD net and one VSS net. The number of
partitions is 4 (N=2, M =2).
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
RedHawk Modeling of Chip Power Delivery Network
Figure 14-4
RedHawk User Manual
| 372
Modeling a chip power circuit for a flip-chip package
CPM for Wirebond Designs
For wire-bond designs, an N-terminal CPM is created, for which typically each wire-bond
pad corresponds to a terminal of the model, as shown in Figure 14-5.
For PLOC files that have grouped ports (package nodes) and named them accordingly,
CPM by default uses the PLOC port groups and generates a set of external ports that
follow the grouping pattern in the PLOC file.
Figure 14-5
Modeling a chip power circuit for a wirebond package
3DIC CPM Generation
A combined CPM can be generated for the complete 3DIC structure, as shown in Figure
14-6. For example, if there is a memory die stacked on a logic die, CPM generation for
both logic and memory die combined can be performed using the following Tcl
commands:
import gsr mem.gsr -die mem
import gsr logic.gsr -die logic
setup design
perform pwrcalc
perform extraction -power -ground -r -c
perform powermodel -nx 1 -ny 1 -o 3dic_cpm.sp
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
RedHawk Modeling of Chip Power Delivery Network
Figure 14-6
RedHawk User Manual
| 373
3DIC CPM generation
Modeling Choices Based on Analysis Speed and Accuracy
High speed modeling
The “model order reduction” (MOR) methodology is based on a DC/zero frequencycentered solution, that becomes more inaccurate as the switching frequencies of the
design become higher, but saves runtime for conditions that do not require high
frequencies and high accuracy.
In general an assumption of power-ground symmetry is made, which means that package
power and ground impedances are considered similar. However, setting the GSR
keyword DYNAMIC_SOLVER_MODE to 1 allows a P/G solution without this assumption,
increasing the accuracy, although this makes it a more time-consuming and memoryintensive methodology.
High Accuracy Modeling
“AC” Modeling
The default AC analysis-based version of CPM significantly improves the accuracy of the
model, and has far better correlation with RedHawk simulations. CPM model construction
consists of two parts: calculation of current signatures and the reduction of the passive
part of the circuit.
The AC analysis-based CPM generation uses grid RC reduction applied to the original
RC network that contains not just the resistance and capacitance representing the
parasitics of the power/ground wires, but also the series RC branches that model the
parasitics of non-switching instances. Switching instances are modelled as time and
voltage-dependent current sources.
The analysis takes the large network of resistors and capacitors (typically with millions of
nodes) and generates a much smaller network (typically with tens or hundreds of nodes),
whose frequency domain response at the specified ports for the specified frequency
range matches that of the original network, with a tolerance better than 0.2 %. The
resulting network, which consists of R, C, and possibly L and G (constant Voltage
Controlled Current Source) elements, is exported as a SPICE netlist. The netlist is
guaranteed to be passive by construction, and thus suitable to be used in transient
simulations with SPICE or another transient simulator. This netlist can be used with any
version of SPICE (such as NSPICE from Apache and HSPICE from Synopsys) as it only
uses classic circuit elements.
S-Parameter Modeling
CPM can generate an S-parameter model of the RLC grid and export it to a Touchstone
file. This allows you to generate frequency-dependent S-parameters for the on-die power
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
RedHawk Modeling of Chip Power Delivery Network
RedHawk User Manual
| 374
grid netlist. The S-parameters are calculated at the frequencies at which the AC analysis
is performed. To use this capability, you need to specify the configuration file in the
command
perform powermodel -grid [RC |RLC ]
-options <config_file_path>'
or RC_reduction.config in the run directory. In the configuration file, you must specify the
path to the port definition file as:
portFileName=<port file name>
and specify the flag to enable S-parameter model generation (‘sParam=true’). You can
also specify the value of the reference impedance (Zo=<value>).
Example configuration file:
sParam=true
Zo=50
portFileName=port.file
In this case, the reference impedance is 50 Ohms (default is Zo=2 Ohms), and the port
file is port.file in the run directory. In the port file, the ports of the S-parameter model are
specified as CPM port (terminal) pairs. The format of the port file is:
<CPM_port_name1> <CPM_port_name2>
Note that the CPM port name is either the pad name, if there is no grouping (no 6th
column in the ploc file), or the name given in the 6th column of the PLOC file. An example
of a port file follows:
pwr_0 gnd_0
pwr_1 gnd_1
pwr_2 gnd_2
pwr_3 gnd_3
pwr_4 gnd_4
pwr_5 gnd_5
Note: there is no S-parameter port name; the first port is between the CPM ports
(terminals) pwr_0, gnd_0, the second port is between (pwr_1, gnd_1), and the 10th port is
between (pwr_9, gnd_9).
Example CPM command:
perform powermodel -grid RC -plocname -options rc.config -o output.sp
The S-parameter (Touchstone) filename is based on the specified output filename. For
example, for an output specification ‘-o rc_grid.sp’, the Touchstone filename is
re_grid.Snp, where n is the number of ports. For example, if the output file is output.sp
and there are 10 ports, the S parameter file is output.s10p, written to the run directory.
There is also a regular CPM grid netlist output output*sp file.
A sample PLOC file follows:
VDD01 10 20 metal5 POWER VDD_group1
VSS01 11 21 metal5 GROUND VSS_group1
VDD02 5 20 metal1 POWER VDD_group2
VSS02 6 21 metal1 GROUND VSS_group2
Note that automatic presim time determination is supported in S-parameter package
models. Set the GSR keyword 'DYNAMIC_PRESIM_TIME -1' to enable this function.
ESD- aware CPM Models
ESD-aware CPM models can be created for system-level ESD analysis. Clamp
connections are modeled as ports in the CPM model, and sub-circuits for clamp devices
then are included in the CPM model. The command steps are as follows:
setup analysis_mode esd
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 375
setup design <GSR_file>
...
perform extraction –power –ground
...
perform powermodel –esd ?-esd_clamp <file>? ...
Note that the ‘-esd_clamp’ option is not needed if a clamp file is specified using the
‘ESD_CLAMP_FILE’ keyword in the GSR.
CPM Simulation Procedures
Initial Setup and Preparation
The required input data for CPM is the same as you need for a full-chip RedHawk DvD
analysis. You must use the correct APL characterization data, or AVM characterization if
APL data is missing for memories and custom macros (see Chapter 9, "Characterization
Using Apache Power Library").
The switching current component of the CPM depends on the switching activity in the
design during transient simulation. Hence setting proper switching rates is critical. This
can be achieved either by using the Vectorless algorithm (see Chapter 5, "Dynamic
Voltage Drop Analysis"), or by using a VCD file (either gate level or RTL level VCD). In
contrast to the DvD analysis flow, you do NOT need to specify any package models
during a CPM run.
Additional input parameters to be decided and specified for a flip chip CPM model are the
number of partitions desired in the X and Y directions.
Running CPM
The Chip Power Model is created from the RedHawk flow, by reading the input data,
performing power calculation and on-die P/G extraction, and then creating the electrical
model of the chip power delivery network and current profiles based on the defined
partitioned network.
The RedHawk command line setup and invocation command steps are as follows:
1.
Import and set up design.
The GSR file contains the paths to all design and library files (including APL/AVM)
data and simulation conditions. See section "Global System Requirements File
(*.gsr)", page C-550, for a description of the GSR keywords. The keyword
‘GENERATE_CPM 1’ must be set or the CPM run fails.
setup design <design>.gsr
2.
Specify a temporary file location on a local disk. Particularly when multiple
processors are used and for large designs (more than 10 M nodes), writing
temporary files to a disk on the network slows down execution because of I/O
operations. Put temporary files on a local disk by setting the CACHE_DIR GSR
keyword. After chip power modeling finishes, the temporary files (linear.*) in
CACHE_DIR are deleted.
3.
Determine appropriate toggle rates and calculate average power.
perform pwrcalc
4.
Extract RLC parasitics of on-die P/G networks.
perform extraction -power -ground -c -l
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
5.
RedHawk User Manual
| 376
Set up the files to determine an accurate switching scenario for dynamic analysis:
a. To use a vectorless method to determine the switching scenario, including
clock gating, see section "Vectorless Dynamic Analysis", page 5-83, for
instructions on setting up the proper GSR keyword settings.
b. To use a VCD file to specify the switching scenario, use the GSR keyword
VCD_FILE. Refer to section "VCD_FILE", page C-585, for syntax and usage.
6.
The command syntax for generating a CPM is as follows:
perform powermodel [ -wirebond | <flip chip partitions>| -cdie| -static
| -lowpower | -esd ] ? -esd_clamp <file> ? ? -parasitic ? ?-vcd ?
?<no model option-default>? ? -pincurrent ? ? -rleak ? ? -rleak_par?
?-solver mor? ?-plocname? ? -ind? ? -no_afs? ? -passive ?
? [ -noglobal_gnd | -global_gnd ] ? ? -high_capacity 1 ?
? -repeat_current [ <start_time> | presim | best ]? -probe ?
? -internal_node -cell_file <cell_list_filename> ? ? -reportcap ?
? -o <output_filename> ? ? -reuse ? ? -io ?
where
-wirebond : specifies a wirebond package
<flip chip partitions> : -nx <num_x_ partitions> -ny <num_y_partitions>, specifies
the number of partitions in the x and y directions. For -nx 1, -ny 1, a Cdie/
Rdie report is generated in the adsRpt/CPM/apache.Cdie file.
-cdie : sets nx=1 and ny=1, and connects all power nets together and all ground
nets together to obtain a single-port solution to obtain the equivalent Cdie
and Rdie values for the chip. No current waveform is generated. A Cdie/Rdie
report is generated in the adsRpt/CPM/apache.Cdie file.
Note that the -cdie option just provides faster run time by not calculating the
current waveforms. For all other purposes it is equivalent to using ‘-nx1 -ny1’.
-static : creates static analysis chip power model, using DC conditions, a
resistance-based circuit, and average current.
-lowpower: CPM generation support for ramp-up analysis.
-esd: creates a CPM that includes clamp device models/characteristics, along
with the PDN model Spice deck. Clamp connections are modeled as ports in
the CPM model, and sub-circuits for clamp devices are included in the CPM
model. You must also specify the clamp files in the GSR. If the clamp files
are not present in the GSR, use the “–esd_clamp” option to specify the clamp
file.
-parasitic: generates only the passive part of the CPM, without performing
transient simulation, to generate the current signatures of the CPM ports, an
extension of -cdie option for multi-partition CPMs. This can save time in
transient simulation. However, the CPM model generated with -parasitic can
only be used for DC and AC analysis (not usable for transient analysis).
-vcd : uses VCD file as basis for determining the worst case switching scenario
-pincurrent: specifies that CPM generate the model without current conservation
(balanced current between Vdd and Vss) to achieve better correlation with
RedHawk dynamic simulation results. In general, CPM enforces current
conservation. However, in cases when RedHawk does not produce balanced
VDD and VSS currents, this option can be used.
-rleak: causes the leak resistance to be added between ports on the VDD (power)
net and the reference port on the VSS net.
-rleak_par: inserts leakage resistance between the VDD and VSS ports of each
defined partition. Note that this option only works with partitioned CPM
models. See the following section for more details on usage.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 377
-solver mor: turns off the default ‘solver ac’ function, which is an accurate
frequency-based linear solver AC solution with passivity enforcement.
-plocname: specifies pad/group names for CPM port names. If the '-wirebond'
option is used, the subcircuit terminal names are taken from the pad names
(if no grouping is specified), or the group names from the 6th column of the
.ploc file. These group names are also known as SPICE node names, as this
mechanism is used to connect a package using the keyword
'PACKAGE_SPICE_SUBCKT'. If this option is used with '-nx # -ny #' options,
the node names are generated in the following form: PAR_0_0_VDD1,
PAR_0_0_VSS2, ... For wirebond CPMs without any grouping, the subckt
terminal name is the ploc name.
-ind: accounts for on-chip inductance, if the option '-l' of the RedHawk 'perform
extraction' command has been used
Note: If you specify the '-l' option of the 'perform extraction' command, but not '-ind',
inductance is ignored. Not specifying the ‘-l’ option and using ‘-ind’ is an error.
-no_afs : turns off the default AFS function. Adaptive Frequency Sweep for AC
mode execution intelligently selects seven to nine frequencies (enough to
reach convergence) to perform AC analysis, as opposed to 26 frequency
samples that are performed by default in ‘solver ac’ mode. This option is
recommended for design sizes exceeding 50 ports. Port count can be
determined by computing N * M * P, where N = number of X partitions in the
CPM (-nx option), M = number of Y partitions in the CPM (-ny option), and P
= number of power and ground domains.
-passive : only effective with the MOR function, which uses MOR to generate a
passivity-enforced SPICE model, which can reduce accuracy. This mode can
be useful if the SPICE simulation of the package/PCB CPM has convergence
issues. The SPICE netlist is significantly smaller than using the default mode.
But CPM is a compact model, so complexity is not a concern for cases with,
for example, 100 bond pads, or up to 10x10 partitions for a flip-chip design.
-noglobal_gnd | -global_gnd: specifies the type of parasitic modeling in CPM,
either (a) without Spice Node 0, using option '-noglobal_gnd' (the default),
where there is a direct connection between the power and ground ports
without going through Spice node 0, or (b) using Spice Node 0, using option
'-global_gnd’, in which the RLC parasitics from power and ground are
connected to Spice global ground (node 0).
-high_capacity 1: specifies use of the asim3d solver for CPM. The default CPM
generation solver is ASIM3D(on by default). Specifying -high_capacity 0 will
switch the solver to asim_mixed.
-repeat_current: specifies that the CPM current signature is repeated starting
from the specified time point. Either a <start_time> in ns, the ‘presim’ time, or
‘best’ (chosen to cause the best continuity at the repeat point), can be
chosen as the starting point of the repeating waveform. A warning is issued
for incorrect values (such as a negative value or value greater than the
maximum time of the PWL source). For non-zero values the closest time in
the PWL definition is used. For example, if a ‘-repeat_current 1n’ option is
specified, and PWL time values ..., 900, 930, 960, 990, 1020, ... ps are
defined, ‘R=990 ps’ is used. This is required for SPICE to accept the netlist.
For the ‘best’ option to work well, the presim time and the transient simulation
time need to be set to “n*T”, where n is a positive integer, and T is the period
of the clock frequency. With this option, the repeat time may be different for
each individual PWL current source. Usage examples:
perform powermodel -nx 2 -ny 2 -repeat_current 0
which repeats starting from the beginning, t=0. Or,
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 378
perform powermodel -nx 2 -ny 2 -repeat_current 2n
which repeats starting from the time value in the PWL source definition
closest to the 2ns time specified.
-probe: invokes the iCPM utility that enables the visibility of sensitive P/G
connections in the design, and allows you to probe device locations inside
the chip. You must set the PROBE_NODE_FILE GSR keyword, as described
in section "iCPM- Internal Node Probing", page 14-382.
-internal_node: specifies additional ports located at P/ G pins on the same net
that are to be shorted together to form one internal port. These nodes are
named with the format '<instance name>_<netname>' in the CPM, such as
“inst_1_VDD”. Note that the option “–internal_node” is not supported in static
analysis.
Note that the options '-internal_node' and '-cell_file' are required to execute
this feature, and the '-pincurrent' option should be used to keep the CPM
currents at the correct value without further modifying the port currents, so
that the sum of all port currents is zero. This feature also allows you to
include/exclude the instance current profile and device capacitance from
CPM creation, using the EXCLUDE option in the GSC file. To exclude
instance current profiles and device capacitance, use the GSC syntax:
'<instance name> EXCLUDE'.
-cell_file <cell_list_filename>: specifies a file containing a list of the instances
whose internal P/G pins are to be exposed.
-reportcap: creates a log file report of all capacitance components included in the
CPM generation. Example output:
Capacitance components Intentional Decap - 0.000000e+00 pF
Intrinsic
Decap - 2.404236e+02 pF
Load
Decap - 1.945542e+02 pF
Power grid Decap - 3.260729e+00 pF
Well
Decap - 0.000000e+00 pF
Total - 4.382385e+02 pF
-o <output_filename> : specifies output filename (default - PowerModel.sp, with
the passive part in the file PowerModel.sp.inc)
-reuse : allows reuse of the generated current waveforms after one CPM run, if
chip power models with different partitioning schemes are desired
-io : specifies that the I/O cells are to be included in the chip power model
7.
So to generate a CPM for a flip chip design:
a. to use a vectorless methodology for an accurate solution:
perform powermodel
-nx <num_x_partitions>
-ny <num_y_partitions> -o <output_filename>
b. to use a VCD scenario, use the same command as in step (a) and use
the ‘-vcd’ option.
c. to generate a CPM quickly for a wirebond design:
perform powermodel -wirebond -solver mor
-o <output_filename>
d. to generate the passive part of a CPM (in a file cpm.sp.inc) with 2 x 3
partitioning:
perform powermodel -nx 2 -ny 3 -parasitic -o cpm.sp
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 379
Note that AC mode analysis in Chip Power Modeling can provide a fast solution using the
linear solver with multi-threading. You can set the maximum number of processors to be
used, which by default is the lesser of the number of processors available or 8. To use
more than 8 processors, or fewer, you can set the Linux/UNIX environment variable
'MAX_CPU <number>'. Then the number of processors used is the lesser of the
processors available and the MAX_CPU value. For example, using 'setenv MAX_CPU 4'
limits the maximum number of processors in use to four.
Basic power integrity analysis
The following GSR keywords settings are recommended for creating CPMs for basic
power integrity analysis:
DYNAMIC_TIME_STEP <ps> : time step should be less than 20ps
DYNAMIC_PRESIM_TIME < time> <TSM=1> : do not use TSM > 1.0. For
example:
DYNAMIC_PRESIM_TIME 10n 1.0
For multiple-Vdd designs, the following GSR keyword must be used. Note that run time
and memory use will increase significantly for these cases.
DYNAMIC_SOLVER_MODE 1
The recommended command options to generate CPM for power integrity analysis are:
perform powermodel [-wirebond | -nx <x-part.> -ny <y-part.>
] -plocname -repeat_current <start_time> -rleak -ind
The effects of using the -pincurrent option are described in Table 14-1 below.
Use of option
-pincurrent
Dynamic I(t)
Solver
Passive portion
Not used
0
Current from N-1 ports flow Coupled between VDD and
to one common VSS port.
VSS. Not affected by these
options.
Not used
1
Current from N-1 ports flow Coupled between VDD and
to one common VSS port.
VSS. Not affected by these
options.
Used
0
Current for all N ports flow
to Spice node 0.
Coupled between VDD and
VSS. Not affected by these
options.
Used
1
Current for all N ports flow
to Spice node 0.
Coupled between VDD and
VSS. Not affected by these
options
Table 14-1
Effects of -pincurrent option use
The effects of using the -noglobal_gnd and -global_gnd options are described in Table 142 below.
Use of options Dynamic
-noglobal_gnd Solver
and -global_gnd
-global_gnd
0
ANSYS INC - Apache Design Business Unit
I(t)
Not affected by these
options. Controlled by
–pincurrent.
Passive portion
Capacitance connected to
Spice node 0 (global
ground)
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
Use of options Dynamic
-noglobal_gnd Solver
and -global_gnd
I(t)
| 380
Passive portion
-global_gnd
1
Not affected by these
options. Controlled by
–pincurrent.
Coupled between Vdd and
Vss.
-noglobal_gnd
(default)
0
Not affected by these
options. Controlled by
–pincurrent.
Coupled between Vdd and
Vss.
-noglobal_gnd
(default)
1
Not affected by these
options. Controlled by
–pincurrent.
Coupled between Vdd and
Vss.
Table 14-2
Effects of -noglobal_gnd and -global_gnd option use
EMI modeling
The following GSR keywords settings are recommended for creating CPMs for EMI
analysis:
COUPLEC 1
DYNAMIC_SOLVER_MODE 1
DYNAMIC_TIME_STEP <ps> : time step should be less than 20ps
DYNAMIC_PRESIM_TIME < time> <TSM=1> : do not use TSM > 1.0
The recommended command options to generate CPM for EMI analysis are:
perform powermodel -pincurrent -couple_gridc [-wirebond |
-nx <x-part.> -ny <y-part.> ]
-plocname -repeat_current <start_time> -rleak -ind
User-specified Grouping for Port Creation
CPM port generation has two methodologies, wirebond and flip chip, matching the pack
designs. For designs with a low number or power and ground connections, such as
wirebond designs, the wirebond option (‘perform powermodel -wirebond’) is
recommended. By using the wirebond option, a CPM is created with a port representing
each of the power and ground connections, as defined by the PLOC file.
For designs with a higher port count or those containing a distributed sea of power and
ground connections, such as a flip chip design, the flip-chip configuration is
recommended. In this approach, the chip is divided into regions specified by the user
(that is, ‘perform powermodel -nx 4 -ny 4’). In each region, a CPM port is created for each
analyzed domain.
In some cases, the user may want use a hybrid approach. For example, for some
domains, per-pad resolution (wirebond) is required, but for other domains a grouped
representation is preferred. This section describes the procedure to enable userspecified grouping for the CPM wirebond option.
Wirebond Grouping Procedure
Arbitrary partitions are created by adding a 6th column to the PLOC file, and then using
the '-wirebond' option of the 'perform powermodel' command. In the following example,
there are 8 individual entries to the PLOC file. The 6th column represents the userspecified group name. The first two power source locations (DVDD1 and DVDD2) are
grouped into a single CPM port (GROUP_POWER_1). Similarly, the first two ground
sources (DVSS1 and DVSS2) are grouped together into a single CPM port
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 381
(GROUP_GROUND_1), as shown in Figure 14-7. The remaining PLOC sources are
represented by a unique CPM port.
Figure 14-7
Wirebond port grouping
Example PLOC file:
#source name #loc_x #loc_y #layer name #POWER/GROUND #Group name
DVDD1 10 5 METAL6 POWER GROUP_POWER_1
DVDD2 15 5 METAL6 POWER GROUP_POWER_1
DVDD3 10 5 METAL6 POWER POWER_2
DVDD4 15 10 METAL6 POWER POWER_3
DVSS1 10 15 METAL6 GROUND GROUP_GROUND_1
DVSS2 15 15 METAL6 GROUND GROUP_GROUND_1
DVSS3 10 5 METAL6 GROUND GROUND_2
DVSS4 5 5 METAL6 GROUND GROUND_3
To generate a CPM with user-configured grouping, use ‘perform powermodel -wirebond’.
If the ‘-plocname’ option is used, the CPM port names reflect the 6th column group names
from the PLOC file.
Modeling leakage resistance using arbitrary partitioning
You can use the '-rleak_par' option to capture leakage resistance in CPM between
POWER/GROUND ports defined in arbitrary partitions. Arbitrary partitions are created by
adding a 6th column to the PLOC file and then using the '-wirebond' option of the 'perform
powermodel' command. Pads with the same “package node” (the entry in the 6th column
of the PLOC file) are grouped together, forming a so-called “CPM port”. Unlike geometric
grouping using '-nx # -ny #'' partitioning, an additional file partition.txt is needed to define
which VCC and VSS ports belong to the same partition. The format of the partition.txt file
is '<package node> < group name>'.
The following is an example partition definition in a partition.txt file:
bump_vcc1 part1
bump_vcc2 part2
ref1 part1
ref2 part2
In this example, the partition named 'part1' has'bump_vcc1' as its VCC port, and 'ref1' as
its 'VSS port'. The partition named 'part2' has 'bump_vcc2' as its VCC port, and 'ref2' as its
VSS ports. So if you specify ‘-rleak_par’, two leakage resistances are added, one
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 382
between 'bump_vcc1' and 'ref1', and the other between 'bump_vcc2' and 'ref2'. The file
partition.txt should be placed in the run directory.
The CPM command is:
perform powermodel
-rleak_par -wirebond
Example PLOC file
#source name #loc_x #loc_y #layer name #POWER/GROUND #Group name
DVDD41 35 3426 METAL6 POWER GROUP41_POWER
DVSS41 35 3548 METAL6 GROUND GROUP41_GROUND
DVDD42 35 3730 METAL6 POWER GROUP42_POWER
DVSS42 35 3790 METAL6 GROUND GROUP42_GROUND
DVDD43 35 3976 METAL6 POWER GROUP43_POWER
DVSS43 35 4028 METAL6 GROUND GROUP43_GROUND
DVDD44 35 4212 METAL6 POWER GROUP44_POWER
DVSS44 35 1270 METAL6 GROUND GROUP44_GROUND
The leakage resistance in the output CPM model appears as follows:
R0_A320 GROUP44_GROUND GROUP44_POWER 99660.431993
R0_D821 GROUP43_POWER GROUP43_GROUND 64882.488351
R0_N863 GROUP42_POWER GROUP42_GROUND 87442.938928
iCPM- Internal Node Probing
iCPM enables access to sensitive P/G connections in the design, and allows you to probe
device locations inside the chip. This capability can evaluate the drop through the on-die
PDN in a fast system-level simulation. You can not only see the impact of changes at the
boundary between the die and the package (at the pads or C4 bumps), but also deep
inside the chip at critical locations, such as near the PLL or the FGU blocks.
CPMs created iCPM technology have terminals at user-defined device locations, in
addition to the traditional C4 bump and/or pad locations. The iCPM model is created in an
incremental step after simulation:
perform powermodel -nx 1 -ny 1 -probe -o cpm_probe.sp
In the GSR, add the keyword 'PROBE_NODE_FILE <file_path>'. The file format is:
<X_location> <Y_location> <Metal_layer_name> <Port_name>
For example:
68.81
67.25
47.76
40.10
METAL1
METAL1
port_vdd
port_vss
Or you can use the options ‘-internal_node’ and ‘-cell_file <instance_list_file> to specify
particular instances that should have probe access.
Resonance frequency-aware mode
In the Resonance Frequency Aware mode, the RedHawk VectorLess™ engine generates
a multiple-cycle switching scenario for the current signature that introduces most of the
energy around the chip-package-system resonance frequency. You only need to specify
the system resonance frequency when creating the model, and CPM analysis
automatically creates the frequency-based form of on-die excitation, while maintaining the
logic and timing properties of the circuit, as shown in the Figure 14-8.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
Figure 14-8
RedHawk User Manual
| 383
Frequency-aware CPM mode
To use this option, first generate a regular CPM model and use its passive part to perform
AC analysis for the circuit that includes the CPM and package (and PCB if desired). This
AC analysis yields the resonance frequency. Then a second CPM generation run is
performed with the GSR setting: DYNAMIC_FREQUENCY_AWARE <frequency in Hz>
For example, for a resonance frequency of f= 40 MHz:
DYNAMIC_FREQUENCY_AWARE 40e6
Power Transient Mode (variable power)
Power Transient Analysis, also known as Variable Power, provides greater flexibility to
simulate frame-by-frame power/current transient behavior, such as for Gated Clock
operations, and more accurately models power transients on the chip.
While the resonance-aware mode generates current transients that match a particular
resonance frequency, variable power mode has more flexibility to include a range of
frequencies. By capturing the power stepup, the impact of various chip transitions--such
as from reset to running mode, from traffic to no-traffic mode, or from memory-on to
memory-off mode--can be modeled, as shown in Figure 14-9. These power transients
affect the entire VRM, board, package, and die system to varying degrees, based on the
duration and amplitude of the power step. The variable power CPM also can be used to
create a low-frequency spectrum, as opposed to a traditional high-frequency spectrum, to
allow testing of the package and PCB in the low-to-middle frequency range.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
Figure 14-9
RedHawk User Manual
| 384
CPM Power Transient mode
CPM gets the Power Transient Analysis from the RedHawk dynamic run. The following
GSR keyword are used to specify its operation:
POWER_TRANSIENT_ANALYSIS {
<duration_frame_1_sec> <config_file_1>
<duration_frame_2_sec> <config_file_2>
<duration_frame_3_sec> <config_file_3>
...
}
Power transient configuration file
The CPM configuration file supports the following GSR keywords:
• GSC_FILE
• INSTANCE_POWER_FILE
• GSC_OVERRIDE_IPF
• BLOCK_POWER_FOR_SCALING (and BLOCK_POWER_FOR_SCALING_FILE)
• STATE_PROPAGATION {
PROPAGATION_MODE
GATED_ON_PERCENTAGE
CONSTRAINT_FILE
GATED_CONTROL_FILE
}
• TOGGLE_RATE_RATIO_COMB_FF
• INSTANCE_TOGGLE_RATE (and INSTANCE_TOGGLE_RATE_FILE)
• BLOCK_TOGGLE_RATE (and BLOCK_TOGGLE_RATE_FILE)
• TOGGLE_RATE
Settings in the configuration file versus the GSR file
The configuration keyword, if defined, overrides the same keyword in the GSR. The GSR
keyword is used if the configuration file keyword is not defined, except for
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 385
• GSC_FILE
• STATE_PROPAGATION
which are ignored in the GSR if the Config file keyword is not defined.
Note that at present Power Transient Analysis works only in the Vectorless mode, and it
does not support keywords other than the list above. It does not support:
(a) VCD_FILE or BLOCK_VCD_FILE
(b) STA_FILE or BLOCK_STA_FILE
(c) BLOCK_POWER_ASSIGNMENT
(d) PAR or BLOCK_PAR
Also note that simulation uses charge from the first frame for its simulation reference, so
the dynamic simulation result may vary depending on the first frame config setting.
User-configurable mode
The user-configurable mode enables package and board designers to divide and
customize a CPM for multiple individual system simulations, each targeting a specific
operating mode or area of the chip, without having to regenerate the model for each
single operating mode. The user-configurable CPM allows package and board engineers
to mix and match contributions from different user-specified regions, or functional blocks
of the die, creating unique scenarios that reflect different operating states of the chip. For
example, an analysis of EMI from different blocks on the chip could be performed
separately with one run.
First, you must partition the chip into groups of functions by hierarchical blocks and
instances. Each group is represented by its unique current signature that can be enabled
or disabled independently of the current signatures of other groups. The current signature
sources corresponding to different groups are connected in parallel to each other, with
sources belonging to each group marked by SPICE comments to activate one or more
groups in a particular SPICE simulation, as shown in the Figure 14-10. Note that the sum
of currents of all groups is equal to the current of the original CPM model. The passive
part is also identical to that of the original CPM model.
The partitioning of the IC into multiple groups is achieved by specifying a list of blocks and
instances that belong to each group in a “group file.” The resulting CPM model can be
constructed for a vectorless or a VCD case.
Figure 14-10
Creating a user-configurable CPM
To use the user-configurable feature, the following options of the 'perform powermodel'
command are used:
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 386
-user_config : enables the user-configurable feature (note that it does nothing
specifically involving emi)
-group_file <file name>: specifies the name of the file used to define the
partitioning of the chip into groups of hierarchical blocks and instances. A full
or relative path to the file is allowed, but tilde '~' and environment variables
are not allowed. The purpose of the group file is to assign switching instances
(in the apache.scenario file) to groups. Note that instances can be grouped in
hierarchical blocks, and the separator for blocks is slash ('/'). Users can
assign a whole hierarchical block, a sub-block, or an individual instance to a
group. Any instances that do not belong to any user-defined group are
assigned to group Ng+1 (Ng = number of groups), with the name “others”.
The format of the group file is as follows:
GROUP <group name1>
INSTANCE <inst_name_1A> ...
GROUP <group name2>
INSTANCE <inst_name_2A> ...
...
;
;
The keywords are case-sensitive, as are instance names. Wildcard names are supported,
and lines starting with '#' are considered comments.
Example group file:
GROUP GS1
INSTANCE Bl_1
Bl_2/Inst1
Inst2
Bl_3/MEM*;
...
In this example, 'Bl_1' could be a hierarchical block name, 'Bl_2/Inst1' could be an
instance name (or level 2 hierarchical block name), and 'Inst 2' may be an individual
instance name. The syntax does not specify this. So group 1 contains all instances whose
full name starts with “Bl_1”, followed either by '/' or white space, and also “Bl_2/Inst1”
followed either by '/' or white space, and “Inst2” followed either by '/' or white space. If P =
number of CPM ports, the resulting CPM model has (P-1)*Ng current signature PWL
sources without the '-pincurrent' option, or P*Ng current sources with the '-pincurrent'
option. The PWL sources belonging to the same group have names starting with the
group name, such as “Icsg1_1”, “Icsg1_2”, for a group named “csg1”, and so on. This
allows third party tools to easily enable or disable sources belonging to a particular group.
User-configurable CPMs can easily be applied to power delivery analysis because the
current contribution from different portions of the chip has impact on voltage drops. For
example, the worst voltage drop can be observed and optimized by turning off the current
contribution of certain blocks in the chip. The source of noise can be identified using this
approach, where different die activity scenarios are explored, to understand the blocklevel contribution to the overall system noise. Results for a sample design are shown in
Figure 14-11 and Figure 14-12.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
Current Demand
Figure 14-11
Bump Voltage
Analysis of multiple group current/voltages
Block 1
Block 2
Rest of Chip
Peak Current
Peak-to-Peak DvD
ON
ON
ON
192A
95mV
OFF
ON
ON
139A
72mV
ON
OFF
ON
130A
66mV
ON
ON
OFF
116A
53mV
OFF
OFF
ON
76A
42mV
Figure 14-12
| 387
Example CPM analysis results
CPM LDO analysis support
CPM models can be generated for chips with LDO features using the 'perform
powermodel' command with no additional options. The number of terminals created
corresponds to the behavioral LDO models that APLDO generates. The presence of LDO
features is detected automatically. The CPM option '-plocname' is always enabled if LDOs
are present. CPM generates additional internal ports at the pins (terminals) of the LDO
models. The main CPM subcircuit (.SUBCKT adsPowerModel) has terminals only for the
CPM ports at the pads, the same as it would without the LDO models. The CPM contains
comments indicating the name of the LDO instance and the name of the SPICE subcircuit
instantiated for the LDO instance. For example:
* ****** CPM-LDO ***
* LDO cell | SPICE subcircuit name
* -------------------------------* VDD_REG_FC_ISO_580173
VDD_REG_FC_ISO
* -------------------------------* VDDCO_REG_FC_ISO_580174
VDDCO_REG_FC_ISO
* -------------------------------If LDOs are present, the top level CPM subcircuit adsPowerModel instantiates the LDO
subcircuits with one per LDO instance present. For example:
**** Instantiation of the LDO subcircuits : ***
X_VDD_REG_FC_ISO_580173 VDD_REG_FC_ISO_580173__vddhv
VDD_REG_FC_ISO_580173__vddcore0
+ VDD_REG_FC_ISO_580173__vddcore1 VDD_REG_FC_ISO_580173__vss
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 388
VDD_REG_FC_ISO
X_VDDCO_REG_FC_ISO_580174 VDDCO_REG_FC_ISO_580174__vddhvcore
VDDCO_REG_FC_ISO_580174__vddcore0
+ VDDCO_REG_FC_ISO_580174__vddcore1 VDDCO_REG_FC_ISO_580174__vss
VDDCO_REG_FC_ISO
*********************************************
To perform system-level simulation with CPM, you must create a SPICE netlist that
includes the models for package/PCB and supply sources. If LDOs are present, you must
also provide the LDO subcircuits, which can be either transistor-level SPICE models or
behavioral models. Transistor-level LDO models provide the greatest accuracy, while the
behavioral models may have better simulation speed. If transistor-level LDO models are
used, they typically have additional terminals, such as for the bias pins. They must be
“wrapped”, along with the bias voltage sources and other required circuitry, to generate
the subcircuit that is invoked by the CPM.
For best accuracy, the following two options of the 'perform powermodel' command are
recommended: -pincurrent and -global_gnd.
Notes on using the LDO methodology:
1.
No LDO subcircuits are instantiated in the binary CPM (Sentinel-PI format).
2.
The CPM header includes coordinates and layer information for the LDO subcircuit
terminals.
3.
LDO can be used with the CPM '-probe' option to create additional CPM ports at
internal nodes, but not with the '-internal_node’ or ‘-cell' options of the 'perform
powermodel' command. Example:
perform powermodel -wirebond -global_gnd -pincurrent
-o ABCD_ldo_de BZ.sp -probe
4.
The -probe option requires that the PROBE_NODE_FILE GSR keyword be used,
as shown below:
PROBE_NODE_FILE <file_path>
Format of the probe node file:
<x coordinate> < y coordinate> <layer> <probe name>
...
5.
It is possible to have a probe node exactly at the location of the LDO terminal. In
this case, the probe node becomes one CPM port and it becomes exposed.
Normally, the terminals of the LDO subcircuits are not exposed.
CPM Outputs
The outputs from CPM processing are the following:
• CPM model files
• get_cdie.sp NSpice netlist file
• *.cdie file, effective die series resistance and capacitance values for ‘1 X 1’ partition
models
• differential output voltages from S-parameter models
These outputs are described in the following paragraphs.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 389
CPM Model Files
The CPM model has several elements: the passive part of the CPM model (*.sp.inc), and
the current signatures by partition (*.sp), as shown in Figure 14-13. The output of
RedHawk CPM simulation is a hierarchical SPICE netlist that includes the switching
current signature, as well as the reduced-order model of the die power delivery network.
The complexity of the SPICE netlist is determined by the number of partitions over which
the CPM model is created.
Three types of models are generated simultaneously during the run, and written to the
adsRpt/CPM directory:
• standard SPICE (default)
• CPM optimized for HSPICE (adsRpt/CPM/<design_name>_hspice.sp). For designs
with a large number of ports (100+), the use of HSPICE-specific elements (Foster
VCCS) is important, to provide a way to eliminate internal nodes, improve simulation
speed and reduce memory consumption.
• Sentinel-PI CPM (adsRpt/CPM/<design_name>_snpi.sp), which is the same as the
HSPICE format, but in binary form.
.
Figure 14-13
CPM model elements
get_cdie.sp File
The NSPICE netlist is exported to the file get_cdie.sp, which can be used to calculate
Rdie/Cdie at the specified frequency (50 MHz by default, unless you modify it in the
get_cdie.sp file), and to plot Cdie(f) and Rdie(f) for frequencies ranging from 1 MHz to 1
GHz. This file eliminates user errors, which are likely for a CPM model with a large
number of ports, and also saves time that would be required to create the netlist by hand.
For designs with multiple power/ground nets RedHawk generates a separate
get_cdie*.sp file for each pair of nets. If there are only two nets, the file name is still
get_cdie.sp. Otherwise file names of the form get_cdie_<pwr_net>_<gnd_net>.sp are
written to the working directory.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 390
*.cdie File
If you run CPM simulation with the 1 x 1 partition option using ‘-nx 1 -ny 1’ (even for a
wirebond design), or the -cdie option, a *.Cdie file is generated in the <workdir>/
adsRpt/CPM/apache.Cdie directory. The *.Cdie file contains the effective capacitance, as
well as the effective series resistance, of the die PDN at various frequency points. This is
useful as a quick ballpark assessment of die parasitics.
The following is an example of a *.Cdie file:
Cdie and Rdie between nets VDD and
4.700000e+08 Hz, Cdie=2.662143e-11
6.250000e+08 Hz, Cdie=2.635451e-11
9.350000e+08 Hz, Cdie=2.571951e-11
1.250000e+09 Hz, Cdie=2.501593e-11
1.875000e+09 Hz, Cdie=2.362147e-11
2.500000e+09 Hz, Cdie=2.229990e-11
VSS
F, Rdie=2.902836e+00
F, Rdie=2.874828e+00
F, Rdie=2.811440e+00
F, Rdie=2.746562e+00
F, Rdie=2.634761e+00
F, Rdie=2.548309e+00
Ohm
Ohm
Ohm
Ohm
Ohm
Ohm
Note that the *.Cdie file reports results only at the frequencies at which actual calculation
of the Y matrix has been performed, and no approximations are involved in calculating the
Rdie and Cdie (an exact calculation that does not rely on the equivalent circuit).
For AC analysis, you should connect to the parasitics part only (.inc file), and not connect
the CPM port to global ground (Spice node 0). For current signature, by default, CPM
uses the Norton current model. It picks one of the ground ports as the negative terminal
for every PWL current source. The sum of all port currents will be zero. If you generate a
CPM with the option’ -pincurrent’ it does not use the Norton current model. Every PWL is
referenced to node 0. Note that some tools do not support non-Norton current models.
The CPM is described in hierarchical subcircuit-based SPICE netlists. The main CPM
Spice deck includes piecewise linear switching current signatures, which are connected to
the parasitic model of the die power delivery network, which is in turn described in a
second SPICE netlist file (.inc file). A two-port equivalent model is shown in Figure 14-14.
C u rre n t s ig n a tu re
V D D (p o r t 2 )
T o p o lo g y o f G ij
i
G 11
G 1P2 a ra s itic
n e tw o rk
…
G 22
j
V S S (p o rt 1 )
Figure 14-14
Two-port CPM equivalent circuit
The following is a simple CPM generated for a die (one Vdd and one Vss net) using a 1x
1 partition. The Chip Package Protocol section lists the name of the die pad, x and y
location of the pad, the corresponding SPICE node name, as well as the partition and net
information of the pad.
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
CPM Simulation Procedures
RedHawk User Manual
| 391
********************************************
* Apache RedHawk Chip Power Model [ Ver 1.00 ]
* @Apache Design Solutions 2002 - 2006
* Presimulation time 3500.000000ps
********************************************
.INCLUDE “PowerModel.sp.inc”
*
*
*
*
*
*
*
*
Begin Chip Package Protocol --->
die_area 0 0 293.04 313.17
Vdd_130564_1645 : (65.000000 0.000000) : p1 = PAR_0_0_VDD
Vdd_326658_1645 : (163.000000 0.000000) : p1 = PAR_0_0_VDD
Vdd_526412_2605 : (263.000000 0.000000) : p1 = PAR_0_0_VDD
Vdd_527135_6258365 : (264.000000 313.000000) : p1 = PAR_0_0_VDD
Vdd_327130_6258415 : (164.000000 313.000000) : p1 = PAR_0_0_VDD
Vdd_126096_6259955 : (63.000000 313.000000) : p1 = PAR_0_0_VDD
..... * End Chip Package Protocol <--.subckt adsPowerModel
+ p1 p2
Xpdn
+ p1 p2
+ PowerModel
Icursig1 p1 p2 pwl(
+ 0.000000ps 0.000178
+ 10.000000ps 0.000657
+ 20.000000ps 0.005198
+ 30.000000ps 0.007278
....
Note that the PowerModel.sp file reports the presimulation time in the header. This is
useful for CPM-to-RedHawk correlation, as you must shift the RedHawk waveform by the
presimulation time.
The PowerModel.sp.inc file, generated with AC analysis CPM, has the following header
(note “Accurate RC reduction”):
**********************************************************
* Apache RedHawk Chip Power Model [Accurate RC reduction]
* Model Subcircuit of Die PDN
* @Apache Design Solutions 2007
**********************************************************
Using the Chip Power Model
You can attach the SPICE netlist created from CPM to the package/PCB models and
simulate those using NSPICE or any other SPICE compatible simulator.
Some of the key applications of Chip Power Model technology are:
• Determining global Power Delivery Network impedance, identifying IC-package
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
Validating the Model
RedHawk User Manual
| 392
resonance using AC analysis (use the parasitic part only).
• Performing dynamic voltage noise budgeting at board and package level
• Package and board decap optimization
Differential Voltage Waveforms
Since designers typically want to look only at differential voltages to review results, Sparameter models used for RedHawk package-aware analysis are differential in nature.
For this reason the wire voltage drop summary in redhawk.log is disabled, and differential
voltage waveform probing at the pads is enabled, using the TCL command
plot voltage -pad_pair {<vdd_pad> <vss_pad>} ?-sv? ?-o <output_file> ?
Example command:
plot voltage -pad_pair {VDD1 VSS2} -sv -o vdrop.txt
Validating the Model
One type of accuracy validation of the Chip Power Model involves the following steps:
1.
Run RedHawk without the package model to generate the CPM. The accuracy
improves if the time step is reduced. A time step of 10ps provides the best
accuracy (there is no need to use a smaller one). To change the time step, add the
following to the GSR file:
DYNAMIC_TIME_STEP 10e-12
The best accuracy is achieved if you let the presimulation time step be the same as
during simulation. However, the time step can be changed as follows (see section
"DYNAMIC_PRESIM_TIME", page C-677, for details):
DYNAMIC_PRESIM_TIME [<presim_time_ps>| -1] ?<TSM> ?
?<TSM_fraction>?
The time step during the presimulation time is TSM*TS, where TS is the time step
specified in the DYNAMIC_TIME_STEP GSR keyword. For example,
DYNAMIC_PRESIM_TIME 2e-9 1
The value of 1 sets the presimulation time step at the normal length.
2.
Attach a package model to the CPM model and run using SPICE.
3.
Measure the current and the voltage at the connection points (die pads) of the
CPM model to the package model.
4.
Attach the same package model to RedHawk and run DvD analysis (with the same
pre-simulation time as used for CPM generation). Remember to shift the RedHawk
waveform by the pre-simulation time, which is prior to t=0 in RedHawk and after it
in Spice. The presimulation time is reported in the header of the CPM output file.
5.
Measure the current profile for all the bumps and the VDD/GND waveform at any
bump.
6.
Compare the two waveforms.
Figure 14-15 shows waveforms from the measurement of current from one test-case
using the above procedure. The red current profile is from measuring the bump current in
ANSYS INC - Apache Design Business Unit
CHAPTER 14 — Chip Power Modeling (CPM)
Validating the Model
RedHawk User Manual
| 393
a RedHawk run, while the yellow current profile is from measuring the bump current from
the SPICE run with the CPM model.
Figure 14-15
Comparison of CPM model with full RedHawk chip
simulation.
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Introduction
RedHawk User Manual
| 394
Chapter 15
Reliability and EM Analysis
Introduction
Electromigration (EM) is the movement of material that results from the transfer of
momentum between electrons and metal atoms under an applied electric field. This
momentum transfer causes the metal atoms to be displaced from their original positions.
This effect increases with increasing current density in a wire, and at higher temperatures
the momentum transfer becomes more severe. Thus in sub-100nm designs, with higher
device currents, narrower wires, and increasing on-die temperatures, the reliability of
interconnects and their possible degradation from EM is a serious concern.
The transfer of metal ions over time from EM can lead to either narrowing or hillocks
(bumps) in the wires. Narrowing of the wire can result in degradation of performance, or in
extreme cases can result in the complete opening of the conduction path. Widening and
bumps in the wire can result in shorts to neighboring wires, especially if they are routed at
the minimum pitch in the newer technologies.
Foundries typically specify the maximum amount of current that can flow through a wire
under varying conditions. These EM limits depend on several design parameters, such as
wire topology, width, and metal density. EM degradation and EM limits depend on the
temperature at which interconnects operate, as well as on the material properties of the
wires and vias, on the direction of current flow in the wire, and on the distance of the wire
segment from the driver(s). EM current characteristics are defined in Figure 15-1.
Figure 15-1
EM current definitions
Key EM current characteristics are defined as follows, where tp = tperiod:
tD
R = ----tp
I peak = max I  t 
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Temperature Setting for Power EM Calculation
RedHawk User Manual
I  t  dt
I avg =
- for P/G and Signal current with an APL-simulated waveform.
 ------------t
p
I avg =
 I  t dt
I rms
=
| 395
 t p for Signal current with an estimated waveform.
 I  t  2 dt  tp
One common EM check employed is to measure the average or DC current density
flowing through a wire and compare it against foundry-specified limits. The impact of
average or DC current in wires in a design is typically quantified using Black's equation,
which is used to measure and compare the Mean-Time-To-Failure for interconnects with
different parameters, such as the average current density, temperature, and activation
energy. Another common check employed is to measure the peak and RMS current
flowing through interconnects and check them against foundry-specified targets. These
checks are to ensure that metal failures do not occur because of Joule or self-heating in
the wires.
RedHawk™ provides a single platform approach in which to analyze EM of both power
grid and signal interconnects in a design. Power EM analysis is performed as an integral
part of static and/or dynamic analysis. Signal EM analysis, which is performed in a
separate run, checks for average (uni-directional or bi-directional), RMS, and peak current
densities in all signal wires and vias in a design.
Temperature Setting for Power EM Calculation
Operating temperature for Static and Dynamic EM calculation can be set independently of
the temperature value used for analysis, if desired, using the required tech file keyword
TNOM_EM and the required GSR keywords TEMPERATURES_EM and
TEMPERATURE_EM. The associated power analysis temperature keywords are TNOM
in the tech file and TEMPERATURES and TEMPERATURE in the GSR. These
temperature keywords affecting EM calculation are described below.
In the Tech file, specify the nominal and final temperatures with the syntax:
metal <metal_layer_name> {
EM <max_wire_current_density>
TNOM_EM <EM_nom_temp>
? T_EM <EM_final_temp> ?
TNOM <Power_nom_temp>
? T <Power_oper_temp>?
..
In the GSR, use the following keywords for EM calculation:
TEMPERATURES_EM {
<layer_1> <temp_1 ºC>
...
<layer_n> <temp_n ºC>
}
, or
TEMPERATURE_EM <temp ºC>
The associated extraction GSR keywords for temperature are:
TEMPERATURES {
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
RedHawk Methodology for Static Power EM Analysis
RedHawk User Manual
| 396
<layer_1> <temp_1 ºC>
...
<layer_n> <temp_n ºC>
}
or
TEMPERATURE <temp ºC>
Then for EM calculation, the priorities for temperature-setting keywords are:
1.
TEMPERATURES_EM - layer-based, in GSR
2.
TEMPERATURE_EM - global, in GSR
3.
T_EM - layer-based, in the tech file
4.
TEMPERATURES - layer-based, in GSR, for extraction
5.
TEMPERATURE - global, in GSR, for extraction
6.
T - in the tech file, for extraction
7.
TNOM_EM - global, in tech file
RedHawk records the temperatures used in extraction and in EM checking in the
redhawk.log file.
RedHawk Methodology for Static Power EM Analysis
RedHawk™ automatically performs power EM analysis based on currents obtained as
part of static or dynamic voltage drop analysis. The primary difference is that static EM
analysis is based on true average current values, which is covered in this section,
whereas dynamic power EM analysis is based on either peak, true average or RMS
current values (see section "Methodology for Dynamic Power EM Analysis", page 15399).
There is no separate command required for performing static EM analysis. It is performed
by default if you have EM limits specified in the technology file. In electro-migration
analysis, RedHawk checks the actual current density for METAL wires, or current per cut
or area for a VIA segments, against the EM limit specified in the technology file. The setup
for static power EM analysis involves defining the desired EM limits in the tech file, which
can be done in several different ways, as described in the following section.
Setting Up EM Limits
The simplest EM limit is specified per layer, which defines the allowed current density
value for a specific METAL or VIA layer. For a metal layer, the current density limit is
defined as the current flowing per unit width. It can be specified in the tech file, as in the
following example:
metal METAL1
{
Thickness
1.45
Resistance 0.2343
EM
2.7
above
PASS4
}
In the above example the current density limit for layer METAL1 is defined as 2.7. The unit
for current density comes from the units for length and current in the 'Units' section of the
technology file, as in the following example:
units {
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
RedHawk Methodology for Static Power EM Analysis
capacitance
resistance
length
current
voltage
time
frequency
RedHawk User Manual
| 397
1p
1
1u
1m
1
1n
1me
}
For VIA layers, the EM limit is defined by layer on a per-cut basis: the allowed current per
cut of the via or via array, as in the following example:
via VIA78
{
Area
{ 9 }
Resistance 0.041
T
25
Tnom
110
Coeff_RT1
0.00337
Coeff_RT2
-7.91e-7
EM
7
UpperLayer METAL8
LowerLayer METAL7
}
There are more advanced methods for specifying the EM limits in the tech file, using the
following options of the ‘metal’ tech file keyword:
EM_Adjust
Width_Based_EM
Blech_JLC
EM_Temp_Rating
Tnom_EM
For a description of how to use these options to define metal and via EM limits, see the
section "METAL", page C-524, of section "Apache Technology File (*.tech)", page C-521.
If you are creating the tech file using the Apache utility 'rhtech', you can use the option '-e
<EM_FILE>' to populate the tech file with two of the EM-related keywords, or to read a
user-specified polynomial-based EM rule file, use the option '-pe <file>', instead of '-e' for
simple EM rules. Only the EM and EM_ADJUST options can be used inside this rule file;
you should include the other EM-related keywords manually in the tech file. The following
is the syntax for using the 'rhtech' utility:
rhtech -i <input_file> [-o <output_file>]
[-m <layer_mapping_file>]
[-e <EM_file>] [-t <temp_file>]
Following is an example of an EM rule file for passing EM tech file keywords:
## <layer_in_itf/nxtgrd> <EM_limit-mA/um for metal; mA for vias> <EM adjust>
metal5 0.9308 0.02
metal4 0.9308 0.02
metal3 0.9308 0.02
metal2 0.9308 0.02
metal1 0.716 0.02
via4 0.06766
via3 0.06766
via2 0.06766
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
RedHawk Methodology for Static Power EM Analysis
RedHawk User Manual
| 398
via1 0.0676
Running Power EM Analysis
For procedures for setting up and running power EM analysis, see section "Running
RedHawk-S (Static IR/EM Analysis)", page 4-57. RedHawk by default does not perform
EM analysis as a part of static and dynamic simulation. However, you can set the GSR
keyword 'ENABLE_AUTO_EM 1' to perform the EM check during regular post simulation
processing. Then the TCL command ‘perform emcheck’ can be used to perform
power EM analysis for specific modes and nets, using the command:
perform emcheck ?-mode [AVG |RMS |PEAK |all ]?
?-net <netname>?
The default mode is ‘all’.
Analyzing Static EM Analysis Results
Once the simulation is performed you can click on the EM button in the View Results
panel to see the EM violations map, such as shown in Figure 15-2, which displays the EM
violations in different ranges in different colors. RedHawk highlights all metal or via
segments with current density or current per cut exceeding the specified EM limit (default)
in red, and lesser fractions of the limit in other colors.
You can change the EM ranges and their color display using the ElectroMigration Color
Map dialog, available by clicking on the ‘Set Color Range’ button in ‘Configuration’ panel
in the GUI.
Figure 15-2
EM results display
After static analysis, EM violations are also listed in the report adsRpt/Static/
<design_name>.em.worst, which lists the details of all METAL or VIA segments with
average current density or current exceeding the default EM limit of 100%, in decreasing
order. You can change the default limit using the GSR keyword,
EM_REPORT_PERCENTAGE. By default, RedHawk dumps only the top 1000 violations.
You can increase this number using the GSR keyword EM_REPORT_LINE_NUMBER. If
you want to dump EM violations in a specific range, you can use the GSR keyword
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Dynamic Power EM Analysis
RedHawk User Manual
| 399
EM_DUMP_PERCENTAGE. For example, if you specify “EM_DUMP_PERCENTAGE 50
60" in the GSR, it dumps all violations having an EM ratio between 50% and 60% in the
file adsRpt/Static/<design_name>.em. This file is not in sorted order and is not
generated unless you specify the above keyword in GSR.
In the EM report file RedHawk reports all METAL EM violations using the following format.
#Layer #End-to-end_coordinates
#EM_Ratio #Net #Width
METAL4 (4905.670,3398.849 4905.670,3400.562) 469.016% VDD 25.000
This report is also available using the GUI menu command Results -> List of Worst EM.
In this GUI display list you can zoom in to any violation using the Go To Location button.
Then click on the geometry to see more details on the violation in the log window. This
information can be used for calculating the EM ratio of this segment. Actual current
density is calculated by dividing the current by the effective wire width. If you specify the
EM_ADJUST parameter in the tech file, RedHawk subtracts this value from the actual
width to get the effective width.
Methodology for Dynamic Power EM Analysis
Dynamic power EM analysis is similar to static EM analysis. In static analysis, the EM
analysis is based on true average current density for wires and current per cut (or area)
for vias. In dynamic analysis, RedHawk can perform EM wire/via analysis based on three
different types of currents: peak, RMS or average. The GSR keyword EM_MODE is used
to select the mode for the current analysis. By default, RedHawk does not perform an EM
analysis on the specified EM_MODE (Avg, RMS or Peak). You can set the GSR keyword
ENABLE_AUTO_EM to 1 to enable EM checking as part of simulation. You can then use
the TCL command 'perform emcheck' to perform EM analysis for specific modes and
nets.
Setting Up EM Limits
You can set up simple EM limits by specifying EM limit values for each layer in the tech
file. If these are the only EM limits specified, they are used for all EM_MODEs. You can
set up separate EM rules for each EM_MODE, in three different ways:
1.
POLYNOMIAL_BASED_EM rules have a format that specifies the target
EM_MODE as part of the keyword. If you specify a
POLYNOMIAL_BASED_EM_PEAK rule in your base tech file, that rule will only be
applied to a Peak EM analysis. POLYNOMIAL_BASED_EM_AVG and
POLYNOMIAL_BASED_EM_RMS keywords are also accepted.
2.
Separate EM rule tech files. Another way to specify separate EM rules for each
mode is to supply those rules in separate EM rule tech files. These files are
identified in the GSR file:
EM_TECH_DC <DC_em_rule_file>
EM_TECH_RMS <RMS_em_rule_file>
EM_TECH_PEAK <Peak_em_rule_file>
The basic structure and syntax for these files are similar to the base tech file. They
accept a section for each 'metal' and 'via' layer, followed by EM rule specifications.
The rules read in from the EM_TECH_DC file are applied to DC (average) EM
analysis. Note that DC rules are also used for any Static EM analyses.
3.
Rule sets. A more flexible and general way to specify EM rules is to group them
together in named rule sets using the tech file keyword EM_RULE_SET. Rule sets
allow you to read in any number of different sets of EM rules, and then selectively
use them for different analyses during a RedHawk session. The format of an
EM_RULE_SET file is similar to the EM rule files above. The first line has the
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Dynamic Power EM Analysis
RedHawk User Manual
| 400
EM_RULE_SET keyword followed by the user-assigned name for the set. This is
followed by 'metal' and 'via' sections containing EM rules, as in the example
following:
EM_RULE_SET <user_rule_name1>
metal <layer name> {
<metal EM rules>
...
}
...
via <layer name> {
<via EM rules>
...
}
...
EM_RULE_SET <user_rule_name2>
...
To load the EM rule sets into RedHawk, identify the file using the GSR keyword
‘EM_TECH_FILE <ruleset_file>’. Once loaded into RedHawk, you can specify which
EM_RULE_SET to use for each analysis with the following GSR command:
EM_RULE_SET [AVG|PEAK|RMS] <user_rule_name>
You also can change the EM rule set being used for an analysis with the TCL command:
gsr set EM_RULE_SET [AVG|PEAK|RMS] <new_user_rule_name>
and then rerun the ‘perform emcheck’ command with the new EM_RULE_SET.
Analyzing Dynamic Power EM Violations
After running dynamic analysis you can generate additional power EM reports based on
different modes and specific net names using the TCL command ‘perform emcheck’,
whose syntax is:
perform emcheck ?-mode [AVG |RMS |PEAK |all ]?
?-net <netname>?
Skip the -mode and -net options to perform analysis for all modes and all nets in the
design.
Dynamic EM analysis generates reports of the worst EM violations for each mode with the
same filenames (<design>.em.worst.peak, *.avg, and *.rms) as in static analysis,
located in the adsRpt/Dynamic directory. The report format is also the same. This is
useful with several EM file limits as described in the previous section. In this case
RedHawk automatically generates a detailed report for all the modes for which EM
analysis has been performed. An example report generated after performing EM analysis
for PEAK mode is shown below:
EM MODE is PEAK
# This file reports the EM violations, i.e. EM_Ratio =
Actual_Current_Density/Current_Density_Limit > 100% (default or from
“em_report_percentage”) for wire pieces and vias in decreasing order. Unit
used for coordinates and dimensions is um.
# For wires: #layer #end-to-end_coordinates #EM_Ratio #net #width
# Blech_length
# For vias: #via_name #x-y_coordinates #EM_Ratio #net #blech_length
METAL3 (886.190,1018.712 887.192,1018.712)
1081.01% VDD 2.003 141.951
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Dynamic Power EM Analysis
METAL3
METAL3
METAL3
METAL3
METAL3
...
(885.190,1020.695 886.190,1020.695)
(2944.210,2479.555 2944.210,2480.055)
(2942.980,2479.305 2942.980,2479.555)
(1108.770,2479.555 1108.770,2480.055)
(1107.540,2479.305 1107.540,2479.555)
RedHawk User Manual
1081.01%
1024.24%
1024.24%
1023.81%
1023.81%
VDD
VDD
VDD
VDD
VDD
2.000
2.000
0.500
2.000
0.500
| 401
141.951
10.500
10.500
10.500
10.500
In the violation display in Figure 15-3, EM_ADJUST for METAL4 is defined as 0.016. So
RedHawk calculates the actual current density as follows:
Actual I density = (Current/Eff_Width) = 219.664 /(25-0.016) = 8.7922 mA/u
And the EM limit for METAL4 in the tech file is defined as 1.874 mA/u.
RedHawk calculates the EM_Ratio using the following equation.
EM_Ratio = 100 * (Actual density of current) / (EM limit in tech file).
Therefore
EM_Ratio = 100 * 8.7922 / 1.874 = 469.2
Figure 15-3
Investigating a potential metal EM violation
For VIAs, RedHawk reports the EM violations in the following format:
#Via_name
#x-y_coordinates
#EM_Ratio #net
via via3Array_87 (3154.820,893.390)
172.29%
GND
The EM_ratio of a VIA layer is calculated as follows (percentage):
EM_Ratio = (Current through the VIA)*100 /(EM limit)
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Dynamic Power EM Analysis
RedHawk User Manual
| 402
When you click on a via in the GUI, the RedHawk log window displays additional
information that helps you in analyzing the violation, as shown in Figure 15-4.
Figure 15-4
Investigating a potential via EM violation
In the example above, RedHawk reports both EM percentage and the EM limit value used
in the calculation. The EM limit displayed is the limit calculated for the specific VIA array.
As described earlier, inside the tech file Via EM limits are defined on a per-cut basis.
RedHawk calculates the EM limit for every via array in the design, considering the number
of via cuts in the via array and total area of the cuts included. For example, if the via array
has 10 cuts, the EM limit reported is (Tech file EM limit * 10).
Note that, depending up the type of EM rule selected, additional data relating to checks
associated with that rule are also displayed.
Current direction and EM violations
To accurately analyze EM violations in a design, you need to understand the actual
current directions. After EM analysis, when you click on any METAL or VIA geometry in
RedHawk, the assumed current direction is indicated by a symbol in the log display
window, along with the current value, as shown in Figure 15-5:
Figure 15-5
Log display showing current direction
The symbol conventions followed for displaying the current direction are:
> : For metals, current flow from left to right.
< : For metals, current flow from right to left.
^ : For metals, current flow from bottom to top.
V : For metals, current flow from top to bottom
Up : For vias, current flow from lower metal layer to upper metal layer
Down : For vias, current flow from upper metal layer to lower metal layer.
Using the correct current direction, you can identify the actual path for the current flow.
You can also look at the Current map (CUR button in View Results GUI panel) to see any
discrepancy in the current flow.
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Signal EM Analysis
RedHawk User Manual
| 403
Fixing Power EM Violations
EM violations are mostly caused by weak power grid connections feeding current to high
power-consuming regions or blocks in the design. If this is the case, increasing the metal
width to reduce the current density is a typical solution. Similarly, for a via EM violation,
you can increase the number of vias to fix potential EM issues. You also can provide
additional straps for the current supply, thereby reducing the current-per-strap value.
Layer switching is another option; typically, upper metal layers in the technology have
higher current driving capability (due to greater thickness). So you can use these layers
for designing the major power grids (grids with higher current flow) in the design.
You can use the what-if and Fix and Optimize capabilities (see Chapter 7, "Fixing and
Optimizing Grid and Power Performance") in RedHawk to modify the grid for fixing EM
violations. Using this method you can edit any existing strap or add any new straps or
vias. RedHawk has incremental extraction capability, which helps you in analyzing the
design quickly after making any modification.
The following example helps in understanding how you can resolve EM issues quickly
using the “What-if” capability in RedHawk. An example EM violation is caused by an
insufficient number of vias between the power straps. More vias are added in this area
using the 'Add Via' option in RedHawk to fix the problem, as shown in Figure 15-6 below:
Figure 15-6
Using FAO to repair EM violations
Methodology for Signal EM Analysis
Signal EM analysis should estimate the Iavg, Irms, and Ipeak for every signal wire in the
design, especially those belonging to the clock tree network, and compare them against
their respective EM limits. The signal EM flow in RedHawk estimates these different
current values based on cell design parameters. RedHawk analyzes EM for all signal
wires in a design -- both inside cells (intra-cell) and between cells (inter-cell).
The average current flowing in every wire (Iavg) is estimated from the capacitive load seen
at the output of each cell, its operating frequency, its supply voltage and toggle rate (which
is defined as 2.0 or 200% for clock pins).
Iavg = f (capacitive load, frequency, toggle rate, supply voltage)
Since the current flowing in a signal net is usually bi-directional, the true average current
is usually very small. Therefore in RedHawk a rectified average current is calculated.
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Signal EM Analysis
RedHawk User Manual
| 404
Estimation of RMS current requires an understanding of the current profile that is seen
during the charging or discharging process in any output net. The RMS current is defined
as follows, where the current is integrated from 0 to Tclk, the clock period:
2
Irms =
 i  t dt
----------------Tclk
RedHawk by default approximates the switching current profile at the output of a cell
using a polynomial-based profile whose shape and size depend on the average current of
the net and the transition times (for rising or falling edges). Once the current profile is
constructed, Irms can be calculated using the above equation. You also have the choice
of creating a different polynomial- based waveform for estimation of Irms. Using that
profile, RedHawk determines the peak current (Ipeak).
The currents (Iavg, Irms, and Ipeak) are estimated for every signal wire segment in the
design. The current values are typically highest closest to the driver cell and decrease
gradually as distance from the drivers increases. RedHawk reads in the signal net routing
and geometry information, along with signal net parasitic data, to determine the current
values in each net, from its driver(s) to its receiver(s).
Once the current values are determined for each of these modes, the current density is
estimated at each wire segment and via and compared to the relevant EM limits. The EM
limits can be specified in the technology file as dependent on physical parameters such
as the width of the wire, size of the via, and temperature of the die.
Input Data Requirements
An inter-cell EM analysis (wires outside of cells) requires the same data preparation as a
regular RedHawk static analysis. Some of the key data requirements for an inter-cell EM
analysis include:
• Routed design netlist in the DEF format
• Signal parasitic information in the SPEF/DSPF format
• Timing information (frequency, slew, clock nets)
• VCD or instance-specific toggle information [optional]
• Technology file with specified EM limits
Setup for Signal EM Analysis
The command files and setup needed for signal EM analysis are similar to those needed
for static analysis. RedHawk estimates three different measures of current for every net in
a single run. You can display different EM modes in the GUI by changing setting in
‘ElectroMigration Color Map’ dialog box, which is accessed using the ‘Set Color Range’
button in the GUI.
Waveform Specifications
The current profile used to estimate the RMS and peak current can be either a triangular
or a polynomial waveform. You can select the mode using the GSR keyword (polynomial
is the default):
EM_WAVEFORM_TYPE [polynomial | triangle ]
Besides waveform types, you can set the slew type with a GSR keyword to estimate the
RMS and peak current, as follows (default is Min):
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Signal EM Analysis
RedHawk User Manual
| 405
EM_USE_SLEW [ Max | Min | Average]
When set to 'Max', RedHawk uses the maximum available slew value (transition time) for
the net. If set to 'Min’, the minimum available slew value is used. If 'Average' is specified,
an average of the minimum and maximum slew values are used (in ns units). Using the
'Min' option is recommended.
The current profiles that are constructed depend on the output slew and load at every net,
among other parameters. RedHawk gets slew information for signal and clock nets from
the STA data provided and RC loading data. For cells missing the STA and RC data, you
can control the profile construction using the following keywords (which also have default
values to cover cells with missing slew data).
EM_SLEW_SIG_PERCENTAGE
p1 (default 0.25)
EM_SLEW_SIG_TIME
t1 (default 0.8 ns)
EM_SLEW_CLK_PERCENTAGE
p2 (default 0.1)
EM_SLEW_CLK_TIME
t2 (default 0.3 ns)
For signal nets, slew is calculated as
min(p1*clock_period, t1)
For clock nets, slew is calculated as
min(p2*clock_period, t2)
For signal nets missing load information in the SPEF/DSPF data, RedHawk estimates the
missing slew information based on routing data. The GSR keyword TOGGLE_RATE
should be set in order to assign a default toggle rate to signal and clock nets.
TOGGLE_RATE <signal toggle rate> <clock toggle rate>
Wire Merging
RedHawk tries to merge all signal wires that overlap, unless there are 45-degree wires in
the design, when wire merging is disabled. Also overlapping nets are automatically
dropped in analysis if there are any wires that it cannot merge. These nets are reported in
the file adsRpt/SignalEM/topcell.droppedSignalNets. Note that you can force wire
merging by setting the GSR keyword 'MERGE_WIRE 1' for designs with 45-degree wires.
EM Limits
For signal EM analysis on high technology designs, the peak current EM spec includes a
duty ratio value for each net. To include the duty ratio data in RedHawk signal EM
analysis, set the following GSR keyword to 1:
EM_USE_DUTY_RATIO 1 (default 0)
In the RedHawk technology file, in addition to the parameters needed for a regular
analysis, the following additional EM limits can be set in the GSR:
EM_TECH_RMS <tech_file_nameA>
EM_TECH_DC <tech_file_nameB>
EM_TECH_PEAK <tech_file_nameC>
The format of these tech files is the same as a standard RedHawk tech file, except that
only EM-related data are included. Three formats are acceptable, as follows:
metal <metal_layer> {
EM <limit_value>
}
or
metal <matal_layer> {
WIDTH_BASED_EM {
width { <width1> <width2> ... <widthN>}
em { <limit_width1> <limit_width2> ... <limit_widthN+1>}
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Signal EM Analysis
RedHawk User Manual
| 406
}
or
via <via_name> {
EM <limit_value>
}
The list of EM limit values for WIDTH_BASED_EM correspond to the list of widths, with an
additional EM value for any wire widths bigger than the largest width in the list.
These special tech files should only contain EM limits. All other tech file information,
such as resistivity, thickness, and EM_adjust, should be specified in the regular RedHawk
tech file, since they are the same across all EM modes (signal and power EM). If the
additional tech files for EM limits are not provided, the EM limits in the regular tech file will
be used.
If the special tech files for an EM mode contains no via-related information, via EM will not
be checked for that EM mode. For example, the signal EM specification has no Peak or
RMS EM limit for vias.
If there are nets with no driver port or physical connection the nets are dropped from the
analysis and RedHawk errors out. A file adsRpt/SignalEM/
<top_cell>.droppedSignalNets is generated to report the dropped nets.
Custom Current File
You can create a custom current file to specify current at signal net driving points using
the GSR keyword ‘EM_CUSTOM_CURRENT_FILE <filename>’. The format of the
custom current file is as follows:
<net_name> INST <inst_name> <pin_name> <avg> <rms> <peak>
...
<net_name> CELL <cell_name> <pin_name> <avg> <rms> <peak>
...
where
net_name: specifies the net name
INST <inst_name>: specifies the instance name
pin_name: specifies the pin name
<avg> <rms> <peak>: specifies the current value for each type of current, in
Amps. Current types that are not to be set should be given values of '-1'.
Example custom current file:
net1 INST ANA1 VREGO -1 -1 1e-3
net2 INST ANA1 SIGPIN -1 -1 2e-3
The example sets PEAK current to '1e-3' for net1 and '2e-3' for net2 at driving points
VREGO and SIGPIN, respectively. Other current values are unspecified.
Using the custom current file you can also limit EM analysis to those nets that are
specified. In above example, only nets 'net1' and 'net2' would be reported if you set the
GSR keyword EM_CCF_ONLY to 1.
Hierarchical analysis
Signal EM analysis can be performed at the full-chip level, but verify only the interface
nets and the top level nets. Interface nets are those that connect standard cells in a DEF
to the primary I/Os in the DEF. Running in hierarchical mode reduces the overall run time
and memory requirements by ignoring all internal nets and analyzing only the top level
nets and the nets that connect from sub-block to sub-block. The GSR keyword to enable
hierarchical analysis is:
SEM_HIERARCHICAL_MODE [ 0 | top_only | internal_only ]
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Signal EM Analysis
RedHawk User Manual
| 407
Running Signal EM Analysis
The EM analysis flow uses a unified engine for both Power and Signal EM, so advanced
EM rules are supported, with the following features:
• RMS and Peak current calculation consider RC load
• adding extra pin capacitance in the SEM_NET_INFO file is possible
• peak current calculation is adjusted based on saturation current
• ability to specify default slew, toggle-rate, and pin-cap parameters for all nets with
missing information
• improved wire merging
• waveform estimation-based Signal EM analysis
• an APL-based flow is supported if the APL files are specified in the GSR file
• the Signal EM flow calculates I(rms) and I(Peak) of the primary output nets using the
Ceff values of the primary output nets. To enable this, you must provide Ceff values
for the nets in the EM_NET_INFO file, which has the following format:
#<net_name> <trans_time_sec> <toggle_rate> <freq> <uni-dir_scale>
<bi-dir_scale> <extra-cap> #<driver_cell> <pin> ?<Ceff>?
The signal EM flow includes command steps as described below, so that you have access
to the results of each step individually:
# set the analysis mode to signal EM
setup analysis_mode signalEM
# import the GSR file
import gsr <gsr_file_name>
# set up the design
setup design
# Perform power calc step to find toggle rates of instances
perform pwrcalc
# extract signal nets using the SPEF file
perform extraction -signal
# perform signal EM analysis
perform analysis -signalEM
# create EM analysis report for each set of rules
perform emcheck <options>
Note:
1.
The ‘setup analysis_mode’ step must be first for signal EM, as opposed to the
power EM analysis procedure, when it is run after ‘setup design’.
2.
If user wants to perform only-clock extraction or only-signal extraction then the
following option can be used in extraction step in SignalEM analysis.
perform extraction -signal -exclude_clock -> for signal-only
extraction
perform extraction -clock
-> for clock-only extraction
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Signal EM Analysis
RedHawk User Manual
| 408
Using the RedHawk GUI in Signal EM
In the GUI, there are several useful ways to analyze EM-related results:
• Current information can be obtained by clicking on any metal wire:
Bidirectional current:
RMS 9.061e-02 A
Peak 1.812e-01 A
Avg 4.530e-02 A
• To check current EM_MODE, use the command:
gsr get EM_MODE
• To change the EM_MODE, use the command:
gsr set EM_MODE [ rms | avg | peak ]
or use the appropriate GUI button in the EM Color Map dialog.
• To view nets, select from the menu View->Nets
• To highlight instances related to a net, use the command :
select add [get instbynet <netname>]
• Also, the command
select add [get instbynet -driver <netname>] -color red
can be used to highlight a driver in a different color, such as red.
Defining Equipotential Regions
You can define equipotential regions by creating a single resistor to represent the metal
segment in that region, if the analysis is creating too many nodes and dividing the voltage
and current among them. This technique is useful for special shapes, such as octagonal
pads. In order to do this, the equipotential regions must be defined in the pad file, using
the format described below. Equipotential support is available for P/G nets as well as
signal nets for signal EM analysis, and can be defined on any layer. The PLOC file format
for defining the regions is as follows:
<area_name> <x1> <y1> <x2> <y2> <layer> <net_name>
For example:
Equi_pot_area1 203.840 341.000 323.840 461.055 ZA TEST_NET
Analyzing Results
You generate signal EM reports based on netname, mode, or temperature using the TCL
command described below, after EM checks have been performed for all nets in the
design. The invocation syntax is:
perform emcheck ?-mode [AVG |RMS |PEAK |all ]?
?-net <netname>?
The default mode is ‘all’.
After RedHawk completes signal EM analysis, the following text reports and maps are
available
• adsRpt/apache.sigem.info file
Check signal nets that have no loading capacitance, timing, or driver instance
information.
• adsRpt/redhawk.err file
ANSYS INC - Apache Design Business Unit
CHAPTER 15 — Reliability and EM Analysis
Methodology for Signal EM Analysis
RedHawk User Manual
| 409
Reports all signal EM flow setup and analysis errors.
• adsRpt/SignalEM/<design_name>.rms_em.worst file
Reports the highest 1000 Jrms (RMS current density) violations.
To report more than 1000 violations, use the GSR keyword:
EM_REPORT_LINE_NUMBER [ Max_line]
Also, EM_REPORT_PERCENTAGE (default 100) can be used to specify the
threshold for reporting violations, the same as Power EM. Sometimes you must use a
lower EM_REPORT_PERCENTAGE to get any entries in the *em.worst output files.
• adsRpt/SignalEM/<design_name>.avg_em.worst
Reports highest 1000 Javg (average current density) violations.
• adsRpt/SignalEM/<design_name>.peak_em.worst
Reports highest 1000 Jpeak (peak current density) violations.
• adsRpt/SignalEM/<design_name>_sem_toggle_summary
Reports toggle rates by net type.
Report format:
Net_Type
Data
Clock
Count
<count>
<count>
Avg_Toggle_Rate
<TR>
<TR>
• adsRpt/SignalEM/<design_name>_sem_layer_wise_violation_summary
Reports layer-based EM violations.
Report format:
# Layer AVG_EM_VIOLATIONS RMS_EM_VIOLATIONS PEAK_EM_VIOLATIONS
Metal1 <violation_count> <violation_count> <violation_count>
Debugging Tips
• When encountering unexpected EM results, first check the adsRpt/apache.err file for
error messages.
• Check the adsRpt/SignalEM/<design>.em.warn file.
• Use the ‘IGNORE_NETS { <netname> ... }’ GSR keyword to eliminate from
consideration nets that are not of interest and reduce output data.
• Use the GSR keyword:
ANALYZE_NETS {
<net_name_1>
<net_name_2>
...
}
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Introduction - The ESD Problem
RedHawk User Manual
| 410
Chapter 16
Pathfinder™ ESD Analysis
Introduction - The ESD Problem
Electrostatic Discharge (ESD) is a common reliability problem in chip design that involves
very high discharge currents that can fatally damage sensitive circuit elements, or
adversely affect their operation. As many as 35% of total IC field failures are reported as
ESD-induced. ESD represents a serious problem for the electronics industry, which must
insure proper operation of chips during all phases of manufacture, test, packaging, and
installation into products. Serious semiconductor problems caused by ESD are: oxide
punch-through, junction burnout, and metalization burnout. ESD phenomena are typically
classified into three discharge/test models:
• Human Body Model (HBM), an ESD discharging event occurring when a charged
human body contacts an electronic device directly
• Machine Model (MM), an ESD pulsing event when charged machinery discharges
when touching an IC during testing
• Charged-device Model (CDM), a self-induced discharging ESD event when ungrounded electronic parts are charged up during assembly and then discharge
through a grounded pin.
These three ESD modes and their discharge waveforms are shown in Figure 16-1.
The traditional approach to ESD design and verification consists of several steps:
1.
design at circuit level and verify on test chips
2.
integrate ESD test cells into I/O cells of the SoC
3.
review results by ESD experts before tape-out.
These empirical approaches are error-prone and involve high costs when the chip fails
due to ESD problems.
A further complication is that ESD is a time-domain transient behavior, and has a very
short duration. Some ESD failures can only be captured in time-domain circuit-level
transient simulation. Unfortunately, there is no circuit-level simulator that can do dynamic
ESD simulation at this time. Pure Spice-level simulation fails in properly handling negative
resistance from the snap-back behavior of clamp devices under ESD stress. The tools
that designers can use now are Spice analysis plus a device simulator. Capacity and long
run-times are significant limitations of such solutions, so they can only be applied to a very
small portion of a design.
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
Figure 16-1
RedHawk User Manual
| 411
Three common ESD event models and discharge waveforms
Chip design has benefited from EDA solutions in many areas, but an EDA solution for
ESD analysis has been a missing piece of the complete EDA design and analysis flow.
Furthermore, ESD problems are now occurring more often due to advanced processes,
larger design sizes, and mixed-signal and low power design methodologies.
Dealing with the difficulty of ESD transient simulation and long run times involved for
covering all the discharging paths, a set of static techniques have been developed,
primarily checking the resistance of the potential discharge paths, assuming ESD
protection clamps are turned on. The RC time constant that controls the turn-on order of
the clamps is constrained by the threshold resistance value, so the assumed actual
resistance for the discharge path from a bump to another bump, or from a core instance to
a clamp, can be calculated reasonably. If the resistance of a discharge path is much
larger than the threshold resistance value, it often indicates a potential problem that will
show up during the ESD testing, since there is no obvious discharge path for a bump in
HBM/MM condition, or for a large custom macro in CDM condition.
ESD Analysis
Overview
PathFinder™-S provides a comprehensive set of technologies for performing ESD
verification and analysis for both analog and SoC designs. The PathFinder tool uses static
techniques (rule-based checks), while Pathfinder-D uses dynamic transient simulation
techniques for ESD analysis. Differences in PathFinder and PathFinder-D analyses are
shown in Figure 16-2. For Netlist-based rule checks and dynamic-based simulation
capability, please refer to the PathFinder Application Note “ESD Analysis and Verification
in Totem for Analog and Mixed-signal Designs.”
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
PathFinder
Rule-Based
PathFinder-D
Simulation-based
Figure 16-2
RedHawk User Manual
Analog IP Pre-layout
and Post-layout
User-defined Rules
Checks connectivity
and layout rules
Full Chip Cell-based
Resistance Rules
Checks effectiveness
of ESD protection
IP-Level Post-Layout
Transient Simulation
HBM, CDM, MM
Sign-Off
| 412
ESD analysis and coverage verification of PathFinder
PathFinder can be used for design planning (such as clamp cell placement, number of
clamp cells, and design of clamp cells) or for sign-off (such as meeting discharge
guidelines, and passing device-level threshold criteria). It can be used both on pre-layout
circuits and also on post-layout designs. The checks provided by PathFinder are
applicable for all three primary modes of electrostatic discharge events:
• Human Body Model (HBM)
• Machine Model (MM)
• Charged Device Model (CDM)
The capabilities provided in PathFinder can be classified into two broad categories:
• Verification of the placement of clamp circuits with respect to each other, the pads, and
other cells in the design.
• Verification of the design of individual clamp circuits (at the schematic or layout level).
One set of checks evaluates the connectivity and topology of all elements of the circuit. In
addition, resistance-based checks calculate accurate resistance values between the pads
and the clamps, the clamps to the clamps, or from the clamps to other cells in the design.
This capability is described in this chapter.
Clamp Cell Definition
Clamp Files
For all types of ESD analysis, you must specify I-V curves for the relevant diodes/clamps.
A clamp cell can be defined either in its own clamp cell file or in a combined clamp cell/
rule file. In a manually-generated clamp file, you can also specify the clamp I-V curve as
in the following example:
BEGIN_CLAMP_CELL
NAME <cell name>
TYPE <user_type_name>
? PIN [<pin_name> | NA] [<x_loc> <y_loc>]
[ BOTTOM | TOP |<layername>] <locID> ?
? XTOR <xtorName>:<net> <x_loc> <y_loc> <layer> <locID> ?
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
RedHawk User Manual
| 413
...
? RON <clamp_On_Resistance_Ohms> ?
? ESD_PIN_PAIR <loc_ID1> <loc_ID2> [
[ <RON> | [ <RON+>|OFF] [<RON->|OFF] |
<I-V_clamp_name> ]?
? IMAX <I1> [<I2>] ?
? VMAX <V1> [<V2>] ?
END_CLAMP_CELL
BEGIN_CLAMP_IV
NAME <I-V_clamp_name>
RON <RON+> [<RON->]
VT1 <VT1+> [<VT1->]
VH <VH+> [<VH->]
ROFF <ROFF+> [<ROFF->]
ION2
0.9
RON2
0.1
IT2
3.0
RT2
1.0
VT2
0.5
IMAX <I1> [<I2>]
VMAX <V1> [<V2>]
TLP_FILE <tlp_filename>
TLP_I_RESOLUTION <value>
END_CLAMP_IV
For the CLAMP_CELL file, the keywords are:
NAME: specifies the name string to identify this cell or I-V device.
TYPE : user-specified name for the clamp cell type
PIN : specifies clamp cell pins by either <pin name>, by <x_loc> <y_loc>, by
BOTTOM /TOP layer or <layername>, or by <locID>.
Note that only “-” should be used as a placeholder for clamp pin names, and
not “NA”; “NA” is treated the same as any other pin name in the cell. If “-” is
specified, PF-S gets the pin location from wires/vias of the closest top level
domain net for the BOTTOM/TOP layer or <layername> specified. If
BOTTOM or TOP is chosen, the specified <x/y> location is snapped to the
closest bottom or top layer of the <pin_name> net defined in LEF. If only a
legal pin name is specified and no other information, by default a node with
near minimum resistance to the pads is chosen. If no clamp cell pins are
specified, one pin per domain is identified automatically that has near the
minimum resistance to a pad. If only a subset of all clamp cell pins is
specified, only the pins specified are used for ESD check. If a legal pin name
is given, then this is also the default <locID> used in the ESD_PIN_PAIR
clamp file keyword (defined below).
XTOR: defines ESD clamp device connections on transistors for MMX blocks.
Options are defined the same as for PIN, except that ‘:<net>’ is the name of
the net that the transistor pin is connected to.
RON : resistance value when the clamp device is On; default: 0.0001 Ohms,
RON+ is the resistance for current flowing from the positive to negative
terminal; RON- is the resistance for current flowing in the opposite direction.
OFF: specifies the zapping direction is “off”; that is, RedHawk treats the clamp
device as an open circuit with that zapping polarity. Note that it is considered
a syntax error if both directions of a pin pair is specified “off”.
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
RedHawk User Manual
| 414
ESD_PIN_PAIR : defines a legal ESD discharge path for B2B rules, and
resistance values for both current discharge directions. <RON+> defines the
On resistance for discharges from <loc_ID1> to <loc_ID2>, and <RON> defines the On resistance for discharges from <loc_ID2> to
<loc_ID1>). <RON> defines symmetric resistance between the node pair; if
defined, it overrides the RON definition above, or otherwise a default value of
0.0001Ohms is used.
IMAX: for a clamp cell rule, specifies the current thresholds for the positive and
negative breakdown checks for the associated ESD_PIN_PAIR. When only
one value is specified, the threshold is the same in both directions.
For a clamp I-V device rule, specifies the current thresholds for that device.
For an ESD_PIN_PAIR, the limits specified in the clamp I-V rule have the
highest precedence, followed by those in the clamp cell rule, then in the ESD
rule.
VMAX : for a clamp cell rule, specifies the voltage thresholds for the positive and
negative breakdown checks for the associated ESD_PIN_PAIR. When only
one value is specified, the threshold is the same in both directions. For a
clamp I-V device rule, specifies the voltage thresholds for that device. For an
ESD_PIN_PAIR, the limits specified in the clamp I-V rule have the highest
precedence, followed by those in the clamp cell rule, then in the ESD rule.
For the CLAMP_IV file, the keywords are described below and identified in Figure 16-3.
ROFF: resistance value when the clamp device is Off; default: 1e6 Ohms.
ROFF+ is the off resistance for current flowing from the positive to negative
terminal;
ROFF- is the off resistance for current flowing in the opposite direction.
VT1: threshold voltage that turns On the clamping device; default: 0. That is, the
clamp is modeled as a linear resistor with RON.
VH: holding voltage when the clamping device is On; default for VH: VH = VT1;
the supported range for VH is 0 <= VH <= VT1.
ION2: current threshold for On resistance to change from RON to RON2.
RON2 : resistance in the upper conducting region
IT2: current threshold for I-V curve to enter breakdown region.
RT2: resistance in the breakdown region.
VT@: threshold voltage at the beginning of the breakdown region.
TLP_FILE : specifies a file with Transmission Line Pulse (TLP) curve data in ESD
clamp I-V definitions for both resistance and CD checks. Sample TLP file:
0,0
1.075228,-5.57006E-06
2.181616,3.30643E-05
3.273627,7.19229E-06
4.283446,7.90741E-05
5.371665,7.80592E-05
where ',' can also be a space or tab. And '#' at the beginning of a line for comments is
allowed.
TLP_I_RESOLUTION: Based on the TLP data PF-S engine automatically decides
a value for 'TLP_I_RESOLUTION' by default and user does not have to set it.
The typical range is from 0 to 0.001.
Most clamp I-V parameters have two versions, '+' for the positive-to-negative current
direction, and the '-' for the reverse direction.
The executable script 'pfscrypt' can be used to encrypt IV_clamp curve in CLAMP_FILE
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
Usage:
Pfscrypt <clampfile>
RedHawk User Manual
[options]
options:
-h print this help message
-d turn on decryption mode
-p <Password> set the password for encrypt/decrypt
-o <OutputFile> set the output file name; Default: <FileName>.enc
Sample output:
When read encrypted clamp_file, Clamp_IV is show below
adsRpt/ESD/ClampInfo.rpt
# CLAMP IV DATA:
BEGIN_CLAMP_IV
NAME diode_iv # Encrypted
END_CLAMP_IV
BEGIN_CLAMP_IV
NAME pwr_iv
# Encrypted
END_CLAMP_IV
Figure 16-3
Diode/clamp device I-V characteristics
Sample clamp cell file:
BEGIN_CLAMP_CELL
NAME IO_cell
PIN PAD 7.29 362.14 METAL1 pad_1
PIN VSS 7.39 362.04 METAL2 vss_1
PIN VDD 7.29 363.66 METAL1 vdd_1
ANSYS INC - Apache Design Business Unit
| 415
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
RedHawk User Manual
| 416
PIN VDD 7.29 369.4 METAL2 vdd_2
PIN VSS 7.0 334.5 METAL3 vss_2
RON 0.01
ESD_PIN_PAIR pad_1 vss_1 0.001 0.05
ESD_PIN_PAIR vdd_1 vss_1 0.02 OFF
ESD_PIN_PAIR vdd_2 vss_2 OFF 0.0001
END_CLAMP_CELL
Sample transistor clamp cell settings are shown following:
BEGIN_CLAMP_CELL
NAME IO
# INST : mos1__2 PIN : VDD
XTOR mos1__2:VDD 2.24 328.14 BOTTOM
# INST : mos1__2 PIN : VSS
XTOR mos1__2:VSS 2.34 328.14 BOTTOM
# INST : mos4__1 PIN : VDDO
XTOR mos4__1:VDDO 1.81 309.23 BOTTOM
# INST : mos4__1 PIN : VSS
XTOR mos4__1:VSS 1.91 309.23 BOTTOM
# INST : mos4__2 PIN : VDDO
XTOR mos4__2:VDDO 1.81 317.31 BOTTOM
# INST : mos4__2 PIN : VSS
XTOR mos4__2:VSS 1.91 317.31 BOTTOM
ESD_PIN_PAIR mos1__2:VDD mos1__2:VSS diode
ESD_PIN_PAIR mos4__1:VDDO mos4__1:VSS sback
ESD_PIN_PAIR mos4__2:VDDO mos4__2:VSS b2b_diode
END_CLAMP_CELL
BEGIN_CLAMP_IV
NAME diode
RON 0.1 100K
VT1 0.4
ROFF 100K
END_CLAMP_IV
BEGIN_CLAMP_IV
NAME b2b_diode
RON 0.2
VT1 0.2
END_CLAMP_IV
BEGIN_CLAMP_IV
NAME sback
RON 0.3 0.2
VT1 1.2 1.5
VH 0.1 0.15
END_CLAMP_IV
In this example, VT1, VH, and RON are specified according to the parameters defined in
Figure 16-3. By default, VH = VT1, <RON-> = <RON+>, <VT1-> = <VT1+>, and <VH-> =
<VH+>. If none of <RON->, <ROFF->, <VT1->, <VH-> are specified, they assume the
default values defined above.
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
RedHawk User Manual
| 417
For more information on clamp device connection and modeling, see GSR keyword
section "ESD_CLAMP_PIN_FILE", page C-701, and TCL command section "pfs", page
D-771.
You can perform B2B checks before doing DC analysis. Loop resistance used for DC
analysis does not need to be the same as that used for the B2B check. The clamps in
“pass loops” in the B2B check are used for DC analysis. When there are no “pass loops”,
all clamps are off, and DC analysis cannot be performed. If the B2B check has not been
performed, RedHawk performs iterative convergence to decide which clamps are on and
off in the final solution.
Clamp DB Creation
To make clamp definition and reuse more efficient, PathFinder creates a binary DB for
clamp devices (such as cells, instances, nodes, esd pin pairs, I-V data ) to be used by the
general ESD checking command 'perform esdcheck' (for syntax details, see section
"perform esdcheck", page 16-425) for both clamp rules and also for bump rules. With
general clamps definition in the DB, specific clamp parameters can be added or removed
from particular rules files. The basic controls to invoke checking relative to clamps are
described in this section. Using the clamp-related options, the syntax is:
perform esdcheck
-clamp <clamp_file> ? -setupClamp ? ? -shortNode [ 0 | 1 |
2 ] ?
where
-clamp <clamp_filename> : specifies the clamp filename. Clamp statements can
be combined in the rule file or separately defined in a clamp file. See the
clamp file section for a description of the clamp file syntax and an example
clamp file. If a clamp file is specified using the GSR keyword
ESD_CLAMP_FILE, this option is not required.
-setupClamp : imports and saves the clamp info into the DB. You can check
Errors/Warnings in the clamp file before running ESD checks. Saves
significant run-time without having to import a clamp file using “-clamp <file>”
each time ESD checks are run. You can save or load the clamp data by
including the following keywords in the rule file:
SAVE_CLAMP_DB 1
LOAD_CLAMP_DB 1
Both keywords are default off. Note that
• Only one of SAVE or LOAD can take effect. When both are specified, LOAD is used.
• When you specify an ESD rule without LOAD_CLAMP_DB 1, and if you do not specify
clamp info either in rule file or with -clamp <file>, RedHawk loads the existing clamp
DB.
• If neither option -setupClamp or the rule 'SAVE_CLAMP_DB 1' are specified, if the
clamp DB does not exist, the clamp info is saved into the DB.
-shortNode: Specifies the node shorting options. The available options are:
0 (off): Do not short ESD clamp pin nodes during extraction.
1 (all): Short all ESD clamp pin nodes during extraction.
2 (loc): Short ESD clamp pin nodes when x/y/layer are specified in
ESD_CLAMP_FILE during extraction.
SPT tracing from clamp nodes
You can perform SPT (minimum resistance path) tracing from clamp nodes using the
‘perform min_res_path' command. To do this, the clamp DB should be ready. That is, the
‘perform esdcheck -clamp <clampFile> -setupClamp’ command must be executed before
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
ESD Analysis
RedHawk User Manual
| 418
doing SPT. After the clamp DB is set, the following two methods can be used to trace SPT
paths from clamp nodes:
1.
Add the “-fromClamp” option to the “perform min_res_path –instance < >”
command, or
2.
Execute the ‘perform min_res_path -set fromclamp [on | 1 ]’ command to turn the
feature on. After it is turned on, the specified SPT paths are automatically traced
from clamp nodes until it is turned off. This feature is designed for SPT tracing from
the GUI.
Example:
perform min_res_path -instance inst_13ab/inst_50cd
-fromClamp
ESD Rules Files
The parameters for ESD checks must be specified using a rules file that defines key
elements of each desired check, such as TYPE (BUMP2BUMP, BUMP2CLAMP,
CLAMP2CLAMP, PIN2CLAMP, PIN2PIN), a user-assigned rule NAME, limits on ARC_R,
LOOP_R, and PARALLEL_R, the number of stages, and also the clamp types, bumps
and nets that are to be specifically included or excluded in that check.
Defining Groups of Nets
ESD rules files can specify user-defined net groups to simplify including or excluding
certain groups of nets in ESD testing. The rule syntax for defining a net group is as
follows:
BEGIN_NET_GROUP
NAME <userDefinedGroupName>
NET <netName1>
NET <netName2>
...
END_NET_GROUP
The creation of various types of specific rules files are described in the following sections.
Reducing Design Size for Improved ESD Analysis
To speed up performance on large designs, PathFinder can generate a special GSR file
that selectively removes ESD-irrelevant cells/layers to reduce design size, while keeping
acceptable accuracy. The methodology is as follows:
1.
In the original GSR file, add the following GSR keywords:
ESD_CLAMP_FILE <clampFile>
ESD_RULE_FILE <ruleFile>
where <clampFile> and <ruleFile> are the clamp and rule files to be used for the
“perform esdcheck” command.
2.
Add the “ESD_GSR 1" rule keyword in the appropriate rule file.
3.
Run RedHawk through the setup design stage. A new esdGsr.gsr file with modified
GSR keywords is generated:
a. Unnecessary standard-cell LEF cells are removed from analysis with the
IGNORE_CELLS keyword, when no C2I/C2M/B2I rules are involved.
b. SPLIT_VIA_ARRAY or SPLIT_SPARSE_VIA_ARRAY keywords are
removed, if no current density rules are involved.
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Topology and Connectivity Checking of Bumps and Clamps
RedHawk User Manual
| 419
c. Lower metal layers from the block/top level DEF files are ignored using the
DEF_IGNORE_SPECIFIC_LAYERS keyword.
4.
Replace the original GSR file with the esdGsr.gsr file and rerun RedHawk.
The performance and capacity improvement of running with the new esdGsr.gsr could be
up to 50%, depending on the design.
Topology and Connectivity Checking of Bumps and Clamps
PathFinder evaluates and reports on clamp instances that are not connected to P/G and
signal nets, and bumps isolated from clamps. You can obtain a text report using the
command 'perform clampcheck' as follows:
perform clampcheck ?-o <file>? ?-instConn?
? -isolatedBump? ?-cell <cell_name>? ?-celltype <type>?
? -inst <inst_name>? ? -volt <voltage>? ?-net <net_name>?
? -netConn <net1> <net2> ...? ? -allNetConn ?
? -bumpConn <bump_name> ? ? -allBumpConn ? ? -loop?
? -loopLength <stage_num>? ? -b2bLoopLength <stage_num>?
? -roff <R_thresh> ? ? -rptDisConn ?
? -rule <rule_file> ? ? -esdStage <stage_num>?
? -detail? ?-append?
where
-o <file>: specifies the output filename
-instConn: reports clamp instances that have missing connections to the P/G grid.
-isolatedBump: reports bumps that do not connect to any clamp
-cell <cell_name>: reports information on specified clamp cell(s)
-celltype <type>: reports information on clamp cells of a particular clamp type
-inst <inst_name>: reports information on specified clamp instance(s).
-volt <voltage>: reports a list of clamps connected to a particular node voltage.
-net <net_name>: reports information on all clamp nodes connected to specified
net(s), both directions.
-netConn: checks connectivity of each net pair (both directions), so for “-netConn
{netX netY}”, the connectivity of both netX->netY and netY->netX is checked.
If “-netConn netX” is specified, the connectivity from netX to all other nets and
from all other nets to netX is checked. For each net pair reported, a symbol “>” or “<->” is added between the two nets to indicate the connectivity
direction between them.
-allNetConn: reports clamp connectivity to all nets and domains, in both directions
-bumpConn: reports clamp connectivity to all bump connectivity from the specified
bump
-allBumpConn: reports clamp connectivity of all bumps
-loop: lists the clamp instances of all B2B loops for queried net pairs.
-loopLength: -b2bLoopLength : set the EXACT stage number(s) to be reported for
queried net pairs. Note that “-esdStage” sets the RANGE of stage numbers,
while “-loopLength” sets the EXACT stage numbers. -loopLength can specify
more than 2 numbers.
-roff: sets the resistance threshold value at which clamp devices are considered
“OFF”. The default threshold value is 1e6 Ohms.
-rptDisConn: reports net-pairs with no clamps between
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Layout Resistance Checking of Bumps and Clamps
RedHawk User Manual
| 420
-rule: specifies the name of the rule file for checking. Multiple rule files can be
represented in two formats: {rule1 rule2 ...}, or rule1,rule2, ... (no spaces in
this form).
-esdStage: specifies the number of clamp stages for net/domain pair checks
-detail: reports detailed information on net/domain pair.
-append: appends results to existing results in the output file
An example invocation would be:
report clampcheck -rptDisConn -allNetConn
which reports all net-pairs between which no clamps are found.
A sample ‘Unconnected Clamp Instances’ report is shown following for the command:
perform clampcheck -o instConn.txt -instConn
######## List of Unconnected Clamp Instances ########
#
# <CELL NAME>:
#
<PIN_NAME> <X> <Y> <LAYER> <LOCID> <INSTANCE_NAME>
inst_ndiode_0:
VDDO 1.07374e+06 1.07374e+06 metal1 VDDO inst_ndiode_0/adsU4
A sample ‘Bumps Isolated from Clamps’ report is shown following for the command:
perform clampcheck -o isolated_bumps.txt -isolatedBump
######## List of Bumps Isolated from Clamps ########
#
# <BUMP_NAME> <BUMP_X> <BUMP_Y> <NET_NAME> <BUMP_LAYER>
1_pad 4569.13 10992.5 net1 metal8
Layout Resistance Checking of Bumps and Clamps
Overview
PathFinder can perform the following five types of ESD-related resistance checks:
• Bump-to-Bump (BUMP2BUMP, or B2B), including multi-stage checks
• Bump-to-Clamp (BUMP2CLAMP, or B2C)
• Bump-to-Instance (BUMP2INSTANCE, or B2I)
• Clamp-to-Clamp (CLAMP2CLAMP, or C2C)
• Clamp-to-Inst (CLAMP2INST, or C2I)
• Clamp-to-Macro (CLAMP2MACRO)
Note that ESD checking is automatically turned off in low power analysis mode.
Bump-to-Bump (BUMP2BUMP, or B2B)
For bump-to-bump resistance checking, you must specify the list of bumps/pads (or bump
locations) that form pairs. Each bump pair must be connected by one or more clamp cells.
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Layout Resistance Checking of Bumps and Clamps
RedHawk User Manual
| 421
The first step in this calculation is the estimation of the loop resistance, which is the
resistance for each bump->clamp->bump path. Loop resistance is defined as the actual
Vdd/Vss resistance from a bump to another bump. For bump pairs that have multiple
clamp cells connecting them, an equivalent number of paths for loop resistances is
calculated.
Once the loop resistances are calculated, they are compared against the loop resistance
threshold that has been defined. The loops (bump->clamp->bump paths) having an
effective resistance greater than the specified threshold are considered as failing the loop
resistance check. The clamps that are in these failing loops are deemed “invalid” and are
discarded from the subsequent bump-to-bump parallel resistance calculation, in which the
effective resistance from one bump to another is calculated, considering all the valid
clamp cells connecting these two bumps. The invalid bumps (from the loop resistance
checks) are considered to not provide a discharge path between a pair of bumps.
This rule also calculates and performs ESD resistance checks on multi-stage ESD BUMP
to BUMP pairs. PF-S calculates the resistance from each bump to ESD clamp instances,
forms multi-stage bump to bump paths, and performs ESD resistance checks on these
multi-stage bump2bump paths.
Bump-to-Clamp (BUMP2CLAMP, or B2C)
Next, the effective resistance from a pad to a clamp cell is calculated and reported. You
can provide the pad location, or the tool can determine it automatically. Similarly, for the
clamp cell, the location to which the resistance is calculated can be specified
(recommended), or it can be determined by the tool. If the tool determines it automatically,
it attempts to identify the location with the highest effective resistance. This pad-to-clamp
resistance is compared against the threshold specified using the command line option ‘arc_R’.
For B2C resistance checking, to apply different resistance thresholds from the pad to the
anode of the HBM diode, and from the pad to the cathode of the HBM diode, use the
following keywords to select the clamp pins to be tested in separate B2C runs:
• To apply the rule only to the anode of the HBM diode:
CLAMP_POS_PIN 1
• To apply the rule only to the cathode of the HBM diode:
CLAMP_NEG_PIN 1
Bump-to-Instance (B2I)
B2I rules support Bump-to-Instance resistance checks. Using this feature you can check
if the resistance to an instance from the bump is greater than the resistance to the clamp.
Clamp-to-Clamp (CLAMP2CLAMP, or C2C)
Finally the effective resistance between any two clamp cells connected to each other is
reported, and compared against the threshold specified in the ‘-arc_R’ command line
option.
Clamp-to-Inst (CLAMP2INST or C2I)
The effective resistance from a core instance to a clamp cell is calculated and reported to
identify potential CDM failures. You must provide a list of the instances. Then locations
with minimum effective resistances are chosen for standard cells and locations with
maximum effective resistances are selected for macro cells (such as memories, IPs, etc.)
automatically. The rationale for these choices is that macro cells are much larger in size
compared to standard cells and therefore the worst location with maximum effective
resistance should be considered to catch potential C2I failures. The same location
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Layout Resistance Checking of Bumps and Clamps
RedHawk User Manual
| 422
selection method can be applied to clamp cells. Both Loop_R and Arc_R are reported
with pass/fail criteria with respect to Arc_R and Loop_R constraints specified in the rule.
Clamp-to-Macro (CLAMP2MACRO or C2M)
The effective resistance from a macro instance to a clamp cell is calculated and reported
to identify potential CDM failures. You must provide a list of the instances. Then all node
locations on the bottom/top/<layer> of the LEF pin geometries with minimum effective
resistances with respect to one of the clamp cells are chosen (such as memories, IPs,
etc.) automatically. The difference from C2I selection is that many more node locations
are considered for checking potential CDM failures (therefore achieving better location
coverage) . The same location selection method can be applied to the clamp cells. Only
arc_R is reported with pass/fail criteria with respect to arc_R constraints specified in the
rule.
Cross-domain DRIVER2RECEIVER (D2R)-to-Bump
Checks bump resistance for driver-receiver circuits that cross voltage domains. Rules for
these tests are used to check the difference/ratio of the resistance from P/G pins of crossdomain driver-receiver instance pairs to all bumps in design that are connected directly or
through clamps.
Including Package Resistance
RedHawk PathFnder ESD analysis can include the effects of package subcircuits. The
package can have a significant impact on some ESD results, since it modifies the resistive
paths between many nodes in the chip. For ESD resistivity analysis, inductances in the
package subcircuit are short-circuited, and mutual inductances and capacitances are
open-circuited. Clamps are identified, a radius formed, valid bumps are identified, and
then resistances are calculated and compared. The same ESD checks are performed as
in chip analysis, except that the package resistance from the bumps to their package BGA
sources (for both the VDD and VSS) is included. So the check starts from the BGA side of
the package, through the package, through the VDD bumps, through the P/G network to
the clamp, and then returns to VSS bumps and through the package to the BGA pins.
Several types of rules are added to the 'perform esdcheck' command for computing
resistances beginning or ending at the package pins. The setup of these rules is similar to
the corresponding BUMP-related checks. The package-related rules are:
• PIN2CLAMP (or P2C) - external package pins to clamp nodes, similar to B2C
• PIN2PIN (or P2P) - external package pins to external package pins, similar to B2B,
including multi-stage cases.
Package subcircuits can be included in RedHawk analysis by the same mechanism as is
used for static and dynamic simulation. The most common method is to specify the
package subcircuits using the GSR keyword PACKAGE_SPICE_SUBCKT. Once a
package subcircuit is included, ESD checks can be performed with or without the package
subcircuits. The package subcircuit is required and is automatically included for the P2C,
P2P and P2PM checks, in which all resistive paths start or end at the package pins. For
other resistive ESD rule types, the default behavior is to exclude the effects of the
package.
Data Flow
The Layout Resistance Checker of PathFinder can be run inside both RedHawk and
Totem tools. When running inside RedHawk, it helps verify the placement of clamp cells in
SoCs and other digital circuits. It typically works with a LEF/DEF-based input, although
GDS is also supported. When running inside Totem, it helps perform similar checks,
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Layout Resistance Checking of Bumps and Clamps
RedHawk User Manual
| 423
particularly for analog, custom, and mixed signal circuits. In this case, it works with GDSbased inputs, with additional data coming from the Spice netlist. The data flow is shown in
Figure 16-4.
Design DEF or GDS
with P/G network data
Pad/Clamp locations
Technology LEF file
Apache Technology file
RedHawk/Totem
+ PathFinder
Resistance Report
Figure 16-4
PathFinder Data Flow
Description of Inputs
The inputs for the Layout Resistance Checker are as follows:
• Technology LEF file - contains the layer and via descriptions for a particular library or
process node in the LEF format available from the library team.
• Apache Technology file - specifies key technology parameters, such as resistance and
dielectric constant, for RedHawk to use for extraction.
• Pad location (ploc) file - specifies the locations of voltage sources in the regular PLOC
file format, as used in RedHawk. An example of a PLOC file with single VDD and VSS
source points and is as follows:
# pad location points
<unique name> <x-loc>
<y-loc>
<metal>
<power/ground>
vdd1
6808
11091 metal7
POWER
vss1
7038
11612 metal7
GROUND
• ESD static check includes geometry-based resistance checks for HBM/MM/CDM
modes, and current density checking for HBM/MM.
• In the command file, include ‘setup analysis_mode ESD’ for ESD-specific control and
GUI display.
• Rule definitions - see following sections
• Clamp cell definitions - a clamp cell can be defined either in its own clamp cell file or in
a combined clamp cell/rule file, as described in section "Clamp Cell Definition", page
16-412.
• Job control - PathFinder supports multi-threading and multi-processing capabilities.
For multi-threading, use the '-thread' option; and for multi-processing, use the
'-jobCount' option. To perform esdcheck with the -jobCount option, it is advisable to set
up the clamp DB using ‘perform esdcheck -clamp <clampfile> -setupClamp’, and then
execute 'perform esdcheck -rule <ruleFile> -jobCount <N>'. You can do multiANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Layout Resistance Checking of Bumps and Clamps
RedHawk User Manual
| 424
processing by starting a session from scratch, or by importing a previously-exported
DB. In that case, make sure the DB is exported from a session with ‘setup
analysis_mode esd’ as the first TCL command executed.
If the machine has multiple CPU's, PathFinder splits the job and executes them. One
job is performed by the parent PathFinder session, and the rest of the jobs are
executed in different sessions in adsESD1, adsESD2, … as the working directory.
The job count and save directory options of ‘perform esdcheck’ are defined as follows:
-jobCount <n>: the number of jobs to execute at a time.
-saveDBDir : directory to save the DB and then import it when executing
esdcheck in the same run
For detailed ‘perform esdcheck’ syntax, see section "perform esdcheck", page 16-425.
You can also control splitting of rules into separate jobs by creating a job file using the
‘-jobFile <job_defin_file>’ option, such as the sample job file below:
BEGIN_ESD_JOB
NAME <jobName>
RULE <ESD_rule_file_name>
CLAMP <clamp_file_name>
DIR
<work_dir>
END_ESD_JOB
where NAME, CLAMP and DIR specifications are optional.
Inputs for 3D-IC Designs
Most inputs for ESD analysis are very similar for 3D-IC designs. The following are
keywords that are specific for 3D-IC designs.
Current Density and Point-to-Point checks for 3D-IC
ESD check types “Current Density” and “Resistance”, the following ESD rule keywords
are available:
FROM_DIE <name>: connects the high terminal of zap source in this die
TO_DIE <name> : connects the ground terminal of zap source in this die
DIE_NAME <name>: the CD/R analysis is performed for this die only
Also, DIE_NAME <name> can be used to specify that a clamp cell is in this die, as in the
following example.
BEGIN_CLAMP_CELL
NAME <cellName>
DIE_NAME <dieName>
...
END_CLAMP_CELL
Also, you can use keywords BEGIN_DIE /END_DIE to specify the die name with a list of
clamp cells, as follows:
BEGIN_DIE <dieName>
BEGIN_CLAMP_CELL
NAME <cellName>
...
END_CLAMP_CELL
...
END_DIE
ANSYS INC - Apache Design Business Unit
CHAPTER 16 — PathFinder ESD Analysis
Layout Resistance Checking of Bumps and Clamps
RedHawk User Manual
| 425
Resistance Checking for B2B, B2C, and C2C Rules
The resistance checking command is 'perform esdcheck'. There are a number of basic
options available, which are described in the following syntax descriptions. Additional
controls on the checking are provided by rules file keywords in the following section.
perform esdcheck
-rule {<file1> <file2> ...}
-clamp {<file1> <file2> ...}
? -thread <num_threads> ?
? -optimize <mode>? ? -detail ? ? -append ?
?