Calbr 3dstack User

Calibre® 3DSTACK User's Manual
Software Version 2016.2
© 2012-2016 Mentor Graphics Corporation

All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: www.mentor.com/trademarks.
The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.
Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: www.mentor.com
SupportNet: supportnet.mentor.com/
Send Feedback on Documentation: supportnet.mentor.com/doc_feedback_form

Table of Contents
Chapter 1
Introduction to Calibre 3DSTACK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 2
Getting Started With Calibre 3DSTACK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Calibre 3DSTACK Invocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
calibre -3dstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Calibre 3DSTACK Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Assembly Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Calibre 3DSTACK Verification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Running a Calibre 3DSTACK Verification from the Command Line . . . . . . . . . . . . . . . . 32
Running a Calibre 3DSTACK Verification from Calibre Interactive . . . . . . . . . . . . . . . . 33
Running Calibre Interactive 3DSTACK From Calibre DESIGNrev . . . . . . . . . . . . . . . . . 35
Calibre 3DSTACK Results Analysis Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Highlighting DRC Results from a Calibre 3DSTACK Run . . . . . . . . . . . . . . . . . . . . . . . . 39
Opening a Calibre 3DSTACK DFM Database in Calibre RVE . . . . . . . . . . . . . . . . . . . . . 41
Debugging Connectivity Errors in Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Viewing Design Elements in a Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Chapter 3
Using Calibre Interactive for Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Calibre Interactive 3DSTACK Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Set Up and Run Calibre 3DSTACK from Calibre Interactive. . . . . . . . . . . . . . . . . . . . . . . . 53
Invoking Calibre Interactive for Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Specifying and Loading a Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Running Calibre 3DSTACK from Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Specify Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Modifying Layouts and Layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Specifying Anchor and Placement Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Specifying Text Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Creating a Source Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Specifying a Source Netlist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Excluding Pins from a Verification Run. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Specify Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Specifying Report and Results Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Exporting Connectivity and Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Specifying Assembly Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Selecting Specific Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Calibre® 3DSTACK User's Manual, v2016.2 3

Table of Contents
Writing a Calibre Interactive Customization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Triggers in Calibre Interactive 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Chapter 4
Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
System and Miscellaneous Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
assembly_path_extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
export_connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
export_template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
layer_props_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
set_version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
source_filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
source_netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Assembly Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
anchor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
attach_text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
ignore_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ignore_trailing_chars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
import_text_labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
layout_primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
map_placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
place_chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
place_layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
rename_text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
trace_text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Rule Check Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
copy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
enclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
external . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
offgrid_centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
select_checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
unselect_checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
tvf_block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Calibre RVE Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Check Text Override Comments for Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . 177
set_auto_rve_show_layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
set_rve_cto_file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
4 Calibre® 3DSTACK User's Manual, v2016.2

Table of Contents
Chapter 5
Calibre 3DSTACK+ Extended Syntax Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Calibre 3DSTACK+ Extended Syntax File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Rule Check and Analysis Commands for the Calibre 3DSTACK+ Extended Syntax . . . . . 185
System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
3DSTACK+ Extended Syntax Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
die . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
custom_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
select_checks (Extended Syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
unselect_checks (Extended Syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
3dstack_block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Chapter 6
System Netlist Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
System Netlist Generator Flow and Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
sng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
System Netlist Generator Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Creating a New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Importing Chips into the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Modifying and Adding Pins on Chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Creating Placements for the Chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Defining Net Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Exporting the Complete Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
System Netlist Generator Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
System Netlist Generator GUI Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Properties Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Set Net Name Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
System Netlist Generator Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
PLACEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
CONNECTIVITY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
EXPORTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
System Netlist Generator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
sng::create_journal_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
sng::export_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
sng::export_netlist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
sng::new_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
sng::open_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
sng::save_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
sng::filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
sng::get_begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
sng::get_buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
sng::get_chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
sng::get_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
sng::get_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Table of Contents
sng::get_placements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sng::get_ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
sng::get_property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
sng::get_property_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
sng::incr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
sng::set_property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
sng::sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
sng::add_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
sng::connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
sng::create_chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
sng::create_placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
sng::import_chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
sng::remove_chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
sng::remove_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
sng::remove_placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
sng::set_net_name_template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
sng::unconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Appendix A
Calibre 3DSTACK Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
AIF Converter Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
AIF Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
3dstack::aif2gds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
3dstack::aif2oasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
3dstack::aif2spice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Spreadsheet Converters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
3dstack::ss2gds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
3dstack::ss2oasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
3dstack::ss2spice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
3dstack::xpi2spice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Appendix B
Calibre 3DSTACK Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Example Design Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Preparing the Dies for Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Creating the Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Writing Assembly Operations in the Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . . . . 313
Defining the Layout Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Defining Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Placing the Dies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Connecting Layers and Placements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Attaching Text to Placements for LVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Writing Verification Checks in the Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . . . . . 327
Checking Connectivity (LVS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Checking Spacing Between Placements (DRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Checking For Sufficient Pad Overlap (DRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Table of Contents
Appendix C
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Calibre 3DSTACK+ Extended Syntax Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Conventional Syntax — Example 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Conventional Syntax — Example 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Appendix D
Error and Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Appendix E
Report File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Report Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Summary of Drawn Layers, Placements, and Text Layers . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Verification Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Index
Third-Party Information
End-User License Agreement

Table of Contents

List of Figures
Figure 1-1. TSV-based 3D-IC Cross-section (Conceptual Illustration) . . . . . . . . . . . . . . . . 14

Figure 1-2. 3DSTACK Assembly (Conceptual Illustration) . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 1-3. Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 1-4. Calibre 3DSTACK Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 2-1. Calibre 3DSTACK Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 2-2. Specify Rule File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 2-3. Run 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 2-4. Calibre 3DSTACK Analysis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 2-5. Highlighting DRC Results from a Calibre 3DSTACK Run . . . . . . . . . . . . . . . . 40
Figure 2-6. Calibre 3DSTACK Results in Calibre RVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 2-7. Layout and Source Net Details in Calibre RVE . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 3-1. Calibre Interactive GUI Launcher for Calibre 3DSTACK . . . . . . . . . . . . . . . . 53
Figure 3-2. Specify Rule File and Run Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 3-3. Run 3DSTACK from Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 3-4. View Transcript Output in Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 3-5. Modify and View Layout and Layer Information. . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 3-6. Modify Placements and Anchors in Calibre Interactive . . . . . . . . . . . . . . . . . . . 62
Figure 3-7. Modify Text in Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 3-8. Create Source Netlist With Calibre Interactive. . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 3-9. Specify Source Netlist Options in Calibre Interactive . . . . . . . . . . . . . . . . . . . . 67
Figure 3-10. Modify the ignore_pin Command in Calibre Interactive . . . . . . . . . . . . . . . . . 69
Figure 3-11. Specify Outputs in Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 3-12. View Connectivity Files for Export in Calibre Interactive . . . . . . . . . . . . . . . . 73
Figure 3-13. Specify the Assembly Operations in Calibre Interactive . . . . . . . . . . . . . . . . . 74
Figure 3-14. Select Specific Verification Checks in Calibre Interactive . . . . . . . . . . . . . . . 76
Figure 3-15. Customization Settings in Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 4-1. Connectivity Export Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 4-2. Connectivity Import Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figure 4-3. Calibre DESIGNrev Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 4-4. Anchoring Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 4-5. Multiple Chips Using the Same Memory Cell . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 4-6. Stacked Dies With RDL Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Figure 4-7. density -window_type truncate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figure 4-8. density -window_type backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figure 4-9. density -window_type ignore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Figure 4-10. density -window_type wrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Figure 6-1. System Netlist Generator Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Figure 6-2. System Netlist Generator Interposer Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Figure 6-3. Select Multiple Cells by Clicking and Dragging the Cell Corner. . . . . . . . . . . . 242
Figure 6-4. Copy Existing Properties in the System Netlist Generator . . . . . . . . . . . . . . . . . 243

List of Figures
Figure 6-5. Shift-Select and Paste Into Multiple Cells in the System Netlist Generator. . . . 243
Figure 6-6. Updated Cells In the System Netlist Generator . . . . . . . . . . . . . . . . . . . . . . . . . 243
Figure 6-7. Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Figure 6-8. Properties Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Figure 6-9. Set Net Name Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure B-1. Calibre 3DSTACK Rule Creation and Verification Flow . . . . . . . . . . . . . . . . . 309
Figure B-2. Design Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Figure B-3. Desired 3D-IC Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Figure B-4. Example Placement Coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Figure B-5. Layer Definitions Before Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Figure B-6. Layer Definitions After Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Figure B-7. Connect two Placed Layers by a Via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Figure B-8. Connect Layers Directly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Figure B-9. Placement with Text on Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Figure C-1. Overhead View of the Example Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Figure C-2. Side View of the Example Assembly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

List of Tables
Table 1-1. Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Table 2-1. Source Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Table 3-1. Files Used by the Calibre Interactive 3DSTACK GUI . . . . . . . . . . . . . . . . . . . . 52
Table 3-2. Functions in the Inputs Pane for Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . 58
Table 3-3. Outputs Pane for Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table 3-4. Supported Trigger Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table 4-1. Calibre 3DSTACK Full Command List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 4-2. System Control and Miscellaneous Commands . . . . . . . . . . . . . . . . . . . . . . . . . 82
Table 4-3. export_connectivity -hier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Table 4-4. Assembly Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table 4-5. Nets With Trailing Characters In Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table 4-6. Regular Expression Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Table 4-7. Rule Check Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Table 4-8. Density Math Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Table 4-9. ! and ~ Operator Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Table 4-10. Calibre RVE Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Table 5-1. Extended Calibre 3DSTACK Command Summary . . . . . . . . . . . . . . . . . . . . . . 184
Table 5-2. Layer Information for the RAM_block Die . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Table 6-1. Netlists for Chips Used In This Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Table 6-2. Net Connectivity of the Interposer Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Table 6-3. Main Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Table 6-4. Properties Panel Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Table 6-5. Set Net Name Template Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Table 6-6. System Netlist Generator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Table 6-7. Property Values For Each Iterator Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Table B-1. Die Placement Coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Table B-2. Layout Extraction With and Without attach_text . . . . . . . . . . . . . . . . . . . . . . . . 324
Table D-1. Calibre 3DSTACK Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Table D-2. Calibre 3DSTACK Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

List of Tables

Chapter 1
Introduction to Calibre 3DSTACK
Calibre® 3DSTACK is a software application that allows you to verify designs containing flip
chips, Through Silicon Vias (TSVs), and other 2.5D and 3D-IC configurations.
Video
For an introduction to Calibre 3DSTACK, view the video Getting Started with Calibre
3DSTACK.
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Overview
Traditional ICs are self-contained and are verified at the chip-level using Calibre nmDRC,
Calibre nmLVS, Calibre RVE, and Calibre DESIGNrev. 3D-ICs consist of multiple stacked
chips with connectivity achieved through traces on an interposer or with special vias or bumps.
Calibre 3DSTACK verifies the interfaces between these chips, which may consist of black box
IP.
Note
This document includes code from a 3D-IC Description Language (3DIC_DL) used within/
by Mentor Graphics’ products supporting 2.5D/3D IC applications. You shall not use this
3DIC_DL unless you are a Mentor Graphics customer. The exact terms of your obligations and
rights are governed by your respective license.
You shall not use this 3DIC_DL except:

(a) for your internal business purposes and
(b) for use with Mentor Graphics’ Calibre tools.
The 3DIC_DL may constitute or contain trade secrets and confidential information of Mentor
Graphics or its licensors. You shall not make the 3DIC_DL available in any form to any person
other than your employees and on-site contractors, excluding Mentor Graphics competitors,
whose job performance requires access and who are under obligations of confidentiality.
A cross-section of a 3D-IC is illustrated in Figure 1-1. The primary difference between a 2.5D
and 3D-IC configuration is the use of a silicon interposer. A silicon interposer, as illustrated in
Figure 1-2, electrically connects the pads between chips. These chips can either use TSVs

Overview
(allowing for additional stacking), or may contain no TSVs (in which case the chips do not
allow for additional stacking and are flip chips). 2.5D configurations use a silicon interposer,
while 3D-IC configurations contain TSVs in active silicon that form a complete 3D stack.
A TSV is a via that passes through the substrate of a chip or silicon interposer. Typically, in a
chip containing TSVs, devices and metal layers are manufactured on one side of the chip (the
front), while additional metal layers are manufactured on the other side of the chip (the back).
The front metal layers are normally manufactured at a more advanced process node than the
back metal layers. Small spheres of solder called micro bumps can be used to connect multiple
chips together. Refer to Figure 1-1.
Figure 1-1. TSV-based 3D-IC Cross-section (Conceptual Illustration)
Calibre 3DSTACK operates on these configurations by supplementing your existing Calibre

verification flow. Your existing Calibre flow operates on each design independently, while
Calibre 3DSTACK operates on the interfaces between designs. Designs are assembled
according to instructions contained in a 3DSTACK rule file, which include offset values along
the x and y axes, rotation angles, and magnification factors.
For example, in Figure 1-2, two designs (chip1 and chip2) are to be assembled on a silicon
interposer. To assemble the die stack, chip2 is shifted along the x-axis by x_offset and the

Overview
interposer is rotated clockwise by 90 degrees. Figure 1-2 summarizes the necessary inputs and
outputs to a 3DSTACK assembly operation.
Figure 1-2. 3DSTACK Assembly (Conceptual Illustration)

Overview
Figure 1-3 illustrates the input files that Calibre 3DSTACK accepts and the output files that it
creates. Dimensional check (DRC) and connectivity operations (LVS) can be performed on the
assembled chip stack using commands specified in the 3DSTACK rule file.
Figure 1-3. Inputs and Outputs
The following figure illustrates the typical workflow for verifying a design with Calibre
3DSTACK.

Overview
Figure 1-4. Calibre 3DSTACK Flow
Related Topics
Requirements
Calibre 3DSTACK Invocation

Requirements
Requirements
Before running Calibre 3DSTACK, you must have a full Calibre installation and the appropriate
licenses. The chips in your stack must already be DRC and LVS clean.
You must have the following Calibre licenses:
• Calibre nmDRC-H and Calibre nmDRC.

• Calibre nmLVS-H and Calibre nmLVS.
• Calibre DESIGNrev.
• Calibre RVE (highly recommended for debugging results)
You must set the CALIBRE_HOME or MGC_HOME environment variable to point to the
location of your Mentor Graphics software tree. See “Setting the CALIBRE_HOME
Environment Variable” in the Calibre Administrator’s Guide for details.
The following inputs must be defined:
• The layout files that compose the 3D assembly. The layout must be in GDS or OASIS
format. Cell and pin names should not have spaces, as this causes the exported netlist to
be incorrect.
• A valid 3DSTACK rule file containing only commands specified in the Command
Reference chapter of this document, plus any standard Tcl constructs.
• A source netlist for the chip stack is highly recommended.
Related Topics
Documentation Conventions
The command descriptions for Calibre 3DSTACK statements use font properties and several
metacharacters to document the command syntax.
The commands described in this document and any examples follow the syntax conventions
outlined in the following table.
Table 1-1. Syntax Conventions

Convention Description
Bold Bold fonts indicate a required item.
Italic Italic fonts indicate a user-supplied argument.

Table 1-1. Syntax Conventions (cont.)

Convention Description
Monospace Monospace fonts indicate a shell command, line of code, or
URL. A bold monospace font identifies text you enter.
Underline Underlining indicates either the default argument or the default
value of an argument.
UPPercase For certain case-insensitive commands, uppercase indicates the
minimum keyword characters. In most cases, you may omit the
lowercase letters and abbreviate the keyword.
[] Brackets enclose optional arguments. Do not include the brackets
when entering the command unless they are quoted.
{} Braces enclose arguments to show grouping. Do not include the
braces when entering the command unless they are quoted.
‘’ Quotes enclose metacharacters that are to be entered literally. Do
not include single quotes when entering braces or brackets in a
command.
| or || Vertical bars indicate a choice between items. Do not include the
bars when entering the command.
… Three dots (an ellipsis) follows an argument or group of
arguments that may appear more than once. Do not include the
ellipsis when entering the command.
Example:
DEVice {element_name [‘(’model_name‘)’]}
device_layer {pin_layer [‘(’pin_name‘)’] …}
[‘<’auxiliary_layer‘>’ …]
[‘(’swap_list‘)’ …]
[BY NET | BY SHAPE]


Chapter 2
Getting Started With Calibre 3DSTACK
Calibre 3DSTACK uses the powerful and familiar set of verification and analysis features
included with the Calibre nmDRC, Calibre nmLVS, Calibre RVE, and Calibre DESIGNrev
products. Calibre 3DSTACK uses its own rule file format and commands, but the principles of
operation are familiar to existing Calibre verification flows.
Video
For a quick introduction, view the video Getting Started with Calibre 3DSTACK.
Video
To view a complete step-by-step guide to creating a rule file, assembling your design,
writing rules, and running a verification, view the video Calibre 3DSTACK Tutorial.
Calibre 3DSTACK Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Calibre 3DSTACK Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Assembly Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Calibre 3DSTACK Verification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Calibre 3DSTACK Results Analysis Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


Invoke Calibre 3DSTACK in batch mode from the command line or from Calibre Interactive.
The majority of rule file operations can be modified from Calibre Interactive 3DSTACK. After
a run is complete, use Calibre RVE and Calibre DESIGNrev to view the results.

calibre -3dstack
calibre -3dstack
Calibre 3DSTACK command-line invocation arguments.
Usage
calibre -3dstack {[-help] [-turbo [number_of_processors]] {[-system {GDS | OASIS}]
[-create_assembly assembly_name] | [-use_assembly assembly_path]}
| [-cs]} rule_file_name [-run_dir directory] [-compile_only]
Arguments
• -3dstack
Required switch that enables Calibre 3DSTACK.
• -help
Optional switch that displays the command line usage.
• -turbo
Optional switch that enables multi-threaded parallel processing. You can optionally specify
the number of processors to use (the default is all).
• -system {GDS | OASIS}
Optional switch that specifies the layout system. The default is GDS. Cannot be specified
with -use_assembly or -cs.
• -create_assembly assembly_name
Optional switch that limits the run to creating the 3D assembly. Cannot be specified with
-use_assembly or -cs.
• -use_assembly assembly_name
Optional switch that instructs the tool to use the specified assembly_name for the run. All
specified verification checks are executed on the supplied assembly_path file. Cannot be
specified with -create_assembly, -system, or -cs.
• -cs
Optional switch that verifies the syntax of the source netlist file and checks if placements
involved in connectivity checks are valid; no verification checks are run. If the report
command is not specified, the log is saved to the working directory.
• rule_file_name
Required switch that specifies the path to the 3DSTACK rule file.
• -run_dir directory
Optional switch that specifies a path to a directory to place output files. The default is the
current directory.

calibre -3dstack
• -compile_only
Optional switch that specifies to only compile a 3DSTACK+ rule file. The compiled rule
file is written to your working directory with the name <name>.3dstack. This is useful for
debugging your 3DSTACK+ operations.
Description
When a Calibre 3DSTACK run is executed, specified layout files are assembled according to
the instructions present in your Calibre 3DSTACK rule file. Calibre 3DSTACK then performs
specified verification checks and generates 3DSTACK results databases, an extracted layout
netlist, and a report file, if specified by your rule file.
Additional information about the command options for Calibre Interactive can be found under
the topic “Invoking Calibre Interactive from the Command Line” in the Calibre Interactive and
Calibre RVE User’s Manual.
Note
The use_assembly argument is mutually exclusive with the create_assembly and system
arguments. When create_assembly is specified, only the 3DSTACK assembly and
export_template commands are executed (no rule checks are done). When use_assembly is
specified in the invocation, no 3DSTACK assembly and export_template commands are
performed; all the specified checks are executed on the user-specified assembly file.
Examples
Invoke Calibre 3DSTACK in batch mode:
calibre -3dstack rules.3dstack
Invoke Calibre Interactive for Calibre 3DSTACK with the following command:
calibre -gui -3dstack [-runset runset] [gui_options]
Invoke Calibre Interactive batch mode for Calibre 3DSTACK with the following command:
calibre -gui -3dstack -runset runset [gui_options] -batch
Generate a compiled version of a 3DSTACK+ rule file in your working directory without
performing any other operations.
calibre -3dstack -compile_only extended_rules.3dstack
Related Topics
System Netlist Generator Flow and Invocation
Invoking Calibre Interactive for Calibre 3DSTACK

Calibre 3DSTACK Output
Calibre 3DSTACK Output

All output files are saved to your working directory during a Calibre 3DSTACK run. The
transcript is updated in real-time.
Output Files
The following output files are created in your working directory during a run:
• 3dstack.log — the complete transcript from a run.

• 3dstack_assembly.gds.gz — assembled chip stack view file.
• 3dstack_assembly.gds.gz.layerprops — layer properties file for the chip stack. This
file defines the layer properties for a set of design layers, polygon connectivity, and via
cell information.
• 3dstack_assembly.gds.gz.layermap — SVRF layer definitions generated from the
assembly process. This file can be used to write custom SVRF rules for verification runs
on the assembly.
• 3dstack_cross_section.gds.gz — optional view of your layout in the x, y, and z
dimensions. See “Assembly Views” on page 28 for details.
• 3dstack_cross_section.gds.gz.layerprops — layer properties for the cross-sectional
assembly view.
• 3dstack_overlay_generator.tcl — Tcl script used to generate the chip stack view from
the individual layouts.
• 3dstack.rdb — RDB file containing analysis results. An RDB is an ASCII-formatted
results database generated from the 3DSTACK verification run. The RDB file can be
directly opened in Calibre RVE.
• 3dstack.dfmdb (directory) — binary database containing analysis results. The
DFMDB enables advanced cross-referencing in Calibre RVE between the error results,
the source schematic, and the design layout. See “Opening a Calibre 3DSTACK DFM
Database in Calibre RVE” on page 41 for more information.
• <3dstack+_rule_file>.3dstack — compiled 3DSTACK+ rule file.
• Layout files in GDS or OASIS — optional layout files from derived layer or export
operations.
In addition to these files, RDB files can optionally be created for each layout file in the chip
stack. If the report command is specified (recommended), a report is saved in your working
directory.

Calibre 3DSTACK Rule File
Run Time Status Notifications

The transcript output updates continuously during the 3DSTACK run with the following
information:
• Chips currently being processed.

• Cell and placements under creation.
• 3DSTACK assembly file path and physical size.
• Run duration.
• Summary statistics for each stage of the run.
Related Topics
Command Reference
Report File Format

The Calibre 3DSTACK rule file specifies the system configuration, assembly operations, and
rule check and verification operations necessary to verify your 3D-IC.
Note
The Calibre 3DSTACK rule file must be written using either the conventional syntax, as
documented in this topic and in “Command Reference” on page 81, or the extended syntax
(3DSTACK+), as documented under “Calibre 3DSTACK+ Extended Syntax File Format” on
page 184.
The rule file must only consist of commands defined in the “Command Reference” chapter of
this document and supported Tcl constructs. Rule checks cannot share names with
Calibre 3DSTACK file format keywords. See the “Examples” chapter to view sample rule files
using the 3D-IC Description Language.
Required Statements
• Set the syntax version of the 3D-IC Description Language.
o Use the set_version command (currently, the only valid syntax value is 1.0).
• Specify the layout files that compose the chip stack.
o Use the layout and layout_primary commands.
Recommended Statements
• Specify a source netlist for the chip stack to aid in debugging and LVS.

Assembly Views
o Use the source_netlist command.

• Perform 3DSTACK assembly commands to place layouts and define the chip stack.
o See Assembly Commands in the Command Reference chapter.
• Write rule checks commands to verify that your design meets the chip stack rules.
o Use the centers, connected, copy, density, enclosure, external, internal, locations,
offgrid_centers, overlap, select_checks, unselect_checks, and tvf_block commands.
• Instruct the tool to compare the names of matched top-level ports and to report naming
conflicts for each die in the stack.
o Use the LVS CHECK PORT NAMES YES command. See the Standard
Verification Rule Format User’s Manual for a detailed description.
• Generate a report to provide additional information to aid in debugging.
o Use the report command.
Note
The connected -detailed, report, and source_netlist commands provide valuable
information about the assembled chip stack. They are highly recommended for
use in the 3DSTACK rule file for debugging.
Related Topics
Command Reference
Examples
Assembly Views
Calibre 3DSTACK automatically generates an overhead assembly view of your stacked
package when you perform a verification run. You can also create an optional assembly view
that displays the package in the x, y, and z dimensions.
Calibre 3DSTACK saves the overhead view of your assembly in your working directory as
3dstack_assembly.gds.gz. Open this file in Calibre DESIGNrev to see the layout of your stack.
You can optionally generate a cross-sectional x, y, and z view of your assembly from a
3DSTACK+ or 3DSTACK rule file. The 3dstack_cross_section.gds.gz assembly view file is
generated in your working directory if you specify thicknesses and z-origins for your

Assembly Views
dies.
For 3DSTACK+ rule files, the following arguments enable the generation of the cross-section
view:
• Apply the -thickness option of the die command. This option defines the thickness of the
die in microns. If this is not specified, you can use the
CALIBRE_3DSTACK_DEFAULT_THICKNESS environment variable to set a global
thickness for all dies.
• Apply the -z_origin option in the stack command. The -z_origin option specifies the
height of the object from the bottom of the stack.
For 3DSTACK rule files, the following arguments enable the generation of the cross-section
view:
• Apply either the -z_origin or-level options in the place_chip and place_layer commands.
These arguments are mutually exclusive. The -z_origin option specifies the height of the
die from the bottom of the stack. The -level option indicates the order of the die in the
stack.
• Apply the -thickness option in the layout command. This option defines the thickness of
the die in microns. If this is not specified, you can use the
thickness for all dies. If neither the environment variable nor the -thickness option is
specified, the thickness of the placement level is calculated based on the minimum width
and height of the dies in the same level.

Assembly Views
The following is an example for 3DSTACK+:
die -die_name interposer \

-layout { \
-path ./design/interposer.gds \
-type gdsii \
-primary interposer \
} \
-thickness 20 \
…
die -die_name ram \

-layout { \
-path ./design/ram.gds \
-type gdsii \
-primary ram \
} \
-thickness 11 \
…
die -die_name controller \

-layout { \
-path ./design/controller.gds \
-type gdsii \
-primary controller \
} \
-thickness 13 \
…
stack -stack_name assembly \

-die { \
-name interposer \
-placement 0 0 \
-invert \
} -z_origin 0 \
-tier { \
-die {-name controller -placement 14 12}\
-die {-name ram -placement 80 12}\
} -z_origin 20

Calibre 3DSTACK Verification Examples

Run Calibre 3DSTACK from the command line, Calibre DESIGNrev, and Calibre Interactive.
The flow for running a Calibre 3DSTACK verification is highlighted in Figure 2-1 below.
Figure 2-1. Calibre 3DSTACK Verification Flow
Running a Calibre 3DSTACK Verification from the Command Line . . . . . . . . . . . . . . 32

Running a Calibre 3DSTACK Verification from Calibre Interactive . . . . . . . . . . . . . . 33
Running Calibre Interactive 3DSTACK From Calibre DESIGNrev . . . . . . . . . . . . . . . 35

Running a Calibre 3DSTACK Verification from the Command Line
Running a Calibre 3DSTACK Verification from the

Command Line
Run Calibre 3DSTACK from the command line and understand output results.
Prerequisites
• You have met the “Requirements” listed in Chapter 1.
• You have layout files in GDS or OASIS format that compose the 3D assembly.
• You have a valid 3DSTACK rule file. Refer to “Calibre 3DSTACK Rule File” on
page 27 for more details on writing Calibre 3DSTACK rule files.
Procedure
1. Modify your Calibre 3DSTACK rule file so that it includes the report command (or
config -report for 3DSTACK+). The report provides essential details about a Calibre
3DSTACK run that can aid in debugging and design validation.
2. From the command line, run Calibre 3DSTACK with the following command:
calibre -3dstack rule_file
where rule_file is the path to your 3DSTACK rule file. Sample rule files are provided in
the “Examples” section of Appendix A.
By default, Calibre 3DSTACK writes all associated verification output files to your
working directory. The outputs are described in detail under “Calibre 3DSTACK
Output” on page 26.
3. During the verification run, observe the transcript output to view the assembly and rule
checking process. Investigate and correct any warnings or error messages as necessary.
4. When the verification run completes, open the report file, 3dstack_report.rpt, in your
output directory in a text editor and become familiar with the different sections.
Understanding the structure of the assembly and verification process greatly aids in
debugging complex designs. Information on the report file can be found under “Report
File Format” on page 361 of Appendix C.
Results
Your output directory now contains the assembled 3DSTACK layout view,
3dstack_assembly.gds.gz, and results database files that can be opened in Calibre RVE. If
specified, your run directory also contains a report file used to debug the verification run. To
understand how to view and analyze the verification results produced by a Calibre 3DSTACK
run, proceed to “Calibre 3DSTACK Results Analysis Examples” on page 38.
Related Topics

Running a Calibre 3DSTACK Verification from Calibre Interactive
Calibre 3DSTACK Results Analysis Examples
Running a Calibre 3DSTACK Verification from

Calibre Interactive
Set up and run a Calibre 3DSTACK verification from Calibre Interactive.
Detailed procedures for Calibre Interactive 3DSTACK are found under the section “Using
Calibre Interactive for Calibre 3DSTACK” on page 51. Additional information about
Calibre Interactive can be found in the Calibre Interactive and Calibre RVE User’s Manual.
Note
In the case of a conflict between commands in the rule file and Calibre Interactive, the
settings in Calibre Interactive take precedence.
Prerequisites
• You have a valid Calibre 3DSTACK rule file. Refer to “Calibre 3DSTACK Rule File”
on page 27 for more details.
Procedure
1. Enter the following command to invoke Calibre Interactive for Calibre 3DSTACK:
calibre -gui -3dstack
2. After you invoke Calibre Interactive, you are prompted to specify a runset file. A runset
sets GUI options and can be useful for managing different types of verification
operations. You may choose to continue without a runset by clicking Cancel, or load an
existing runset with the Browse (…) button.
3. Click on the Rules button in the upper-left pane of the CI window and specify the path
to your Calibre 3DSTACK rule file and run directory (see Figure 2-2).

Running a Calibre 3DSTACK Verification from Calibre Interactive
Figure 2-2. Specify Rule File
4. (Optional) Click the Load button to load instructions from the rule file and apply them
to the current Calibre Interactive session. Any syntax errors are reported.
5. Click on the Outputs button and enable the Show results in RVE checkbox under the
Reports tab to display results in Calibre RVE following a Calibre 3DSTACK run.
6. Enable the Write 3DSTACK Summary Report File checkbox and specify a path to a
file. The report file contains important information about the design and verification
results. Enabling this option is highly recommended.
7. Ensure that the input and output file options are correct and then click Run 3DSTACK.
(see Figure 2-3).
Figure 2-3. Run 3DSTACK

Running Calibre Interactive 3DSTACK From Calibre DESIGNrev
Results
Your output directory now contains the assembled 3DSTACK layout view (if specified) and
results databases that can be opened in Calibre RVE. Your run directory also contains a report
file used to debug the verification results.
To understand how to view and analyze the verification results produced by a
Calibre 3DSTACK run, proceed to “Calibre 3DSTACK Results Analysis Examples” on
page 38.
Related Topics
Running Calibre Interactive 3DSTACK From

Calibre DESIGNrev
Export a layout view from Calibre DESIGNrev to Calibre Interactive 3DSTACK and perform a
verification run.
Prerequisites
• You have a valid Calibre 3DSTACK rule file.
• You have a layout open in Calibre DESIGNrev that is specified in your rule file.
Procedure
1. Select the top cell of your layout in the cells list on the left pane of Calibre DESIGNrev,
as shown in the following figure:

2. Select Verification > Run 3DSTACK. You do not have to save your layout file. The
current layout view is exported to Calibre Interactive, including unsaved changes.
operations. You may choose to continue without a runset by clicking Cancel, or load an
existing runset with the Browse (…) button.
4. Click the Rules button, specify the path to your Calibre 3DSTACK rule file, and click
Load. Loading a rule file updates the fields in the Calibre Interactive GUI with the
settings from your rule file.

5. Click the Inputs button, enable the Export from layout viewer checkbox, and specify
the layout view in Calibre DESIGNrev using the Chip Name dropdown box.
The above snapshot of Calibre Interactive shows that the interposer top cell was
exported from Calibre DESIGNrev. The Layout Path field of the Layouts table lists the
path as interposer.calibre.db.
6. Select Run 3DSTACK to start a verification run from Calibre Interactive.
Results
The layout view of one of the specified chips in your 3DSTACK assembly was exported from
Calibre DESIGNrev and used in a Calibre 3DSTACK verification run. This process allows you
to modify layouts in Calibre DESIGNrev and view changes in the verification results without
saving the layout.
Related Topics


View and analyze verification results produced by Calibre 3DSTACK.
The typical Calibre 3DSTACK results analysis flow is highlighted in Figure 2-4 below.
Figure 2-4. Calibre 3DSTACK Analysis Flow
Highlighting DRC Results from a Calibre 3DSTACK Run . . . . . . . . . . . . . . . . . . . . . . 39

Opening a Calibre 3DSTACK DFM Database in Calibre RVE . . . . . . . . . . . . . . . . . . . 41
Debugging Connectivity Errors in Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Viewing Design Elements in a Schematic View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Highlighting DRC Results from a Calibre 3DSTACK Run
Highlighting DRC Results from a Calibre 3DSTACK

Run
Use Calibre RVE to highlight DRC results from a Calibre 3DSTACK run. DRC results are
produced by the geometrical rule checks in the 3DSTACK rule file.
For advanced connectivity debugging using 3DSTACK DFM databases, follow the procedure
described in “Debugging Connectivity Errors in Calibre 3DSTACK” on page 44.
Prerequisites
• Calibre 3DSTACK results databases generated by a verification run. See “Calibre
3DSTACK Verification Examples” on page 31.
• Layout files that compose the 3DSTACK assembly.
Procedure
1. Load the Calibre 3DSTACK assembly in a supported layout editor and launch
Calibre RVE with the 3DSTACK RDB file. For Calibre DESIGNrev:
calibredrv 3dstack_assembly.gds.gz -rve 3dstack.rdb
Calibre DESIGNrev displays a top-level view of the assembled 3D chip stack.

Calibre RVE displays results for each check defined in the 3DSTACK rule_file.
Tip
It is also possible to debug a design by viewing the Calibre 3DSTACK report file
(generated with the report command). The report file can be opened from the Report
tab in Calibre RVE, or in any supported text viewer. Refer to the Report File Format in
Appendix C for more details on report files.
2. Select Clear Existing Highlights from the Calibre RVE Highlight options dropdown
menu. This option causes Calibre RVE to clear existing highlights before creating a new
highlight.

3. Select the check you want to view in the tree view, or use Shift- and Ctrl-click to select
multiple checks.
4. In the detailed view, double-click on a result to highlight it, as shown in Figure 2-5, or
use the highlight toolbar. Browse each result by clicking the next and previous icons
( ).
Figure 2-5. Highlighting DRC Results from a Calibre 3DSTACK Run
Figure 2-5 shows an internal check result highlighted in Calibre DESIGNrev. See
“Using Calibre RVE for DRC” in the Calibre Interactive and Calibre RVE User’s
Manual for more information on debugging with Calibre RVE for DRC.
Tip
You can also view DRC errors in the context of the separate components for the
3DSTACK assembly. To do this, open the design (the base chip, for example) in
your layout viewer, then highlight the result using Calibre RVE.

Opening a Calibre 3DSTACK DFM Database in Calibre RVE
Results
You performed the following actions while completing this procedure:
• Used Calibre RVE to view DRC results generated by a Calibre 3DSTACK verification.
• Highlighted DRC results from Calibre RVE in Calibre DESIGNrev.
You can control the highlighting behavior in Calibre RVE from your rule file by applying check
text override comments. For complete details, see “Calibre RVE Commands” on page 176.
Related Topics
Opening a Calibre 3DSTACK DFM Database in

Calibre RVE
Use the cross-referencing capability provided by DFM databases in Calibre RVE to open and
debug results from a Calibre 3DSTACK verification run.
Prerequisites

• You have specified a netlist that defines connectivity in your chip stack with the
source_netlist rule file command.
• You have a valid 3DSTACK verification results database produced from a
Calibre 3DSTACK run. See “Running a Calibre 3DSTACK Verification from the
Command Line” on page 32 or “Running a Calibre 3DSTACK Verification from
Calibre Interactive” on page 33 for information on how to execute a Calibre 3DSTACK
run.
Procedure
1. Open the 3DSTACK assembly (3dstack_assembly.gds.gz) in a supported layout editor.
calibredrv 3dstack_assembly.gds.gz
2. Start Calibre RVE from the layout editor’s graphical user interface:
• Calibre DESIGNrev and Calibre layout viewers — Verification > Start RVE.
• Other supported layout viewers — Calibre > Start RVE.
3. In the Calibre RVE dialog box, do the following:
a. Select a Database Type of DFM (do this before browsing to a database).

b. Enter the path to your 3DSTACK database (3dstack.dfmdb):

c. Click Open.
Calibre RVE automatically opens 3dstack.rdb and the 3DSTACK report generated
by the run, as shown in Figure 2-6 on page 43.
4. Setup the Internal Schematic Viewer to display the source and layout netlists as follows:
a. Click Setup > Options to open the Options tab.
b. Select the Schematic Viewer category.
c. Enable Show netlist schematics when highlighting connectivity objects.
d. Enable the Schematic, Hierarchy, and Text options for Show Panes.
e. Click Apply.
f. Select View > Schematics > All to open the layout and source netlists in the Internal
Schematic Viewer.
Now, when you highlight a net it is automatically highlighted in the Internal
Schematic Viewer in addition to the physical layout.
g. Close the Options tab, or click the 3dstack.rdb tab to return to viewing 3DSTACK
results.
Results
Calibre RVE automatically opens the 3dstack.rdb and the 3DSTACK report generated by the
run, as shown in Figure 2-6. You can also select View > Results and View > Reports to see the
available results databases and reports. Schematic views of the source and layout netlists are
shown in windows below the RDB tab.
The RDB tab is displayed using Calibre RVE for DRC. The display includes the following
areas:
• Tree View — (left side) Select View > Tree Options to change the grouping.

• Detailed View — (top right) Displays property data in table format. Select View >
Result Options to change the view.
• Results Data — (center right) Shows property data for the result(s) selected in the
detailed view.
Figure 2-6. Calibre 3DSTACK Results in Calibre RVE
Tip
Check names are defined in the rule file with the -check_name option. For example:
external -check_name EXT_ -placement stack_bot_if …
#where EXT_ is the assigned check name
Related Topics

Debugging Connectivity Errors in Calibre 3DSTACK
Viewing Design Elements in a Schematic View

Internal Schematic Viewer

Use the advanced debugging capability in Calibre RVE for 3DSTACK DFM databases.
Connectivity errors are reported by the connected command in a 3DSTACK rule file.
Prerequisites
• A Calibre 3DSTACK database with a connected check using the -detailed option.
The -detailed option adds the LNC (Layout Net Component) and SNC (Source Net
Component) properties to the database.
• A Calibre 3DSTACK database opened in Calibre RVE, as described in “Opening a
Calibre 3DSTACK DFM Database in Calibre RVE” on page 41.
• The 3DSTACK assembly open in an attached layout viewer.
• The source and layout netlists open in the Internal Schematic Viewer, as described in
Step 4 of “Opening a Calibre 3DSTACK DFM Database in Calibre RVE” on page 41.
Procedure
1. Disable Clear Existing Highlights in the Calibre RVE Highlight options dropdown
menu. This causes Calibre RVE to keep existing highlights, and allows you to view
layout net, source net, and result highlights together.
2. Select Highlight > Highlight Net/Device/Pin and enable Highlight by layer. This
selection causes Calibre RVE to highlight the different layers of an object in different
colors.
See “Highlight Layout Net/Device/Pin Dialog Box” in the Calibre Interactive and
Calibre RVE User’s Manual for more information on this dialog box.

3. Select a connected check in the tree view of Calibre RVE, then select a result in the
detailed view. Review the LNC (Layout Net Component) and SNC (Source Net
Component) properties in the Result Data pane; these properties report the ports
connected to the respective nets. For the MissingPads check, see Step 6.
Display properties aid you in debugging connectivity errors (refer to Figure 2-7). Note
that display of the LNC and SNC properties are enabled with the -detailed option for the
connected command.
In Calibre RVE, the SourceNet property indicates the source net number of each
particular result, and the SNC property indicates the ports that the source net is
connected to in the form placement_name:port.
For the result shown in Figure 2-7, net WDA<7> is connected to port WDA<7> of
placement pCont and to port WDA<7> of placement pRAM_stack_1. Calibre RVE
displays these connections as shown in Table 2-1.
Table 2-1. Source Properties

Property Name Property Value
SNC pCont:WDA<7> pRAM_stack1:WDA<7>
SourceNet WDA<7>

Figure 2-7. Layout and Source Net Details in Calibre RVE
4. Click on the layout net (Net ID) and SourceNet links to highlight the nets in the Internal
Schematic Viewer.

You can also click on the LNC and SNC text strings to highlight the ports on the
placements involved in the result. The layout net is also highlighted in the layout viewer.
5. Click the highlight button ( ) in the highlight toolbar to highlight the result in the
layout viewer. Since highlighted shapes and layers may overlap, you may need to use
your layout viewer controls to set layer visibility.
The following figure shows the result from a connected check highlighted in
Calibre DESIGNrev. The layout net is also highlighted from Step 4.

6. For a MissingPads result, the result properties include links for the missing pad and the
source net. (The MissingPads results occurs when a port in the source netlist has no
corresponding layout pad.) Do the following to highlight the net and source port:
a. Click the “SourceNet” link in the Result Data Pane in Calibre RVE. The net is
highlighted in Calibre DESIGNrev and in the source and layout netlist views in the
Internal Schematic Viewer.
b. Click the “MissingPad” link. The port is highlighted in the source netlist.
c. (Optional) Double-click the result in the Details View to highlight it in Calibre
DESIGNrev. When the result is highlighted, there is no layout object to highlight, so
the result properties are displayed in the bottom left corner of the top cell in the
assembly.
7. (Optional) Click the 3DSTACK Report tab to view the text report.
Tip: You can right-click a result in the detailed view for a context-sensitive highlight
menu:
The available menu items depend on the properties included with the result.
Results
You performed the following actions while completing this procedure:
• Viewed the LNC and SNC properties in the Calibre RVE display.
• Viewed the source and layout nets in the Internal Schematic Viewer.
• Highlighted the layout net in the layout viewer.
• Highlighted the result from the connected check in the layout viewer.
All these actions provide useful information for debugging a connectivity result in
Calibre 3DSTACK results.
Related Topics


Enable the Internal Schematic Viewer.
Calibre RVE includes an Internal Schematic Viewer which displays a rendered schematic view
for both source and layout. The Internal Schematic Viewer is disabled by default for
Calibre 3DSTACK results viewing.
Prerequisites
A Calibre 3DSTACK database opened in Calibre RVE, as described in “Highlighting DRC
Results from a Calibre 3DSTACK Run” on page 39.
Procedure
1. Click Setup > Options to open the Options tab.
2. Select the Schematic Viewer category.
3. Enable Show netlist schematics when highlighting connectivity objects.
4. Click Apply.
5. Select View > Schematics > All to open the layout and source netlists in the Internal
Schematic Viewer.
Tip
If you close the schematic views, you need to repeat this step to reopen them.
Results
When you highlight a net, device, instance, or pin, the design element is highlighted in both the
attached layout viewer and the Internal Schematic Viewer. The Internal Schematic Viewer is
displayed in a new window below the results and report tabs.
See “Internal Schematic Viewer” in the Calibre Interactive and Calibre RVE User’s Manual for
complete information.
Related Topics


Chapter 3
Using Calibre Interactive for
Calibre 3DSTACK
Calibre Interactive 3DSTACK is a graphical interface to the Calibre 3DSTACK verification

tool. It allows you to specify command line options and modify rule file statements that execute
desired Calibre 3DSTACK operations.
Calibre Interactive facilitates the following types of Calibre 3DSTACK verification operations:
• Chip assembly operations — Modify the layouts, assembly operations of the chip
stack, layers, and placements.
• Netlist specification — Specify a source netlist, verify its syntax, and export the
extracted connectivity of your stack.
• Text operations — Import, map, or modify text.
• Verification check selection — Select specific checks to execute in the verification run.
• Customization files — Customize panels in the GUI.
For detailed information on Setup Preferences for Calibre Interactive 3DSTACK, see “Setup
Preferences” in the Calibre Interactive and Calibre RVE User’s Manual.
Calibre Interactive 3DSTACK Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Set Up and Run Calibre 3DSTACK from Calibre Interactive . . . . . . . . . . . . . . . . . . . . 53
Invoking Calibre Interactive for Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Running Calibre 3DSTACK from Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Specify Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Specifying Anchor and Placement Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Specifying Text Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Specifying a Source Netlist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Excluding Pins from a Verification Run. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Specify Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Specifying Assembly Instructions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Selecting Specific Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Using Calibre Interactive for Calibre 3DSTACK
Calibre Interactive 3DSTACK Input
Writing a Calibre Interactive Customization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Triggers in Calibre Interactive 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Calibre Interactive 3DSTACK Input

The Calibre 3DSTACK rule file is required and defines all of the inputs used by Calibre
Interactive 3DSTACK.
Table 3-1 lists the files and a short description.
Table 3-1. Files Used by the Calibre Interactive 3DSTACK GUI

Name Description
Layout databases The layout databases, or designs, in GDS or OASIS format that
compose your 2.5D or 3D IC.
3DSTACK rule file A text input file you must create using commands in the Command
Reference chapter and supported Tcl statements.
3DSTACK Assembly An existing composite layout database (in GDS or OASIS format) of
(optional) your 3D IC. This database can be specified with the Use Generated
option when “Specifying Assembly Instructions” on page 74.
Source netlist The source netlist defines the connectivity of your IC. Use it to
(optional) enable advanced LVS debugging in Calibre RVE and in the
3DSTACK report file.
Netlist Configuration Defines pin connections between placements. This is used when
File (optional) generating a netlist file.
Text Label File Input files that contain text labels for placements or chips in the
(optional) design.
Calibre Interactive Runset file that contains saved preferences and settings for
Runset File (optional) Calibre Interactive.

Set Up and Run Calibre 3DSTACK from Calibre Interactive
Set Up and Run Calibre 3DSTACK from

Calibre Interactive
Verify your 2.5D or 3D IC using Calibre Interactive 3DSTACK.
To run Calibre 3DSTACK from the command line, refer to “Running a Calibre 3DSTACK
Verification from the Command Line” on page 32.
To see how Calibre RVE is used to view the verification results, refer to “Calibre 3DSTACK
Results Analysis Examples” on page 38.
Note
In the case of a conflict between commands in the rule file and Calibre Interactive, the
settings in Calibre Interactive take precedence.
Invoking Calibre Interactive for Calibre 3DSTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Running Calibre 3DSTACK from Calibre Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Invoking Calibre Interactive for Calibre 3DSTACK

Invoke Calibre Interactive for Calibre 3DSTACK. Calibre Interactive 3DSTACK can be
invoked from the command line or from Calibre DESIGNrev.
Prerequisites
Procedure
1. Start Calibre Interactive for Calibre 3DSTACK using any of the following methods:
• Enter the following command to invoke the Calibre Interactive GUI launcher:
calibre -gui
Click the 3DSTACK button shown in Figure 3-1.

Figure 3-1. Calibre Interactive GUI Launcher for Calibre 3DSTACK
• Enter the following command to directly invoke Calibre Interactive 3DSTACK:

calibre -gui -3dstack

Specifying and Loading a Rule File
• Select Verification > Run 3DSTACK from Calibre DESIGNrev.

operations. You may choose to continue without a runset by clicking Cancel, or load a
runset with the Browse (…) button.
Related Topics
Running Calibre 3DSTACK from Calibre Interactive

Specify and load the 3DSTACK rule file for a Calibre 3DSTACK verification run in Calibre
Interactive. A rule file is required for Calibre 3DSTACK.
Prerequisites
• You have completed the procedure “Invoking Calibre Interactive for Calibre
3DSTACK” on page 53.
• You have a valid Calibre 3DSTACK rule file. Refer to “Calibre 3DSTACK Rule File”
on page 27 for more details.
Procedure
1. Click on the Rules button in the left panel of the CI window and specify the path to your
Calibre 3DSTACK rule file and run directory (see Figure 3-2).
Figure 3-2. Specify Rule File and Run Directory
2. (Optional) Click the Load button to load instructions from the rule file and apply them
to the current Calibre Interactive session.

3. (Optional) If you prefer rule file loading to occur automatically when a runset is loaded
or the rule file is modified, follow these steps:
a. Select Setup > Preferences to open the Setup Preferences dialog box.
b. Select the Misc tab and enable the Automatically load rules file checkbox.
After loading a runset or modifying the rule file, Calibre Interactive option fields are
filled in using the specified rule file commands. If the Show Prompt checkbox is
enabled in the Setup Preferences dialog box, a confirmation window appears before
the rule file is loaded. Any errors in the rule file are reported.
If the rule file is not loaded and the Automatically load rules file checkbox is disabled,
Calibre Interactive options are not updated with commands from the rule file before a
Calibre 3DSTACK run.
Results
The paths to the Calibre 3DSTACK rule file and working directory have been specified. If
chosen, the Calibre 3DSTACK rule file was checked and loaded to fill in Calibre Interactive
GUI fields and verify the rule file syntax.
Once a rule file is specified, Calibre 3DSTACK can be executed. Refer to “Triggers in Calibre
Interactive 3DSTACK” on page 78 for complete details.
Related Topics
Specify Inputs
Specify Outputs

Run a Calibre 3DSTACK verification from Calibre Interactive.
Prerequisites
• You have specified a rule file as described in “Specifying and Loading a Rule File” on
page 54.
Procedure
1. Ensure that the input and output file options are correct (only a rule file is required) and
then click Run 3DSTACK. (see Figure 3-3).

Figure 3-3. Run 3DSTACK from Calibre Interactive
2. The Transcript appears automatically. The Transcript can be viewed after a run by
clicking the Transcript button on the left panel of the CI window to view the assembly
and runtime notifications (see Figure 3-4).
Figure 3-4. View Transcript Output in Calibre Interactive
3. After the Calibre 3DSTACK run completes, review the output report and transcript for
any issues.
Results
Your output directory now contains the assembled 3DSTACK layout view (if specified) and
results databases that can be opened in Calibre RVE. If specified, your run directory also
contains an extracted layout netlist and report file used to debug the verification results.

If you enabled the Check source netlist only option, a report file appears with the results of the
syntax check. No verification checks or assembly operations were performed.
To understand how to view and analyze the verification results produced by a
Calibre 3DSTACK run, refer to “Calibre 3DSTACK Results Analysis Examples” on page 38.
Related Topics
Specify Inputs
Specify Outputs

Specify Inputs
Specify Inputs
Specify inputs for a Calibre 3DSTACK verification run in Calibre Interactive.
Table 3-2 summarizes the options available under the Inputs pane. Some operations are required
in the rule file, but do not need to be modified in Calibre Interactive.
Table 3-2. Functions in the Inputs Pane for Calibre 3DSTACK

Tab Purpose Required
Layout Modify the layout design database and format. Modify layers No
and layer numbers for each chip in the stack. See “Modifying
Layouts and Layers” on page 59.
Placement Modify existing anchor and placement operations loaded No
from the rule file. See “Specifying Anchor and Placement
Operations” on page 61.
Texts Import text label files or rename text in the design. See No
“Specifying Text Operations” on page 64.
Netlist Specify the schematic source netlist. A source netlist is used No
when you want to perform advanced connectivity checking
between the extracted layout netlist and the specified source
netlist. See “Specifying a Source Netlist” on page 67.
Misc Exclude pins from a 3DSTACK verification. See “Excluding No
Pins from a Verification Run” on page 68.
In order to follow these procedures, you must meet these requirements:
• You have completed the procedure “Invoking Calibre Interactive for Calibre
• You have completed the procedure “Specifying and Loading a Rule File” on page 54.
Specifying Anchor and Placement Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Specifying Text Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Specifying a Source Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Excluding Pins from a Verification Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Modifying Layouts and Layers

Modify and view Layout database and layer information in Calibre Interactive. If the rule file
has been loaded, input fields are populated with values from the rule file. This procedure is
optional.
Procedure
1. Click on the Inputs button in the left panel of the CI window, if it is not already
selected.
2. Click on the Layout tab. If the rule file was previously loaded, layouts and layers
specified in your rule file are shown in the Layouts and Layers tables. If no information
appears, click the Rules button and select Load next to the specified rule file.
• Layouts are GDS or OASIS databases that are used to create your 3D IC stack. Refer
to the layout command in the “Command Reference” chapter for complete details.
• Layers are user-defined original layers in the design. Refer to the layer command in
the “Command Reference” chapter for complete details.

Figure 3-5. Modify and View Layout and Layer Information
3. To modify a Layout, select a row in the Layouts table and edit the desired entry. The
Layouts table has the following items:
• Chip Name — Read-only value of chip names specified in the rule file.
• Primary Cell — Specifies the top-level cell of the design.
• Layout Path — Specifies the path of the layout database.
• Format — Specifies that the layout is either GDSII or OASIS.
• Exclude Dies — Specify cells in the layout to exclude from the assembly.
• Interposer — Specifies that the layout is an interposer. This is used for hierarchical
netlist generation in 2.5D ICs. Only one chip can be an interposer. The other chips
are instantiated within the interposer chip when the netlist is generated.
4. (Optional) Enable the Export from layout viewer checkbox and specify a layout to
export from Calibre DESIGNrev if you are actively viewing a chip from your

Specifying Anchor and Placement Operations
Calibre 3DSTACK assembly. See “Running Calibre Interactive 3DSTACK From

Calibre DESIGNrev” on page 35 for complete details.
You can use file naming templates to customize the name of the files that
Calibre Interactive generates when exporting a layout from Calibre DESIGNrev. The
template preference settings are applied when you invoke Calibre Interactive from a
layout or schematic editor.
Templates are defined from the Templates tab of the Setup Preferences dialog box,
which is opened from Setup > Preferences in Calibre Interactive. See “Templates for
File Naming” in the Calibre Interactive and Calibre RVE User’s Manual for complete
details.
5. To modify a Layer, select a row in the Layers table and edit the desired entry. The
Layers table has the following items:
• Layer Name — Read-only value of a layer name specified in the rule file.
• Chip Name — Drop-down box used to select the desired chip name.
• Layer Numbers — Specifies layer numbers. Layer numbers are comma-separated.
• SVRF — Specifies SVRF statements. Cannot be used with the Layer Numbers
column. Statements entered in the row are translated to the -svrf layer_derivation
statement in the layer command. For example, entering “COPY A” in the SVRF
column is equivalent to specifying layer -svrf {COPY A} in your rule file.
• Level Number — Specifies the level number. The value can be any positive or
negative integer.
Note
You may not add or delete rows in the Layout or the Layers tables.
Results
The layers and layouts in your design have been viewed and modified. This procedure is
optional if the layout and layer commands in your rule file do not require modification.
Related Topics
Specify Inputs
Command Reference
Specify Outputs

Modify and view anchors and placement operations in Calibre Interactive. If the rule file has
been loaded, the fields are populated with values from the rule file. This procedure is optional.

Procedure
selected.
2. Click on the Placement tab to modify or add placements and anchors to the assembly
operations (see Figure 3-6). For details on these commands see anchor, place_layer, and
place_chip in the “Command Reference” chapter.
Figure 3-6. Modify Placements and Anchors in Calibre Interactive
3. To modify an Anchor, enable the Anchors checkbox, select a row in the Anchors table,
and edit the desired entry. The Anchors table has the following items:
• Use — Enables or disables an anchor. When checked, the anchor is created at run
time.
• Name — Specifies the name of the anchor. Each anchor name must be unique and
exist on the specified chip.
• Chip Name — Drop-down box used to select the desired chip name.
• X Offset — Floating-point number that specifies the x offset of the anchor.
• Y Offset — Floating-point number that specifies the y offset of the anchor.
The anchor table is the GUI equivalent of the anchor rule file command. Rows can be
added and deleted from the table.
4. To modify a Placement, select a row in the Placement table, and edit the desired entry.
The Placement table has the following items:
• Name — Read-only value that specifies the name of the placement loaded from the
rule file.

• Type — Specifies whether the placement is a Layer or a Chip.

• Chip/Layer Name — Drop-down box used to select the desired Chip or Layer
name.
• Placement Type — Specifies whether the placement is an Anchor or a Coordinate.
• X Offset — Floating-point number that specifies the x offset of the anchor. Only
enabled if the placement type is Anchor.
• Y Offset — Floating-point number that specifies the y offset of the anchor. Only
enabled if the placement type is Anchor.
• Anchor Placement Name — Optional value that specifies the name of an existing
placement specified in the rule file.
• Rotate — Optional integer value (in multiples of 90) that specifies the rotation value
to apply to the placement.
• Flip — Optional value that specifies the direction to flip the placement. The value
can be x, y, or NONE.
The Placement table is the GUI equivalent of the place_layer and place_chip rule file
commands. Rows cannot be deleted or added to the Placement table.
5. To map placements to source names, enable the Map Placements checkbox and edit the
table. The layout and source names on each row are treated as the same object. The Map
Placements table has the following items:
• Use — Enable the row.
• Layout Placement Name — Dropdown list that contains all placement names
loaded from the rule file.
• Source Placement Name — Dropdown list that contains all source names from the
source netlist (see “Specifying a Source Netlist” on page 67).
The Map Placements table is the GUI equivalent of the map_placement rule file
command.
Results
The anchor and placement operations have been modified using Calibre Interactive. This
procedure is optional if the anchor and placement commands in your rule file do not require
modification.
Related Topics
Specify Inputs
Command Reference
Specify Outputs

Specifying Text Operations
Specifying Text Operations

Specify text operations in Calibre Interactive.
The Texts tab of the Inputs pane allows you to specify text options and modify the
import_text_labels and rename_text rule file commands. If the rule file has been loaded, the
fields are populated with values from the rule file.
Procedure
selected.
2. Click on the Texts tab to modify or view specified text operations (see Figure 3-7).
Figure 3-7. Modify Text in Calibre Interactive
3. Enable the Import Text Labels checkbox, select a row in the Text Labels table, and edit
the desired entry. The Text Labels table has the following items:
• Use — Enables or disables the import of a text label file. When checked, the text file
is imported at run time.
• File Name — Specifies the pathname of an existing text file containing custom text
labels. The value turns green when a valid file is specified.
• Chip Name — Drop-down box used to select the desired Chip.
If the Import Text Labels checkbox is unchecked, no text labels are imported at run
time (the import_text_labels command is ignored).

Creating a Source Netlist
4. Enable the Rename Texts checkbox, select a row in the Rename Texts table, and edit
the desired entry. The Rename Texts table has the following items:
• Use — Enables or disables the rename text operation. When checked, the text
operation is applied at run time.
• Type — Specifies whether the object is a placement or a chip.
• Chip/Placement Name — Specifies an existing chip or placement in your design.
• Pattern — Specifies a GNU regular expression. See Table 4-6 on page 132 and the
rename_text command for complete details.
If the Rename Texts checkbox is unchecked, no text is renamed at run time (the
rename_text command is ignored).
5. Enable the Attach Texts checkbox, select a row in the table, and edit the desired entry.
The Attach Texts table is only active if the attach_text command was specified in a rule
file that is currently loaded in Calibre Interactive.
Results
Text operations have been specified and modified using Calibre Interactive. This procedure is
optional if the text in your design does not require modification.
Related Topics
Specify Inputs
Command Reference
Specify Outputs

Use Calibre Interactive to generate a netlist based on specified options if you do not have a
complete source netlist for your 3D assembly.
Prerequisites
• Source netlists for each chip in your stack.
Procedure
1. Select the Rules button in the left panel of the CI window, define the path to your rule
file, and click Load.
2. Chose Setup and enable the 3DSTACK options checkbox.
3. Click on the 3DSTACK Options button and select the Netlist tab (see Figure 3-8).

Figure 3-8. Create Source Netlist With Calibre Interactive
4. Enable the Generate Netlist File checkbox.

5. Specify the path to an existing configuration file that defines the pin connectivity
between placements. The configuration file uses the syntax of a System Netlist
Generator configuration file except that it only contains the CONNECTIVITY
statement’s placement and pin mapping lists. See “System Netlist Generator
Configuration File Format” on page 251 for more details.
The following example connects two pins on two placements together:
CONNECTIVITY {
place_1 {pin_a clk} place2 {connect_to_a connect_to_clk}
}
All pins for each placed chip must be connected. Any unconnected pins are reported as
errors.
6. Click Run 3DSTACK.
The configuration file and your defined placements are passed to the System Netlist
Generator tool. The System Netlist Generator uses the given information to generate a
source netlist for your assembly.
Results
You have created a source netlist for your 3D assembly by defining connectivity in a
configuration file. Calibre 3DSTACK passes this information to the System Netlist Generator
and generates a source netlist for your design. The netlist is used in the verification run to
perform LVS.
Related Topics
Specifying a Source Netlist
CONNECTIVITY

System Netlist Generator Configuration File Format

Define and check a source netlist in Calibre Interactive. A source netlist defines the connectivity
of your 3D IC. If a source netlist is specified, the connectivity can be traced and compared to the
extracted layout netlist. This procedure is optional.
Procedure
1. Click on the Inputs button in the left panel of the CI window and select the Netlist tab
(see Figure 3-9).
Figure 3-9. Specify Source Netlist Options in Calibre Interactive
2. Enable the Source Netlist checkbox

3. Specify the format of the netlist file using the Format dropdown box. The format must
be SPICE or MGC.
4. (Optional) Enable the Case Sensitivity checkbox if your source netlist file is
case-sensitive.
5. (Optional) Enable the Hierarchical checkbox if the source netlist is hierarchical. See
sng for information on creating a hierarchical source netlist.
6. Specify the path to your netlist file using the 3D Netlist File field. If necessary, select the
View button to view or modify your source netlist.
7. To verify the syntax of the source netlist file and validate placement operations without
executing a full verification run, enable the Check source netlist only checkbox and
click Run 3DSTACK.

Excluding Pins from a Verification Run
Calibre 3DSTACK displays a report file that summarizes the results of the syntax check
of your source netlist file. It also reports any invalid placements found in the assembly.
Caution
When you are ready to run a full verification on your 3D IC, disable the Check
source netlist file only checkbox before clicking Run 3DSTACK.
Results
A source netlist file has been specified and checked for syntax errors and placement issues. A
source netlist allows you to perform advanced connectivity debugging with your DFMDB
verification results. For complete details, see “Debugging Connectivity Errors in Calibre
If your source netlist was clean, the report contains the following text:
*************************************************************************
OVERALL SYNTAX CHECK RESULTS
*************************************************************************
####################
# #
# SYNTAX OK #
# #
####################
Any syntax error is reported as follows:

*************************************************************************
OVERALL SYNTAX CHECK RESULTS
*************************************************************************
# # #########################
# # # #
# # SYNTAX CHECK FAILED #
# # # #
# # #########################
Syntax errors were found in the source.
Related Topics
Specify Inputs
Command Reference
Specify Outputs

Filter pins from a verification run.

Pin exclusion operations can be defined or modified in Calibre Interactive. If the rule file has
been loaded, the fields are populated with values from the rule file.
Procedure
selected.
2. Click on the Misc tab to specify pins to ignore during the assembly operations (see
Figure 3-10). For details on this command see ignore_pin in the “Command Reference”
chapter.
Figure 3-10. Modify the ignore_pin Command in Calibre Interactive
3. Enable the Ignore Pins checkbox and edit the desired entry. The Ignore Pins table has
the following items:
• Use — Enables or disables the rename text operation. When checked, the ignore pin
operation is applied at run time.
• Layer Placement Name — Specifies an existing layer placement in your design.
• Regexp — Specifies a regular expression string that selects pins to ignore. See
Table 4-6 on page 132 and the rename_text command for complete details on
specifying regular expressions. The text in the row is red if the entry is invalid.
Rows can be added or deleted from the table if the rows above are complete by clicking
in the empty space, or pressing the down arrow. If the Ignore Pins checkbox is
unchecked, no pins are ignored at run time (the ignore_pin command is not executed).
Results
The ignore pin operations have been modified using Calibre Interactive.

Related Topics
Specify Inputs
Command Reference
Specify Outputs

Specify Outputs
Specify Outputs
The outputs pane of Calibre Interactive allows you to specify the files and paths for the
verification output.
Table 3-3. Outputs Pane for Calibre 3DSTACK

Tab Purpose Required
Reports Specify the results database and reporting options. See No
“Specifying Report and Results Options” on page 71.
Export Specify netlist and layout files to extract from the generated No
Data layout. See “Exporting Connectivity and Templates” on
page 73.
In order to follow these procedures, you must meet these requirements:
• (Optional) Your rule file contains the export_connectivity command to specify layout
netlist extraction.
• (Optional) Your rule file contains the export_template command to save specified layout
databases.
Specifying Report and Results Options

Specify the path and location of the results database and Calibre 3DSTACK report file. Report
files are very useful for debugging runs. This procedure is optional.
Procedure
1. Click on the Outputs button to specify optional reporting and output files (see
Figure 3-11).

Specifying Report and Results Options
Figure 3-11. Specify Outputs in Calibre Interactive
2. Enable the Show results in RVE checkbox under the Reports tab to display results in
Calibre RVE following a Calibre 3DSTACK run. This checkbox is disabled if the
Create Only operation is selected under Setup > 3DSTACK Options.
3. Specify a CTO file that controls how Calibre RVE displays rule check results. See
“Check Text Override Comments for Calibre 3DSTACK” on page 177 for details on
this file.
4. Enable the Generate child RDBs checkbox and use the table to select additional RDBs
that you want to generate. These databases are produced by Calibre 3DSTACK and are
opened along with 3dstack.rdb when the run completes.
5. Enable the Write 3DSTACK Summary Report File checkbox and specify a pathname
for the report. You may limit the number of results per check in the report by selecting
the User Specified checkbox and entering a positive integer value.
The report file contains important information about the design and verification results.
Enabling this option is highly recommended.
Results
The results database file and directory have been specified. These files contain verification
results used by Calibre RVE. Additionally, a report file and reporting options have been
specified.
Related Topics
Specify Inputs
Command Reference

Exporting Connectivity and Templates
Specify Outputs
Exporting Connectivity and Templates

Specify or view the paths, filenames, and formats of extracted netlists and templates. Extracted
layout netlists are used to debug the connectivity of your assembled 3D IC. Templates are saved
layouts from your 3D IC. This procedure is optional.
Procedure
1. Click on the Outputs button (see Figure 3-11).
2. Select the Export Data tab.
3. Enable the Export Connectivity Information checkbox. If the rule file was loaded,
netlists specified with the export_connectivity are listed in the table (see Figure 3-12).
4. Modify the filename or format as necessary. If the Use checkbox is disabled, the file in
that row is not generated at run time.
Figure 3-12. View Connectivity Files for Export in Calibre Interactive
5. To modify and view output layout files specified with the export_template rule file
command, enable the Export template checkbox under the Export Data tab of the
Outputs pane. Use this table to verify or modify the specified output layout database
filenames and formats.
The “Type”, “Chip/Placement Name”, “Clip”, and “Neighbors and bumps” options in
the Export Template table allow you to generate a placement or chip that includes
surrounding layers. See export_template for a description of the options.

Specifying Assembly Instructions
Results
The extracted netlist and template files have been specified. Next, follow the procedure
“Specifying Assembly Instructions” on page 74.
Related Topics
Specify Inputs
Command Reference
Specify Outputs
Specifying Assembly Instructions

Specify the assembly instructions to apply at run time.
Prerequisites
Procedure
1. From Calibre Interactive, select Setup and enable 3DSTACK Options (see Figure 3-13).
Figure 3-13. Specify the Assembly Operations in Calibre Interactive
2. Click the 3DSTACK Options button on the left pane of Calibre Interactive and specify
the assembly operations to apply at run time.
The assembly options define how Calibre 3DSTACK uses or generates the 3DSTACK
assembly view file. The assembly options in Calibre Interactive behave as follows:
• Create & Use — Calibre 3DSTACK generates a 3DSTACK assembly file
internally and uses it in a verification run. This option invokes Calibre 3DSTACK
without the -create_assembly and -use_assembly options, which is the default mode.

Selecting Specific Checks
See “Calibre 3DSTACK Invocation” on page 23 for a description of the assembly

command options.
• Create Only— Calibre 3DSTACK generates a 3DSTACK assembly file and
exports template files without executing any further operations (no verification run
is performed). This is the same as invoking Calibre 3DSTACK from the command
line with the -create_assembly option. If this option is selected, the Show results in
RVE checkbox is disabled.
• Use Generated — Calibre 3DSTACK uses an existing assembly file for the
verification run. This is the same as invoking Calibre 3DSTACK with the
-use_assembly option. When this option is enabled, the Top Cell and Format fields
are disabled.
The Top Cell field allows you define the top cell of the 3D layout. The File field
specifies the path to the assembly file.
Results
The assembly file operations have been defined.
Related Topics
Specify Inputs
Command Reference
Specify Outputs
Selecting Specific Checks

Select specific checks for a verification run.
Prerequisites
Procedure
1. Select Setup > Select Checks. The Select Checks dialog box opens. Checks in the
Groups area are grouped by type and placement—expand the hierarchy as needed.

Writing a Calibre Interactive Customization File
Figure 3-14. Select Specific Verification Checks in Calibre Interactive
2. Click the checkbox next to the check name or check group to enable or disable the
checks at run time. A green check mark indicates that the check is enabled, a red cross
indicates that the check is excluded.
Note
Use the View menu to sort the checks and groups. Use the Select menu to toggle
check selection.
Results
Checks to execute at run time have been specified. The selections made in the Select Checks
dialog box are not saved to the Calibre Interactive runset file.
Next, follow the procedure “Writing a Calibre Interactive Customization File” on page 76.
Related Topics
Specify Inputs
Specify Outputs
Command Reference
Writing a Calibre Interactive Customization

File
Write a Calibre Interactive Customization settings file.
Customization files are fully supported in Calibre Interactive 3DSTACK. See “Customization
Files” in the Calibre Interactive and Calibre RVE User’s Manual for more details.

Writing a Calibre Interactive Customization File
Procedure
1. Open Calibre Interactive for Calibre 3DSTACK and load a rule file. For details, see
“Invoking Calibre Interactive for Calibre 3DSTACK” and “Specifying and Loading a
Rule File.”
2. Create a new text file called select_checks.tcl in your working directory and insert the
following text:
set _customMaster_0 [CUSTOM::VARIABLE -name "select_by" -choices \
{{"All checks" 0} {"by group" 1} } -initval {1} -select 1 -boolean 0 \
-prompt "select checks by:" -display 1 -tool 3DSTACK ]
CUSTOM::LABEL -prompt "Select checks by group " -tool 3DSTACK \
-master [list $_customMaster_0 1]
CUSTOM::CHECK -name "connected" -choices {connected} -initval {connected}\
-select 1 -boolean 1 -prompt "connected" -display 1 -tool 3DSTACK \
CUSTOM::CHECK -name "internal" -choices {internal} -initval {internal} \
-select 1 -boolean 1 -prompt "internal" -display 1 -tool 3DSTACK \
CUSTOM::CHECK -name "external" -choices {external} -initval {external} \
-select 0 -boolean 1 -prompt "external" -display 1 -tool 3DSTACK \
CUSTOM::CHECK -name "enclosure" -choices {enclosure} -initval {enclosure}\
-select 0 -boolean 1 -prompt "enclosure" -display 1 -tool 3DSTACK \
Save the file and close it.

3. In Calibre Interactive, select Setup > Preferences and enable the Customization File:
checkbox. In the file field, browse to the path where you saved the select_checks.tcl file.
Click OK.
A new Customization button appears under the Transcript button on the left panel of
Calibre Interactive.
4. Click on the Customization button. The select_checks.tcl file, shown in Step 2, enables
modification of the select checks command (see Figure 3-15). Choose the checks to
include in the verification run and click OK to close the dialog box.

Triggers in Calibre Interactive 3DSTACK
Figure 3-15. Customization Settings in Calibre Interactive
5. Click Setup > Select Checks to verify that the checks have been selected as intended.
Results
A Calibre Interactive customization file has been created and used to modify the select checks
command. This particular example is useful for saving select check options after
Calibre Interactive is closed.
In this case, if you choose the All Checks option, no commands are added to the control file,
and therefore all checks are run. If you choose the By Group option, you may choose to select
checks by the type of rule check.
Use this example to create your own customization file for Calibre Interactive.
Related Topics
Specify Inputs
Command Reference
Specify Outputs

Custom trigger usage in Calibre Interactive.
Calibre Interactive provides the ability to specify and run pre- and post-execution internal
triggers. A trigger can be any program or script executed from a shell. The trigger program is
run immediately before or after a batch Calibre 3DSTACK run. For complete information on
Calibre Interactive triggers, see “Trigger Functions in Calibre Interactive” in the
Calibre Interactive and Calibre RVE User’s Manual.

To access the Trigger options in Calibre Interactive 3DSTACK, select Setup > Preferences and
click on the Triggers tab. The following trigger parameters are available.
Table 3-4. Supported Trigger Parameters

Parameter Runtime Replacement
%r Calibre 3DSTACK rule file
%R Calibre Interactive runset file
%t Top cell of the 3D assembly
%e Calibre termination status
%P Netlist placement table content (Inputs>Netlist
tab)
%d Run directory
%m Calibre 3DSTACK report file
%C System Netlist Generator Configuration file
%n 3D Netlist file
Related Topics
Specify Inputs
Command Reference
Specify Outputs


Chapter 4
Command Reference
The Calibre 3DSTACK rule file uses its own set of commands to assemble and verify your 3D-
IC design intent.
The commands listed in the following table use the syntax conventions outlined in the following
table.
Table 4-1. Calibre 3DSTACK Full Command List

Name Description
System and Miscellaneous Commands that specify the verification inputs, outputs, and
Commands run control options.
Assembly Commands Commands that specify assembly operations for the chip
stack.
Rule Check Commands Commands that specify rule checks for the verification run.
Calibre RVE Commands Commands that control Calibre RVE results.

Command Reference
System and Miscellaneous Commands

Commands that specify the verification inputs, outputs, and run control options.
Table 4-2. System Control and Miscellaneous Commands

Name Description
assembly_path_extension Sets the severity of circular GDS path extension errors.
export_connectivity Exports the connectivity information into a netlist file.
export_template Exports a specified chip or placement from the stack into a
GDS or OASIS file.
layer_props_file Specifies a layer properties file for Calibre DESIGNrev that
sets custom layer visibility options.
report Generates a report file that contains information about the
verification run. This is useful for debugging the design.
run Runs Calibre using the specified rule file and command-line
options.
set_version Sets the syntax version of the Calibre 3DSTACK rule file.
source_filter Applies filtering options to the imported source netlist file.
source_netlist Imports a source netlist file used for connectivity
comparison. It is highly recommended that you use a source
netlist during the verification of your assembly.

Command Reference
assembly_path_extension
assembly_path_extension
Sets the severity of circular GDS path extension errors.
Usage
assembly_path_extension value
Arguments
• value
Required integer between 0 and 8. See PATH_CIRCULAR in the “Exceptions for Layout
Input Exception Severity” table of the SVRF Manual.
Examples
assembly_path_extension 8

Command Reference
export_connectivity
export_connectivity
Exports the connectivity information into a netlist file.
Usage
export_connectivity -file file_name [-format {VERILOG | SPICE | MGC}]
[-hier [-no_top] [-pkg package_name]]
Arguments
• -file file_name
Required argument and value set that specifies the name of the output file.
• -format {VERILOG | SPICE | MGC}
Optional argument set that specifies the format to write to the output file (the default is
VERILOG).
• -hier
Optional argument that specifies to generate a hierarchical netlist for 2.5D ICs. This option
only works with -format SPICE. You must also specify layout -interposer for one of the
imported chips.
When the -interposer argument is applied to a layout and the -hier option is used, the
generated netlist instantiates all dies within the layout instance specified by -interposer. The
top cell of the assembly only contains the instantiated interposer die. The net names are
generated from the interposer pin names.
• -no_top
Optional argument that specifies not to create a new top cell for the entire design. This
option requires -hier to be specified.
• -pkg package_name
Optional argument that specifies a package layout in the design. The layout must not be an
interposer. The specified package_name must have at least one layer defined in the
connectivity stack. This option requires -hier to be specified.
Description
Exports connectivity information to a file_name in the specified format (Verilog, SPICE, or
MGC).
The MGC format contains a list of add_connection directives that describe single connections in
the 3D assembly:
add_connection -connection1 {placement1 cell1 net1 pin_instance_name1}

-connection2 {placement2 cell2 net2 pin_instance_name2}

Command Reference
export_connectivity
Warnings are issued for single-port connections (nets connected to one port only) in the
extracted netlist.
Caution
There should not be spaces in cell or pin names as this causes the exported netlist to be
incorrect. For pins, the tool creates multiple pins in such a case. The export_connectivity
command issues a warning for these cases.
Examples
Example 1
Consider the chip stack shown in Figure 4-1. In this chip stack, two layouts (chip1 and chip2)
are arranged such that they overlap. Polygons on each layout contain text objects labeled net1
through net4.
Figure 4-1. Connectivity Export Example

Command Reference
export_connectivity
The chip stack rule file for this example is shown as follows:
set_version -version 1.0
#define layouts
layout -chip_name c1 -primary TOPCELL -path ./chip1.gds -system GDS
#write SPICE, Verilog, and MGC netlists for the design

export_connectivity -file spice.out -format SPICE
export_connectivity -file verilog.out -format VERILOG
export_connectivity -file mgc.out -format MGC
#define layers and place chips

layer -layer m1 -chip c1 -layer_number 0
place_chip -placement c1p -chip c1 -x_origin 0 -y_origin 0

#define connectivity
connect c1p_m1 c2p_m2
connected -check_name con_check -placement1 c1p_m1 \

-text_placement1 c1p_m1 -placement2 c2p_m2 -text_placement2 c2p_m2
The export_connectivity commands in this file generate three output files. These files, which
are written in the SPICE, Verilog, and MGC formats, contain the connectivity information for
the chip stack. The contents of these files are shown as follows:
• SPICE
.SUBCKT TOPCELL_3DIC
Xc1p 4 3 2 1 TOPCELL
.ENDS TOPCELL_3DIC
.SUBCKT TOPCELL net1 net2 net3 net4

.ENDS TOPCELL
• VERILOG

Command Reference
export_connectivity
module TOPCELL_3DIC (
) ;
wire 4 ;
wire 1 ;
wire 2 ;
wire 3 ;
TOPCELL c1p (
.net1 (4) ,
.net2 (3) ,
.net3 (2) ,
.net4 (1)) ;
TOPCELL c2p (
.net1 (4) ,
.net2 (3) ,
.net3 (2) ,
.net4 (1)) ;
endmodule
module TOPCELL (
net1 ,
net2 ,
net3 ,
net4) ;
inout net1 ;
inout net2 ;
inout net3 ;
inout net4 ;
endmodule
• MGC
add_connection -connection1 {c1p TOPCELL net1 net1} -connection2\
{c2p TOPCELL net1 net1}

Command Reference
export_connectivity
Example 2
This example demonstrates the export_connectivity -hier option. Assume you have the
following chips in your assembly:
layout -chip_name interposer -primary interposer -path interposer.gds \

-system GDS -original_extent -interposer
layout -chip_name controller -primary controller -path controller.gds \

-system GDS -original_extent
layout -chip_name ram -primary ram -path ram.gds -system GDS \

-original_extent
Note that the -interposer option was applied to the interposer die. The top cell of the assembly is
called TOP_CELL:
layout_primary TOP_CELL
After assembling your 2.5D IC, you export the two SPICE netlists; one with -hier option:
export_connectivity -file output/3dstack_hier.sp -format SPICE -hier

export_connectivity -file output/3dstack_no_hier.sp -format SPICE
The two netlists are shown side-by-side for comparison:
Table 4-3. export_connectivity -hier

3dstack_hier.sp 3dstack_no_hier.sp
.SUBCKT TOP_CELL .SUBCKT TOP_CELL
XpInterposer XpInterposer
… interposer … interposer
.ENDS TOP_CELL XpController
… controller
XpRam0
.SUBCKT controller … ram
… XpRam1
.ENDS controller … ram
.ENDS TOP_CELL
.SUBCKT ram
…
.ENDS ram .SUBCKT controller
…
.ENDS controller
.SUBCKT interposer
… .SUBCKT ram
XpController …
… controller .ENDS ram
XpRam0
… ram .SUBCKT interposer
XpRam1 …
… ram .ENDS interposer
.ENDS interposer

Command Reference
export_connectivity
Without -hier, all chips in the assembly are instantiated in the TOP_CELL. With -hier, the chips
that are not interposers are instantiated within the interposer.
Related Topics
Assembly Commands
Rule Check Commands
Calibre RVE Commands

Command Reference
export_template
export_template
Exports a specified chip or placement from the stack into a GDS or OASIS file.
Usage
export_template {-chip chip_name } | {-placement placement_name
{[-neighbor layer [-bump value]] … } [-clip distance] } -file output_file
[-system {GDS | OASIS}]
Arguments
• -chip chip_name
Argument and value set that specifies the chip name to export (chip names are defined using
the layout command). You must specify either this argument or the -placement argument.
The layer properties and layer map files are generated when export_template -chip is
specified in your rule file.
• -placement placement_name
Argument and value set that specifies an existing placement in the assembly to export. You
must specify either this argument or the -chip argument. The layer properties and layer map
files are generated when export_template -placement is specified in your rule file.
• -neighbor layer …
Optional argument set that specifies a layer in the assembly to export with the specified
placement. Multiple layers require a separate -neighbor layer argument pair for each layer.
This option can only be used with the -placement argument.
• -bump value
Optional argument set that increments the layer number of the layer by an integer value.
This argument can be specified for each -neighbor layer pair.
• -clip distance
Optional argument set that specifies a clipping distance in microns around the chip extent to
exclude from the exported layout. The -clip argument accepts positive floating-point
numbers and can only be specified once for each export_template command.
• -file output_file
Required argument and value set that specifies the name of the output file. Each application
of the export_template command requires a unique output_file name.
Optional argument that specifies the layout system. The default is GDS.
Description
Exports the specified chip or placement from the 3D assembly to a GDS or OASIS file. Layers
are written (with their original layer numbers) only if they are declared in layer commands for
the specified chip_name. The output file is written using the precision of the input files. See the

Command Reference
export_template
layout command for information on precision handling within Calibre 3DSTACK. Empty
layers are supported. Layermap and layer properties files for Calibre DESIGNrev are exported
automatically using the same naming convention.
Examples
Example
Export a GDS for the controller chip in the assembly.
layout -chip_name controller -primary controller \

-path ${dsn_dir}/controller.gds -system GDS -original_extent
…
export_template -chip controller -file controller_export.gds -system GDS
The exported layout contains the layout of the controller chip as shown in the following figure.
In this example, the original controller only contains pad shapes.
Example
Export a GDS for the placement of the controller chip in the assembly. This example also
specifies to include some of the surrounding interconnect layers on the interposer. The -bump
argument for each included layer increments the layer number by the specified integer value.

place_chip -placement pController -chip controller \

-x_origin $controller_x -y_origin $controller_y
export_template -file pController.gds -system GDS -placement pController \

-neighbor pInterposer_RDL_M1 -bump 50 -neighbor pInterposer_RDL_V1 \
-bump 100 -neighbor pInterposer_RDL_M2 -neighbor pInterposer_RDL_M3

Command Reference
export_template
Example
Export an OASIS layout for the placement of the controller chip in the assembly. This is the
same as the previous example, except that the included layers are clipped at 15 um from the
edge of the controller placement.
export_template -file pController_clipped.oas -system OASIS \

-placement pController -neighbor pInterposer_RDL_M1 -bump 50 \
-neighbor pInterposer_RDL_V1 -bump 100 -neighbor pInterposer_RDL_M2 \
-neighbor pInterposer_RDL_M3 -clip 15
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
layer_props_file
layer_props_file
Specifies a layer properties file for Calibre DESIGNrev that sets custom layer visibility options.
Usage
layer_props_file props_file
Arguments
• props_file
Required path to a layer properties file. See the “Description” section for details.
Description
The specified props_file defines the properties of the layers used in Calibre DESIGNrev and
follows this format:
layer_name layer_color layer_fill layer_visibility layer_width
where:
• layer_name — is an alphanumeric string specifying the name of the layer.

• layer_color — is any valid Tcl color name.
• layer_fill — is one of the following fill types:
clear diagonal_1 diagonal_2

wave brick circles
speckle light_speckle solid
• layer_visibility — Specifies whether the layer is visible. The layer_visibility must be

one of the following:
o 0 — the layer is not visible.
o 1 — the layer is visible.
• layer_width — an integer greater than 1 that specifies the line width of the polygon
outline on that layer.
Examples
layer_props_file assembly.layerprops

Command Reference
layer_props_file
where assembly.layerprops is written as follows:
controller1 blue speckle 1 1

ram_1 yellow diagonal_1 1 1
ram_2 red wave 1 1
...

Command Reference
report
report
Generates a report file that contains information about the verification run. This is useful for
debugging the design.
Usage
report -file report_file [-max_results value] [-child_rdbs {no | yes}]
Arguments
• -file report_file
Required argument set that specifies the name of the output file.
• -max_results value
Optional argument set that limits the number of reported results (per check) to the number
specified with the value keyword. The max_results argument applies to each check in the
rule file. The value keyword must be a positive integer, unless “all” is specified. If value is
set to “all”, no limitation is applied to the report command. The default is 50.
• -child_rdbs {no | yes}]
Optional argument set that specifies whether to generate results databases for each chip in
the stack. Specify yes to generate child RDBs for all chips in the design. The default is no.
Description
Generates a file containing a report of the run. The format of the report is similar to the reports
for Calibre nmLVS and Calibre PERC runs. Refer to Report File Format for an example.
The following sections are only generated when a source_netlist command is present in the chip
stack rule file:
• Layout pads missing source ports.

• Source ports missing layout pads.
• Incorrect nets.
• Connectivity rulecheck results.
Errors are reported only for connected checks. Errors for other verification commands (internal,
external, and copy) are not included in the report.
Examples
Use the following command to generate a report file with no reported result limitations.
report -file report.txt -max_results all
Use this command to limit the reported results for each rule check to a maximum of 30.

Command Reference
report
report -file report.txt -max_results 30 -child_rdbs yes
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
run
run
Runs Calibre using the specified rule file and command-line options.
Usage
run {-drc | -lvs | -perc | -xrc} -directory run_dir -rule_deck rules [-run_options options]
Arguments
• -drc | -lvs | -perc | -xrc
Required argument set that specifies the type of Calibre run to perform.
• -directory run_dir
Required argument and value set that specifies the path to the run directory. Output files
from the run are written to this directory.
• -rule_deck rules
Required argument and value set that specifies the path to the rule file (see “Calibre
3DSTACK Rule File” on page 27 for details on 3DSTACK rule files).
• -run_options options
Optional argument and value set that specifies command-line options for the run. Multiple
command-line options must be enclosed in quotes.
Description
Runs Calibre nmDRC, Calibre nmLVS, Calibre PERC, or Calibre xRC using the specified rule
file and command-line options. The specified Calibre run is done before the Calibre 3DSTACK
run.
Examples
run -drc -directory ./DRC \
-rule_deck ./n45_m.rules -run_options “-turbo -hier”
run -lvs -directory ./LVS \

-rule_deck ./LVS/n45_l.rules -run_options “-turbo -hier”
run -perc -directory ./PERC \

-rule_deck ./n22.rules -run_options "-turbo -hier"
run -xrc -directory ./XRC \

-rule_deck ./rules_xcalh -run_options "-fmt -all"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
run

Command Reference
set_version
set_version
Sets the syntax version of the Calibre 3DSTACK rule file.
Usage
set_version -version version
Arguments
• -version version
Required argument and value set that specifies the version of the rule file syntax. Currently,
the only valid value for version is “1.0”.
Description
Specifies the version of the rule file syntax. This command must appear once in your rule file.
Examples
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
source_filter
source_filter
Applies filtering options to the imported source netlist file.
Usage
source_filter -chip chip_name
{-subckt subckt_name -short_pins ‘{’pins‘}’ } |
{ -short_device ‘{’device_type‘}’ [-short_pins ‘{’pins‘}’] [-constraint “expression”] }
Arguments
• -chip_name chip_name
Required argument and value set that specifies a chip name that can be referenced in other
commands. If this command is used multiple times, each chip_name must be unique.
• -subckt subckt_name
Required argument and value set if -short_device is not specified. When -subckt is
specified, all the instantiations of the specified subcircuit are filtered by shorting the nets
connected to specified pins.
• -short_pins ‘{’pins‘}’
Required when -subckt is specified, optional when -short_device is specified. When
-short_device is specified, all the instantiations of the specified device matching with the
constraint (if specified) are filtered by shorting the nets connected to the device pins.
If a device or subckt does not have specified pins given by the -short_pins argument, then
filtering is not applied.
• -short_device ‘{’device_type‘}’
Required argument and value set if -subckt is not specified. Use this to specify that all
instantiations in the device_type list that match the constraint (if specified with the -
constraint expression) are filtered by shorting the nets connected to the device pins.
Optionally, if -short_pins is specified with -short_device, then the nets connected to the
specified pins of the device are also shorted.
Model-based filtering for devices can be achieved by specifying the device name followed
by the model name enclosed with ‘(’ and ‘)’.
• -constraint “expression”
Optional argument and value set that specifies a constraint expression. A single constraint
expression can only be applied to one chip and subckt pair, otherwise an error is issued.
The filtering expression should adhere to the following format:
-constraint “property_name condition value”
When -constraint is specified, the properties used in the filtering expression should be
defined in the source SPICE file, otherwise filtering is not applied.

Command Reference
source_filter
Description
Use this command to define filtering options for the source netlist data imported for a
Calibre 3DSTACK verification run. When the source_filter command is applied, a new SPICE
file containing the “filtered” data is generated and stored in the 3dstack DFM database
directory. Calibre 3DSTACK run info data used by Calibre RVE is automatically updated with
the path of the new SPICE file.
The report file contains a separate section describing the source filtering options.
Note
Filtering is applied for all specified subcircuits or devices regardless of the context (chip
specified by -chip argument). The source_filter command only accepts netlist files
formatted in SPICE. If a non-SPICE netlist is detected, a warning is issued.
The source_filter command is not supported if the source_netlist command includes the -hier
argument specifying a hierarchical source netlist and white box analysis.
Examples
Example 1
Apply filtering by shorting pins, bottom and top, in the tsv subcircuit on the interposer chip.
-source_filter -chip interposer -subckt tsv -short_pins {bottom top}
Example 2
Apply filtering by shorting device, R(SH), and pins, p and n, on the interposer chip that meet a
constraint of resistance, R, equal to zero.
source_filter -chip interposer -short_devices {R(SH)} -short_pins {p n} \

-constraint "R == 0"
Example 3
Different constraint expression examples. See the -constraint argument for a description of the
required format.
source_filter -chip i -short_devices {R(SH)} -constraint "R >= 0"

source_filter -chip i -short_devices {R(SH)} -constraint "R == 10"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
source_netlist
source_netlist
Imports a source netlist file used for connectivity comparison. It is highly recommended that
you use a source netlist during the verification of your assembly.
Usage
source_netlist -file file_name -format {SPICE | MGC} [-hier] [-case {NO | YES}]
Arguments
• -file file_name
Required argument and value set that specifies the name of the source netlist file.
• -format {SPICE | MGC}
Required argument and value set that specifies the format of the input file.
The MGC format contains a list of add_connection directives that describe single
connections in the 3D assembly:
add_connection -connection1 {placement1 cell1 net1 pin_instance_name1} \
-connection2 {placement2 cell2 net2 pin_instance_name2}
• -hier
Optional argument that specifies the source netlist is hierarchical.The source netlist format
must be SPICE if -hier is specified.
• -case {NO | YES}
Optional argument and value set that controls whether the source netlist file is handled as
case-sensitive or not. Note that this option only applies to the source netlist file. The default
value is NO (the file is handled regardless of case).
Description
Imports connectivity information from the specified file_name.
If there are connected commands specified in the chip stack rule file, the imported connectivity
information is checked against the netlist information extracted from the chip stack. If your
source netlist file is case-sensitive, specify the -case YES option.
Specify the -hier option if the source netlist is hierarchical. The source_filter command is not
supported when the -hier argument is used. See the sng command for information on generating
a hierarchical source netlist.
You can create a source netlist using the System Netlist Generator. See “System Netlist
Generator Example” on page 230.

Command Reference
source_netlist
Examples
Consider the chip stack shown in Figure 4-2. In this chip stack, two layouts (chip1 and chip2)
are arranged such that they overlap. Polygons on each layout contain text objects labeled net1
through net4.
Figure 4-2. Connectivity Import Example
The chip stack rule file for this example is shown as follows:

source_netlist -file spice.spi -format SPICE -case NO


connect c1p_m1 c2p_m2
attach_text -placement c1p_m1 -text_placement c1p_m1

connected -check_name con_check -placement1 c1p_m1 -placement2 c2p_m2
Assume that the spice.spi file contains the results of the export_connectivity command with the
SPICE option specified:
.ENDS TOPCELL_3DIC
.SUBCKT TOPCELL net1 net2 net3 net4

.ENDS TOPCELL

Command Reference
source_netlist
Since the connectivity information in this file matches the connectivity specified with the
connect statement, this file does not produce errors. However, suppose that the .SUBCKT
TOPCELL_3DIC definition is modified as follows:
.ENDS TOPCELL_3DIC
Now, since an incorrect node number has been introduced, the connected command produces
two results that identify the offending polygons. Figure 4-3 shows these results highlighted in
Calibre DESIGNrev.
Note that the properties attached to each polygon identify the 3D assembly node number, the
port name, and the netlist node number.
Figure 4-3. Calibre DESIGNrev Output
Related Topics

Command Reference
source_netlist
Assembly Commands
Rule Check Commands

Command Reference
Assembly Commands
Assembly Commands
Commands that specify assembly operations for the chip stack.
Table 4-4. Assembly Commands

Name Description
anchor Defines an anchor name and location for a chip. This is
helpful during the assembly of the stack.
attach_text Attaches text to a placed layer for connectivity extraction
and checking.
connect Specifies electrical connections among input layer objects.
ignore_pin Excludes specified pins from a Calibre 3DSTACK run.
ignore_trailing_chars Removes specified characters from the end of text labels.
import_text_labels Imports text objects from a file and applies them to a
specified chip.
layer Defines an original or derived layer in the assembly.
layout Imports a GDS or OASIS database that contains a chip used
in the assembly.
layout_primary Defines the name of the top-level cell for the 3D assembly.
map_placement Associates layout placements in the assembly to placements
specified in the source netlist file.
place_chip Defines the placement name, orientation, and scaling factor
for a chip.
place_layer Defines the placement name, orientation, and scaling factor
for a layer.
rename_text Edits existing layout text in the assembly.
trace_text Traces connectivity text from an originating layer to a
destination layer.

Command Reference
anchor
anchor
Defines an anchor name and location for a chip. This is helpful during the assembly of the stack.
Usage
anchor -name anchor_name {-chip chip_name -x_origin x_offset -y_origin y_offset
| -layer layer_name -text text }
Arguments
• -name anchor_name
Required argument and value set that specifies the name of the anchor.
• -chip chip_name
Required argument and value set that specifies the name of the chip to which to assign the
anchor. Cannot be specified with -layer or -text.
• -x_origin x_offset
Required argument and value set that specifies the offset from the origin along the x-axis.
The value of x_offset is in microns.
• -y_origin y_offset
Required argument and value set that specifies the offset from the origin along the y-axis.
The value of y_offset is in microns.
• -layer layer_name
Required argument set that specifies the name of the layer on a chip. Cannot be specified
with -chip.
• -text text
Required argument that specifies the text label name in the layer_name layer to identify the
anchor location.
Description
Assigns an anchor name and location to a chip, which can be used in the place_chip or
place_layer commands for simplified alignment of a chip stack.
Assume that you wish to place chips C1 and C2 in the configuration shown in Figure 4-4.

Command Reference
anchor
Figure 4-4. Anchoring Example
One way this can be accomplished is by defining two anchors as follows:
anchor -name a1 -chip C1 -x_origin 1.4 -y_origin 1.0

anchor -name a2 -chip C2 -x_origin 0.4 -y_origin 0.4
where anchor a1 is relative to the origin of chip C1, and anchor a2 is relative to the origin of
chip C2.
The chips can then be placed as follows:
layer -layer 0 -chip C1 -layer_number 0

layer -layer 1 -chip C2 -layer_number 0
place_chip -placement C1p -chip C1 -x_origin 0 -y_origin 0

place_chip -placement C2p -chip C2 -anchor_placement C1p -anchor_from a2 \
-anchor_to a1
Examples
anchor -name interposer_mem -chip interposer -x_origin 30.0 \
-y_origin 14.0
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
attach_text
attach_text
Attaches text to a placed layer for connectivity extraction and checking.
Usage
attach_text -placement placed_layer -text_placement placed_text_layer
[-text_depth depth] [-no_update]
Arguments
• -placement placed_layer
Required argument and value set that specifies the name of a placed layer.
• -text_placement placed_text_layer
Required argument and value set that specifies the name of a text layer. This layer does not
need to be unique, and can be the same layer specified for placed_layer.
• -text_depth depth
Optional argument that specifies the hierarchical depth of the text on the placed_text_layer.
The depth value is specified as one or more positive integers (multiple values are specified
using braces {}). Note that you cannot specify more than one attach_text command with
the same placed_text_layer but different depth values.
• -no_update
Optional argument that specifies the input layers are not included in the extracted layout
netlist.
Description
Associates a text layer with a placed layer to be used for connectivity data extraction from the
3D assembly and for connectivity checking (using the connected command).
If either the placed_layer or placed_text_layer values reference a placement that is defined

using place_chip, the values must be specified in the following format:
placement_name'_'layer
If these values reference a placement defined using place_layer, the placement name is
specified directly.
The -no_update argument should be used when associating text with a source placement layer
for use with a locations check. This prevents the source layer from being included in the
extracted layout netlist.

Command Reference
attach_text
Examples
Example 1
attach_text -placement m_mtsv -text_placement m_mtxt
attach_text -placement l_ltsv -text_placement l_ltxt
connected -check_name connectivity_check -placement1 m_mtsv \

-placement2 l_ltsv
Example 2
attach_text -placement m_mtsv -text_placement m_mtxt -text_depth 1
attach_text -placement l_ltsv -text_placement l_ltxt -text_depth {1 2}
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
connect
connect
Specifies electrical connections among input layer objects.
Usage
Syntax 1:
connect layer1 [layerN …]
Syntax 2:
connect layer1 layer2 [layerN …] BY layerC
Arguments
• layer1
A required value that specifies an original polygon layer.
• layer2
A required value that specifies an original polygon layer. This value is required in Syntax 2,
but is not used in Syntax 1.
• BY layerC
A required value that specifies an original polygon layer, which is the contact layer. This
value is required in Syntax 2, but is not used in Syntax 1.
Description
Specifies electrical connections among input layer objects. Syntax 1 specifies an electrical
connection among layer1 through layerN objects (typically shapes or paths) that abut or
overlap, regardless of any other objects present on non-specified layers. Syntax 2 (connect BY)
specifies electrical connections among layer1 and layerC objects, and the first available layer2
through layerN object, in that order.
If either the layer1, layer2, or layerC values reference a placement that is defined using
place_chip, the values must be specified in the following format:
If these values reference a placement defined using place_layer, the placement name is
specified directly.
Refer to the Connect statement in the Standard Verification Rule Format (SVRF) User’s
Manual for more information and examples on the usage of this command.
Note
The connect layer1, layer2, and BY layerC arguments do not accept derived layers.

Command Reference
connect
Examples
connect c1p_m1 c1p_m2 BY c1p_v1
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
ignore_pin
ignore_pin
Excludes specified pins from a Calibre 3DSTACK run.
Usage
ignore_pin -placement placement_name -pin ‘{’expression‘}’
Arguments
Required argument and value set that specifies a placement name.
• -pin ‘{’expression‘}’
Required argument and value set that specifies an expression that matches one or more pin
names. The expression can be any Tcl regular expression and is not case-sensitive. The
opening ‘{’ and closing ‘{’ braces are required.
Description
Excludes the specified pin(s) from the Calibre 3DSTACK analysis. The ignore_pin command
only applies to the layout pins. The source schematic is considered golden and not impacted.
Examples
# ignore all pin instances of placement p1 that contain the substring
# "VSS" in their names.
ignore_pin -placement p1 -pin {VSS}
# ignore all pin instances of placement p1 with the name "VDD".
ignore_pin -placement p1 -pin {^VDD$}
# ignore all pin instances of placement p1 that contain either the

# substrings "VSS" or "VDD" in their names.
ignore_pin -placement p1 -pin {VSS|VDD}
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
ignore_trailing_chars
Removes specified characters from the end of text labels.
Usage
ignore_trailing_chars {character...}
Arguments
• character...
Required list of characters to remove from the end of all text labels.
Description
Removes up to one character from the end of text labels during connectivity extraction. Trailing
characters, such as “:”, are sometimes used on text labels to indicate implied connections
between polygons that are not physically connected.
In the 3DSTACK assembly, it is possible for placement labels to inherit trailing characters. For
example, the VSS and CLK nets may also be VSS: and CLK:. These are interpreted as different
nets, even though they are the same.
Use this command to ignore trailing characters so that the nets are connected during
connectivity comparison.
Examples
The following text label pairs are used in a design:
Table 4-5. Nets With Trailing Characters In Design

Net Standard Text Label Label With Implied Connectivity
VDD VDD VDD:
VSS VSS VSS.
CLK CLK CLK::
ADR ADR ADR,
Use the following command to merge the desired nets:
ignore_trailing_chars ":.,"
The following nets are extracted during connectivity analysis as a result of the command:
VDD VSS CLK CLK: ADR

Command Reference
Note, that only the last character (“:”) was removed from the CLK net. Even though that
character is specified, Calibre 3DSTACK only ignores the last character in the string, so the
CLK and CLK: text labels are still considered different nets.
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
import_text_labels
import_text_labels
Imports text objects from a file and applies them to a specified chip.
Usage
import_text_labels -chip chip_name -file file_name
Arguments
• -chip chip_name
Required argument and value set that specifies the chip name being referenced (chip names
are defined using the layout command).
• -file file_name
Required argument and value set that specifies the path to a file. This file must contain only
Layout Text statements (one per line). Each Layout Text statement is specified in the
following form:
LAYOUT TEXT text_name
x y layer text_type cell_name
where:
o text_name — required name of a text object.
o x y — required pair of floating-point coordinates in user units specifying the location
of the text label. These coordinates are in the cell context of cell_name.
o layer — required original layer number specifying the text layer.
o text_type — required non-negative integer that indicates a text object’s text type.
o cell_name — required name of a cell in which the text object is placed.
For example:
LAYOUT TEXT BACKUP_1 -0.27 0.28 10215 1 MTR_TOP2_ip_flip
LAYOUT TEXT BACKUP_1_GROUP -0.27 0.28 10131 0 MTR_TOP2_ip_flip
LAYOUT TEXT tx1_n -0.85 1.26 10215 1 MTR_TOP2_ip_flip
LAYOUT TEXT tx1_n_GROUP -0.85 1.26 10131 0 MTR_TOP2_ip_flip
Description
Adds text objects to a chip. This command must appear after the layer and layout commands in
the chip stack rule file. Any layers declared in the file_name that do not exist in the layout file
are created.
Examples
import_text_labels -chip stack_die -file lvsText_dieWrapper.txt

Command Reference
layer
layer
Defines an original or derived layer in the assembly.
Usage
layer -layer layer_name -chip chip_name
{ {-layer_number layer_number['.'data_type]} … | -svrf ‘{’ layer_derivation‘}’ [-show]}
[-level level_number] [-top_only]
Arguments
Required argument and value set that specifies the name of the layer.
• -chip chip_name
• -layer_number layer_number['.'data_type]
Required argument and value set that specifies the layer number and (optionally) the
datatype. Optional additional -layer_number arguments are allowed for geometric and text
data. Must not be specified with the -svrf argument.
• -svrf ‘{’ layer_derivation ‘}’
Required argument and value set that specifies a layer derivation using SVRF commands.
The layer derivation must be enclosed in braces. Must not be specified with the
-layer_number argument.
The layer_derivation body is similar to that of a rule check statement. It must have at least
one standalone layer operation, which is the output layer. If two output layers are specified,
they are merged. Local layer definitions may be used in the layer derivation.
If the precision of the chip_name layout is not 1000 (the default), the -precision option is
required in the layout command for chip_name in order to specify the precision.
See the “Description” section for additional information.
• -show
Optional argument that writes derived layers to the generated assembly view of your stack.
If this option is not specified, no derived layers are included in the assembly layout view.
This option must be specified with the -svrf argument set.
• -level level_number
Optional argument and value set that specifies the level of the layer in the 3D stack. Positive
and negative integer values are allowed. Use this argument to assist in drawing the system
nets and 3D views of the 3D assembly. Layer level numbers are reported in the 3DSTACK
rule file.

Command Reference
layer
• -top_only
Optional keyword that specifies to only use the top-level geometry that belongs to the
specified layer. When this option is specified, geometry that belongs to all cells other than
the top cell on this layer is ignored. The -top_only option of the layout command takes
precedence over this command option.
Note
When multiple -layer_number arguments are specified in the argument list, the
layers are merged (ORed) together at the design compilation stage.
Description
Defines the name of an original or derived layer. Definitions for empty layers are allowed. A
warning is given for empty layers.
If you create derived layers with the -svrf argument, Calibre 3DSTACK generates a layout file
that includes the derived layers. The layout file is used in assembly generation and further
processing. The generated layout file is named chip_name.gds or chip_name.oas and is saved
in the working directory with a unique suffix. The generated layout file uses the default
precision of 1000 or the precision specified in the layout command for chip_name. The
transcript includes the statement “Creating new layout file for chip_name”.
Examples
Example 1
layer -layer base_bottom_interface_shapes -chip base -layer_number 52
Example 2
This example demonstrates layer usage with multiple layer_number arguments.
layer -layer base_bottom_interface_shapes -chip base \

-layer_number 51 -layer_number 51.1
Example 3
This example uses the -svrf argument to supply a layer derivation.
layer -layer CUPB -chip die -layer_number 220.170

layer -layer CUPB_pin -chip die -layer_number 220.175
layer -layer CUPB_merged -chip die –svrf {
CUPB OR CUPB_pin
}
layer -layer die_extent -chip die –svrf {
MERGE (EXTENT DRAWN CUPB CUPB_pin)
}

Command Reference
layer
Local layer definitions may be used in the layer derivation. For example, the last layer
derivation in the previous example can be written this way:
layer -layer die_extent -chip die –svrf {

temp_x = EXTENT DRAWN CUPB CUPB_pin
MERGE temp_x
}
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
layout
layout
Imports a GDS or OASIS database that contains a chip used in the assembly.
Usage
layout -chip_name chip_name -primary top_cell_name -path layout_path
-system {GDS | OASIS} [-original_extent] [-top_only] [-exclude cells] [-interposer]
[-precision value] [-thickness value]
Arguments
Required argument and value set that specifies a chip name that can be referenced in other
commands. If this command is used multiple times, each chip_name must be unique.
• -primary top_cell_name
Required argument and value set that specifies the name of the top cell in the design.
• -path layout_path
Required argument and value set that specifies the path to the layout file. The layout_path
can be relative or absolute.
Required argument and value set that specifies the format of the layout file.
• -original_extent
Optional argument that generates a new layer that represents the total extent of the original
die. This is used for die spacing checks. The extent is based off of all the original layers in
the specified layout file. The die extent is written to a new placement_name_EXTENT layer
in the 3dstack_assembly.gds.gz file. When geometrical checks are specified for placements
of a chip with -original_extent, the new layer is considered.
• -top_only
Optional keyword that specifies to only import the top-level geometry of the die. When this
option is specified, geometry that belongs to all cells other than the top cell is ignored. This
option takes precedence over the -top_only option of the layer command.
• -exclude cells
Optional argument and list of cells to exclude from the layout.
• -interposer
Optional argument that specifies that the layout is an interposer. This is used for 2.5D ICs
when you want to generate a hierarchical netlist using the export_connectivity command
with the -hier option. This option can only be applied once (only one interposer is allowed in
a 3DSTACK assembly.

Command Reference
layout
• -precision value
Optional argument and value specifying the precision of the layout file, where value is the
ratio of database units to user units.
The -precision argument is only used if layer derivation is specified with the -svrf argument
to the layer command. If using layer derivation and the precision differs from 1000 (the
default), the -precision argument is required, otherwise the argument is not required.
When layer derivation is not used, the precision is handled automatically and the -precision
argument is not used. If physical precisions differ between layouts, the generated assembly
file uses the least common denominator of the precisions of the input layouts. For example,
if two input layouts have precisions of 1/2000 and 1/3000, the output file is generated with a
precision of 1/6000. A warning is issued if -precision is used when it is not required.
• -thickness value
Optional argument set that defines the thickness of the die in microns. Calibre 3DSTACK
uses the thickness values to generate a cross-sectional assembly view of the stack. See
“Assembly Views” on page 28 for details.
If this option is not specified, you can use the
Examples
Example
Import three chips into the assembly.
layout -chip_name interposer -primary interposer \

-path ${dsn_dir}/interposer.gds -system GDS -original_extent

layout -chip_name ram -primary ram -path ${dsn_dir}/ram.gds -system GDS \

-original_extent
Example
Import the controller.gds layout into the assembly, but do not include the PLL and cap_array
cells.

-path ${dsn_dir}/controller.gds -system GDS -original_extent \
-exclude {PLL cap_array}
Example
Declare a chip as an interposer and export a hierarchical SPICE netlist of the assembly.

Command Reference
layout
layout -chip_name interposer -primary interposer -path interposer.gds \

-system GDS -original_extent -interposer
# Declare other chip layouts, connectivity, and assembly operations

…
export_connectivity -file 3dstack_hier.sp -format SPICE -hier
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
layout_primary
layout_primary
Defines the name of the top-level cell for the 3D assembly.
Usage
layout_primary name
Arguments
• name
Required value that specifies the name of the top-level cell for the 3D assembly. The default
name is “TOPCELL_3DI” if this command does not appear in the chip stack rule file.
Examples
layout_primary TOPCELL_3DSTACK
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
map_placement
map_placement
Associates layout placements in the assembly to placements specified in the source netlist file.
Usage
map_placement -placement layout_placement_name -source source_placement_name
Arguments
• -placement layout_placement_name
Required parameter and value set that specifies the layout placement of a cell.
• -source source_placement_name
Required parameter and value set that specifies the source placement of a cell. Hierarchical
names are supported if the source netlist is hierarchical; use the forward slash (/) as the
hierarchy separator. For example:
o A source netlist has a top cell named 3DSTACK_TOP that contains one placement,
named INTERPOSER, of the sub-circuit INTERPOSER_CHIP.
o The INTERPOSER_CHIP has two placements, named DIE1 and DIE2.
In order to map to DIE1, you specify the hierarchical source_placement_name as
INTERPOSER/DIE1.
Description
This command maps the layout placement to the source netlist placement imported with the
source_netlist command. The mapping information is used during connectivity checking (LVS)
if the names used in your rule file and source netlist are different.
This command is necessary when the source names in your netlist file cannot be changed, but
must match the placement names in the assembly operations given by your Calibre 3DSTACK
rule file. It also is necessary to use map_placement when forcing certain names to the
assembly’s cells.
Cell mapping from layout to source is implicit. That is, if a placement from the layout is mapped
to the placement from the source, then the layout placement cell (the chip) is implicitly mapped
to the source placement cell.
Note
The map_placement command is order dependent. It must be specified after the place_chip
command in the 3DSTACK rule file.
Examples
This example shows the commands for mapping the layouts shown in Figure 4-5. In this
example, blocks Memory_1 and Memory_2 are the same layout. Blocks Logic_1 and Logic_2
are also the same layout. In the source schematic, the memory block is named memory_block_1

Command Reference
map_placement
and memory_block_2. In order to associate the layout placements named Memory_1 and
Memory_2 with the source netlist names for LVS, the map_placement command is used. The
same associations are made with the logic blocks.
Figure 4-5. Multiple Chips Using the Same Memory Cell
These statements map the layout placements to the source placements:
#mapping memory blocks

map_placement -placement Memory_1 -source memory_block_1
#mapping logic blocks

map_placement -placement Logic_1 -source logic_block_1
map_placement -placement Logic_2 -source logic_block_2
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
place_chip
place_chip
Defines the placement name, orientation, and scaling factor for a chip.
Usage
place_chip -placement placement_name -chip chip_name
{{-x_origin x_offset -y_origin y_offset} | {-anchor_placement anchor_placement_name
-anchor_from from_name -anchor_to to_name}}
[-rotate angle] [-magnify factor]
[-flip {x | y}] [-level value | -z_origin value]
Arguments
Required argument and value set that specifies a unique placement name that can be
referenced with other commands in the following format:
• -chip chip_name
Argument and value set that specifies the offset from the origin along the x-axis. The value
of x_offset is in microns.
Argument and value set that specifies the offset from the origin along the y-axis. The value
of y_offset is in microns.
• -anchor_placement anchor_placement_name -anchor_from from_name -anchor_to
to_name
Argument and value set that aligns the locations of from_name and to_name (relative to the
origins of their respective chip names) at the location of the specified
anchor_placement_name. Mutually exclusive with x_origin and y_origin. See the
description section under the anchor command for an example.
• -rotate angle
Optional argument and value set that specifies a rotation angle in degrees, which must be
either 0 or a multiple of 90 (positive or negative). The layer is rotated about the origin (after
x_offset and y_offset values are applied) by the specified angle. Positive angle values yield
a counter-clockwise rotation; negative angle values yield a clockwise rotation.

Command Reference
place_chip
• -magnify factor
Optional argument and value set that specifies a magnification factor by which to expand or
shrink the chip. Coordinate data on each layer is multiplied by the specified factor. The
factor must be a positive number.
• -flip {x | y}
Optional argument that flips the chip across the x-axis or y-axis.
• -level value
Optional argument set that specifies the vertical level or tier number to which the placement
belongs, where the value is an integer greater than 0. This option enables the generation of a
cross-section assembly view and is mutually exclusive with -z_origin. See “Assembly
Views” on page 28 for details.
If there is more than one placement on the same level, then the thickness of the level is the
maximum of all placements. For example, if you have an interposer with a stack of two ram
dies on top and a single controller die also on top of the interposer, the following commands
correctly specify the level value:
place_chip -placement int_place -chip interposer -level 1
place_chip -placement cont_place -chip controller -level 2
place_chip -placement ram1_place -chip ram -level 2
place_chip -placement ram2_place -chip ram -level 3
• -z_origin value
Optional argument set that specifies the height of the die from the bottom of the stack,
where the value is a distance in microns. This option enables the generation of a cross-
section assembly view and is mutually exclusive with -z_origin. See “Assembly Views” on
page 28 for details.
Description
Defines the placement name, orientation, and scaling factor for a chip.
If anchor_placement_name references a placement that is defined using place_chip, the value

must be specified in the following format:
If anchor_placement_name references a placement defined using place_layer, the placement

name is specified directly. Refer to the anchor command for a detailed description of its usage.

Command Reference
place_chip
Examples
place_chip -placement place_base_bottom_interface_shapes -flip x \
-chip chip1 -x_origin 0 -y_origin 0
place_chip -placement i -chip interposer -x_origin 0.0 -y_origin 0.0
place_chip -placement m -chip memory -anchor_placement i_tsv \

-anchor_from anchor_mem -anchor_to interposer_mem -flip x
place_chip -placement l -chip logic -anchor_placement i_tsv \

-anchor_from anchor_logic -anchor_to interposer_logic -flip x
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
place_layer
place_layer
Defines the placement name, orientation, and scaling factor for a layer.
Usage
place_layer -placement placement_name {-layer layer_name {{-x_origin x_offset
-y_origin y_offset} | {-anchor_placement anchor_placement_name
-anchor_from from_name -anchor_to to_name}} | -svrf ‘{’svrf_operations‘}’ [-show] }
[-rotate angle] [-magnify factor] [-flip {x | y}] [-level value | -z_origin value]
Arguments
Required argument and value set that specifies a unique placement name that can be
referenced with other commands.
Argument and value set that specifies the name of a layer. You must specify this argument
or -svrf.
• -svrf ‘{’svrf_operations‘}’
Argument and value set that specifies a set of SVRF operations to derive an output layer.
You must specify this argument or -layer. The operations define an output layer or a merge
of output layers. Any placement layers defined by either place_chip or place_layer that use
the -layer option can be used in the SVRF operations.
The -svrf operation adds a new layout to your design that uses the name specified in the
-placement option. The -svrf operation also adds a new layer to the design with the name
placement-name_placement-name. For example, if the placement name is “derived1” then
the generated layer name is “derived1_derived1”. Finally, a layer placement of the new
derived layer is placed at the origin (0,0).
See the “Examples” section for more details.
• -show
Optional argument that writes derived layers to the generated assembly view of your stack.
If this option is not specified, no derived layers are included in the assembly layout view.
This option must be specified with the -svrf argument set.
Required argument and value set that specifies the offset from the origin along the x-axis.
The value of x_offset is in microns. This argument set only applies to -layer.
Required argument and value set that specifies the offset from the origin along the y-axis.
The value of y_offset is in microns.This argument set only applies to -layer.

Command Reference
place_layer
• -anchor_placement anchor_placement_name -anchor_from from_name

-anchor_to to_name
Argument and value set that aligns the locations of from_name and to_name (relative to the
origins of their respective chip names) at the location of the specified
anchor_placement_name. Mutually exclusive with x_origin and y_origin. See the
description section under the anchor command for an example. This argument set only
applies to -layer.
• -rotate angle
Optional argument and value set that specifies a rotation angle in degrees, which must be
either 0 or a multiple of 90 (positive or negative). The layer is rotated about the origin (after
x_offset and y_offset values are applied) by the specified angle. Positive angle values yield
a counter-clockwise rotation; negative angle values yield a clockwise rotation.
• -magnify factor
Optional argument and value set that specifies a magnification factor by which to expand or
shrink the layer. Coordinate data on the layer is multiplied by the specified factor. The
factor must be a positive number.
• -flip {x | y}
Optional argument that flips the layer across the x-axis or y-axis.
• -level value
Optional argument set that specifies the vertical level or tier number to which the placement
belongs, where the value is an integer greater than 0. This option enables the generation of a
cross-section assembly view and is mutually exclusive with -z_origin. See “Assembly
Views” on page 28 for details.
If there is more than one placement on the same level, then the thickness of the level is the
maximum of all placements.
• -z_origin value
Optional argument set that specifies the height of the layer from the bottom of the stack,
section assembly view and is mutually exclusive with -z_origin. See “Assembly Views” on
page 28 for details.
Description
Defines the placement name, orientation and scaling factor for a layer.
If anchor_placement_name references a placement that is defined using place_chip, the value

If anchor_placement_name references a placement defined using place_layer, the placement

name is specified directly. Refer to the anchor command for a detailed description of its usage.

Command Reference
place_layer
Examples
Example
Use the -layer argument to place the bottom interface layer at the origin and flip it over the x-
axis.
place_layer -placement place_base_bottom_interface_shapes \

-layer base_bottom_interface_shapes -x_origin 0 -y_origin 0 -flip x
Example
Use the -svrf argument to derive a new layer by merging two existing layers and place it at the
origin. The internal command uses the derived layer in a spacing rule check.
place_layer -placement P3_1 -svrf { P01_10 OR P02_11 }

place_layer -placement P3_2 -svrf { P11_21 OR P12_22 }
place_layer -placement P3_3 -layer 32 -x_origin 0 -y_origin 0

...
internal -check_name int_ -placement P3_2 -constraint "< 35.0"

...
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
rename_text
rename_text
Edits existing layout text in the assembly.
Usage
rename_text {-chip chip_name | -placement placed_layer} -rename “expression”
Arguments
• -chip chip_name
Required argument and value set that specifies a chip name.
Required argument and value set that specifies a placed layer.
• -rename “expression”
Required argument and value set that specifies a GNU regular expression that defines a
pattern to be matched and replaced.
Description
Enables editing of layout port names. The format of the expression follows the syntax of Layout
Rename Text described in the Standard Verification Rule Format (SVRF) Manual. Table 4-6
contains a list of regular expression examples.
Table 4-6. Regular Expression Examples

Regular Expression Input Output Notes
/A/B/ AAA BAA Replaces the first
instance of A
/A/B/2 AAA ABA Replaces the second
instance of A
/A/B/g AAA BBB Global replacement.
/A.*B/R/ ABAABBC RC Longest left-most
string is replaced.
/^VDD.*/VCC/ VDD:1 VCC ^ searches from
beginning of text.
If the placed_layer value references a placement that is defined using place_chip, the value
chip_placement_name'_'layer
If the value references a placement defined using place_layer, the placement name is specified
directly.

Command Reference
rename_text
Examples
rename_text -chip chip1 -rename "/^VDD$/PWR/"
In this example, the first instance of the string “^VDD$” in each name in chip1 is renamed to
“PWR”.
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
trace_text
trace_text
Traces connectivity text from an originating layer to a destination layer.
Usage
trace_text -from tracer_placement_name -to pad_placement_name
Arguments
• -from tracer_placement_name
Required parameter and value set that specifies the originating text layer for tracing.
• -to pad_placement_name
Required parameter and value set that specifies the destination text layer for tracing.
Description
Traces connectivity text from an originating layer to a destination layer. The traced text may be
on the same chip or on different chips that are physically connected. The text is used in the
assembly verification process.
Establish connectivity between layers with the connect statement before using trace_text. Also,
follow these constraints:
• Ensure that both placements are part of a connectivity stack.

• Attach the text to be traced to a layer. That is, specify an attach_text statement for the
tracer layer.
• Use only one trace_text statement for pad text placement.
• Do not use text tracing statements as part of any connected checks.
• Do not cascade text tracing. That is, do not specify a layer used with the -to argument of
one trace_text statement in the -from argument of another trace_text statement.
• Do not attach text placement to pad placement. This prevents ambiguity during netlist
extraction for LVS.
When used with the report command, the trace_text command generates a section in the
summary report with the heading TRACE TEXT. This shows the originating and destination
layers for the tracing operations, as follows:
TRACE TEXT:
FROM: TO:
------------------------------------
die1_M7 die1_RDL1

Command Reference
trace_text
LVS verification in Calibre 3DSTACK requires text labeling on the layers. Figure 4-6 shows an
example of connectivity between two dies, each using a redistribution layer (RDL). Die 1 has a
top-most metal routing RDL called RDL1. Die 2 has a back-side metal layer used as an RDL,
called BM_RDL. This layer connects to the Die 2 M1 layer with a through silicon via (TSV).
The I/O pads attach to the RDLs.
Figure 4-6. Stacked Dies With RDL Layers
For this example, to trace text labels in the same die, use the trace_text command to trace the
text from layer M7 to RDL1 and then to PAD_TEXT1. To trace text labels between dies, from
Die 1 to Die 2, use the trace_text command to trace text from layer M7, to RDL1, to
PAD_TEXT1, and finally to NEW_TEXT1 on Die 2.
Examples
For this example, refer to Figure 4-6. For text tracing inside Die 1, the following rule statements
are used:
# layer connection statements

connect die1_M7 die1_RDL1
connect die1_RDL1 PAD_TEXT1
# tracing the text

trace_text -from die1_M7 -to PAD_TEXT1

Command Reference
trace_text
This statement defines text tracing between Die 1 and Die 2:
connect die2_BM_RDL NEW_TEXT1

trace_text -from die1_M7 -to NEW_TEXT1
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
Rule Check Commands
Rule Check Commands

Commands that specify rule checks for the verification run.
Table 4-7. Rule Check Commands

Name Description
centers Checks for misaligned pads.
connected Checks for connectivity between connected shapes when
there is a source netlist present. When no source netlist is
present, it checks for matching text strings on connected
shapes.
copy Exports specified layer contents.
density Checks for density constraints on specified placements.
enclosure Checks for sufficient separation distance between the
exterior-facing sides of the first placement’s edges and the
interior-facing sides of the second placement’s edges.
external Checks for sufficient separation distance between the
exterior-facing sides of the first placement’s edges and the
exterior-facing sides of the second placement’s edges.
internal Checks for sufficient separation distance between the
interior-facing sides of the first placement’s edges and the
interior-facing sides of the second placement’s edges.
locations Checks the location of pads and that the shape and text
match between source and layout.
offgrid_centers Checks for pads that are not aligned to a specified grid.
overlap Checks for sufficient overlap between two placed layers.
select_checks Selects specified checks to execute during a Calibre
3DSTACK verification.
unselect_checks Selects specified checks not to execute during a Calibre
3DSTACK verification.
tvf_block Defines custom checks for the Calibre 3DSTACK rule file.

Command Reference
centers
centers
Checks for misaligned pads.
Usage
centers -check_name check_name -placement1 placed_layer1
[-placement2 placed_layer2] -constraint “constraint_value”
[-alignment {octagonal_only | orthogonal_only}]
[-overlapping]
[-square]
[-comment “comment”] [rve_option …]
Arguments
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
output results. If centers is specified multiple times, each check_name must be unique.
• -placement1 placed_layer1
Required argument and value set that specifies the name of the first layer, which must be a
polygon layer.
Optional argument and value set that specifies the name of the second layer, which must be
a polygon layer.
• -constraint “constraint_value”
Required argument and constraint that specifies the dimensions of the measurement region
around a pad of placement1, which must have an upper bound. The constraint_value must
conform to the constraint notation described under “Constraints” in the Standard
Verification Rule Format (SVRF) Manual.
The expression may not be of the form ">", ">=", or "!=".
• -alignment {octagonal_only | orthogonal_only}
Optional argument and keyword that defines the alignment of pad centers for distance
measurement. The options are defined as follows:
o octagonal_only — the distance between the center points of the pad extents is
defined to satisfy the constraint only if the center-points are aligned at multiples of
45 degrees.
o orthogonal_only — the distance between the center points of the pad extents is
defined to satisfy the constraint only if the center-points are aligned in either the x-
or y-direction.

Command Reference
centers
• -square
Optional argument that specifies that the distance measurement is performed using a square
metric, rather than a Euclidean metric.
• -overlapping
Optional argument that checks the specified constraint between two overlapping
placements. Floating pads are ignored if -overlapping is specified. This option must be
specified with two placed layers using the placed_layer1 and placed_layer2 arguments.
• -comment “comment”
Optional argument and value set that specifies a rule check comment. You can specify
multi-line comments using the “\n” escape sequence.
• rve_option …
Optional argument and value set that controls how Calibre RVE displays rule check results.
Multiple options are allowed. The permitted values for rve_option are described in detail
under “Check Text Override Comments for Calibre 3DSTACK” on page 177.
Description
This command checks whether the pad centers are aligned, or if the centers are spaced at a
specified distance. Or in other words, the centers check flags pads that are not within a
specified distance of other pads. The measurement is performed using the centers of the extents
of the pads. Its functionality is similar to the Not With Neighbor SVRF operation using the
CENTERS option.
If you want to check the center alignment of overlapping pads, specify the -overlapping
argument. This option only checks the specified constraint between two overlapping pads. If
this option is not specified, the centers command checks for neighboring and overlapping pads.
Examples
Example 1
This example reports any pads on a layer placement that are not exactly within a center-to-
center distance of 80 microns.
centers -check_name controller_pads -placement1 ${controller}_CON_if \

-constraint "== 80" -alignment orthogonal_only \
-comment "Controller pads spaced 80 um in x or y from all pad centers"

Command Reference
centers
If any pads from -placement1 are not exactly 80 um away from each pad’s center,
Calibre 3DSTACK flags them by selecting the offending pads, similar to this:
Example 2
This example demonstrates how to check the alignment between two overlapping pad
placements. In this case, a chip is stacked on an interposer and you want to ensure that the pads
do not misalign more than 0.1 um.
The following rule check defines a maximum center-center deviation between the
cont_placement and inter_placement pads of 0.1 um. It also specifies that the pad placements
are orthogonally aligned and the detection region is square shaped.
centers -check_name centers_controller_interposer \

-placement1 cont_placement -placement2 inter_placement \
-constraint "<= 0.1" -square -alignment orthogonal_only -overlapping \
-comment "Center-to-center spacing for the controller to
interposer_controller landing pads must be within 0.1 um in the x or y
direction (ortho)."

Command Reference
centers
In this example, the check selects any interposer pads with centers more than 0.1 um away from
the centers of the controller pads:
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
connected
connected
Checks for connectivity between connected shapes when there is a source netlist present. When
no source netlist is present, it checks for matching text strings on connected shapes.
Usage
connected -check_name check_name -placement1 placed_layer1
-placement2 placed_layer2 [-detailed] [-text_checks ‘{’ALL | NONE | [type …]‘}’]
[-nothrutier] [-no_dangling_ports] [-no_extra_ports] [-no_missing_ports]
Arguments
out results. If this command is specified multiple times, each check_name must be unique.
Required argument and value set that specifies the name of the first placed layer. The layer
must be defined in the Calibre 3DSTACK rule file and cannot be a derived layer.
Required argument and value set that specifies the name of the second placed layer. The
layer must be defined in the Calibre 3DSTACK rule file and cannot be a derived layer.
• -detailed
Optional argument that enables detailed reporting of connectivity errors. When specified,
two additional properties are reported for each result:
o LNC (Layout Net Components) — the names of the ports connected to the layout
net.
o SNC (Source Net Components) — the names of the ports connected to the source
net.
This option has no effect if source_netlist is not present in the chip stack rule file.
• -text_checks ‘{’ALL| NONE | [type …]‘}’]
Optional argument and keyword list that specifies the types of text checks that you want to
execute. You can specify either of the following options to enable or disable all text checks:
ALL — all text checks are performed. This is the default.
NONE — no text checks are performed.
Otherwise, you can specify one or more of the following text type options:
NO_TEXTS — missing text is checked.
FLOATING_TEXTS — floating text is checked.

Command Reference
connected
MULTI_TEXTS — multiple text labels on one object are checked.

• -nothrutier
Optional argument that specifies not to perform through-tier connectivity checking in the
connected check. This option ignores internal layers that pass through dies from the
connected check.
• -no_dangling_ports
Optional argument that specifies to exclude DanglingPort errors from the verification
results. DanglingPort errors are reported when port placements have no physical
connectivity with connectivity layers.
• -no_extra_ports
Optional argument that specifies to exclude ExtraPort errors from the verification results. If
you want this option to apply to an entire layer, then it must be specified for each connected
check in which the layer is specified.
• -no_missing_ports
Optional argument that specifies to exclude MissingPort errors from the verification results.
If you want this option to apply to an entire layer, then it must be specified for each
connected check in which the layer is specified.
• rve_option …
Description
This command has two modes, depending on the presence of source_netlist in the rule file:
• Mode 1 — verifies that connected shapes on the specified placed layers form valid
connections, and outputs results to a check named check_name. This mode is enabled
when source_netlist is present in the chip stack rule file. (See “Calibre 3DSTACK Rule
File” on page 27 for more information.)
• Mode 2 — verifies that connected shapes on the specified placed layers contain
identical text strings, and outputs results in a check named check_name. This mode is
enabled when source_netlist is not present in the chip stack rule file. (See “Calibre
3DSTACK Rule File” on page 27 for more information.)
More information on each mode is given later in the section.

Command Reference
connected
Typically, this command appears more than once in the chip stack rule file. This command
reports an error if the attach_text command has not been used to associate a text layers with
placed_layer1 and placed_layer2.
If either the placed_layer1 or placed_layer2 values reference a placement that is defined using
place_chip, the values must be specified in the following format:
If these values reference a placement defined using the place_layer command, the placement
name is specified directly.
Caution
Calibre 3DSTACK issues an error message if placements involved in a connected check are
not part of a connectivity stack. A connectivity stack is defined by explicitly issuing the
connect command in the rule file, or through implicit connect statements generated by Calibre
3DSTACK. To avoid this error, the placement should be properly defined with the connect
statement.
Mode 1
If the source_netlist command is present in the chip stack rule file, this command verifies that
connected shapes on the specified placed layers form valid connections, and outputs results to a
check named check_name.
Connectivity data is extracted from the chip stack based on placement layer connections (either
defined explicitly using a connect statement, or implicitly if there are no connect statements)
and placement text labels (defined using the attach_text command). This connectivity data is
compared with the connectivity data defined in the source_netlist file_name. All mismatches
are considered invalid connections and are reported as errors. Connected shapes that do not
contain text are output in a separate text checks.
By default, three properties are reported for each result:
• Net — the 3D assembly node number that the pin is connected to.
• Port — the 3D assembly port name in the form placement_name:net_name.
• SourceNet — the netlist node number that the pin is connected to. If the netlist node
number cannot be determined, “UNKNOWN” is used for the value.
Additional properties LNC and SNC can be enabled with the -detailed option.
Mode 2
If the source_netlist command is not present in the chip stack rule file, this command verifies
that connected shapes on the specified placed layers contain identical text strings, and outputs
results in a check named check_name. Connected shapes that do not contain text are output in a

Command Reference
connected
separate text checks. If there are no connect statements in the chip stack rule file, a connect
statement is executed implicitly for the specified placed layers.
Text Checks
All text-related verification checks are reported by the type of text result and the chip it belongs
to (if the placement is part of a connectivity check). The text results are organized into the
following categories:
• Floating text — Text labels that do not overlap with a pad.

• No text — Pads that are missing text labels.
• Multi text — Pads that have more than one text label (overlapping labels). In certain
cases, pads can overlap and create overlapping text labels. In these cases, the following
warning message is issued:
WARNING: there are multiple text-labels overlapping with the pads on
layer layer.
"connected" check may produce incorrect results!
Multi text warnings are not issued if the overlapping text labels are identical.
Note
If there are multiple placements for one chip and the placements do not use
rename_text operations, the text results are reported for the first placement only (the
other affected placements are mentioned in the generated Calibre RVE check
comments).
• Extra Port — Missing ports in the source (or extra ports in the layout). The
source_netlist command must be included in order for these results to be produced.
Calibre RVE allows you to highlight and cross-reference LNC and SNC ports from the
details pane. This result can occur if one or more of the following conditions are true:
o The subcircuit for a placement is missing a pin definition in the source netlist.
o When multiple text labels are found on one pad, Calibre 3DSTACK chooses one of
the labels and associates it with that pad during connectivity extraction. As a result,
an Extra Port result can occur because the placement port may not be found in the
source netlist.
You can disable this check by specifying the -no_extra_ports option.
• Missing Ports — A port in the source netlist has no corresponding layout pad. The
source_netlist command must be included in order for these results to be produced.
When the result is highlighted, there is no layout object to highlight, so the result
properties are displayed in the bottom left corner of the top cell in the assembly.
The result includes the properties SourceNet and MissingPort and these properties are
displayed as links in the Result Data Pane—click the links to highlight the source net

Command Reference
connected
and port. The Calibre 3DSTACK DFM Database and the source netlist must be open in
Calibre RVE; see “Debugging Connectivity Errors in Calibre 3DSTACK” on page 44.
You can disable this check by specifying the -no_missing_ports option.
Examples
Example 1
This example verifies that shapes on the placed layers contain identical text strings. Note that
source_netlist is not present in the chip stack rule file.


-placement2 l_ltsv -comment "Memory-to-logic \n connectivity check"
Example 2
This example compares the connectivity information extracted from the chip stack to the
connectivity information defined in the input.spi file.

source_netlist -file input.spi -format SPICE

-placement2 l_ltsv -text_checks {FLOATING_TEXTS NO_TEXTS}\
-comment "Memory-to-logic \n connectivity check"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
copy
copy
Exports specified layer contents.
Usage
copy -check_name check_name -placement placement_name [-comment “comment”]
Arguments
output results. If copy is specified multiple times, each check_name must be unique.
Required argument and value set that specifies the name of the placement.
Description
Use this command to copy and export the layer contents. This command saves the layer
placement in DFM database format and exports it into the 3dstack.rdb and corresponding
auxiliary RDB.
Examples
copy -check_name enc_check -placement placement1 \
-comment "EXPORT OPERATION\n Writing placement1 to DFM database format."
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
density
density
Checks for density constraints on specified placements.
Usage
density -check_name check_name -placements ‘{’placed_layer …‘}’
[-expression “density_expression”] -constraint “constraint_expression”
[-window {wxy | wx wy} [-step {sxy | sx sy}] ]
[-window_type {truncate | backup | ignore
| wrap}] [-inside { extent | placed_layer}]
[-centers value] [-comment “comment”] [rve_option ...]
Arguments
• -checkname check_name
output results.
• -placements ‘{’placed_layer …‘}’
Required argument and value set that specifies a list of placements to which the density
operation is applied.
• -expression “density_expression”
Optional argument and value set that performs a calculation involving layer data. If no
density_expression is provided, then the density is calculated as the ratio of the area of the
input layers in a data capture window to the area of the data capture window itself. If you
supply a density_expression, then the value (based in user units) of the density_expression is
computed within each data capture window. If the value of the expression satisfies the
constraint_expression, then the window is output as usual.
The density_expression may involve numbers (including numeric variables), operators,
parentheses ( ), and the functions given in the following table:
Table 4-8. Density Math Functions

Function Definition
AREA(input_layer) Area of input_layer in user units of length squared.
AREA() gives the area of the data capture window.
SQRT(x) Square root of x
EXP(x) Exponential (base e) of x
LOG(x) Natural logarithm of x
SIN(x) Sine of x in radians
COS(x) Cosine of x in radians

Command Reference
density
Table 4-8. Density Math Functions (cont.)

Function Definition
TAN(x) Tangent of x in radians
MIN(expression1,expression2) Returns the lesser value of the two expressions. The
expressions must be of the same form as the primary
density_expression, without the square brackets.
MAX(expression1,expression2) Returns the maximum value of the two expressions. The
expressions must be of the same form as the primary
density_expression, without the square brackets.
In Table 4-8, x is a numeric argument (including numeric variables and other numeric-
valued expressions). There is no compile-time or runtime exception checking on the
arguments of these functions, and unreasonable or undefined values may result from certain
arguments.
The expression must not result in strictly negative values because such values cannot be
checked by a constraint_expression. Division by zero is defined not to satisfy any
constraint_expression.
Parentheses have the highest precedence for the calculation of numeric values and may be
used for grouping of terms.
Operators — Unary operators (+, -, !, ~) require only one numerical argument and all such
operators have the same precedence. The unary + and - operators are the usual positive and
negative signs. The other unary operators do the following:
! operator — Returns 0 (or false) if its argument is non-zero and 1 (or true) if its
argument is 0.
~ operator — Returns 0 (or false) if the argument is positive and 1 (or true) if the
argument is non-positive.
The following table shows some useful combinations of the ~ and ! operators.
Table 4-9. ! and ~ Operator Combinations

x !(x) !!(x) !(x-1) !!(x-1) ~(x) ~~(x) ~(x-1) ~~(x-1)
3 0 1 0 1 0 1 0 1
2 0 1 0 1 0 1 0 1
1 0 1 1 0 0 1 1 0
0 1 0 0 1 1 0 1 0
-1 0 1 0 1 1 0 1 0
-2 0 1 0 1 1 0 1 0
-3 0 1 0 1 1 0 1 0

Command Reference
density
Here is a summary of interpretations of the ! and ~ operators:
!(x) detects whether something is absent (here, 0 means absent).

!!(x) detects whether something is present (not 0 means present).
!(x-r) detects the value r.
!!(x-r) detects everything except r.
~(x) detects whether something is absent (here, x <= 0 means absent).
~~(x) detects whether something is present (x > 0 means present).
~(x-r) detects everything <= r.
~~(x-r) detects everything > r.
Table 4-8 does not show the following relations explicitly, but they can be verified from the
table:
!~(x) = ~~(x) and ~!(x) = !!(x).
The binary operators ^, *, /, +, - require two numerical arguments. The ^ operator is the
same as the C language pow( ) function, where x ^ y means x raised to the y power. The *, /
, +, and - operators are multiplication, division, addition, and subtraction, respectively, and
have the customary precedence. The ^ operator has the same precedence as * and /.
The binary operators || (OR) and && (AND) are the same as the C language operators of the
same type, except that they have the same precedence as binary + and -. They expect
numeric-valued inputs. For example:
AREA(via) && AREA(met) returns 1 if both inputs are non-zero and 0 otherwise.
AREA(via) || AREA(met) returns 1 if either input is non-zero and 0 otherwise.
• -constraint “constraint_expression”
Required argument and value set that specifies a constraint. The constraint_expression
“< 0” is not allowed.
When used without a density_expression, data capture windows whose area ratio meets the
constraint_expression are output. In this case, if the ratio is intended as a percentage, the
constraint_expression should contain numbers between 0 and 1, where division by 100 has
already occurred.
If a density_expression is provided, then data capture windows whose expression values
meet the constraint_expression are output.

Command Reference
density
• -window {wxy | wx wy}

Optional argument and value set that specifies the dimensions of the data capture window
within which the density check is to occur. The choices are:
-window wxy — Specifies a square window with a height and width of wxy user units.
The parameter wxy must evaluate to a positive real number.
-window wx wy — Specifies a rectangular window with a height of wy user units and a
width of wx user units. The parameters wx and wy must evaluate to positive real
numbers.
The windows are tiled across a data capture extent, which is determined by the keywords
specified with the operation. Windows that meet the constraint_expression are output.
Windows that are written to the DRC Results Database are merged.
If you do not specify this keyword set in the statement, the default window size is either the
extent of the layout database read in at runtime, or is defined by the -inside condition when
one is specified. Calibre 3DSTACK does not read in database layers if they are not required
for calculating outputs during the run. If the window is larger than the boundary in the x-
direction or y-direction, then the window is truncated to the boundary’s dimensions in the
appropriate directions.
For further details, refer to the Density command described in the Standard Verification
Rule Format (SVRF) Manual.
• -step {sxy| sx sy}
Optional argument and value set that is specified with the -window argument. Specifies the
grid increment for which data capture windows are tiled within the data capture extent. The
choices are:
-step sxy — Specifies that the windows are tiled to the right and up in increments of sxy
user units. The parameter sxy must evaluate to a positive real number.
-step sx sy — Specifies that the windows are tiled incrementally to the right sx user units
and up sy user units. The parameters sx and sy must evaluate to a positive real
numbers.
If you specify both -step and -window, then the values sxy, sx, and sy must evenly divide
into the window values wxy , wx , and wy , respectively.
Default behavior — If you do not specify -step in the statement, the default -step size is
defined by the -window dimensions.
Note that -step 3 -1 is interpreted as -step 2, and -step 3(-1) is a compiler error.
The stepped data capture windows start in the lower-left corner of the data capture extent
and initially are tiled in sxy or sx increments to the right. Upon arriving at the right edge of
the data capture extent, the capture windows are tiled upward by the sxy or sy increment and
are tiled again starting from the left edge of the data capture extent.

Command Reference
density
• -window_type {truncate| backup | ignore | wrap}

Optional argument and value set that specifies the type of window.
o truncate
Optional keyword that specifies a data capture window is truncated at the limits of
the data capture extent. The density calculation in a truncated window is based upon
the truncated dimensions of the window. This is the default behavior if you do not
specify this keyword. The algorithms for this and related keywords are discussed in
the “Functional Details” section of the Density command in the Standard
Verification Rule Format (SVRF) User’s Manual.
Figure 4-7. density -window_type truncate
o backup
Optional keyword that specifies if a window overlaps the right-hand or top edges of
the data capture extent, the window is shifted left or down until it is no longer
overlapping the data capture extent. The density calculation is then performed after
the window has been shifted.
Figure 4-8. density -window_type backup
o ignore

Command Reference
density
the data capture extent, then the window is ignored and no data for that window
location is output.
Figure 4-9. density -window_type ignore
o wrap
the data capture extent, then the data capture extent and its data are duplicated and
added to the right-hand side or top side of the original bounding box. The density
measurement is then taken in the window that intersects the duplicated data capture
extent regions.
Figure 4-10. density -window_type wrap
• -inside { extent | placed_layer}

Optional argument and value set that defines a data capture extent within which data capture
windows are tiled.
The extent keyword specifies that the data capture extent is the rectangular extent of the
input placements parameters.
The placed_layer replaceable specifies that the output of data capture windows is coincident
with polygons from placed_layer. The placed_layer parameter must be an original or

Command Reference
density
derived polygon layer. The data capture extents are the rectangular extents of polygons from
placed_layer.
If you do not specify any of these keyword sets in the operation, the default data capture
extent is the database extent read in at run time. Calibre 3DSTACK does not read in
database layers if they are not required for calculating outputs during the run. Layers that
are not read in do not contribute to the Calibre 3DSTACK database extent.
• -centers value
Optional argument and positive floating number in user units that causes the geometric
output of density to be squares of value ´ value dimensions located at the centers of
rectangles that would be output by default.
• rve_option …
Description
The density verification check is typically used to compute the density of an input layer within
a specified data capture window, such as in this design rule: “The density of metal2 in every
50 x 50 area of the layout must exceed 25%.” The default density function is defined as the
ratio of the total area of the input layers within the data capture window to the area of the
window itself. The density is calculated as the window is tiled over a specified data capture
extent. Each window placement that meets the constraint value is output as part of a merged
layer.
The size of the data capture window, the data capture extent, and how the data capture window
is tiled across the capture extent are controlled with options. The density_expression option is
used to provide a user-defined calculation instead of the default density calculation.
For further details, refer to the Density command described in the Standard Verification Rule
Format (SVRF) Manual. Also see “Density Best Practices” in the Calibre Solutions for Physical
Verification manual.

Command Reference
density
Examples
density -check_name density_tracer_and_interposer \
-placements { i_tsv m_mtsv_trace } -constraint " < 0.1" \
-window 50 -window_type "wrap" -centers 25 -step {10 20} \
-comment "Density check for m-tracer and interposer"
density -check_name density_tracer_and_interposer \

-placements { i_tsv m_mtsv_trace } -constraint " < 0.1" \
-expression "(AREA(i_tsv) + AREA(m_mtsv_trace)) / AREA()" \
-window 20 -window_type "truncate" -centers 10 \
-comment "density check i_tsv m_mtsv_trace < 0.1"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
enclosure
enclosure
Checks for sufficient separation distance between the exterior-facing sides of the first
placement’s edges and the interior-facing sides of the second placement’s edges.
Usage
enclosure -check_name check_name -placement1 placement1 -placement2 placement2
-constraint “constraint_value” [-comment “comment”] [rve_option …]
Arguments
• -placement1 placement1
polygon layer or chip placement. The placement1 value must be of the same type as the
placement2 value.
Required argument and value set that specifies the name of the second layer, which must be
a polygon layer or chip placement. The placement2 value must be of the same type as the
placement1 value.
Specifies the checking distance, which must have an upper bound. The constraint_value
must conform to the constraint notation described under “Constraints” in the Standard
• rve_option …
Optional argument and value set that controls how Calibre RVE displays the rule check
results. Multiple options are allowed. The permitted values for rve_option are described in
detail under “Check Text Override Comments for Calibre 3DSTACK” on page 177.
Description
Measures the separation distance between the exterior-facing sides of placement1 edges and the
interior-facing sides of placement2 edges, and outputs edge pairs that satisfy the specified
constraint_value.
The placement1 and placement2 values must either be a pair of placed polygon layers (from a
place_layer operation) or a pair of chip placements (from a place_chip operation). You cannot

Command Reference
enclosure
mix placement types (for example, specifying placement1 as a chip and placement2 as a
polygon layer results in an error).
If chip placements are specified, the check is performed using the extents of the chip.
Examples
This example checks for Through Silicon Vias that are not enclosed within metal pads by at
least 0.5 um.
enclosure -check_name TSV_enclosure \

-placement1 pInterp_TSV -placement2 pInterp_bmetal1 \
-constraint "< 0.5 REGION" -comment "TSV is less than 0.5 microns from
the edge of pad on layer bmetal1"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
external
external
Checks for sufficient separation distance between the exterior-facing sides of the first
placement’s edges and the exterior-facing sides of the second placement’s edges.
Usage
external -check_name check_name -placement1 placement1 [-placement2 placement2]
Arguments
placement2 value.
placement1 value.
Required argument and value set that specifies the checking distance, which must have an
upper bound. The constraint_value must conform to the constraint notation described under
“Constraints” in the Standard Verification Rule Format (SVRF) Manual.
• rve_option …
Description
Measures the separation distance between the exterior-facing sides of placement1 edges and the
exterior-facing sides of placement2 edges. If -placement2 is not specified, this command
measures the separation distance between the exterior-facing sides of placement1 edges. Edge
pairs are output that satisfy the specified constraint_value.

Command Reference
external
Examples
Check spacing between two placed layers:
external -check_name external_check -placement1 p_stack_if1_stack_bot_if \

-placement2 p_base_bot_if -constraint "< 0.4 REGION" \
-comment "Checking < 0.4 REGION between \
layer p_stack_if1_stack_bot_if and layer p_base_bot_if"
The following example demonstrates how to check for sufficient spacing between chip
placements. Three chips are placed on an interposer using the following assembly operations:
place_chip -placement Controller -chip CONT -x_origin 40 -y_origin 40

place_chip -placement Mem_1 -chip RAM -x_origin 250 -y_origin 100
place_chip -placement Mem_2 -chip RAM -x_origin 280 -y_origin 40 \
-rotate 90
For this example, we want to ensure that no chip comes within 65 microns of the extents of the
Controller chip.
Tip
The extent of a chip is automatically considered by the rule check if the -original_extent
option is used in the layout command.
The chip instantiations can be directly referenced in a geometrical check as follows:
external -check_name controller_spacing_check -placement1 Controller \

-constraint "< 65 REGION" -comment "Chip placement closer than 65 um."

Command Reference
external
Calibre 3DSTACK flags the Mem_1 chip placement because it lies within 65 um of the
Controller’s extents. Mem_2 is within a safe distance:
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
internal
internal
Checks for sufficient separation distance between the interior-facing sides of the first
placement’s edges and the interior-facing sides of the second placement’s edges.
Usage
internal -check_name check_name -placement1 placed_layer1 [-placement2 placed_layer2]
Arguments
placement2 value.
placement1 value.
Specifies the checking distance, which must have an upper bound. The constraint_value
must conform to the constraint notation described under “Constraints” in the Standard
• rve_option …
Description
Measures the separation distance between the interior-facing sides of placed_layer1 edges and
the interior-facing sides of placed_layer2 edges. If -placement2 is not specified, this command
measures the separation distance between interior-facing sides of placed_layer1 edges. Edge
pairs are output that satisfy the specified constraint_value.

Command Reference
internal
Tip
The extent of a chip is automatically considered by the rule check if the -original_extent
option is used in the layout command.
Examples
internal -check_name internal_check -placement1 p_stack_if1_stack_bot_if \
-placement2 p_base_bot_if -constraint "< 0.3 REGION" \
-comment "Checking < 0.3 REGION between layer p_stack_if1_stack_bot_if
and layer p_base_bot_if"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
locations
locations
Checks the location of pads and that the shape and text match between source and layout.
Usage
locations -check_name check_name -placement1 placement_layer1
-placement2 placement_layer2 [-constraint "constraint_value"]
[-direction {both | up | down} | {both | direct | reverse}] [-text_only | -overlap_only]
[-comment "comment"] [rve_option …]
Arguments
Required argument and value set that specifies a check name that is used when writing out
results. If this command is specified multiple times, each check_name must be unique.
• -placement1 placement_layer1
• -placement2 placement_layer2
• -constraint "constraint_value"
Optional argument and value set that specifies the overlap constraint in terms of a
percentage. The constraint must have an upper bound.The constraint_value must conform to
the constraint notation described under “Constraints” in the SVRF Manual. The default
constraint is “<100”.
• -direction {both | up | down} | {both | direct | reverse}
Optional argument that specifies the vertical direction of the locations check. This option is
useful for checking enclosure issues between specific sets of pads. By default, the locations
check verifies the pads and text to both placements or in both directions, depending on the
syntax. The behavior for the two types of rule file syntax are described in the following
table.
Conventional Syntax 3DSTACK+ Extended Syntax

-direction {both | direct | reverse} -direction {both | up | down}
• both — apply the locations check to both • both — apply the locations check in both
placement_layer1 and placement_layer2 vertical directions.
• direct — apply the locations check to • up — apply the locations check upwards.
placement_layer1 only • down — apply the locations check
• reverse — apply the locations check to downwards.
placement_layer2 only

Command Reference
locations
• -text_only
Optional argument that specifies to only check for placement geometries with text that does
not match. If the geometries overlap, but the text does not match, Calibre 3DSTACK reports
a “Different Text” error. If the geometries do not overlap, then the geometry is reported as
an “Unmatched Pads” error. This option cannot be specified with -overlap_only or
-constraint.
• -overlap_only
Optional argument that specifies to only check for placement geometries that meet the
specified constraint_value. Geometries that do not overlap or exceed the specified
constraint are flagged as “Unmatched Pads” errors. This option cannot be specified with
-text_only.
• rve_option …
Description
This command checks that pads overlap correctly, have matching shapes, and have text labels
that match between two placement layers, typically source and layout. By default, checking is
done in both directions—layout pads are compared to source pads and source pads are
compared to layout pads. The source pad information must be given as a placement in the
3DSTACK assembly. Apply the -direction, -text_only, or -overlap_only options to change the
default behavior.
Location checking is only done for pads with attached text, in other words, for placement layers
with associated text placement layers specified with the attach_text command. By default, the
attach_text command causes the placement layer to be part of connectivity extraction, which is
only needed for layout placement layers. When using attach_text with source layers, use the
-no_update argument to specify that the layer is not included in the extracted layout netlist.
The command produces an output layer with result shapes corresponding to the pad. Each result
has the following property annotations:
• Result Type (RT) — Unmatched Pads or Different Texts

• Placement — The placement.
• Overlap — The percent overlap.
• Text — The text for placement_layer1, if it exists.
• Text2 — The text for placement_layer2 for Different Texts results.

Command Reference
locations
Examples
layout -chip_name layout -primary TOP -path ./gds/layout.gds -system GDS

layout -chip_name source -primary TOP -path ./gds/source.gds -system GDS
layer -layer l_pads -chip layout -layer_number 0

layer -layer l_pad_txts -chip layout -layer_number 1
layer -layer s_pads -chip source -layer_number 0

layer -layer s_pad_txts -chip source -layer_number 1
place_chip -placement p_layout -chip layout -x_origin 0 -y_origin 0

place_chip -placement p_source -chip source -x_origin 0 -y_origin 0
attach_text -placement p_layout_l_pads -text_placement \

p_layout_l_pad_txts
attach_text -placement p_source_s_pads -text_placement \
p_source_s_pad_txts -no_update
locations -check_name locations_check \

-placement1 p_layout_l_pads \
-placement2 p_source_s_pads

Command Reference
offgrid_centers
offgrid_centers
Checks for pads that are not aligned to a specified grid.
Usage
offgrid_centers -check_name check_name -placement placed_layer
–resolution {resolution_value | x_resolution_value y_resolution_value }
Arguments
Required argument and value set that specifies the name of a placement layer, which must
be a polygon layer.
• -resolution {resolution_value| x_resolution_value y_resolution_value}
Required argument and value set that specifies the grid resolution in microns. Floating-point
numbers are allowed. The resolution value is applied in both the x and y directions. If
x-resolution and y-resolution are specified, x-resolution is applied in the x direction and
y-resolution in the y direction.
• rve_option …
Description
This command detects pads that are not aligned to a specified grid. The grid used for checking
objects is defined by either the resolution_value or x-resolution and y-resolution parameters.
For example, if you specify the resolution as 45, then all relevant points (vertices, endpoints, or
center points) of objects are checked to see if their x and y coordinates are on a 45 micron grid.
The functionality is similar to the SVRF Offgrid operation with the CENTERS option as
described in the Standard Verification Rule Format (SVRF) User’s Manual.
Examples
Example 1
Check that pads are aligned to a 5 micron square grid.

Command Reference
offgrid_centers
offgrid_centers -check_name offgrid_memory -placement m_mtsv \

-resolution 5 -comment "m_mtsv pads must align to 5x5 um grid“
Example 2
Check that pads are aligned to a 5 um by 10 um (x by y) grid.
offgrid_centers -check_name offgrid_memory -placement m_mtsv \

-resolution "5 10" -comment "m_mtsv pads must align to 5x10 um grid"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
overlap
overlap
Checks for sufficient overlap between two placed layers.
Usage
overlap -check_name check_name -placement1 placed_layer1
-placement2 {placed_layer2 [placed_layer2 …]} -constraint “constraint_expression”
[-by_area] [-intersection] [-comment “comment”] [rve_option …]
Arguments
Required argument and value set that specifies the name of the first polygon layer.
• -placement2 {placed_layer2 [placed_layer2 …]}
Required argument and value set that specifies the name of one or more secondary polygon
layers.
Required argument and value set that specifies the overlap constraint, which must have an
upper bound. The constraint_value must conform to the constraint notation described under
“Constraints” in the .
• -by_area
Optional argument that specifies that the overlap operation outputs the overlapping area,
rather than the percentage of overlap. The constraint must also be an area value.
• -intersection
Optional argument that specifies that the intersecting regions are reported.
• rve_option …
Description
This command measures the percentage of the polygons on placed_layer1 that are common
with the polygons of the layers specified in the placed_layer2 value list. The geometry of
placed_layer1 that meets the specified constraint_expression is the output of overlap.

Command Reference
overlap
If you specify the -by_area option, the overlap value is the area overlap between the first and
secondary placement layers instead of the percentage overlap.
To report the intersecting region between the placement layers, use the -intersection keyword.
Examples
Example 1
Measure the overlap by percentage and output the intersection region.
overlap -check_name overlap_tracer_with_interposer \

-placement1 m_mtsv_trace -placement2 i_tsv \
-constraint "<= 80.0" -intersection \
-comment "TSV and interposer pads must overlap by at least 80%"
Example 2
Measure the overlap by area.
overlap -check_name overlap_tracer_with_interposer \

-placement1 m_mtsv_trace -placement2 i_tsv \
-constraint "<= 20.0" -by_area \
-comment "Overlap must be at least 20um^2 between tsv and interposer pads"
Example 3
Check that all of the interposer pads have suitable overlap with all of the pads of the chips
placed on the interposer.
overlap -check_name interposer_pads \

-placement1 p_interposer \
-placement2 {"p_controller" "p_ram_1" "p_ram_2" "p_ram_3"} \
-constraint "<= 95" \
-comment "Interposer pads must overlap chip pads by at least 95%!"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
select_checks
select_checks
Selects specified checks to execute during a Calibre 3DSTACK verification.
Usage
select_checks { -check_names ‘{’check_name_pattern [check_name_pattern …]‘}’
| -placements ‘{’placement_name_pattern [placement_name_pattern …]‘}’ }
[-check_types ‘{’check_type …‘}’]
Arguments
• -check_names ‘{’check_name_pattern [check_name_pattern …]‘}’
Argument and value set that specifies a list of rule checks that are executed. The list of
checks are specified as Tcl regular expressions. Multiple check_name_pattern values are
allowed. Must not be specified with the -placements argument.
• -placements ‘{’placement_name_pattern [placement_name_pattern …]‘}’
Argument and value set that specifies a list of placements for which rule checks are
executed. Any checks that apply to the specified placements are executed. The list of
placements are specified as Tcl regular expressions. Multiple placement_name_pattern
values are allowed. Must not be specified with -check_names argument.
• -check_types ‘{’check_type …‘}’
Optional argument and value set that specifies the types of checks to execute. The
check_type can be any of the following values:
o enclosure
o internal
o external
o connected
o locations
o copy
o overlap
o density
o centers
o offgrid_centers
Any number of check_type values can be specified. If this option is not specified, all check
types are selected.

Command Reference
select_checks
Description
This command executes only those rule checks that are defined by the check_name_pattern
argument list or checks that apply to the placements in the placement_name_pattern list. If
select_checks is not specified, all rules in the rule file are executed. Multiple select_checks
commands are allowed in the Calibre 3DSTACK rule file. If multiple select_checks statements
are specified, the list is accumulated as shown in Example 2.
The -placements and -check_names arguments are mutually exclusive.
Use the -check_types option to select groups of checks by their type.
Examples
Example 1
Specify a single check to run:
select_checks -check_names {"int_1"}
Example 2
Specify multiple checks to run using either of the following methods:
select_checks -check_names {".*_1" "ext_2" "enc_2"}
or
select_checks -check_names {".*_1"}

select_checks -check_names {"ext_2"}
select_checks -check_names {"enc_2"}
Example 3
Execute only the checks that are used in the interposer and any of the ram placements:
select_checks -placements {"interposer" "ram_*"}
Example 4
Execute internal and external checks only.
select_checks -check_types {internal external}
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
unselect_checks
unselect_checks
Selects specified checks not to execute during a Calibre 3DSTACK verification.
Usage
unselect_checks -check_names ‘{’check_name_pattern [check_name_pattern …]‘}’
| -placements ‘{’placement_name_pattern [placement_name_pattern …]‘}’ }
[-check_types ‘{’check_type …‘}’ ]
Arguments
Required argument and value set that specifies a list of rule checks that are excluded from
the verification run. The list of checks are specified as Tcl regular expressions. Multiple
check_name_pattern values are allowed. Must not be specified with the -placements
argument.
• -placements ‘{’placement_name_pattern [placement_name_pattern …]‘}’
Argument and value set that specifies a list of placements for which rule checks are
excluded. Any checks that apply to the specified placements are ignored. The list of
placements are specified as Tcl regular expressions. Multiple placement_name_pattern
values are allowed. Must not be specified with -check_names argument.
• -check_types ‘{’check_type …‘}’
Optional argument and value set that specifies the types of checks to exclude. The
check_type can be any of the following values:
o enclosure
o internal
o external
o connected
o copy
o locations
o overlap
o density
o centers
o offgrid_centers
Any number of check_type values can be specified. If this option is not specified, no check
types are unselected.

Command Reference
unselect_checks
Description
This command removes specified rule checks from the Calibre 3DSTACK verification run that
are defined with the check_name_pattern value list or checks that apply to the placements in
the placement_name_pattern list. The syntax and usage is similar to the DFM Unselect Check
command described in the Standard Verification Rule Format (SVRF) Manual. Multiple
unselect_checks commands are allowed in the Calibre 3DSTACK rule file. If multiple
unselect_checks statements are specified, the list is accumulated as shown in Example 2.
The -placements and -check_names arguments are mutually exclusive.
Use the -check_types option to unselect groups of checks by their type.
Examples
Example 1
Unselect a single check:
unselect_checks -check_names {"int_1"}
Example 2
Unselect multiple checks using either of the following methods:
unselect_checks -check_names {".*_1" "ext_2" "enc_2"}
or
unselect_checks -check_names {".*_1"}

unselect_checks -check_names {"ext_2"}
unselect_checks -check_names {"enc_2"}
Example 3
Exclude checks that are used in the interposer and ram placements:
unselect_checks -placements {"interposer" "ram_*"}
Example 4
Exclude internal and external check types from the verification run.
unselect_checks -check_types {internal external}
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
tvf_block
tvf_block
Defines custom checks for the Calibre 3DSTACK rule file.
Usage
tvf_block name ‘{’ body ‘}’ [-export_layers placement_list] [-attach_to_placement placement]
Arguments
• name
Required argument that specifies the name of the TVF block.
• ‘{’ body ‘}’
Required body of TVF code that defines statements for the creation of derived layers.
Enclosing the TVF code in braces, { }, is required.
• -export_layers placement_list
Optional argument and value set that defines the list of resulting placements that can be used
in rule checks.
• -attach_to_placement placement
Optional argument and value set that specifies the placement to which the resulting
placements should be attached. If this option is specified and the derived layer is used in
geometrical rule checks, then any resulting errors that are applied on this derived layer are
reported for the specified placement.
Description
Use this command to define custom checks in the Calibre 3DSTACK rule file. The tvf_block
command provides the capability to define derived layers with the TVF language. The layers
can then be used for centers, density, enclosure, external, internal, offgrid_centers, and overlap
checks. Placements generated from the tvf_block command cannot be used as text placements
in the attach_text command.
Examples
tvf_block creating_logic_to_memory_connects { \
tvf::SETLAYER l_logic_ltsv_to_memory = l_ltsv NOT i_out_M1_tsv; \
} -export_layers [list l_logic_ltsv_to_memory] -attach_to_placement l
copy -check_name creating_logic_to_memory_connects \

-placement l_logic_ltsv_to_memory -comment "saving out layer"
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
tvf_block

Command Reference

Commands that control Calibre RVE results.
Table 4-10. Calibre RVE Commands

Name Description
Check Text Override Check text override comments allow additional control over
Comments for how results are displayed in Calibre RVE. Check text
Calibre 3DSTACK override comments can be specified as options to certain
rule check commands.
set_auto_rve_show_layers Specifies for all rule checks (except tvf_block) whether
Calibre RVE layer highlights show only layers used to
derive the rule check.
set_rve_cto_file Specifies the path to a check text override file that controls
how results are highlighted in Calibre RVE.

Command Reference
Check Text Override Comments for Calibre 3DSTACK
Check Text Override Comments for

Calibre 3DSTACK
Check text override comments allow additional control over how results are displayed in
Calibre RVE. Check text override comments can be specified as options to certain rule check
commands.
Usage
rule_check check_arguments [rve_option ...]
Note
The rve_option argument may be replaced by one or more of the argument and value sets
described under Arguments.The rule_check and check_arguments parameter set are one of
the following verification commands which support check text override comments: connected,
centers, density, enclosure, external, internal, offgrid_centers, and overlap.
Arguments
• -set_rve_highlight_index index
Applies a Calibre RVE Highlight Index comment to the check. The index value is an integer
that specifies the highlight layer index used for the rule check. See “RVE Highlight Index”
in the Calibre Interactive and Calibre RVE User’s Manual for more details.
• -set_rve_highlight_color color
Applies a Calibre RVE Highlight Color comment to the check. The color value (for
example, blue) specifies the layer color used when the rule check is highlighted in supported
layout viewers from Calibre RVE. See “RVE Highlight Color” in the Calibre Interactive
and Calibre RVE User’s Manual for more details.
• -set_rve_priority priority
Applies a Calibre RVE Priority comment to the check. The priority value is an integer that
sets the display priority for a rule check. The rule check priority is displayed in the tree view
of Calibre RVE and can be used to sort the rule checks. See “RVE Priority” in the
Calibre Interactive and Calibre RVE User’s Manual for more details.
• -set_rve_show_layers {layer_list | AUTO}
Specifies the layers that are shown in the layout editor when highlighting a result from the
rule check. The layer_list parameter is a list of layers that are visible when highlighting a
rule check result in the layout editor (non-specified layers are hidden).
The AUTO keyword instructs Calibre RVE to only show the input layers that were used to
derive the rule check.
This command is only supported by Calibre DESIGNrev, Calibre WORKbench, and
Cadence Virtuoso.

Command Reference
In order to use this functionality, you must enable the Calibre RVE option Only show
check-dependent layers while highlighting results (hides other layers) on the Setup >
Options > Highlighting pane in the DRC/DFM Highlighting area. See “RVE Show
Layers” in the Calibre Interactive and Calibre RVE User’s Manual for more details.
• -set_rve_link doc [-anchor_tag tag] [-display_text text]
Applies a Calibre RVE Link comment to the check. This option creates a hyperlink to a
filename specified by the doc value. The link is displayed in the check text pane of
Calibre RVE for the specified rule check. The -set_rve_link command may be specified
with the following optional arguments:
o -anchor_tag tag
An optional keyword and parameter that specifies a named destination (tag) within
the document.
o -display_text text
An optional keyword and parameter that specifies the display text for the hyperlink.
If this keyword and parameter is not included, the hyperlink text displays the full
path.
See “RVE Link” in the Calibre Interactive and Calibre RVE User’s Manual for more
details.
Description
The usage of check text override comments is described in detail in the section “DRC Rule
Check Comments for Calibre RVE” in the Calibre Interactive and Calibre RVE User’s Manual.
The CTO commands can be used to set the priority of text related checks during connectivity
extraction.
Examples
Example
If you want to change the default Calibre RVE highlight color for a rule check, you may specify
the set_rve_highlight_color option as follows:
external -check_name spacing_check -placement1 ${place1}_RAM \

-placement2 ${controller}_CONTROLLER -constraint "< 70 REGION" \
-comment "Spacing 70 RAM-CONTROLLER." -set_rve_highlight_color red
When this check is selected in the Calibre 3DSTACK results database using Calibre RVE, the
new highlight color option is listed in the check comments section. When the result is
highlighted, the result layer in the layout editor is colored red.

Command Reference
Example
Multiple check comment options may also be specified as follows:
centers -check_name centers_interposer -placement1 m_mtsv \

-constraint "<=5" -comment "Pad centers 5um" \
-set_rve_highlight_color yellow \
-set_rve_priority 1 \
-set_rve_link ./docs/spec_1.1.5.txt -display_text "Pad Specification"
Example
To assign priorities to text-related checks, include a CTO in your 3DSTACK rule file as
follows:
set_rve_cto_file -file 3dstack.cto
Where the 3dstack.cto file contains statements similar to the following:
my_connected_check_1
RVE Priority: 1
No_Text
RVE Priority: 2
Floating_Text
RVE Priority: 2
Multi_text
RVE Priority: 2
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
set_auto_rve_show_layers
set_auto_rve_show_layers
Specifies for all rule checks (except tvf_block) whether Calibre RVE layer highlights show only
layers used to derive the rule check.
Usage
set_auto_rve_show_layers {NO | YES}
Arguments
• NO
Specifies not to apply -set_rve_show_layers AUTO to any checks that do not have an
existing Calibre RVE layer specification. This is the default.
• YES
Applies -set_rve_show_layers AUTO to all rule checks (except tvf_block) that do not have
an existing Calibre RVE layer specification.
Description
Use this optional rule file command to control the “-set_rve_show_layers {layer_list | AUTO}”
option for all rule checks (except tvf_block). When this command is specified with YES in the
Calibre 3DSTACK rule file, then -set_rve_show_layers AUTO is applied to all rule checks that
do not already specify the -set_rve_show_layers option. The AUTO keyword instructs Calibre
RVE to only show the input layers that were used to derive the rule checks.
Note
In order to use this functionality, you must enable the Calibre RVE option “Only show
check-dependent layers while highlighting results (hides other layers)” on the Setup >
Options > Highlighting pane in the DRC/DFM Highlighting area. See “RVE Show Layers” in
the Calibre Interactive and Calibre RVE User’s Manual for complete details.
Examples
set_auto_rve_show_layers YES
Related Topics
Assembly Commands
Rule Check Commands

Command Reference
set_rve_cto_file
set_rve_cto_file
Specifies the path to a check text override file that controls how results are highlighted in
Calibre RVE.
Usage
set_rve_cto_file -file cto_file
Arguments
• -file cto_file
Required argument and value that specifies the path to a check text override file.
Description
Use this optional rule file command to specify the path to a check text override (CTO) file. The
cto_file contains DRC RVE check text comments that control how results are highlighted in
Calibre RVE. Only one CTO file is allowed.
Note
The -set_rve_* arguments in your Calibre 3DSTACK rule file take precedence over Calibre
RVE options in your CTO file specified for the same rules.
The following CTO file specifies two check text comments for a rule named pads_on_grid:
# DRC RVE check text override file for a Calibre 3DSTACK rule file
#
pads_on_grid
RVE Highlight color: red
RVE Show Layers: backside_rdl
For complete information on the CTO file and how to load it, see “DRC RVE Check Text
Override File (CTO File)” in the Calibre Interactive and Calibre RVE User’s Manual.
Caution
Calibre RVE searches your working directory and loads a CTO file named 3dstack.rdb.cto if
it exists. Do not use set_rve_cto_file to specify this file if it exists in your working directory
as it is automatically loaded. You may use 3dstack.rdb.cto as the CTO filename if it exists
outside of your working directory.
Examples
set_rve_cto_file -file ./custom_rve_settings.cto
Related Topics

Command Reference
set_rve_cto_file
Assembly Commands
Rule Check Commands

Chapter 5
Calibre 3DSTACK+ Extended Syntax
Reference
The Calibre 3DSTACK rule file supports an extended version of the 3D-IC Description
Language (3D-IC DL) commands, called 3DSTACK+. The 3DSTACK+ syntax is a universal
language that allows you to define your 3DSTACK assembly and rule checks with some
additional features.
The 3DSTACK+ syntax can also be used to decouple rule and analysis specifications from the
physical assembly, similar to a typical design flow. This enables you to reuse rule files for
multiple assemblies.
The command line arguments are the same for 3DSTACK+ and standard 3DSTACK.
See “Calibre 3DSTACK+ Extended Syntax File Format” on page 184 to view required format
and syntax rules.

Calibre 3DSTACK+ Extended Syntax Reference
Calibre 3DSTACK+ Extended Syntax File Format
Calibre 3DSTACK+ Extended Syntax File

Format
Input for: Calibre 3DSTACK
File format used to define the physical assembly of a 3D or 2.5D IC.
Format
A Calibre 3DSTACK+ rule file must conform to the following formatting and syntax rules:
• The 3DSTACK+ file is parsed as a Tcl file. It must follow standard Tcl syntax and
formatting rules. Standard Tcl constructs are supported.
• There is a required opening line and set_version command:
#!3dstack+
• The assembly commands are die, config, and stack. These are summarized in the
following section.
• The standard Calibre 3DSTACK verification commands are supported, but you must
use arguments specific to the 3DSTACK+ syntax.
• All distances are specified in microns.
Parameters
Table 5-1. Extended Calibre 3DSTACK Command Summary

Keyword Calibre Description
3DSTACK
Usage
Assembly Commands
die Required Defines a single die in the assembly. This
statement includes a number of arguments that
define the name, layout path, and physical
information about the die, such as the material,
layers, and dimensions.
config Optional Specifies configuration information, such as the
top cell name, source netlist, report file, and
connectivity,
stack Required Defines the locations of dies in the assembly.
Rule Check and Analysis Commands

Rule Check and Analysis Commands for the Calibre 3DSTACK+ Extended Syntax
Table 5-1. Extended Calibre 3DSTACK Command Summary (cont.)

Keyword Calibre Description
3DSTACK
Usage
The 3DSTACK+ extended syntax supports the same set of verification commands that are
defined in the standard 3DSTACK syntax, with some usage differences and additional
parameters. See “Rule Check and Analysis Commands for the Calibre 3DSTACK+ Extended
Syntax” on page 185.
select_checks (Extended Optional Specifies checks to execute.
Syntax)
unselect_checks Optional Specifies checks to not execute.
(Extended Syntax)
custom_check Optional Defines custom checks using TVF format.
set_version Required The current version is 1.0.
3dstack_block Optional Defines a code block in which standard Calibre
3DSTACK rule file format commands can be
specified.
Examples
#!3dstack+
#===========================================#
# Calibre 3DSTACK+ Rule File
# ==========================================#
<die commands>
…
<stack commands>
…
<verification commands>
…
Rule Check and Analysis Commands for the

Calibre 3DSTACK+ Extended Syntax
The 3DSTACK+ extended syntax supports the same set of verification commands that are
defined in the standard 3DSTACK syntax. Additional options are available in 3DSTACK+ and
the connected check has a different behavior.
The following verification commands are supported:
centers enclosure locations

connected external offgrid_centers

copy internal overlap
density
These subsections discuss verification commands in the 3DSTACK+ syntax:
“Differences in Verification Commands Between Standard and 3DSTACK+ Syntax” on

page 186
“Rule Check Command Arguments” on page 186
“Connected Check in 3DSTACK+” on page 187
“Viewing Verification Results” on page 188
“Verification Examples” on page 189
Differences in Verification Commands Between Standard and 3DSTACK+

Syntax
The usage of verification commands is almost the same as in the corresponding standard
3DSTACK syntax. The following differences exist for 3DSTACK+:
• Rule checks in the 3DSTACK+ file take placement layer types instead of placement
(layer) names.
• You can specify stack names in rule checks to apply rules to certain stacks.
• The -direction argument allows you to specify the vertical direction in which a check is
applied.
• The connected check is applied in a different manner and has options to specify white
box and black box checking. See “Connected Check in 3DSTACK+” on page 187.
• You can define a custom check using TVF statements with the custom_check command.
• The select_checks and unselect_checks commands have different syntax; see
select_checks (Extended Syntax) and unselect_checks (Extended Syntax).
Rule Check Command Arguments

The following arguments are available with all verification commands in 3DSTACK+ extended
syntax:
• -stack ‘{’ stack_name_list ‘}’

Optional argument and value set that specifies the stack(s) for which the rule check is
applied. If this argument set is not specified, the check is applied to all stacks. The stack

with the given name should be specified. If the -stack argument is specified, the checks
are applied only to specified stack(s).
• -direction {up | down | both}
Optional argument and value set that specifies the direction of the check. If the
-direction argument is specified, the checks are performed only in the specified
direction.
o up — The check is only performed from the bottom to the top of the stack. This is
the default.
o down — The check is only performed from the top to the bottom of the stack.
o both — The check is performed in both directions
Note
The -direction option does not apply to the connected command.
• -layer_type placed_layer_type
| {-layer_type1 placed_layer_type1 -layer_type2 placed_layer_type2}
| -layer_types {placed_layer_type …}
Argument and value set that specifies the type(s) of the layer for which the check is
applied. All geometrical checks are applied on interfacing (interacting) placement layers
defined by the stack(s). The placement layer refers the layer of the die placement.
The argument used depends on the rule check as follows:
o -layer_type — Used for check with one layer argument: copy and offgrid_centers.
o -layer_type1 and -layer_type2 — Used for checks with two layer arguments, where
the second layer argument may be optional: centers, connected, enclosure, external,
internal, locations, and overlap.
o -layer_types — Used for the density check.
For example, if a check is defined between layer_type1 and layer_type2, all the
placement layers of layer_type1 that interact with the placement layer of layer_type2 (as
defined by the stack) are checked against each other.
If the check has only one layer type specified, the check is done on all placement layers
of that type.
Connected Check in 3DSTACK+

The connected check is applied in the following manner in a 3DSTACK+ 2.0 rule file:
• Checks between interfacing placement layers defined by the stack(s).

• Checks between placement layers within the same tier that directly interface with the
interposer die placement.
• Ignores the -direction option.
The connected check in 3DSTACK+ has two additional optional arguments:
• -black_box — Use black box connection checking. As an example, even if internal

routing layers for the interposer are defined in the assembly file, block box checking is
performed. If tiers are defined with the stack command, connectivity checks are applied
between the interposer and the dies of the interacting tier but not between dies within a
tier.
• -white_box — Use white box connection checking. As an example, routing layers are
checked through the interposer. If tiers are defined with the stack command,
connectivity checking is applied between dies within the tier that interact with the
interposer. A compiler error occurs if the internal routing layers of the interposer are not
defined in the assembly file and -white_box only is specified.
Both -black_box and -white_box may be specified. If neither is specified, both are used.
See the “Verification Examples” section for an example.
Viewing Verification Results

Results from a 3DSTACK+ run are analyzed in the same way as results from a run with a
standard syntax rule file; see “Calibre 3DSTACK Results Analysis Examples” on page 38.
Verification results from 3DSTACK+ rule files have the following additional properties, which
can be used to group results by check or layer type:
Property Description
Check+ Check name
type1 placed_layer_type or placed_layer_type1
type2 placed_layer_type2
types placed_layer_type list for density check
However, these properties are not added for custom_check results.
Check Result Naming Conventions

The generated check names use the following format (the < > brackets are not part of the
format):
<check-name>_<check-index>

where:
• check-name is the name of the check

• check-index is a generated number for the check, starting at 1.
Verification Examples
Example 1: Enclosure Check
This rule example applies to all interacting pad-bump layers in the upward direction (the
default) for all stacks. It measures the separation distance between the exterior-facing sides of
pad layer edges and the interior-facing sides of bump layer edges.
enclosure -check_name enc -layer_type1 pad -layer_type2 bump \

-constraint "<0.4"
Example 2: External Check

This example rule measures the separation distance between the exterior-facing sides of pad
layer edges and the exterior-facing sides of edges of the same layer.
external -check_name ext -stack {st1 st2} -layer_type1 pad \

-constraint "<0.4"
Example 3: Internal Check

This example rule applies to all interacting pad-to-pad layers in both the upward and downward
directions of all stacks. The check measures the separation distance between the interior-facing
sides of pad layer edges and the interior-facing sides of interacting pad layer edges.
internal -check_name int -direction both \

-layer_type1 pad -layer_type2 pad -constraint "<0.4"
Example 4: Offgrid Check

This example check detects the pads of route layer that are not aligned to a 5 micron square grid.
offgrid_centers -check_name off_mem -layer_type route -resolution 5
Example 5: Density Check

This example check computes the density of an input layer’s route and bump types.
density -check_name den1 -layer_types {route bump} -constraint "<0.1"
Example 6: Connected Check

This example defines two dies, INT and MEM, and a stack of two placements, where the MEM
die is placed on top of one INT die.
Based on the defined stack, the connectivity check conn1 derives three separate connectivity
checks:
• Between the bump type of placement layers of the INT die placement and the first
placement of the MEM die

System Variables
• Between the bump type of placement layers of the INT die placement and the second
placement of the MEM die
• A separate check between the bump type of placement layers of two MEM die
placements, since they are defined within the same tier.
die -die_name INT -interposer -layout {-path ./INT.gds} \
-anchor mem1 0 0 -anchor mem2 1000 0 \
-layer_info {-type bump -bottom -layer 43 -text 44}
die -die_name MEM -layout {-path ./MEM.gds} \
-anchor int 0 0 \
-layer_info {-type bump -bottom -layer 40 -text 40}
stack -stack_name w_tier \
-die {-name INT -invert -rotate 90} \
-tier { \
-die {-name MEM -anchor INT mem1 anchor_INT} \
-die {-name MEM -anchor INT mem2 anchor_INT} \
}
connected -check_name conn1 -layer_type1 bump -layer_type2 bump
Both white box and black box checking is performed (the default).
Example 7: Connected Check, White Box and Black Box Checking

The following check for a 2.5D example performs black box connection checking even if the
internal routing layers of the interposer are defined in the assembly file:
connected -check_name connect_bb -layer_type1 pad -layer_type2 pad \

-black_box -detailed \
-comment "BB CONNECT between interposer and interacting dies"
The following check performs white box checking. It checks the physical connection of the pad
layers through the interposer.
connected -check_name connect_wb -layer_type1 pad -layer_type2 pad \

-white_box -detailed \
-comment "WB CONNECT between interposer and interacting dies"
Related Topics
3DSTACK+ Extended Syntax Command Reference
System Variables
The 3DSTACK+ file format supports a set of system variables that allow you to easily reference
layer placements based on the specified type.
The following variables are available:
• _layer_type

System Variables
• _layer_types
• _layer_type1
• _layer_type2
The following examples demonstrate how to apply the variables in your rule file:
connected -check_name chk \

-stack P \
-layer_type1 pad1 \
-layer_type2 pad1 \
-comment "CONNECTION CHECKS between ${_layer_type1} pads
interacting with ${_layer_type2} pads" \
-set_rve_show_layers "${_layer_type1} ${_layer_type2}"
density -check_name chk \

-stack P \
-layer_types {pad1 pad2} \
-constraint ">0" \
-comment {DENSITY CHECKS between ${_layer_types}} \
-set_rve_show_layers "${_layer_types}"

3DSTACK+ Extended Syntax Command Reference
3DSTACK+ Extended Syntax Command

Reference
The 3DSTACK+ rule file can contain system, assembly, and rule check commands.
See the “Calibre 3DSTACK+ Extended Syntax File Format” on page 184 for a description of
the rule file format. See “Rule Check and Analysis Commands for the Calibre 3DSTACK+
Extended Syntax” on page 185 for a description of the rule check options specific to the
3DSTACK+ extended syntax.
die . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
custom_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
select_checks (Extended Syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
unselect_checks (Extended Syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
3dstack_block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

die
die
Required in 3DSTACK+ extended syntax file.
Defines a single die in the assembly. This statement includes a number of arguments that define
the name, layout path, and layers.
Usage
die -die_name die_name -layout ‘{’ -path layout_path
[-type {gdsii | oasis}] [-primary primary_name]
[-depth {all | top-only}] [-precision value] ‘}’
[-thickness value]
{-layer_info ‘{’ -type layer_type -name layer_name
{-layer ‘{’ layer_numbers [-depth {all | top-only}] ‘}’
| -svrf ‘{’ layer_derivation ‘}’ [-show]
[-text ‘{’ layer_numbers [-depth number] [-no_update] ‘}’ ] | [-trace_text]
[-ext_connect]
[-top | -bottom]
}…
‘}’ } …
[-anchor‘{’-name anchor_name {-placement x_offset y_offset
| -layer number -text label}‘}’] …
[-interposer]
[-rename_text “expression …”]
[-import_text_labels file]
[-wb_connect layer1_name layer2_name [BY layer3_name] ] …
Arguments
• die
Required argument that specifies the beginning of a die definition.
• -die_name die_name
Required argument and value set that specifies the name of the die. The die can be thought
of as a cell in your design. The name must be unique within the assembly.
• -layout ‘{’ arguments ‘}’
Required argument and value set that specifies the path, layout system type, and top cell of a
layout. The arguments for -layout are described as follows:
o -path layout_path
Required argument and value set that specifies the path to a GDS or OASIS layout
file used for the die.
o -type {gdsii | oasis}

die
Optional argument set that specifies the layout system for the die. The default is
gdsii.
o -primary cell
Optional argument set that specifies the name of a cell in the layout. If this argument
set is not specified, the cell is assumed to use the name specified by the die_name
argument.
o -depth {all | top-only}
Optional argument set that specifies whether all of the layout should be read or just
the layout that belongs to the specified primary cell. The default is that all of the
layout geometry is read. Specify -depth top-only to only import geometry that
belongs to the specified primary cell.
o -precision value
Optional argument and value that specifies the precision of the layout file, where
value is the ration of database units to user units.
The -precision argument is only used if layer derivation is specified with the -svrf
argument with -layer_info. If using layer derivation and the precision differs from
1000 (the default), the -precision argument is required, otherwise the argument is not
required.When layer derivation is not used, the precision is handled automatically
and the -precision argument is not used.
• -thickness value
Optional argument and value that defines the thickness of the die in microns used to
generate the cross-section assembly view of the stack. See “Assembly Views” on page 28
for details.
If this option is not specified, you can use the
• -layer_info ‘{’ arguments ‘}’
Required argument and value set that specifies a layer in the die. You can specify more than
one layer by applying the -layer_info argument set multiple times. Note that you must
enclose the arguments for each layer within the {} braces. The arguments for -layer_info are
described as follows:
o -type layer_type
Required argument set within -layer_info that specifies the type of layer. The
layer_type is used in rule or analysis operations and can be any user-defined string.
However, it is recommended that layer_type values should identify common
building blocks of 3D ICs, such as pad, bump, c4, tsv, and rdl layers.

die
o -name layer_name
Required argument set that specifies the name of the layer. The layer_name does not
have to be unique.
o -layer ‘{’ layer_numbers [-depth {all | top-only}] ‘}’
Argument and value set that specifies the layer number, datatype, and depth for the
layer. One of -layer or -svrf must be specified for each -layer_info argument. You
must enclose the arguments for each layer within the {} braces.
• layer_numbers — Required argument with -layer that specifies the layer
numbers and datatypes used for the layer in the specified die layout. Multiple
layer numbers and datatypes may be specified as a range or separated by
commas; the layers are merged. For example:
-layer 2-7,16-23
-layer 40-41:3-7
• -depth {all | top-only} — Optional argument set that specifies whether all of the
layer should be read or just the parts of the layer that belong to the specified
primary cell. The default is that all of the layer geometry is read. Specify -depth
top-only to only import geometry on this layer that belongs to the specified
primary cell.
o -svrf ‘{’ layer_derivation ‘}’ [-show]
Argument and value set that specifies a layer derivation using SVRF commands.
One of -layer or -svrf must be specified for each -layer_info argument. Only one
-svrf argument can be used within a -layer_info argument set.
The -svrf option is similar in function to that of a rule check statement. The
layer_derivation must consist of at least one standalone layer operation, which is the
output layer. If two output layers are specified, they are merged. Local layer
definitions can be used in the layer derivation.
If the layout precision is not the default (1000) and the -svrf option is used, the
precision must be specified with the -precision option.
The -svrf argument set has the following option:
• -show — Optional argument that writes derived layers to the generated assembly
view of your stack. If this option is not specified, no derived layers are included
in the assembly layout view.
o -text ‘{’ layer_numbers [-depth number] [-no_update]‘}’
Optional argument and value set that specifies the text number, datatype, and depth.
Note that you must enclose the arguments for each text layer within the {} braces. It
is valid to specify the -text argument set by itself, without a -layer or -svrf argument,
but this is not generally considered useful.

die
• layer_numbers — Required argument that specifies the layer numbers and

datatypes used for the text layer in the specified die layout. Multiple layer
numbers and datatypes may be specified as a range or separated by commas; the
layers are merged. For example:
-layer 2-7,16-23
-layer 40-41:3-7
• -depth number — Optional argument set that specifies the level of design
hierarchy from which to retrieve the text labels. If this argument set is not
specified, text labels are retrieved from all levels of design hierarchy.
• -no_update — Optional argument that specifies the layer is not included in the
extracted layout netlist. Similar to the -no_update argument for attach_text.
o -trace_text
Optional argument that specifies to trace text connectivity from the layer specified
by -layer. In order for text tracing to work, the full white box connectivity must be
defined with the -wb_connect option. Cannot be specified with the -text option. The
following is an example of the usage of -trace_text:
-layer_info { -type pad -name ext_pad -text {137:122 -depth 1} }
-layer_info { -type bump -name metal1_bottom -layer 253:0 \
-trace_text ext_pad -top }
-layer_info { -type route -name via1_bottom -layer 251:0 }
-wb_connect ext_pad metal1_bottom BY via1_bottom
o -ext_connect
Optional argument that specifies the die’s external interface layer for connectivity
purposes. This option is used to explicitly define the off-die interface layers for
connectivity tracing.
o -top
Optional argument that indicates that the layer is physically placed on the top side of
the die. This argument is needed to correctly connect the interface layers in the stack.
o -bottom
Optional argument that indicates that the layer is physically placed on the bottom
side of the die. This argument is needed to correctly connect the interface layers in
the stack.
Note
If the -top or -bottom keywords are not specified, then the layer is considered
internal to the die and cannot be identified as an interacting layer. As a result, the
layer cannot be used in checks with two layer types.

die
• -anchor‘{’-name anchor_name {-placement x_offset y_offset | -layer number -text label}‘}’

Optional argument and value set that creates an anchor with a specified name at an x and y
coordinate specified in microns. You can specify multiple anchors per die. The anchor is a
labeled coordinate that can be referenced in assembly operations for alignment purposes.
The options are defined as follows:
-name anchor_name — specifies the name of the anchor.
-placement x_offset y_offset — specifies the coordinates of the anchor in microns.
-layer number — specifies the anchor layer.
-text label — specifies the label name to identify the anchor location on the layer.
• -interposer
Optional argument that specifies that the layout is an interposer. This is used for 2.5D ICs
when you want to generate a hierarchical netlist or create specific rules for an interposer.
This option can only be applied once (only one interposer is allowed in a 3DSTACK
assembly.
• -rename_text “expression …”
Optional argument set that renames text in the die layout. The expression is a GNU regular
expression. Multiple expressions are supported, but the entire set of expressions must be
enclosed in quotes or braces {}. For example:
-rename_text "/</\[/ />/\]/"
• -import_text_labels file
Optional argument set that specifies a text label file. See “import_text_labels” on page 116
for more details.
• -wb_connect layer1_name layer2_name [BY layer3_name]
Optional argument set that defines the connectivity of the materials inside of the die. This is
only required for hierarchical (white-box) connectivity extraction of the assembly.
Description
The die command is the primary building block for chips in your assembly. It defines the
following components of a die:
• Layout path and layout format (GDSII or OASIS).

• Physical geometry (length, width, and thickness).
• Anchor points for assembly alignment.
• Layers used in the die.
• Layout type: interposer or regular die.
• Hierarchical connectivity

die
The die layout is defined from a GDS or OASIS file.
The anchors are labels fixed to coordinates on specified dies that can be referenced in the stack
definition for alignment purposes. For example, you can specify an anchor at the center of a die
called controller_center and then use the controller_center label in your assembly operations to
place other dies relative to the center of the controller.
The -interposer argument has no impact on the assembly, but it can be referenced in
downstream rules to apply specific checks for 2.5D ICs.
Use the -text option to relate text labels to the layers of the dies. These associations are required
if there are connectivity checking rules defined in the deck. The -no_update argument should be
used when associating text with a source placement layer for use with a locations check. This
prevents the source layer from being included in the extracted layout netlist.
Multiple layers may be specified for each die.
Use the -svrf option to generate derived layers within the die. In order for layer derivations to
work successfully, the precision of the layout must be specified.
The hierarchical (white-box) connections define the connectivity of the materials inside of the
die for netlist extraction purposes. When specified, the intra-die and inter-die connectivity is
taken into account during connectivity rule checking.
Through-tier connectivity checks are supported. This feature allows you to verify connections
that pass through multiple dies. For example, if you stack ChipA on top of an interposer and
ChipB on the bottom of the interposer, you can verify the connectivity of the traces from the
pads of ChipA, through the interposer layers, and down to the pads of ChipB. This feature is
achieved by defining internal layers for a die without specifying the -top or -bottom options for
those layers.
The -layer_info argument of the die command allows you to specify whether the layer belongs
to the top or bottom surface of the die. If you do not specify either -top or -bottom, the layer is
considered internal to the die and is used for internal connectivity tracing.
Note
If you do not want to check connectivity through tiers, apply the -nothrutier option in the
connected check.
Examples
Example 1
The following command defines a new die based on an existing layout for a memory device.

die
die \
–die_name RAM_block \
–layout { -path ./RAM.oas –type OASIS –primary RAM } \
-thickness 150 \
-layer_info { -type pad -name pad1 –top \
-layer { 40:2,41:2 } –text { 40:2,41:2 } } \
-layer_info { -type pad -name pad2 –bottom \
-layer { 8-15:0 } -text { 24-39:1 } } \
-layer_info { -type bump -name bump1 –top \
-layer { 2-7,16-23 } } \
-layer_info { -type bump -name bump2 –bottom \
–layer { 40-41:3-7 -depth top_only} –text { 40:3 –depth 1 }
} \
–rename_text "/a_bump/a/"
The new die is given the name RAM_block. The die definition includes the following layers:
Table 5-2. Layer Information for the RAM_block Die

Name Type Vertical Layer Numbers Text Numbers Depth
Location Number Datatype Number Datatype
pad1 pad Top 40, 41 2 40, 41 2 All
pad2 bump Bottom 8-15 0 24-39 1 All
bump1 bump Top 2-7, 16-23 any none none All
bump2 bump Bottom 40-41 3-7 40 3 Top cell
• pad1 and pad2 are of type pad, and bump1 and bump2 are of type bump. pad1 and
bump1 are in the top surface of the die, and pad2 and bump2 are in the bottom of the die.
• pad1 is the merger of layer number 40 and datatype 2 with layer number 41 and datatype
2. The text on it is associated from the same layers.
• pad2 is the merger of layer numbers from 8 to 15 with datatype 0. The text on it is
associated with layer numbers from 24 to 39 with datatype 1.
• bump1 is the merger of layer numbers from 2 to 7 with all datatypes and layer numbers
from 16 to 23 with all datatypes. It has no associated text.
• bump2 is the merge of layer numbers 40-41 with datatypes from 3 to 7. The text on it is
attached from layer number 40 with datatype 3 from only the top cell.
Any text on all layers of the die are from “a_bump” to “a” with the rename_text option and the
GNU regular expression “/a_bump/a/”.

die
Example 2
die
–die_name INT
–layout {-path ./INT.gds}
-anchor mem 0 0
-anchor log 1000 0
-interposer
-layer_info {-type pad -name pad1 -layer 40 -top}
-layer_info {-type pad -name pad2 -layer 41 -top}
-layer_info {-type route -name route -layer 42 -top}
-wb_connect pad1 pad2 BY route
The die command defines an interposer die with the name INT. The die has two anchors: mem
at (0,0) location, and log at - (1000,0).
The die also has three defined layers: pad1, pad2, and route. pad1 and pad2 are of type pad, and
route is of type route. All three layers are on the top surface of the die.
pad1 and pad2 are connected via route.
Example 3
This example shows the definition of a die with the name der. The die has three layers defined:
pad1, pad2, and merge. pad1 and pad2 are original layers, and merge is a derived layer which is
a union of pad1 and pad2.
die –die_name der \

–layout {-path ./der.gds} \
-layer_info {-type pad -name pad1 -layer 40 -top} \
-layer_info {-type pad -name pad2 -layer 41 -top} \
-layer_info {-type merge -name merge \
-svrf {MERGE (EXTENT DRAWN pad1 pad2)}}
Example 4
The following example demonstrates the anchor usage:
die -die_name T2 \
-layout { -path $env(DESIGN_DIR)/dfm/3di/init/layout_1.gds -type gdsii \
-primary top }
-layer_info { -type bump -name 22 -layer 2 } \
-anchor { -name anch3 -layer 22 -text VSS } \
-anchor { -name anch4 -placement 200 300 }
Related Topics
stack

stack
stack
Required in 3DSTACK+ extended syntax file.
Defines the locations of dies in the assembly.
Usage
stack -stack_name stack_name {die_stack | tier_spec | stack_ref }…
die_stack Usage
-die ‘{’
-name die_name
[-anchor die_anchor_name from_anchor_name to_anchor_name | -placement x y]
[-mag factor] [-rotate angle] [-flip {x | y}] [-invert]
[-rename_text “expression” … ]
[-ignore_pin “expression” …]
[-source source_name]
‘}’ [-z_origin value]
tier_spec Usage
-tier ‘{’
{die_stack | stack_ref }…
‘}’
stack_ref Usage
-stack stack_name
Arguments
• -stack_name stack_name
Required argument set that specifies a stack name used in rule check commands. If this
command is specified multiple times, each stack_name value must be unique.
• -die ‘{’ arguments ‘}’
Argument set that specifies a die placement. The arguments are described as follows:
o -name die_name
Required argument and value set that specifies a die placement. The die must be
defined in the file.
o -anchor die_anchor_name from_anchor_name to_anchor_name
Optional argument and value set that specifies the anchoring information.
die_anchor_name specifies the name of the die already being placed in the stack.
from_anchor_name specifies the name of an anchor defined for the
die_anchor_name die. to_anchor_name specifies the name of an anchor defined for
the current die_name die. -anchor and -placement are mutually exclusive. If both
options are not specified, the die is placed at the location of the last specified die.

stack
o -placement x y
Optional argument and value set that specifies the location to place the die. The
location is defined by x and y coordinates (x y) and should be specified in microns. –
anchor and –placement are mutually exclusive. If both options are not specified, the
die is placed at the location of the last specified die. If there is no previously placed
die, the default placement location is (0 0).
o -mag factor
Optional argument and value set that specifies a magnification factor by which to
expand or shrink the die placement. Coordinate data in the die is multiplied by the
specified factor.
o -rotate angle
Optional argument and value set that specifies the rotation angle of the current die
placement. The angle must be 0, 90, 180, or 270. -rotate is an option to –die and it
should always follow the –die argument.
o -flip {x | y}
Optional argument and value set that specifies the axis around which the current die
placement is flipped. -flip is an option to –die and it must always follow the –die
argument.
o -invert
Optional argument that indicates that the layers with the top connections become
bottom connections, and vice versa in the current die placement. -invert is an option
to –die and it must always follow the –die argument.
o -rename_text “expression” …
Optional argument and value set that specifies the rule for text renaming. The
expression is a GNU regular expression.
o -ignore_pin “expression” …
Optional argument and value set that specifies an expression that matches one or
more pin names to be ignored in layout extraction. The expression is a case-
insensitive GNU regular expression.
o -source source_name
Optional argument and value set that specifies the corresponding source placement
of a cell, similar to the map_placement command in standard 3DSTACK.

stack
Hierarchical names are supported if the source netlist is hierarchical; use the forward
slash (/) as the hierarchy separator. For example:
• A source netlist has a top cell named 3DSTACK_TOP that contains one
placement, named INTERPOSER, of the sub-circuit INTERPOSER_CHIP.
• The INTERPOSER_CHIP has two placements, named DIE1 and DIE2.
In order to map to DIE1, you specify the hierarchical source_name as
INTERPOSER/DIE1.
• -tier ‘{’ {die_stack | stack_ref}… ‘}’
Argument and value set that specifies a tier consisting of dies and stacks placed at the same
z coordinate. A tier provides a method to place elements side-by-side. Additional
connectivity checking is performed between the die placements within the same tier.
• -stack stack_name
Argument and value set that specifies the name of a stack defined in the 3DSTACK+ rule
file. The same stack cannot be referenced more than once.
• -z_origin value
Optional argument set that specifies the height of the die from the bottom of the stack,
section assembly view. See “Assembly Views” on page 28 for details.
Description
The stack statement defines the assembly operations that construct your 3D package. It defines
the locations of die placements and interface layers that connect die placements. The stack
represents any set of vertical alignments. A true 3D stack may consist of multiple die
placements. In a 2.5D interposer approach, each stack consists of a single die placement and the
interposer. It is also possible to have an interposer with multiple stacks, each consisting of more
than one die placement.
For Calibre 3DSTACK, all stack definitions are combined into a single assembly.
At least one die, stack, or tier must be specified. The elements can be specified multiple times.
The order of stack arguments determines the stack’s structure. The order in the stack is from
bottom to top and does not always indicate whether die placements interact with one another.
Each subsequent element in the stack is placed in a layer with the z coordinate greater than the z
coordinate of the previous element.
The -tier option is used to group elements side by side—all elements in a tier are at the same z
location. The -tier option has special meaning during connectivity checking (see “Rule Check
and Analysis Commands for the Calibre 3DSTACK+ Extended Syntax” on page 185 for more
details).

stack
Placement Naming Conventions

The generated placement names use the following format (the < > brackets are not part of the
format):
<stack-name>_tier<tier-index>_<die-name><placement-id>
where:
• stack-name is the name of the stack.

• tier-index is a generated number for the tier’s position in the stack. The numbering starts
from 1 and increases by 1 for each tier from the bottom to the top of the stack.
• die-name is the name of the die.
• placement-id is an identification number for each unique tier and die pair.
Examples
stack
–stack_name w_tier
-tier {
–die {-name RAM –mag 1.1 –flip x -placement 0 0}
–die {-name RAM –mag 1.1 –rotate 90 –flip y -placement 0 750}
–die {-name RAM –mag 1.1 –rotate 180 -placement 750 0}
–die {-name RAM –mag 1.1 –rotate 270 -placement 750 750}}
-die {-name INT –invert –rotate 90}
-tier {
-die {-name MEM –anchor INT anchor_MEM1 anchor_INT -source memory1}
-die {-name MEM –anchor INT anchor_MEM2 anchor_INT -source memory2}
-die {-name MEM –anchor INT anchor_MEM3 anchor_INT -source memory3}}
-die {-name MEM –placement 100 100}
The preceding example defines a stack named w_tier with the following die placements (for
simplicity, the height of each die placement is 100):
• The first four dies form a tier:

o RAM die placement at position (0, 0, 0) magnified by 1.1 factor and flipped across
the x axis.
o RAM die placement at position (0, 750, 0) magnified by 1.1 factor, rotated 90
degrees and flipped across the y axis.
o RAM die placement at position (750, 0, 0) magnified by 1.1 factor and rotated 180
degrees.
o RAM die placement at position (750, 750, 0) magnified by 1.1 factor and rotated 270
degrees.
• INT die placement at position (0, 0, 100) rotated 90 degrees and inverted top and bottom
layers of it.

stack
• The next three dies form another tier and the -source option is used:
o MEM die placement at position (0, 0, 200) calculated by anchor definition.
• MEM die placement at position (100, 100, 300).
Related Topics
die

custom_check
custom_check
Defines custom checks using TVF format.
Usage
custom_check -check_name check_name
[-stack stack_list] [-direction {up | down | both}]
-layer_type1 ‘{’ placed_layer_type1… [-merge] ‘}’
[-layer_type2 ‘{’ placed_layer_type2 … [-merge] ‘}’ ]
-tvf ‘{’ tvf_body ‘}’
Arguments
Required argument set that specifies the check name. The check name must be unique in the
rule file. The check name is used in the output result database.
• -stack stack_list
Optional argument set that specifies the stack(s) the check is applied to. The check is
applied to all stacks if this argument is not specified.
• -direction {up | down | both}
Optional argument set specifying the direction of the check if two layer types are specified.
o up — Apply check from bottom to top (default).
o down — Apply the check from top to bottom.
o both — Apply the check in both directions.
• -layer_type1 ‘{’ placed_layer_type1 … [-merge] ‘}’
A required argument set that specifies the layer type(s) the check applies to. If -merge is
specified all layers of the specified type(s) are merged before the check is applied.
• -layer_type2 ‘{’ placed_layer_type2 … [-merge] ‘}’
An optional argument set that specifies one or more layer types used for a second layer
argument in the rule check. The check is applied to layers of layer_type1 and layer_type2
that interact. If -merge is specified all layers of the specified type(s) are merged before the
check is applied.
• -tvf ‘{’ tvf_body ‘}’
Required argument set that specifies a block of TVF statements that define a rule check. See
the “Description” section for more information on writing the rule check body.
If a list is used within the command body, braces ({…}) should be used to enclose the list to
ensure correct evaluation. Do not use the list syntax ([list …]).

custom_check
Description
The custom_check command defines a custom rule check using TVF statements. Internally, the
tool generates a set of TVF blocks with the correct layer arguments depending on the layer types
specified with -layer_type1 and -layer_type2.
If custom_check is defined with only the -layer_type1 argument, then a set of TVF rule checks
is generated for all layers corresponding to placed_layer_type1. If -merge is specified all
matching layers are merged and only one rule check is generated for the merged layer.
If both -layer_type1 and -layer_type2 are specified, then a set of TVF rule checks is generated
using interacting layer pairs of type placed_layer_type1 and placed_layer_type2. If -merge is
specified all matching layers are merged and only one rule check is generated for the merged
layer.
Rule Check Construction

The rule check body (tvf_body) is constructed with tvf::SETLAYER and tvf::OUTLAYER
statements. Each rule check body must have at least one TVF::OUTLAYER statement defining
the output layer of the rule check. Use multiple tvf::OUTLAYER statements to output more
than one layer.
The TVF::OUTLAYER statement can have only argument, the output layer name, when used in
Calibre 3DSTACK. Use the TVF::SETLAYER statement for layer derivations. For example,
the following construction causes an error:
# INCORRECT, multiple arguments to OUTLAYER cause error

TVF::OUTLAYER EXT via < 0.35 ABUT < 90 SINGULAR
The output layer for the preceding example is correctly specified as follows:
# CORRECT, use SETLAYER for derivation and OUTLAYER with one argument
TVF::SETLAYER out = EXT via < 0.35 ABUT < 90 SINGULAR
TVF::OUTLAYER out
Comments may be specified with tvf::COMMENT; check text comments are specified with
tvf::@. See “Rule checks in Compile-Time TVF” for details.
Tcl Coding Guidelines for custom_check

The tool performs command substitution and evaluates Tcl variables before evaluating the code
within the rule check body. Use the following guidelines when using Tcl within the tvf_body:
• Do not change the value of global Tcl variables. Global variables may be used within the
rule check body, but any changes are local in scope. Therefore, modification of such Tcl
variables within the tvf_body may result in undefined or undesired behavior.
• Do not declare Tcl variables within the tvf_body. Usage of locally declared variables
results in an error.

custom_check
• Use the {A B …} list construction. Do not use the list command because command
substitution takes place and the list command is evaluated.
For example, the command [list A B] is evaluated and replaced by “A B” (without
quotes), which is generally not the intent, as it is no longer a list. Use the {A B} list
construction for proper evaluation.
The following actions take place when the custom_check code body is evaluated:
1. Command substitution and Tcl variable evaluation takes place. Use the preceding
coding guidelines to ensure correct evaluation.
2. The evaluated custom_check code body is passed to the generated 3DSTACK rule file,
along with other commands converted from 3DSTACK+ to standard 3DSTACK.
No syntax checking is done for the 3DSTACK commands within the custom_check,
therefore any errors are reported during the 3DSTACK rule file compilation or at
runtime, not during the 3DSTACK+ rule file compilation step.
Examples
Example 1
A custom check between two interacting pad layers.
custom_check –check_name c1 –layer_type1 pad –layer_type2 pad {

tvf::@ Internal between layers $_layer_type1 and $_layer_type2
tvf::@ RVE Highlight Color: red
tvf::SETLAYER c1 = INT $_layer_type1 $_layer_type2 < 0.4
tvf::OUTLAYER c1
}
Example 2
A custom check that checks the ratio of the die area to package area.
die –die_name die1 –layout {-path ./die1.gds} \

-layer_info {-type pad1 -layer 1}
die –die_name die2 –layout {-path ./die2.gds} \
-layer_info {-type pad2 -layer 1}
die –die_name pack –layout {-path ./pack.gds} \
-layer_info {-type ext -layer 2}
stack -die {-name pack} \

-tier {
-die {-name die1 –invert}
-die {-name die2 –placement 1000 0 –invert}
}

custom_check
custom_check -check_name area_die_pack \

-layer_type1 ext \
-layer_type2 {pad1 pad2 –merge} \
-tvf {
tvf::@ ratio of interacting tiers greater than 60 percent
tvf::SETLAYER out = \
DFM PROPERTY $_layer_type1 $_layer_type2 \
OVERLAP [-= AREA($_layer_type2) / AREA($_layer_type1)] <= 0.6
tvf::OUTLAYER out
}
Related Topics

config
config
Specifies configuration information for the 3DSTACK+ syntax format rule file. The top cell
name, source netlist, report file, connectivity, and other information can be specified.
Usage
config
[-layout_primary name]
[-layer_props_file props_file]
[-source_netlist ‘{’-file file_name -format {SPICE | MGC} [-case {YES | NO}] [-hier]‘}’]
[-report ‘{’ -file report_path [-max_results value] [-child_rdbs {YES | NO}] ‘}’]
[-ignore_trailing_chars char_list]
[-export_connectivity ‘{’ -file output_file [-format {VERILOG | SPICE | MGC}]
[-hier -no_top] [-pkg package_name]‘}’]…
[-set_auto_rve_show_layers {NO | YES}] [-set_rve_cto_file cto_file]
[-svrf_specs specification_file]
[-units [-distance {um | mm | nm}] [-power {W | mW | uW}] [-time {s | hr | min | ms | us}]]
Arguments
• -layout_primary name
Specifies the top level cell for the assembly. The default name is “TOPCELL_3DI” if this
option is not used. Corresponds to the layout_primary command.
• -layer_props_file props_file
Specifies a layer properties file that contains definitions, such as colors, boundaries, and fill-
patterns for the layers in an assembly. See “Layer Properties File” on page 212 for more
information.
• -source_netlist ‘{’-file file_name -format {SPICE | MGC} [-case {YES | NO}] [-hier] ‘}’
Specifies the source netlist file used for connectivity comparison. The default format is
SPICE. See source_netlist for a description of the arguments.
• -report ‘{’-file report_path [-max_results value] [-child_rdbs {YES | NO}] ‘}’
Specifies to generate a report file with information about the verification run. See report for
a description of the arguments.
• -ignore_trailing_chars char_list
Specifies characters to remove from the end of text labels. See ignore_trailing_chars for
details.
• -export_connectivity ‘{’-file output_file [-format {VERILOG | SPICE | MGC}] [-hier] ‘}’
Specifies to export connectivity information into a netlist file. See export_connectivity for a
description of the arguments. This argument set can be specified multiple times.

config
• -no_top
Optional argument that specifies not to create a new top cell for the entire design. This
option requires -hier to be specified.
• -pkg package_name
Optional argument that specifies a package layout in the design. The layout must not be an
interposer. The specified package_name must have at least one layer defined in the
connectivity stack. This option requires -hier to be specified.
• -set_auto_rve_show_layers {NO | YES}
Specifies whether to instruct Calibre RVE to only show the input layers that were used to
derive the rule checks.
Note
In order to use this functionality, you must enable the Calibre RVE option “Only
show check-dependent layers while highlighting results (hides other layers)” on the
Setup > Options > Highlighting pane in the DRC/DFM Highlighting area. See “RVE
Show Layers” in the Calibre Interactive and Calibre RVE User’s Manual for complete
details.
• -set_rve_cto_file cto_file
Specifies the path to a check text override (CTO) file. The cto_file contains DRC RVE
check text comments that control how results are highlighted in Calibre RVE. Only one
CTO file is allowed.
Note
The -set_rve_* arguments in your Calibre 3DSTACK rule file take precedence over
Calibre RVE options in your CTO file specified for the same rules.
The following CTO file specifies two check text comments for a rule named pads_on_grid:
# DRC RVE check text override file for a Calibre 3DSTACK rule file
#
pads_on_grid
RVE Highlight color: red
RVE Show Layers: backside_rdl
For complete information on the CTO file and how to load it, see “DRC RVE Check Text
Override File (CTO File)” in the Calibre Interactive and Calibre RVE User’s Manual.
Caution
Calibre RVE searches your working directory and loads a CTO file named
3dstack.rdb.cto if it exists. Do not use-set_rve_cto_file to specify this file if it exists
in your working directory as it is automatically loaded. You may use 3dstack.rdb.cto as
the CTO filename if it exists outside of your working directory.

config
• -svrf_specs specification_file
Optional argument that specifies the path to custom rule file that contains SVRF statements.
This allows you to include any SVRF statement in a Calibre 3DSTACK run. When this
statement is applied, Calibre 3DSTACK writes a special tvf_block to the generated rule file
with the name “__SVRF__SPECS__”. The body of the tvf_block is a tvf::include statement
that points to the specification_file.
• -units [-distance {um | mm | nm}] [-power {W | mW | uW}] [-time {s | hr | min | ms | us}]
Optional argument set that allows you to specify the units used in the 3DSTACK+ rule file.
The options are described as follows:
-distance {um | mm | nm} — Specifies the units for distance. The value must be
microns, millimeters, or nanometers. The default is microns.
-power {W | mW | uW} — Specifies the units for power. The value must be watts,
milliwatts, or microwatts. The default is watts.
-time {s | hr | min | ms | us} — Specifies the units for time. The value must be seconds,
hours, minutes, milliseconds, or microseconds. The default is s.
Note
The -units option has no effect on statements inside the 3dstack_block command.
Description
This command provides a way to include the configuration information provided with certain
standard 3DSTACK command in the 3DSTACK+ extended syntax rule file. You can use the
3dstack_block command to include standard 3DSTACK commands that are not specified with
the config command.
Layer Properties File

Use the -layer_props_file props_file to specify custom layer properties.
The specified props_file defines the properties of the layers used in Calibre DESIGNrev and
follows this format:
layer_name
layer_color layer_fill
layer_visibility layer_width
where:
• layer_name — is an alphanumeric string specifying the name of the layer.

• layer_color — is any valid Tcl color name.

config
• layer_fill — is one of the following fill types:
clear diagonal_1 diagonal_2

wave brick circles
speckle light_speckle solid
• layer_visibility — Specifies whether the layer is visible. The layer_visibility must be

one of the following:
o 0 — the layer is not visible.
o 1 — the layer is visible.
• layer_width — an integer greater than 1 that specifies the line width of the polygon
outline on that layer.
Examples
The example specifies the name of the top cell for the 3D assembly as BGA, and generates the
file 3dstack.report containing a report of the run. It also specifies to import connectivity
information hierarchically from the source_netlist.spice.
config -layout_primary BGA \

-source_netlist {
-file source_netlist.spice
-format SPICE -hier
} \
-export_connectivity {
-file layout.spice
-format SPICE
} \
-report {
-file 3dstack.report
} \
-units {-distance nm}
Related Topics
3dstack_block

select_checks (Extended Syntax)

Used in the 3DSTACK+ extended syntax file.
Selects specified checks to execute during a Calibre 3DSTACK verification.
Usage
select_checks { -check_names ‘{’check_name_pattern [check_name_pattern …]‘}’
| -stack_names ‘{’stack_name_pattern [stack_name_pattern …]‘}’
| -layer_types ‘{’layer_type_pattern [layer_type_pattern …]‘}’ }
Arguments
Argument and value set that specifies a list of rule checks that are executed. The list of
allowed. Must not be specified with the -stack_names or -layer_types argument.
• -stack_names ‘{’stack_name_pattern [stack_name_pattern …]‘}’
Argument and value set that specifies a list of stacks for which rule checks are executed.
Any checks that apply to the specified stacks are executed. The list of stacks are specified as
Tcl regular expressions. Multiple stack_name_pattern values are allowed. Must not be
specified with the -check_names or -layer_types argument.
• -layer_types ‘{’layer_type_pattern [layer_type_pattern …]‘}’
Argument and value set that specifies a list of layer types for which rule checks are
executed. Any checks that apply to the specified layer types are executed. The list of layer
types are specified as Tcl regular expressions. Multiple layer_type_pattern values are
allowed. Must not be specified with the -check_names or -stack_names argument.
Description
This command executes only those rule checks that are defined by the check_name_pattern,
stack_name_pattern, or layer_type_pattern argument list. If select_checks is not specified, all
rules in the rule file are executed. Multiple select_checks commands are allowed. If multiple
select_checks statements are specified, the list is accumulated.
Examples
Example 1
Specify a single check to run:
select_checks -check_names {"int_1"}
Example 2
Specify a single layer type to run (this can result in multiple rule check selection):
select_checks -layer_types {"pad"}

Example 3
Specify multiple layer types to run:
select_checks -layer_types {"interposer" "ram_*"}
or
select_checks -layer_types { "pad.*" }

select_checks -layer_types { ".*bump.*" }
select_checks -layer_types { "route" }
Example 4
Specify single stack to run (this can result in multiple rule check selection).
select_checks -stack_names { "st1" }
Related Topics
unselect_checks (Extended Syntax)


Selects specified checks not to execute during a Calibre 3DSTACK verification.
Usage
unselect_checks { -check_names ‘{’check_name_pattern [check_name_pattern …]‘}’
| -stack_names ‘{’stack_name_pattern [stack_name_pattern …]‘}’
| -layer_types ‘{’layer_type_pattern [layer_type_pattern …]‘}’ }
Arguments
Argument and value set that specifies a list of rule checks that are not executed. The list of
allowed. Must not be specified with the -stack_names or -layer_types argument.
• -stack_names ‘{’stack_name_pattern [stack_name_pattern …]‘}’
Argument and value set that specifies a list of stacks for which rule checks are not executed.
Any checks that apply to the specified stacks are executed. The list of stacks are specified as
Tcl regular expressions. Multiple stack_name_pattern values are allowed. Must not be
specified with the -check_names or -layer_types argument.
• -layer_types ‘{’layer_type_pattern [layer_type_pattern …]‘}’
Argument and value set that specifies a list of layer types for which rule checks are not
executed. Any checks that apply to the specified layer types are executed. The list of layer
types are specified as Tcl regular expressions. Multiple layer_type_pattern values are
allowed. Must not be specified with the -stack_names or -check_names argument.
Description
This command executes only those rule checks that are not defined by the
check_name_pattern, stack_name_pattern, or layer_type_pattern argument list. If
unselect_checks is not specified, all rules in the rule file are executed. Multiple unselect_checks
commands are allowed. If multiple unselect_checks statements are specified, the list is
accumulated.
Examples
Example 1
Specify a single check to exclude:
unselect_checks -check_names {"int_1"}
Example 2
Specify a single layer type to exclude (this can result in multiple rule check selection):
unselect_checks -layer_types {"pad"}

Example 3
Specify multiple layer types to exclude:
unselect_checks -layer_types {"interposer" "ram_*"}
or
unselect_checks -layer_types { "pad.*" }

unselect_checks -layer_types { ".*bump.*" }
unselect_checks -layer_types { "route" }
Example 4
Specify single stack to exclude (this can result in multiple rule check selection).
unselect_checks -stack_names { "st1" }
Related Topics

3dstack_block
3dstack_block
Defines a code block in which standard Calibre 3DSTACK rule file format commands can be
specified. This command allows you to directly pass standard 3DSTACK syntax commands to
the Calibre 3DSTACK run.
Usage
3dstack_block ‘{’ body ‘}’
Arguments
• ‘{’ body ‘}’
The body is a required set of arguments that consist of commands from the standard Calibre
3DSTACK syntax. You must enclose the commands in braces {}.
If a list is used within the command body, braces ({…}) should be used to enclose the list to
ensure correct evaluation. Do not use the list syntax ([list …]).
Description
Use this command to define custom commands in the 3DSTACK+ rule file. The 3dstack_block
command allows you to specify commands from the standard 3DSTACK syntax language.
Multiple 3dstack_block commands are allowed in the rule file.
Some configuration information can be specified with the config command rather than by using
standard 3DSTACK commands in a 3dstack_block statement; this includes the layout_primary,
source_netlist, report, ignore_trailing_chars, and export_connectivity commands.
Evaluation Details
The tool performs command substitution and evaluates Tcl variables before evaluating the code
within the 3dstack_block. Use the following guidelines when using Tcl within the
3dstack_block:
• Do not change the value of global Tcl variables. Global variables may be used within the
code body, but any changes are local in scope. Therefore, modification of such Tcl
variables within the 3dstack_block may result in undefined or undesired behavior.
• Do not declare Tcl variables within the 3dstack_block. Usage of locally declared
variables results in an error.
• Use the {A B …} list construction. Do not use the list command because command
substitution takes place and the list command is evaluated.
For example, the command [list A B] is evaluated and replaced by “A B” (without
quotes), which is generally not the intent, as it is no longer a list. Use the {A B} list
construction for proper evaluation.

3dstack_block
The following actions take place when the 3dstack_block code body is evaluated:
1. Command substitution and Tcl variable evaluation takes place. Use the preceding
coding guidelines to ensure correct evaluation.
2. The evaluated 3dstack_block code body is passed to the generated 3DSTACK rule file,
along with other commands converted from 3DSTACK+ to standard 3DSTACK.
No syntax checking is done for the 3DSTACK commands within the 3dstack_block,
therefore any errors are reported during the 3DSTACK rule file compilation or at
runtime, not during the 3DSTACK+ rule file compilation step.
Examples
3dstack_block {
export_template -chip c2.oas -system OASIS
run -drc -directory ./DRC -rule_deck ./n45_m.rules \
-run_options "-turbo -hier"
source_filter -chip interposer -subckt tsv -short_pins {bottom top}
ignore_pin -placement p1 -pin {VSS}
import_text_labels -chip stack_die -file lvsText_dieWrapper.txt
tvf_block creating_logic_to_memory_connects {
tvf::SETLAYER l_logic_ltsv_to_memory = l_ltsv NOT i_out_M1_tsv;
} -export_layers {l_logic_ltsv_to_memory} -attach_to_placement l
set_rve_cto_file -file ./custom_rve_settings.cto
}
Related Topics
config

3dstack_block

Chapter 6
System Netlist Generator
Calibre 3DSTACK System Netlist Generator is included in the Calibre installation package and
is used to create a source netlist for a multi-chip design. The tool is invoked separately to
Calibre 3DSTACK and includes its own set of commands and a graphical interface.
System Netlist Generator Flow and Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
sng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
System Netlist Generator Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Importing Chips into the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Creating Placements for the Chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Defining Net Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
System Netlist Generator Graphical User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Properties Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Set Net Name Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
System Netlist Generator Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
PLACEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
CONNECTIVITY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
EXPORTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
System Netlist Generator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
sng::create_journal_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
sng::export_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
sng::export_netlist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
sng::new_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
sng::open_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
sng::save_db . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
sng::filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
sng::get_begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
sng::get_buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
sng::get_chips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
sng::get_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
sng::get_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
sng::get_placements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
sng::get_ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

sng::get_property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
sng::get_property_names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
sng::incr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
sng::set_property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
sng::sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
sng::add_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
sng::connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
sng::create_chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
sng::create_placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
sng::import_chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
sng::remove_chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
sng::remove_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
sng::remove_placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
sng::set_net_name_template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
sng::unconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293


The System Netlist Generator allows you to easily create source netlists for complex stacked
systems. It supports batch and interactive modes.
Calibre Interactive can invoke the System Netlist Generator to create a source netlist before a
verification run. For more information on Calibre Interactive, see “Creating a Source Netlist” on
page 65.
Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
sng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Workflow
The System Netlist Generator can be invoked from Calibre Interactive to generate a netlist from
an existing rule file or it can be used in a stand-alone flow.
The System Netlist Generator workflow is illustrated in the following figure.

Workflow
Figure 6-1. System Netlist Generator Workflow

sng
sng
Invocation arguments for the System Netlist Generator.
Usage
Interactive (GUI) Invocation
sng [-gui] [-project project_file]} [-log_dir log_file_directory]
Batch Invocation
sng -batch -script script_file [-script_args script_args] [-log_dir log_file_directory]
Hierarchical Source Netlist Creation
sng -batch {-stitch -black_box_netlist bb_assembly_netlist [-matching {by_pins | auto}]}
-top_cell cell_name -die_netlists die_netlist_placement_file
-full_hier_netlist output_hier_netlist_file [-log_dir log_file_directory]
Arguments
• -batch
Required keyword for batch mode and hierarchical source netlist creation. This keyword
cannot be specified with -gui.
• -script script_file
Keyword and path to a script file that contains batch Tcl commands for the System Netlist
Generator. This argument is required for batch mode invocation and cannot be specified
with -gui.
• -script_args script_args
Keyword and list of arguments that are passed to the Tcl script_file. The passed arguments
can be accessed in the script using standard predefined variables, such as argv0, argv, and so
on. This argument cannot be specified with the -gui argument.
• -gui
Optional keyword that invokes the System Netlist Generator graphical user interface. This
argument cannot be specified with the -batch argument. If you invoke sng without any
arguments, the GUI is automatically loaded.
• -project project_file
Keyword and path to an existing project. The project_file database opens when the System
Netlist Generator GUI is invoked. This argument cannot be specified with the -batch
argument.
• -log_dir log_file_directory
Optional keyword and path to a directory that contains generated log files. By default, a
directory named sng_log_dir is created where you launch the tool.

sng
• -stitch -black_box_netlist bb_assembly_netlist [-matching {by_pins | auto }]

Keyword and argument set specifying that a hierarchical netlist is generated. The argument
bb_assembly_netlist specifies the path to the black box assembly netlist file. The assembly
netlist file is in SPICE format and is generated by a 3DSTACK assembly run with the
export_connectivity command.
To specify the type of pin matching to perform with -stitch, apply the -matching argument
with one of the following options:
by_net — Pin matching is performed by identifying matching pin sets between the
assembly die instantiations and the individual die netlists. In detail, sub-circuits from
the assembly level netlist are matched to the individual die netlists by checking
whether the pin name set of assembly die is a subset of the pin name set of the
individual die. The first matching pin subset is taken. This is the default behavior.
auto — Pin matching is performed using only the names of the dies. If the die names
match in the die netlist and in the assembly netlist, the netlist is generated regardless
of whether the pins match.
• -top_cell cell_name
Keyword and value specifying the name of the top cell in the assembly netlist file
(bb_assembly_netlist.).
• -die_netlists die_netlist_placement_file
Keyword and path to the netlist placement file. The file uses the System Netlist Generator
Configuration File Format and has one PLACEMENTS command specifying the
placements of the dies.
• -full_hier_netlist output_hier_netlist_file
Keyword and file path specifying the output file for the hierarchical netlist.
Description
The System Netlist Generator application is located in the $CALIBRE_HOME/bin directory of
the Calibre installation tree. You can invoke the tool in batch or interactive modes. You can
specify a script with a set of supported Tcl commands and System Netlist Generator Commands
in batch mode.
You can create a hierarchical netlist using the -batch -stitch keywords and related arguments.
Examples
Example 1 GUI Invocation
Invoke the System Netlist Generator graphical user interface:
sng -gui
or
sng

sng
Example 2 Batch Invocation

Invoke the System Netlist Generator in batch mode and execute a set of Tcl and sng commands:
sng -batch -script system_netlist.tcl
The following is an example of a System Netlist Generator script:
set db [sng::new_db]
sng::create_chip db -chip_name "cont_chip" -cell_name "cont"
sng::add_pin db -pin_name "select" -chip_name "cont" \
-type "INPUT"
set iter [sng::get_pins db -chip_name cont_chip]
test {$iter ne ""}
puts [sng::get_property_names $iter]
sng::add_pin db -pin_name "enable" -chip_name "ram_chip" \
-type "INPUT" -bus_name readdata -bus_order 1
while {$iter ne ""} {

puts "property names = [sng::get_property_names $iter]"
puts [sng::get_properties $iter]
sng::incr iter 1
}
Example 3 Hierarchical Netlist Generation

This example demonstrates using the batch mode to create a hierarchical netlist. The following
input files are used in this example:
• bb_netlist.spi — The black box assembly netlist file created by a 3DSTACK assembly
run.
• base.spi and stack.spi — White box versions of cells in the assembly.
• netlist_placements.tcl — The configuration file with one PLACEMENT command
specifying the netlists to include.
bb_netlist.spi (the black box assembly netlist file):
.SUBCKT top_assembly
Xpinter 2 3 5 8 1 4 6 7 inter
.ENDS top_assembly
.SUBCKT base bclk_1 bclk_2 bgnd bin_1 bin_2 bout_1 bout_2 bvdd
.ENDS base
.SUBCKT inter ipad0 ipad1 ipad2 ipad3 ipad4 ipad5 ipad6 ipad7
Xpbase ipad1 ipad5 ipad4 ipad2 ipad3 ipad6 ipad7 ipad0 base
Xpstack ipad1 ipad5 ipad4 ipad2 ipad3 ipad6 ipad7 nIsolated0 stack
.ENDS inter
.SUBCKT stack sclk_1 sclk_2 sgnd sin_1 sin_2 sout_1 sout_2 svdd
.ENDS stack

sng
base.spi (white box version of cell base):
RR1 A B rap w=3.0 l=3.0 r=21.0m
RR1 C D rap w=3.0 l=3.0 r=21.0m
.ENDS base
stack.spi (white box version of cell stack):
RR1 A B rap w=3.0 l=3.0 r=21.0m
RR1 C D rap w=3.0 l=3.0 r=21.0m
.ENDS stack
netlist_placements.tcl (the configuration file):
PLACEMENTS {
# placementName chipName fileFormat filePath topCell analysingMode
pbase base SPICE base.spi base
pstack stack SPICE stack.spi stack
}
The following command generates the hierarchical netlist hier.spi:
sng -batch -stitch -black_box_netlist bb_netlist.spi \

-top_cell top_assembly -die_netlists netlist_placements.tcl \
-full_hier_netlist hier.spi

sng
The netlist hier.spi has the following contents:
.SUBCKT top_assembly
Xpinter 2 3 5 8 1 4 6 7 inter
.ENDS top_assembly
.SUBCKT inter ipad0 ipad1 ipad2 ipad3 ipad4 ipad5 ipad6 ipad7
Xpbase ipad1 ipad5 ipad4 ipad2 ipad3 ipad6 ipad7 ipad0 base
Xpstack ipad1 ipad5 ipad4 ipad2 ipad3 ipad6 ipad7 nIsolated0 stack
.ENDS inter
.SUBCKT stack_0 sclk_1 sclk_2 sgnd sin_1 sin_2 sout_1 sout_2 svdd
RR1 A B rap w=3.0 l=3.0 r=21.0m
RR1 C D rap w=3.0 l=3.0 r=21.0m
.ENDS stack_0
Xstack_0 sclk_1 sclk_2 sgnd sin_1 sin_2 sout_1 sout_2 svdd stack_0
.ENDS stack
.SUBCKT base_0 bclk_1 bclk_2 bgnd bin_1 bin_2 bout_1 bout_2 bvdd
RR1 A B rap w=3.0 l=3.0 r=21.0m
RR1 C D rap w=3.0 l=3.0 r=21.0m
.ENDS base_0
Xbase_0 bclk_1 bclk_2 bgnd bin_1 bin_2 bout_1 bout_2 bvdd base_0
.ENDS base
The “inter” subckt has no white box data and the sng command gives following warning for this
flow: “Warning: Assembly netlist cell "inter" is not matched to any individual cell.”

System Netlist Generator Example

Create a source netlist for an interposer design using the System Netlist Generator GUI. Design
data is included.
Two identical RAM memory chips and a controller are stacked on an interposer as shown in
Figure 6-2. Note, the interposer netlist is left out for simplicity.
Figure 6-2. System Netlist Generator Interposer Design
The SPICE netlists for the memory and controller are defined in Table 6-1.
Table 6-1. Netlists for Chips Used In This Example

SPICE Filename Contents of SPICE Netlists
myram_netlist.spi .SUBCKT myram mode enable adr[0] adr[1] adr[2]
w_data[0] w_data[1] w_data[2] w_data[3] w_data[4]
w_data[5] w_data[6] w_data[7]
r_data[0] r_data[1] r_data[2] r_data[3] r_data[4]
r_data[5] r_data[6] r_data[7]
.ENDS myram
controller_netlist.spi .SUBCKT controller
reset mode
$--Chip enable bus--
ENABLE<0> ENABLE<1>
$--Address bus--
ADDR<0> ADDR<1> ADDR<2>
$--Port A+B--
GPIO_A<0> GPIO_A<1> GPIO_A<2> GPIO_A<3> GPIO_A<4>
GPIO_A<5> GPIO_A<6> GPIO_A<7>
GPIO_B<0> GPIO_B<1> GPIO_B<2> GPIO_B<3> GPIO_B<4>
GPIO_B<5> GPIO_B<6> GPIO_B<7>
$--Port C+D--
GPIO_C<0> GPIO_C<1> GPIO_C<2> GPIO_C<3> GPIO_C<4>
GPIO_C<5> GPIO_C<6> GPIO_C<7>
GPIO_D<0> GPIO_D<1> GPIO_D<2> GPIO_D<3> GPIO_D<4>
GPIO_D<5> GPIO_D<6> GPIO_D<7>
.ENDS controller
The desired net connectivity of the chips on the interposer design is defined in Table 6-2.

Table 6-2. Net Connectivity of the Interposer Design

Chip Placement Placement Port Net
ram1 mode mode
enable enable_1
adr (3-bit) address
w_data (8-bit) write_data1
r_data (8-bit) read_data1
ram2 mode mode
enable enable_2
adr (2-bit) address
w_data (8-bit) write_data2
r_data (8-bit) read_data2
controller reset reset
mode mode
ENABLE<0> enable_1
ENABLE<1> enable_2
ADDR (2-bit) address
GPIO_A (8-bit) write_data1
GPIO_B (8-bit) read_data1
GPIO_C (8-bit) write_data2
GPIO_D (8-bit) read_data2
This data is used throughout the following procedures:

Importing Chips into the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Creating Placements for the Chips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Defining Net Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Creating a New Project
Creating a New Project

Launch the System Netlist Generator GUI and create a new project.
Prerequisites
• You have the necessary licenses and software as described under “Requirements” on
page 18.
Procedure
1. Enter the following command at the command line to invoke the System Netlist
Generator:
$CALIBRE_HOME/bin/sng -gui
2. Select File > New.

The previously disabled menu icons ( ) are now enabled. This indicates that
an active database is loaded and is ready to be modified.
3. Select File > Save and enter a new name for the project (for example, TOP_3D_sng).
The console at the bottom of the main window can be used to enter supported Tcl
commands and any command listed under “System Netlist Generator Commands” on
page 256. It also reports information, warnings, and errors generated by the tool.
Related Topics
Workflow
sng
sng::new_db
sng::open_db
sng::save_db
Importing Chips into the Database

Import SPICE netlists and create chips for the design.
When you import a chip netlist into an active System Netlist Generator project, a SPICE
subcircuit is defined for that chip. You can view the pins and properties of the chips in the Chips
tree.

Importing Chips into the Database
Note
Set the MGC_SNG_SPICE_IMPORT_TEMP_DIR environment variable to the path of a
temporary directory if you are importing large netlists.
Prerequisites
• You have netlists to import or you have saved the myram_netlist.spi and
controller_netlist.spi netlists in Table 6-1 to two separate files.
Procedure
1. Select File > Import Chips to load the SPICE netlists into the active database.
The Import Chips pane opens in a tab in the Console area at the bottom of the main
window.
2. Click the Add Row button.
3. Enter the Chip Name, Cell Name, Type, File Location, and Bus Characters of the netlist
as shown:
Note, the controller and ram chips use different characters to denote a bus. The Bus
columns are described under “sng::import_chip” on page 287.
4. Click the Import chips button.
Any syntax errors in the source netlists are immediately reported in the console.
If you make a mistake and want to import the source files again, select Edit > Remove
Chips and select the items that you want to delete from the project. After removing the
chips, you can then follow steps 1 to 4 again.
5. Save the database when you are done.
Results
The imported chips are now displayed in the Chips tree as shown here:

Modifying and Adding Pins on Chips
Examples
The following statements achieve the same steps using the Tcl console prompt:
sng::sng::import_chip {sng::database} -chip_name {controller} \

-cell_name {controller} -type {SPICE} -path {./controller_netlist.spi} \
-bus_detection {Yes} -bus_chars {\<\>}
sng::import_chip {sng::database} -chip_name {ram} -cell_name {myram} \

-type {SPICE} -path {./myram_netlist.spi} -bus_detection {Yes} \
-bus_chars {\[\]}
Related Topics
Workflow
sng::import_chip
sng::remove_chip
Modifying and Adding Pins on Chips

Modify pins on chip definitions.
Prerequisites
• You have imported at least one chip definition as described under “Importing Chips into
the Database” on page 232.
Procedure
1. Expand the Chips tree and the Pins View tree.
2. Click on the chip you want to modify under the Pins View. For this example, click on
the controller chip.
Properties of all pins are listed in the table to the right of the Chips tree. You can directly
edit the columns in the table to modify the pin properties.
3. For the reset pin in this example, change the type to INPUT.

Creating Placements for the Chips
4. Select Edit > Add Pins to add a pin to the chip. Alternatively, you can right-click in the
Pins View and select Add Pins. The Add Pins pane opens as a tab at the bottom of the
main window.
5. Click Add Row, enter the pin name and chip name, and then click Add Pins to insert the
new pin on the chip.
6. Save the database when you are done.
Results
You have added or modified a pin on a chip. This is allows you to modify the netlist of the
source chips without manually modifying and importing the SPICE netlists.
Examples
Console equivalent commands to list all of the pins on a chip.
set my_db [sng::open_db -path ./TOP_3D_sng]

set controller_pins [sng::get_pins my_db -chip_name controller]
sng::get_property $controller_pins -property "pin_name"
Related Topics
Workflow
sng::add_pin
sng::remove_pin
sng::set_property
sng::get_property

Create placements, or instantiations, of your chips in the System Netlist Generator project.
This is the netlist equivalent of the place_chip assembly command.
Prerequisites

Procedure
1. Right-click on the controller in the Chips tree and select Add Placement to instantiate
the controller chip.
The Add Placement dialog opens as a tab at the bottom of the main window.
2. Click Add Row to start a new placement.
3. Enter a placement name for the controller (each instantiation must have a unique name)
and click Add Placements.
The pController placement now appears under the Assembly tree as an instantiated chip.
The pins on the chip are converted to ports on the placement.
4. Create the placements for the two memory chips using the same method.
5. If you make any errors, you can remove unwanted placements by selecting Edit >
Remove Placements.
6. Save the database.

Defining Net Connectivity
Results
The three placements on the interposer are now defined in the project. You can view the
placements and port properties by selecting the placements in the Assembly tree.
Examples
sng::create_placement my_db -placement_name {pController} -chip_name
{controller}
sng::create_placement my_db -placement_name {pRam2} -chip_name {ram}
sng::create_placement my_db -placement_name {pRam1} -chip_name {ram}
Related Topics
Workflow
sng::create_placement
sng::remove_placement

Electrically connect the placements in your design by defining and assigning nets in the
database.
Prerequisites
• You have created at least one placement in your design as described under “Creating
Placements for the Chips” on page 235.
Procedure
1. Select Edit > Add Nets.
2. Click Add Row.
3. Enter reset in the net_name field and pController::reset in the ports_list field.
4. Click Add Nets.

5. Select the pController placement and note that the port in the properties table is now
connected to the reset net in the net_name column:
For placements with large pin counts, it is recommended to use the Tcl console interface
to define the connectivity.
6. Save the database and exit the tool.
7. Enter the following Tcl commands in a shell script to connect the four general purpose
8-bit data ports and address port of the controller to the 8-bit read, write, and address
ports of the two ram placements:
#set db_instance to current project
set my_db [sng::open_db -path ./TOP_3D_sng]
#Connect read data from controller to pRam1

sng::connect my_db -net_name read_data1 \
-buses {pController::GPIO_A pRam1::r_data}
#Connect write data from controller to pRam1

sng::connect my_db -net_name write_data1 \
-buses {pController::GPIO_B pRam1::w_data}
#Connect read data from controller to pRam2

sng::connect my_db -net_name read_data2 \
-buses {pController::GPIO_C pRam2::r_data}
#Connect write data from controller to pRam1

sng::connect my_db -net_name write_data2 \
-buses {pController::GPIO_D pRam2::w_data}
#Connect address bus to all three chips

sng::connect my_db -net_name address \
-buses {pController::ADDR pRam1::adr pRam2::adr}
sng::save_db my_db -path ./TOP_3D_sng
8. Save the script as connect.tcl and close it.

9. Source the Tcl script using the following command:
sng -batch -script connect.tcl

Exporting the Complete Design
10. Invoke the System Netlist Generator and load the TOP_3D_sng database. The Assembly
tree now displays all of the new connected nets and buses on the three chips.
11. Complete the remaining connections manually using Table 6-2 on page 231.
12. Save the database.
Results
The Assembly tree and placements are populated with all of the bus net connections. The mode
and enable connections are unconnected and can be connected using the GUI or a batch script.
Related Topics
Workflow
sng::get_ports
sng::incr
sng::connect
sng::unconnect

Export the completed source netlist from the System Netlist Generator.
Prerequisites
• A completed System Netlist Generator database that defines all of the chips, placements,
and net connectivity of your 3D-IC.
Procedure
1. Save the current database or open an existing database.
2. Select File > Export Netlist or click on the ( ) icon at the top of the main window.
The Export Netlist dialog opens at the bottom of the main window.

3. Enable all of the chips that you want to export and specify a path for the SPICE file:
4. Click Export Netlist.

Results
The source netlist for the 3D-IC, shown in Figure 6-2 on page 230, was created using the
System Netlist Generator. You can use this ideal electrical representation of your 3D-IC in a
Calibre 3DSTACK run using the source_netlist command. This allows you to verify your
design intent with the extracted layout.
Examples
The batch command equivalent of this procedure is as follows:
sng::export_netlist my_db –chip_name_list "myram1 controller" \

-path ./top_3d_netlist.spi

The following SPICE netlist is the completed assembly netlist for this design:
.SUBCKT controller reset mode ENABLE<0> ENABLE<1> ADDR<0> ADDR<1> ADDR<2>

+ GPIO_A<0> GPIO_A<1> GPIO_A<2> GPIO_A<3> GPIO_A<4> GPIO_A<5> GPIO_A<6>
+ GPIO_A<7> GPIO_B<0> GPIO_B<1> GPIO_B<2> GPIO_B<3> GPIO_B<4> GPIO_B<5>
+ GPIO_B<6> GPIO_B<7> GPIO_C<0> GPIO_C<1> GPIO_C<2> GPIO_C<3> GPIO_C<4>
+ GPIO_C<5> GPIO_C<6> GPIO_C<7> GPIO_D<0> GPIO_D<1> GPIO_D<2> GPIO_D<3>
+ GPIO_D<4> GPIO_D<5> GPIO_D<6> GPIO_D<7>
.ENDS controller
.SUBCKT myram mode enable adr[0] adr[1] adr[2] w_data[0] w_data[1]

w_data[2]
+ w_data[3] w_data[4] w_data[5] w_data[6] w_data[7] r_data[0] r_data[1]
+ r_data[2] r_data[3] r_data[4] r_data[5] r_data[6] r_data[7]
.ENDS myram
.SUBCKT TOP_CELL
XpController reset mode enable_1 enable_2 address[0] address[1] address[2]
+ read_data1[0] read_data1[1] read_data1[2] read_data1[3] read_data1[4]
+ read_data1[5] read_data1[6] read_data1[7] write_data1[0] write_data1[1]
+ write_data1[2] write_data1[3] write_data1[4] write_data1[5]
write_data1[6]
+ write_data1[7] read_data2[0] read_data2[1] read_data2[2] read_data2[3]
+ read_data2[4] read_data2[5] read_data2[6] read_data2[7] write_data2[0]
write_data2[5]
+ write_data2[6] write_data2[7] controller
XpRam1 mode enable_1 address[0] address[1] address[2] write_data1[0]
write_data1[5]
+ write_data1[6] write_data1[7] read_data1[0] read_data1[1] read_data1[2]
myram
XpRam2 mode enable_2 address[0] address[1] address[2] write_data2[0]
write_data2[5]
+ write_data2[6] write_data2[7] read_data2[0] read_data2[1] read_data2[2]
myram
.ENDS TOP_CELL
Related Topics
Workflow
sng::export_netlist
source_netlist

System Netlist Generator Graphical User Interface
System Netlist Generator Graphical User

Interface
The graphical interface for the System Netlist Generator includes most of the batch command
functionality.
The panels available in the System Netlist Generator GUI are described in the following
sections.

Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Properties Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Set Net Name Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
System Netlist Generator GUI Tips

The graphical interface includes a number of features that allow you to quickly edit your design.
When you select a cell, a small rectangle appears in the cell’s bottom-right corner. Click this
rectangle to select multiple cells as shown in the following figure.
Figure 6-3. Select Multiple Cells by Clicking and Dragging the Cell Corner
Edit properties by entering values for each field or by copying and pasting values from existing
fields. Figure 6-4, Figure 6-5, and Figure 6-6 demonstrate how you can easily modify multiple
cell properties at once.

Figure 6-4. Copy Existing Properties in the System Netlist Generator
Figure 6-5. Shift-Select and Paste Into Multiple Cells in the System Netlist
Generator
Figure 6-6. Updated Cells In the System Netlist Generator

Enable the Show generated netlist file in Calibre RVE SPICE File Viewer checkbox to view
a graphical representation of the complete netlist.

Main Window
Main Window
Main Window
System Netlist Generator Main Window.
Figure 6-7. Main Window
Objects
Table 6-3. Main Window Contents

Item Description
File > New Creates a new System Netlist Generator project.
Command equivalent: sng::new_db
File > Open Opens an existing System Netlist Generator project.
Command equivalent: sng::open_db
File > Save Saves the current System Netlist Generator project.
Command equivalent: sng::save_db
File > Close Closes the active System Netlist Generator project.
Command equivalent: none

Main Window
Table 6-3. Main Window Contents (cont.)

Item Description
File > Import Chips Imports one or more chips from existing files.
Command equivalent: sng::import_chip
File > Export Netlist Exports the selected assembly or chips into a netlist file.
Command equivalent: sng::export_netlist
File > Exit Closes the System Netlist Generator GUI.
Command equivalent: none
Edit > Create Chip Invokes the Create Chip panel. Used to create a new chip
name and cell in the project.
Command equivalent: sng::create_chip
Edit > Remove Chips Invokes the Remove Chip panel. Used to remove selected
chips from the project.
Command equivalent: sng::remove_chip
Edit > Add Pins Invokes the Add Pins panel. Used to add pins to existing chip
definitions without editing the source netlist for that chip.
Command equivalent: sng::add_pin
Edit > Add Placement Invokes the Add Placement panel. Used to create a new
placement for a specified chip in the project.
Command equivalent: sng::create_placement
Edit > Remove Placements Invokes the Remove Placement panel. Used to remove
selected placements from the project.
Command equivalent: sng::remove_placement
Edit > Add Nets Invokes the Add Nets panel. Used to connect ports in the
assembly.
Command equivalent: sng::connect
Edit > Set Net Name Invokes the Set Net Name Template panel. Used to control
Template how net names are generated when port connections are
made.
Command equivalent: sng::set_net_name_template
Edit > Find and Replace Invokes the Find and Replace utility to find and change net
names in the project.
Usage Notes
Enter the following command to invoke the System Netlist Generator main window:
sng -gui

Main Window
The main window enables you to perform the following tasks:
• Create, open, save, close, and edit netlist projects.

• Import and export netlists.
• Enter System Netlist Generator Commands or Tcl code in the command prompt area.

Properties Panel
Properties Panel
Properties button
Shows detailed properties about objects in the design tree.
Figure 6-8. Properties Panel
Objects
Table 6-4. Properties Panel Contents

Item Description
name Name of the port or net.
chip_name Chip associated with the port or net.
placement_name Placement associated with the port or net.
type Direction of the port or net.
bus_name Bus name attached to the port or net.
bus order Order of the bus pins for the port or net.
net_name Net connectivity for the port or net.
Usage Notes
The properties panel opens when objects are selected in the Chip Definition tree in the main
window. The panel allows you to view and sort all properties of the selected chips, assemblies,
or placements.
Tip
Click the button in the upper-left of the properties table to select items to show in the table.
Right-click on any column header to apply a filter or to sort the column contents.

Properties Panel
Related Topics
Main Window

Set Net Name Template
Set Net Name Template

Edit > Set Net Name Template
Controls how net names are generated when port connections are assigned.
Figure 6-9. Set Net Name Template
Objects
Table 6-5. Set Net Name Template Contents

Item Description
Prefix String that is prefixed to all net names defined in a
sng::connect command that do not have an assigned net
name.
Delimiters Start end delimiters for the net. For example, { and }.
Save Net Saves the net name template so that it is applied to port
Name connections when they are created.
Template
Related Topics
sng::connect

System Netlist Generator Configuration File Format
System Netlist Generator Configuration File

Format
The System Netlist Generator configuration file allows you to define placements and
connectivity for your 3D-IC and then export the definitions to a new netlist file.
You can specify this file on the Inputs > Netlist tab of Calibre Interactive to control the
creation of a new source netlist file before a Calibre 3DSTACK verification run. See “Creating
a Source Netlist” on page 65 for complete details.
The commands used in the configuration file can also be entered directly into the System Netlist
Generator Tcl command prompt or in a System Netlist Generator batch script.
The configuration file supports the following PLACEMENTS, CONNECTIVITY, and

EXPORTS commands.
PLACEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
CONNECTIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
EXPORTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

PLACEMENTS
PLACEMENTS
Imports chips and creates placements.
Usage
PLACEMENTS ‘{’
placement_name chip_name format file_path top_cell
...
‘}’
Arguments
• placement_name
Required argument that specifies the name of the placement to create.
• chip_name
Required argument that specifies the name of the chip of which the placement is an instance.
• format
Required argument that specifies the format of the file containing the chip definition. A
value of SPICE is currently supported.
• file_path
Required argument that specifies the path to a file containing the chip definitions.
• top_cell
Required argument that specifies the top cell name of the chip.
Description
Imports chip definitions from a specified file and creates a placements for them in the System
Netlist Generator. The PLACEMENTS command must only appear once in the configuration
file. Each line in the PLACEMENTS command within the required brackets ‘{’ ‘}’ must define
the placement_name, chip_name, format, file_path, and top_cell for the placement. There is
no limit to the number of placements that you create, but each placement definition must appear
on a new line.
Examples
PLACEMENTS {
myram1 myram SPICE ram_netlist.spi myram
myram2 myram SPICE ram_netlist.spi myram
interposer1 interposer SPICE interp_rev0.spi interposer
controller1 controller SPICE controller.spi controller
}
Related Topics
CONNECTIVITY

CONNECTIVITY
CONNECTIVITY
Connects specified pins with new nets.
Usage
CONNECTIVITY ‘{’
from_placement ‘{’pin …‘}’ to_placement ‘{’pin …‘}’ [to_placement ‘{’pin …‘}’ …]
...
‘}’
Arguments
• from_placement ‘{’pin …‘}’
Required list of arguments that defines the primary placement name and a list of pins that
connect to the secondary placements (to_placement). The from_placement placement must
be defined in the PLACEMENTS command. Any number of pins can be defined; however,
all pins must correspond to the pins in the subsequent to_placement pin lists.
• to_placement ‘{’pin …‘}’
Required list of arguments that defines the secondary placement name and a list of pins that
connect to the primary placement (from_placement). The to_placement placement must be
defined in the PLACEMENTS command. Any number of secondary placements are
allowed, but they must be written on the same line.
Description
Defines the connectivity for specified placements in the assembly. Each line in the
CONNECTIVITY command defines pin connectivity for a primary placement. A primary
placement is specified with the from_placement argument. Connectivity is established by
specifying subsequent placement names and pin lists on the same line. The order of the pin lists
establishes the connections. Nets are created automatically to connect the specified pins.
For example, if you want to connect pin_a and pin_b on placement1 to pin_q and pin_d on
placement2, as shown in the following figure, your CONNECTIVITY command must be
written as follows:
CONNECTIVITY {
placement1 {pin_a pin_b} placement2 {pin_q pin_d}
}

CONNECTIVITY
Examples
This example demonstrates how to define connectivity for the myram1 and myram2
placements.
CONNECTIVITY {
myram1{vdd} interposer1{vdd} controller1{vdd}
myram1{gnd} interposer1{gnd} controller1{gnd}
myram2{vdd gnd wri} myram1{wri} controller1{wri<1> wri<2> wri<3> wri<4>}
}

EXPORTS
EXPORTS
Exports the connectivity and placements defined in the configuration file to a netlist file.
Usage
EXPORTS ‘{’
top_cell format file_name
...
‘}’
Arguments
• top_cell
Required argument that specifies the top cell name for the exported netlist file.
• format
Required argument that specifies the netlist format of the exported netlist file. The only
supported value is SPICE.
• file_name
Required argument that specifies the name of the exported netlist file.
Examples
EXPORTS {
myTopCell SPICE 3d_assembly.spi
}
Related Topics
CONNECTIVITY
PLACEMENTS

System Netlist Generator Commands

A set of batch commands are supported by the System Netlist Generator.
The commands listed in the following table use the syntax conventions outlined in Table 1-1.
Tip
All commands support the -help option. Use the -help option in the System Netlist
Generator shell to report the usage for each command.
Table 6-6. System Netlist Generator Commands

Name Description
sng::create_journal_file Creates a journal file in your working directory while the System
Netlist Generator tool is running. No journal is created if this
command is not specified.
sng::export_db Exports the current project to a file.
sng::export_netlist Exports specified chip definitions or the complete assembly to a
netlist file.
sng::new_db Creates a new project.
sng::open_db Opens the specified project.
sng::save_db Saves the current state of the project.
sng::filter Applies a filter to a specified iterator. This command is supported
in batch mode only.
sng::get_begin Moves the specified iterator to the first element of the container.
sng::get_buses Returns an iterator for all buses defined in the specified chip.
sng::get_chips Returns an iterator for all chips defined in the current project.
sng::get_nets Returns an iterator used to access any created nets in the current
project.
sng::get_pins Returns an iterator for all pins on the specified chip.
sng::get_placements Returns an iterator for all placements defined in the current project.
sng::get_ports Returns an iterator for all ports defined for the specified placement.
sng::get_property Returns a list of property values for the specified iterator.
sng::get_property_names Returns a list of property names.
sng::incr Increments the specified iterator.
sng::set_property Changes the value of specified properties.

Table 6-6. System Netlist Generator Commands (cont.)

Name Description
sng::sort Sorts the elements of a list and returns a new sorted list to an
iterator.
sng::add_pin Adds a pin to the specified chip.
sng::connect Creates a new connection.
sng::create_chip Creates a new chip.
sng::create_placement Creates a new placement.
sng::import_chip Imports an existing chip definition.
sng::remove_chip Removes the selected chip definition.
sng::remove_pin Deletes a pin from the specified chip.
sng::remove_placement Removes a placement from the project.
sng::set_net_name_template Sets the net name template.
sng::unconnect Deletes specified connections or ports from a net.

sng::create_journal_file
Creates a journal file in your working directory while the System Netlist Generator tool is
running. No journal is created if this command is not specified.
Usage
Arguments
None.
Examples
Related Topics

sng::export_db
sng::export_db
Exports the current project to a file.
Usage
sng::export_db db_instance -path file_path [-placements] [-connectivity]
Arguments
• db_instance
Required argument that specifies the database instance.
• -path file_path
Required argument and value that specifies the path for the exported project file.
• -placements
Optional keyword that specifies to only save placement information to the database. No
connectivity is exported unless the -connectivity argument is also specified.
• -connectivity
Optional keyword that specifies to only save connectivity information to the database. No
placements are exported unless the -placements argument is also specified.
Examples
sng::export_db db –path /user/3d_netlist/my_db –placements -connectivity
Related Topics
sng::save_db

sng::export_netlist
sng::export_netlist
Exports specified chip definitions or the complete assembly to a netlist file.
Usage
sng::export_netlist db_instance -path file_path
[-chip_name_list {chip_names … | {chip_name cell_name} …}]
[-top_cell_name top_cell_name] [-interposer chip_name]
Arguments
• db_instance
• -path file_path
Required keyword and path for the new netlist file.
• -chip_name_list {chip_names … | {chip_name cell_name} …}
Optional keyword and list of chips that you want to write to the netlist. If you do not specify
this option, all connectivity information is exported. You can specify a list of chips or a list
of chip and cell name pairs. The cell_name is the subcircuit name used for the chip in the
exported netlist. If you only specify a list of chip_names, the exported subcircuit uses the
chip name as the name of the subcircuit.
• -top_cell_name top_cell_name
Optional keyword and top cell name of the exported netlist file. The default top cell name is
3DSTACK_TOP_CELL. This option cannot be specified with the -chip_name_list option.
• -interposer chip_name
Optional keyword set that indicates that the specified chip_name is an interposer.
Description
Exports an assembly or specified chips to a netlist file. The netlist is written in SPICE format. If
the -chip_name_list argument is not used, the tool exports the assembly connectivity
information for the entire project.
Examples
sng::export_netlist my_db –chip_name_list "myram1 myram2" -path ./3dic.net
Related Topics
sng::save_db

sng::new_db
sng::new_db
Creates a new project.
Usage
sng::new_db [-name db_name]
Arguments
• -name db_name
Optional keyword and argument that specifies the name of the new database.
Examples
set db [sng::new_db -name my_3dic_source.sng]
Related Topics
sng::save_db
sng::open_db

sng::open_db
sng::open_db
Opens the specified project.
Usage
sng::open_db -path
file_path
[-name
db_name
]
Arguments
• -path file_path
Required keyword and path to an existing System Netlist Generator project database.
• -name db_name
Optional keyword and argument that specifies the name of the new database.
Examples
Open an existing project:
set my_db [sng::open_db –path ./saved_db]
Related Topics
sng::save_db
sng::remove_chip

sng::save_db
sng::save_db
Saves the current state of the project.
Usage
sng::save_db db_instance -path file_path [-compact]
Arguments
• db_instance
• -path file_path
Required keyword and path to the location where you want to save the System Netlist
Generator project database.
• -compact
Optional keyword that saves the database in compact mode using the PLACEMENTS and
CONNECTIVITY commands. This command option can only be used if the file_path is a
directory.
Description
Saves the current state of the project to the specified file_path. Compact mode saves the project
as a System Netlist Generator configuration file. See “System Netlist Generator Configuration
File Format” on page 251 for details.
Note
Quotation marks (“ ”) cannot be used in the file_path.
Examples
sng::save_db –path /home/user/existing_db
Related Topics
sng::open_db
sng::remove_chip

sng::filter
sng::filter
Applies a filter to a specified iterator. This command is supported in batch mode only.
Usage
sng::filter iterator -expression filtering_expression
Arguments
• iterator
Required argument that specifies an iterator returned by one of the following commands:
sng::get_buses, sng::get_chips, sng::get_nets, sng::get_placements, sng::get_ports,
sng::get_property, sng::get_property_names.
• -expression filtering_expression
Required keyword and filtering expression that is applied to the iterator object. The
filtering_expression is any supported Tcl math expression. The expression can contain
property names of the objects in the System Netlist Generator project and supports Tcl
variables. The expression can contain any of the following symbols:
&& || == != <= < > >=
To distinguish between property names and values, values must be surrounded by literal
quotation marks (“ ”).
Examples
Example
This example gets the full list of pins from a chip and then retrieves the properties of one of the
buses.
#Set the pins iterator to include all pins of the myram chip.
set pins [sng::get_pins sng::database -chip_name "myram"]
set propName bus_name
#set filtered to equal only those pins that include the bus name adr<>
set filtered [ sng::filter $pins -expression "$propName == \"adr<>\""]
#get the properties of the filtered pin list

while {$filtered != ""} {
puts [sng::get_properties $filtered -property name]
sng::incr filtered 1
}
Example
This example demonstrates how to achieve the same result as the first example using a different
method.

sng::filter
set pins [sng::get_pins sng::database -chip_name "myram"]

set filtered [ sng::filter $pins \
-expression {bus_name == \"adr<>\") && (bus_order<=6)}]
while {$filtered != ""} {

puts [sng::get_properties $filtered -property name]
sng::incr filtered 1
}
Related Topics
sng::unconnect
sng::incr

sng::get_begin
sng::get_begin
Moves the specified iterator to the first element of the container.
Usage
sng::get_begin iterator
Arguments
• iterator
Description
Moves the specified iterator to the first element of the container. The iterator can be returned by
any of the get_ commands. The iterator value changes each time you specify the incr command.
The get_begin command allows you to move the iterator to the start of the container.
Examples
In this example, the net iterator changes when you add connectivity to the project. In these
cases, it is recommended to use the get_begin command as shown.
The following excerpt from the complete example shows the correct usage of the $ when
referencing an iterator:
set inets [sng::get_nets db]

<code that affects the inets iterator>
#set inets iterator to first element
set inets [sng::get_begin $inets]
#get properties of nets
while { $inets != "" } {
set sformat "%-25s"
set l [list " ${prefix}:"]
foreach i [lsort [sng::get_properties $inets]] {
lappend l "$i "
append sformat "%-24s"
}
sng::incr inets 1
puts [eval format $sformat $l]
}

sng::get_begin
The complete example follows:
set db [sng::new_db]
#Start the iterator here to make sure it works properly with the nets
#created later
set inets [sng::get_nets db]
#create chips
foreach chipname {a b c } {
sng::create_chip db -chip_name $chipname -cell_name top
#define pins for the chips
foreach pinnmbr { 0 1 2 3 4 5 6 7 8 9 } {
sng::add_pin db -pin_name pin_$pinnmbr -chip_name $chipname -type INOUT
}
#place chips in the design
foreach placenmbr { 0 1 2 3 } {
sng::create_placement db -placement_name p_${chipname}_$placenmbr \
-chip_name ${chipname}
}
}
#create connections for each placement
foreach placenmbr {0 1 2 3} {
foreach netnmbr {0 1 2 3 4 5 6 7 8 9} {
sng::connect db –net_name net_${placenmbr}_${netnmbr} \
-ports [list \
p_a_${placenmbr}::pin_${netnmbr} \
p_b_${placenmbr}::pin_${netnmbr} \
p_c_${placenmbr}::pin_${netnmbr} \
]
}
}
#unconnect certain nets
foreach netname {net_0_2 net_1_2 net_2_2 net_3_2} {
sng::unconnect db -net_name $netname
}
set inets [sng::get_begin $inets]
#get properties of nets
while { $inets != "" } {
set sformat "%-25s"
set l [list " ${prefix}:"]
foreach i [lsort [sng::get_properties $inets]] {
lappend l "$i "
append sformat "%-24s"
}
sng::incr inets 1
puts [eval format $sformat $l]
}
}
Related Topics
sng::incr

sng::get_buses
sng::get_buses
Returns an iterator for all buses defined in the specified chip.
Usage
sng::get_buses db_instance -chip_name name
Arguments
• db_instance
• -chip_name name
Required keyword and name of a chip in the project.
Examples
This example sets an iterator to the buses on the mem_die chip and retrieves all of the bus
names.
set busIterator [sng::get_buses my_db –chip_name mem_die]

while {$busIterator ne ""} {
set bus_name [sng::get_properties $busIterator –property "bus_name"]
sng::incr busIterator
}
Related Topics
sng::incr
sng::get_chips
sng::get_nets
sng::get_placements
sng::get_ports
sng::get_property
sng::get_property_names
sng::get_pins

sng::get_chips
sng::get_chips
Returns an iterator for all chips defined in the current project.
Usage
sng::get_chips db_instance
Arguments
• db_instance
Examples
This example retrieves the names of all chips in the database.
set chipIterator [sng::get_chips my_db]

while {$chipIterator ne ""} {
set chip_name [sng::get_properties $chipIterator –property "chip_name"]
puts "Chip name is $name "
sng::incr chipIterator
}
Related Topics
sng::incr
sng::get_pins
sng::get_nets
sng::get_placements
sng::get_ports
sng::get_property
sng::get_buses

sng::get_nets
sng::get_nets
Returns an iterator used to access any created nets in the current project.
Usage
sng::get_nets db_instance
Arguments
• db_instance
Examples
This example retrieves the names of all nets in the database.
set netIterator [sng::get_nets my_db ]

while {$netIterator ne ""} {
set net_name [sng::get_properties $netIterator –property "net_name"]
sng::incr netIterator
}
Related Topics
sng::incr
sng::get_chips
sng::get_pins
sng::get_placements
sng::get_ports
sng::get_property
sng::get_buses

sng::get_pins
sng::get_pins
Returns an iterator for all pins on the specified chip.
Usage
sng::get_pins db_instance -chip_name name [-bus_name bus_name]
Arguments
• db_instance
• -chip_name name
Required keyword and name of a chip in the project.
• -bus_name bus_name
Optional keyword and name of a bus in the project. If this option is used, the iterator refers
to all pins that share the bus_name.
Examples
This example sets the iterator to return the pins on the mem_die chip. The while loop retrieves
and prints all of the pin names for that chip.
set pinIterator [sng::get_pins my_db –chip_name mem_die]

while {$pinIterator ne ""} {
set pin_name [sng::get_properties $pinIterator –property "pin_name"]
puts "Pin name is $name."
sng::incr pinIterator
}
Related Topics
sng::get_buses
sng::get_chips
sng::get_nets
sng::get_placements
sng::get_ports
sng::get_property

sng::get_placements
sng::get_placements
Returns an iterator for all placements defined in the current project.
Usage
sng::get_placements db_instance [-chip_name name ]
Arguments
• db_instance
• -chip_name name
Optional keyword and name of a chip in the project. This returns all placements of the
specified chip. If this argument set is not specified, the iterator returns all placements in the
current project.
Examples
This example demonstrates how to get all placements for the mem_die chip.
set placementIterator [sng::get_placements my_db –chip_name mem_die]

puts "Placements for mem_die chip are:"
while {$placementIterator ne ""} {
set placement_name [sng::get_properties $placementIterator \
–property "placement_name"]
puts "\t $placement_name"
sng::incr placementIterator
}
Related Topics
sng::get_pins
sng::get_chips
sng::get_nets
sng::get_ports
sng::get_property
sng::get_buses

sng::get_ports
sng::get_ports
Returns an iterator for all ports defined for the specified placement.
Usage
sng::get_ports db_instance -placement_name placement_name [-bus_name bus_name]
[-net_name net_name] [-unconnected]
Arguments
• db_instance
• -placement_name placement_name
Required keyword and name of a placement in the project.
Optional keyword and name of a bus in the project. If this option is used, the iterator refers
to all ports that share the bus_name.
• -net_name net_name
Optional keyword and name of a net in the project. If this option is used, the iterator refers to
all ports that share the net_name.
• -unconnected
Optional keyword that returns all floating ports of the specified placement.
Description
Initializes an iterator that can be used to access the ports of specified placements. Use the
-unconnected option to find all unconnected pins of the placement. The -net_name and
-bus_name options can be used to narrow down the list of ports to a specified string.
Examples
Example 1
This example demonstrates how to get the port names of the mem_die_placement.
set portIterator [sng::get_ports my_db \

–placement_name memory_die::mem_die_placement]
while {$portIterator ne ""} {
set port_name [sng::get_properties $portIterator –property "port_name"]
puts “"\t$port_name"
sng::incr portIterator
}
Example 2
This example demonstrates how to retrieve all unconnected ports of the
memory_die::mem_die_placement placement that use the bus name “wda”.

sng::get_ports
set portIterator [sng::get_ports my_db \

–placement_name
memory_die::mem_die_placement –unconnected –bus_name "wda"]
set port_name [sng::get_properties $portIterator –property "port_name"]
puts "\t$port_name"
}
Related Topics
sng::incr
sng::get_chips
sng::get_nets
sng::get_placements
sng::get_property
sng::get_pins
sng::get_buses

sng::get_property
sng::get_property
Returns a list of property values for the specified iterator.
Usage
sng::get_property iterator [-property property_name]
Arguments
• iterator
sng::sort.
• -property property_name
Optional keyword and name of a property. This can be any value returned by the
sng::get_property_names command. If this is not specified, the command returns all
property name and value pairs associated with the specified iterator.
Examples
sng::get_property $portIterator –property "port_name"
Related Topics
sng::incr
sng::get_chips
sng::get_nets
sng::get_placements
sng::get_ports
sng::get_buses
sng::get_pins

Returns a list of property names.
Usage
sng::get_property_names iterator
Arguments
• iterator
sng::get_chips, sng::get_pins, sng::get_nets, sng::get_placements, sng::get_ports,
sng::get_buses, sng::sort.
Description
Returns a list of property names for the specified iterator. The properties returned for the
iterator depend on the type of iterator. The following properties are returned for each issued
command and iterator type:
Table 6-7. Property Values For Each Iterator Type

Command Iterator Type Returned Property Values
sng::get_chips Chip iterator “chip_name” “cell_name”
sng::get_pins Pin Iterator “pin_name” “chip_name” “type” “bus_name”
“bus_order”
sng::get_buses Bus Iterator “bus_name” “ order_range”
sng::get_place Placement Iterator “placement_name” “chip_name”
ments
sng::get_ports Port Iterator “port_name” “placement_name” “type” “bus_name”
“bus_order”
sng::get_nets Net Iterator “net_name”
Examples
Get a list of ports from the mem_die_placement placement.
set portIterator [sng::get_ports my_db –placement_name mem_die_placement]

set port_property_name_list [sng::get_property_names $portIterator]
puts "\t$ port_property_name_list"
}

Related Topics
sng::incr
sng::get_chips
sng::get_nets
sng::get_placements

sng::incr
sng::incr
Increments the specified iterator.
Usage
sng::incr iterator [step]
Arguments
• iterator
• step
Optional argument that specifies an offset for the iterator. When the incr command is
executed, the iterator is incremented by this step value. Negative values decrement the
iterator. The default is 1.
Description
Changes an iterator by a specified step value. When the iterator reaches the end, it is reset to an
empty string(“”).
The $ symbol is not used when referencing the iterator in the sng::incr command, however, the
$ symbol is used when passing a specific iterator element to other commands, as shown in the
example.
Examples
Set the iterator to the ports on the mem_die placement and print them by retrieving the property
names with the sng::get_property command.
set portIterator [sng::get_ports my_db –placement_name mem_die_placement]

set port_name [sng::get_properties $portIterator –property "PortName"]
puts "\t$port_name"
}

sng::set_property
sng::set_property
Changes the value of specified properties.
Usage
sng::set_property iterator -property property_name -value property_value
Arguments
• iterator
sng::get_nets, sng::get_buses, sng::get_placements, and sng::get_pins.
Required keyword and property name to change.
• -value property_value
Required keyword and new value for the property_name value.
Description
Sets the value of a specified property_name to a different property_value. This command can
only be used for pins, nets, and placements.
Examples
This example demonstrates how to change the placement names for the logic_die chip using the
set_property command.
puts "Changing placement names for logic_die chip"

set placementIterator [ sng::get_placements –chip_name "logic_die"]
while {$placementIterator ne ""} {
set old_value [ sng::get_properties $placementIterator \
puts "Old value is $old_value"
sng::set_property $placementIterator -property placement_name \
-value new_name_of_placement
set new_value [ sng::get_properties $placementIterator \
puts "New value is $new_value"
sng::incr placementIterator
}
Related Topics

sng::sort
sng::sort
Sorts the elements of a list and returns a new sorted list to an iterator.
Usage
sng::sort iterator -property property_name [-increasing | -decreasing]
[-type { Dictionary | Integer | Real } ]
Arguments
• iterator
Required keyword and property name to sort.
• -increasing
Optional keyword that sorts the list from least to greatest. This command option cannot be
specified with -decreasing. This is the default.
• -decreasing
Optional keyword that sorts the list from greatest to least. This command option cannot be
specified with -increasing.
• -type { Dictionary | Integer | Real }
Optional keywords that specify the type of sorting to apply. The default is Dictionary. The
sorting keywords function as follows:
o Dictionary
Sorts the iterator strings in lexicographic order.
o Integer
Converts the iterator value list to integers and sorts the list in -increasing or
-decreasing order.
o Real
Converts the iterator value list to floating-point values and sorts the list using
floating comparison.
Examples
This example demonstrates how to generate nets with the names net0, net1, net2, and so on, and
connect them to the ports of two placements. The sort command is used to connect one of the
placements with an increasing net order and the other with a decreasing net order.

sng::sort
set portIt1 [sng::get_ports –placement "logic_die::placement1"]

set increadedPortIt1 [sng::sort $portIt1 –property “PortName"]
set portIt2 [sng::get_ports –placement "logic_die::placement2"]
set decreasedPortIt2 [sng::sort $portIt2 –property "PortName" -decreasing]
sng::set_net_name_template –template {net*} –type WILDCARD
while {($decreasedPortIt2 ne "") && ($increadedPortIt1 ne "")} {
set elem1 [sng::get_properties $increadedPortIt1 –property "PortName"]
set elem2 [sng::get_properties $decreasedPortIt2 –property "PortName"]
sng::connect $elem1 $elem2
sng::incr decreasedPortIt2
sng::incr increadedPortIt1
}
If {($decreasedPortIt ne "" ) ||($increadedPortIt1 ne "") } {
error "Connectivity Error: Port counts for placements are not equal!"
}
Related Topics
sng::get_property

sng::add_pin
sng::add_pin
Adds a pin to the specified chip.
Usage
sng::add_pin db_instance -pin_name pin_name -chip_name chip_name
-type { INPUT | OUTPUT | INOUT } [ -bus_name bus_name [-bus_order bus_order]]
Arguments
• db_instance
Required argument that specifies the database instance to modify.
• -pin_name pin_name
Required keyword and name of a new pin to create.
Required keyword and name of an existing chip to which the new pin is added.
• -type { INPUT | OUTPUT | INOUT }
Required keyword set that specifies the direction of the new pin.
Optional keyword and bus name for the pin.
• -bus_order bus_order
Optional keyword and order of the bus for the pin. This argument must only be specified
with the -bus_name argument.
Examples
Add a ground pin to a new chip and connect a bus of pins to a memory chip.
sng::create_chip –name memory –cell_name mem_die

sng::add_pin –pin_name VSS –chip_name memory –type INOUT
for {set index 0} {$index < 10} {inc index} {
sng::add_pin –pin_name test_[$index] –chip_name memory \
–type OUTPUT –bus_name test –bus_order $index
}
Related Topics
sng::remove_pin

sng::connect
sng::connect
Creates a new connection.
Usage
sng::connect db_instance [-net_name net_name]
{ -ports port_list {-add_ports_to_net | -create_new }
[-delimiters ‘{’ delimiter_pair ‘}’]
[-range range] [-starting_index index] | -buses bus_name_list }
Arguments
• db_instance
Optional keyword and name of the net to create. If this command is not specified, the net
name for the generated net is taken from the net name template. Net name templates are
created using the sng::set_net_name_template command.
• -ports port_list
Required keyword and list of ports that you want to connect to the specified net.
• -add_ports_to_net
Keyword that adds all specified ports to an existing net. If the net does not exist, a new net is
created. This keyword must only be used with the -ports argument.
• -create_new
Required keyword that connects all specified ports to a new net. This keyword must only be
used with the -ports argument.
• -delimiters ‘{’ delimiter_pair ‘}’
Optional keyword and pair of delimiters that indicate the start and end character of a bus.
This keyword must only be used with the -ports argument. The default delimiter_pair value
is {\[ \]}.
• -range range
Optional keyword and index range to which the bus is connected. This keyword must only
be used with the -ports argument. All ports are connected by default.
• -starting_index index
Optional keyword and integer index from which the bus starts counting. This keyword must
only be used with the -ports argument.
• -buses bus_name_list
Keyword and list of buses that you want to connect to a specified net.

sng::connect
Description
Specifies net connectivity for ports in the design. The -net_name option can be used if you have
net name templates configured with the sng::set_net_name_template command.
Examples
Example 1
This example connects the ports of two placements. If the number of ports do no match, an error
is issued.
set portIt1 [sng::get_ports my_db –placement_name "logic_die::placement1"]

set portIt2 [sng::get_ports my_db –placement_name "logic_die::placement2"]
set portList1 [list]
while {$portIt1 ne "" } {
lappend portList1 [sng::get_properties $portIt1 –property "port_name"]
sng::incr portIt1 1
}
set portList2 [list]
while {$portIt2 ne ""} {
lappend portList2 [sng::get_properties $portIt2 –property "port_name"]
sng::incr portIt2 1
}
If {[llength $portList2] != [llength $portList1]} {
error "Ports of placements logic_die::placement1 and \
logic_die::placement2 are not same"
} else {
set_net_name_template my_db {net_} ; # net_[0], net_[1] …
foreach port1 $portList1 port2 $portList2 {
sng::connect my_db -ports {$port1 $port2}}
}
Example 2
This example generates a net named DUMMY_CUPO[0], which connects the
RELI3_placement::DUMMY_CUPI[0] pin to the RELI2_placement::DUMMY_CUPO[0] pin,
the DUMMY_CUPO[1] pin to the RELI3_placement::DUMMY_CUPI[1] pin, and so on.
sng::connect my_db –net_name DUMMY_CUPO \

-buses "RELI3_placement::DUMMY_CUPI RELI2_placement::DUMMY_CUPO"
Related Topics
sng::unconnect
sng::incr
sng::set_net_name_template

sng::create_chip
sng::create_chip
Creates a new chip.
Usage
sng::create_chip db_instance -chip_name name [-cell_name cell_name]
Arguments
• db_instance
• -chip_name name
Required keyword and name of the chip to create. The name must be unique.
• -cell_name cell_name
Optional keyword and cell name for the chip. If this argument is not specified, the name of
the cell is given by the name -chip_name argument.
Examples
sng::create_chip –chip_name memory –cell_name mem_die
Related Topics
sng::import_chip

Creates a new placement.
Usage
sng::create_placement db_instance -chip_name chip_name
-placement_name placement_name
Arguments
• db_instance
Required keyword and name of an existing chip in the project.
Required keyword and name of the placement to create. The name must be unique.
Examples
sng::create_placement my_db –placement_name "lg_placement1" \
–chip_name "logic_die"
Related Topics
sng::create_chip

sng::import_chip
sng::import_chip
Imports an existing chip definition.
Note
Set the MGC_SNG_SPICE_IMPORT_TEMP_DIR environment variable to the path of a
temporary directory if you are importing large netlists.
Usage
sng::import_chip db_instance -chip_name name -path file_path
-type SPICE -cell_name cell_name
{ [-bus_detection {YES | NO}] [-bus_pattern reg_expression]
[-bus_order_pattern reg_expression] }
Arguments
• db_instance
• -chip_name name
Required keyword and name of the chip in the file_path. The name of the chip must be
identical to the name of the chip in the specified netlist file.
• -path file_path
Required keyword and path to a netlist file that contains the chip you want to import.
• -type SPICE
Required keywords that specify the format of the netlist file. The System Netlist Generator
currently supports SPICE netlists.
• -cell_name cell_name
Required keyword and name of the cell in the input netlist file.
• -bus_detection {YES | NO}
Optional keywords that specify whether smart bus detection is enabled. Specify YES to
enable smart bus detection. The default is YES.
• -bus_pattern reg_expression
Optional keyword and expression used to generate the name of the buses. This command
option must only be used with the -bus_detection YES option. Regular expression
statements inside parentheses “()” are used in the bus name generation. If the corresponding
pin is not matched with the corresponding regular expression, the pin is not associated with
a bus. The default value for reg_expression is {(\D+)(\d*)(\D+)\d+(\D*)}.
For example, if reg_expression is set to the following:
-bus_pattern {(\D+)_.* }

sng::import_chip
And the following pins are detected in the imported chip:

test_[1] test_[2] test_[3] pins
The bus for those pins is named “test”.

• -bus_order_pattern reg_expression
Optional keyword and regular expression that defines a bus order pattern for the imported
chip netlist. The bus order is a regular pattern that identifies each pin of a bus (for example,
bus_1, bus_2, or bus[1], bus[2]). This command option must only be used with the
-bus_detection YES option. The default value for reg_expression is { (\d+)\D*$}}.
If a pin has a bus, but the bus order is not recognized, a warning is issued.
Examples
This example demonstrates different bus detection options when importing a new chip into the
project database.
#use a bus_order_pattern
sng::import_chip my_db –chip_name memory –type SPICE –path ./mem.spi \
–cell_name mem_die –bus_detection YES \
–bus_pattern {(\D+)_\d+_(.*)} –bus_order_pattern {\D+_(\d+)_.*}
#use a bus_pattern
–cell_name mem_die –bus_detection YES –bus_pattern {(\D+)_(\d+)_(. *)}
#do not use smart detection
–cell_name mem_die –bus_detection NO
Related Topics
sng::create_chip

sng::remove_chip
sng::remove_chip
Removes the selected chip definition.
Usage
sng::remove_chip db_instance -chip_name chip_name
Arguments
• db_instance
• -chip_name name
Required keyword and name of a chip in the project that you want to remove.
Examples
sng::remove_chip db -chip_name mem_die
Related Topics
sng::remove_pin

sng::remove_pin
sng::remove_pin
Deletes a pin from the specified chip.
Usage
sng::remove_pin db_instance -pin_name pin_name -chip_name chip_name
Arguments
• db_instance
• -pin_name pin_name
Required keyword and name of the pin that you want to delete.
• -chip_name name
Required keyword and name of an existing chip in the project.
Examples
This example creates a new chip, adds a 10-bit bus to the chip with the prefix “test_”, and then
removes one of the pins from the bus.
set my_db [new_db]

sng::create_chip my_db –chip_name memory –cell_name mem_die
for {set index 0} {$index < 10} {inc index} {

sng::add_pin db –pin_name test_[$index] –chip_name memory –type OUTPUT\
–bus_name test –bus_order $index
}
sng::remove_pin db –pin_name test_0 –chip_name memory
Related Topics
sng::remove_chip

Removes a placement from the project.
Usage
sng::remove_placement db_instance -placement_name placement_name
Arguments
• db_instance
Required keyword and name of a placement in the project that you want to delete.
Examples
sng::remove_placement my_db –placement_name "lg_placement1"
Related Topics
sng::remove_chip
sng::remove_pin
sng::unconnect
sng::get_placements

Sets the net name template.
Usage
sng::set_net_name_template db_instance prefix [-delimiters ‘{’ delimiter_pair ‘}’]
Arguments
• db_instance
• prefix
Required string that is prefixed to all net names defined in a sng::connect command that do
not have an assigned net name.
• -delimiters ‘{’ delimiter_pair ‘}’
Optional keyword and pair of delimiters that indicate the start and end character of a bus.
This keyword must only be used with the -ports argument. The default delimiter_pair value
is {\[ \]}.
Description
Applies a net name template to all nets. The prefix argument is a string that is prefixed to all net
names that do not have a net name property. For example, if prefix is specified as {Net_}, all
nets generated with the sng::connect command without the -net_name option are named as
follows:
Net_0, Net_1, Net_3 …
Examples
sng::set_net_name_template my_db {Net_} -delimiters {\<\>}
Related Topics
sng::connect

sng::unconnect
sng::unconnect
Deletes specified connections or ports from a net.
Usage
sng::unconnect db_instance {-net_name net_name | -ports port_list }
Arguments
• db_instance
Required keyword and name of the net to disconnect from all ports.
• -ports port_list
Required keyword and list of ports that you want to disconnect from any connected nets.
Ports that do not have any defined connectivity are flagged as warnings.
Examples
Remove Net1 connectivity.
sng::unconnect my_db -net_name "Net1"
Remove Port1 and Port2 from the Net2 net.
sng::unconnect my_db –net_name "Net2" –ports {Port1 Port2}
Related Topics
sng::connect

sng::unconnect

Appendix A
Calibre 3DSTACK Utilities
Calibre 3DSTACK includes utilies that allow you to convert other layout or CSV files into
supported formats.
The spreadsheet conversion utilities and AIF conversion utilities are commands within the
Calibre YieldServer tool.
AIF Converter Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
AIF Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
3dstack::aif2gds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
3dstack::aif2oasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
3dstack::aif2spice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Spreadsheet Converters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
3dstack::ss2gds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
3dstack::ss2oasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
3dstack::ss2spice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
3dstack::xpi2spice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

AIF Converter Reference
AIF Converter Reference

Calibre 3DSTACK includes three utilities that allow you to convert AIF designs to OASIS and
GDS layouts, and SPICE netlists.
AIF Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
3dstack::aif2gds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
3dstack::aif2oasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
3dstack::aif2spice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
AIF Support
The AIF converters are invoked on the Calibre command-line. Not all AIF sections are used by
Calibre 3DSTACK.
AIF Format
The AIF format is documented at the following location:
http://www.artwork.com/package/aif/aif_netlist.htm
Supported AIF Sections

The following sections are supported by the AIF converters:
• [DATABASE]
• [DIE]
• [MCM_DIE]
• [BGA]
• [PADS]
• [NETLIST]
• [RINGS]
Unsupported AIF Sections

The following sections are not ignored by the AIF converters:
• [BONDABLE_RING_AREA]
• [WIRE]
• [FIDUCIALS]

AIF Support
• [DIE_LOGO]

3dstack::aif2gds
3dstack::aif2gds
Reads an AIF file and exports a GDS layout file.
Usage
3dstack::aif2gds -aif aif_file -gds gds_file
Arguments
• -aif aif_file
Required argument and path to an AIF file. See “AIF Support” on page 296 for details on
supported AIF statements.
• -gds gds_file
Required argument and path to the GDS output file.
Examples
Enter the following commands from the command-line:
calibre -ys -3dstack

3dstack::aif2gds -aif design.aif -gds converted_aif.gds
exit

3dstack::aif2oasis
3dstack::aif2oasis
Reads an AIF file and exports an OASIS layout file.
Usage
3dstack::aif2oasis -aif aif_file -oasis oas_file
Arguments
• -aif aif_file
• -oasis oas_file
Required argument and path to the OASIS output file.
Examples

3dstack::aif2oasis -aif in.aif -oasis converted_aif.oas
exit

3dstack::aif2spice
3dstack::aif2spice
Reads an AIF file and exports an SPICE netlist file.
Usage
3dstack::aif2spice -aif aif_file -spice spice_file
Arguments
• -aif aif_file
• -spice spice_file
Required argument and path to the SPICE output file.
Examples

3dstack::aif2spice -aif in.aif -spice converted_aif.sp
exit

Spreadsheet Converters
Spreadsheet Converters
You can convert CSV-formatted spreadsheets into SPICE or GDS and OASIS for use in
Calibre 3DSTACK assembly and verification flows.
For information on creating and managing existing netlists, see the “System Netlist Generator”
on page 221.
The following converters are available:
3dstack::ss2gds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
3dstack::ss2oasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
3dstack::ss2spice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
3dstack::xpi2spice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

3dstack::ss2gds
3dstack::ss2gds
Creates GDS layouts that include pin and die boundary locations from a spreadsheet (CSV) file.
Usage
3dstack::ss2gds -ss ss_file
[-order column_list]
[-die_info GDS ‘{’
-layout_path layout_path
[-die_name die_name]
[-precision precision]
[-vertices {x1 y1 ... xn yn}]
‘}’
]...
[-package package_name]
[-package_mapping ‘{’
-die_name die_name
-layer_number layer_number
‘}’
]...
Arguments
• -ss ss_file
Required path to the spreadsheet (CSV) input file.
• -order column_list
Optional argument set that specifies the order of the columns in the spreadsheet file. The
allowed values are the following: REF_DES, PIN_NUMBER, PIN_X, PIN_Y,
PIN_NAME, and NET_NAME.
• -die_info GDS ‘{’die_arguments ‘}’
Optional set of statements that specify information about the output layout. The following
die_arguments are available:
-layout_path layout_path — Path to the output GDS layout. You can specify a directory
or a full file path.
-die_name die_name — Name of the output GDS layout file.
-precision precision — Precision of the output GDS layout.

3dstack::ss2gds
-vertices {x1 y1 ... xn yn} — Polygon coordinates for generated markers in the GDS
output. These coordinates are not multiplied by the precision during generation.
• -package package_name
Optional name for the generated package layout.
• -package_mapping ‘{’ package_arguments‘}’
Optional set of statements that specify mapping information about a package design from
the REFDES column of the spreadsheet file. The following package_arguments are
available:
-die_name die_name — Name of the die for which the mapping is given.
-layer_number layer_number — Layer number of the mapped die. The layer_number
must be greater than 2.
-vertices {x1 y1 ... xn yn} — Polygon coordinates for the pin cells. These coordinates are
not multiplied by the precision during generation.
Examples
3dstack::ss2gds -ss spreadsheet.txt -die_info GDS ./output \

-package pkg -package_info BGA 3 3 3 -3 -3

3dstack::ss2oasis
3dstack::ss2oasis
Creates OASIS layouts that include pin and die boundary locations from a spreadsheet (CSV)
file.
Usage
3dstack::ss2oasis -ss ss_file
[-die_info OASIS ‘{’
-layout_path layout_path
[-die_name die_name]
[-precision precision]
‘}’
]...
[-package package_name]
[-package_mapping ‘{’
-die_name die_name
-layer_number layer_number
‘}’
]...
Arguments
• -ss ss_file
• -die_info OASIS ‘{’die_arguments ‘}’
Optional set of statements that specify information about the output layout. The following
die_arguments are available:
-layout_path layout_path — Path to the output OASIS layout. You can specify a
directory or a full file path.
-die_name die_name — Name of the output OASIS layout file.

3dstack::ss2oasis
-precision precision — Precision of the output OASIS layout.

-vertices {x1 y1 ... xn yn} — Polygon coordinates for generated markers in the OASIS
output. These coordinates are not multiplied by the precision during generation.
• -package package_name
Optional name for the generated package layout.
• -package_mapping ‘{’ package_arguments‘}’
Optional set of statements that specify mapping information about a package design from
the REFDES column of the spreadsheet file. The following package_arguments are
available:
-die_name die_name — Name of the die for which the mapping is given.
-layer_number layer_number — Layer number of the mapped die. The layer_number
must be greater than 2.
-vertices {x1 y1 ... xn yn} — Polygon coordinates for the pin cells. These coordinates are
not multiplied by the precision during generation.
Examples
3dstack::ss2oasis -ss spreadsheet.txt -die_info OASIS ./output \

-package pkg -package_info BGA 3 3 3 -3 -3
exit

3dstack::ss2spice
3dstack::ss2spice
Converts a CSV input file to a SPICE netlist.
Usage
3dstack::ss2spice -ss ss_file
-spice spice_file
[-top_cell top_cell_name]
[-hier]
[-subckt_pins {NET_NAME | PIN_NUMBER | PIN_NAME}]
Arguments
• -ss ss_file
• -spice spice_path
Required path to the SPICE output file.
• -top_cell top_cell_name
Optional name of the top cell. The default value is TOPCELL_3DI.
• -hier
Optional argument that instructs the converter to generate a hierarchical SPICE netlist.
• -subckt_pins {NET_NAME | PIN_NUMBER | PIN_NAME}
Optional argument set that specifies the type of information specified for the pin column of
the CSV file. The default is PIN_NUMBER.
Examples
Generate a SPICE netlist from a spreadsheet CSV file as follows:

3dstack::ss2spice -ss input.csv \
-spice output.sp \
-top_cell BGA \
-hier
exit

3dstack::xpi2spice
3dstack::xpi2spice
Creates a SPICE netlist from a CSV file generated by Mentor Graphics Xpedition® Enterprise.
Usage
3dstack::xpi2spice -xpi xpi_path -spice spice_path [-top_cell top_cell_name] [-hier]
[-subckt_pins {NET_NAME | PIN_NUMBER | PIN_NAME}]
Arguments
• -xpi xpi_path
Required path to the Xpedition Enterprise CSV input file.
• -spice spice_path
Required path to the SPICE output file.
• -top_cell top_cell_name
Optional name of the top cell. The default value is TOPCELL_3DI.
• -hier
Optional argument that instructs the converter to generate a hierarchical SPICE netlist.
• -subckt_pins {NET_NAME | PIN_NUMBER | PIN_NAME}
Optional argument set that specifies the type of information specified for the pin column of
the CSV file. The default is PIN_NUMBER.
Examples
Generate a SPICE netlist from an Xpedition CSV file as follows:

3dstack::xpi2spice -ss input.csv \
-spice output.sp \
-top_cell BGA \
-hier
exit

3dstack::xpi2spice

Appendix B
Calibre 3DSTACK Flow Example
This example steps you through the complete flow for creating a new rule file for your 3D-IC.
Video
These example procedures are shown in the Calibre 3DSTACK Tutorial video.
Figure B-1. Calibre 3DSTACK Rule Creation and Verification Flow
Example Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Preparing the Dies for Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Creating the Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Writing Assembly Operations in the Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . 313
Writing Verification Checks in the Calibre 3DSTACK Rule File . . . . . . . . . . . . . . . . . 327

Example Design Information

The design used in this example is a 2.5D IC that consists of a memory controller and two
identical ram dies stacked on a silicon interposer.
The controller and ram chips contain only the pad shapes and port text on layer 255. The full
layout is not necessary for the example flow, but the dies are all assumed to be DRC and LVS
clean. The interposer contains landing pads and pin text for the three chips and metal
redistribution layers to connect the controller to the two ram chips and the controller to the IO
pads of the interposer. Figure B-2 shows the input layouts before assembly and Figure B-3
shows the final assembly of the stack.
Video
This example is part of the Calibre 3DSTACK Tutorial video.
Figure B-2. Design Inputs
Figure B-3. Desired 3D-IC Assembly
Related Topics

Preparing the Dies for Assembly
Preparing the Dies for Assembly

Before you verify your 3D-IC with Calibre 3DSTACK, you must complete your layout and
verify each die in the stack. The layout is usually performed with a combination of full custom
layout tools and digital place and route tools.
Video
This procedure is part of the Calibre 3DSTACK Tutorial video.
Procedure
1. Design each die in the stack. Ensure that the TSV or interface pins are texted with the
port names.
In this example, the controller, ram, and interposer layouts only include the pad shapes
and pin text on layer 255. The full placement information is not necessary to assemble
and verify your 3D-IC.
2. Run Calibre nmLVS and Calibre nmDRC on each die and perform corrections until they
are completely LVS and DRC clean.
3. Extract the layout netlists for the dies.
4. Create a source netlist for your complete 3D-IC. The System Netlist Generator allows
you to easily place chips, connect pins, and generate a full netlist for your 3D-IC. For a
full example of the System Netlist Generator flow with executable data, see “System
Netlist Generator Example” on page 230.
5. If you do not have a source netlist, you can still verify the connectivity of your layout
using the trace_text command.
6. Continue to “Creating the Calibre 3DSTACK Rule File” on page 311.
Related Topics
Creating the Calibre 3DSTACK Rule File

Create a new rule file. The Calibre 3DSTACK rule file is a text file that defines the chips,
assembly operations, and verification checks.
Video

Creating the Calibre 3DSTACK Rule File
Procedure
1. Change to the directory where you want to assemble your 3D-IC.
2. Create a new text file. For example, 3dstack.rules.
3. Enter the following statement into your rule file:
This sets the syntax version of the Calibre 3DSTACK description language. There is
currently only one version of the 3D-IC description language syntax.
4. Save the file and continue to “Writing Assembly Operations in the Calibre 3DSTACK
Rule File” on page 313.
Results
You have created a new rule file. Use this rule file for the next tasks.
Examples
####################################################
# CALIBRE 3DSTACK RULES
# This 3DSTACK rule file assembles and verifies the
# 2.5D interposer used in this example
# 9/11/2014
####################################################
# Begin commands
…
Related Topics
Writing Assembly Operations in the Calibre 3DSTACK Rule File
Writing Verification Checks in the Calibre 3DSTACK Rule File
set_version

Writing Assembly Operations in the

Before writing any rule checks for your 3D-IC, you must define the layouts, layers, location and
text placement for the dies, and the layer connectivity. These rule file components are called
assembly operations.
Defining the Layout Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Defining Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Placing the Dies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Connecting Layers and Placements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Attaching Text to Placements for LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Defining the Layout Components

The first assembly operation in your rule file flow is to define the layouts that compose your
3D-IC.
In the example design shown in Figure B-3, a controller and two memory chips are stacked on
an interposer. The two ram chips use the same layout file (ram.gds), while the controller and
interposer have their own layouts (controller.gds and interposer.gds, respectively).
Video
Prerequisites
• DRC and LVS clean layout files.
• Completion of “Creating the Calibre 3DSTACK Rule File” on page 311.
Procedure
1. Open your 3dstack.rules file.
2. After the set_version command statement, define the paths to all of the chips in your 3D-
IC as follows:
-path ./design/interposer.gds -system GDS -original_extent
-path ./design/controller.gds -system GDS -original_extent
layout -chip_name ram -primary ram
-path ./design/ram.gds -system GDS -original_extent

Defining the Layout Components
The layout command creates chip definitions for the controller, ram, and interposer
layout files. The -chip_name value is any unique string and it is used as a handle for
each chip when creating placements.
3. Read in the source netlist for the 3D-IC using the following command:
source_netlist -file .designs/top_cell.spi -format SPICE -case YES
Although optional, a source netlist is highly recommended for debugging issues in your
design. Without a source netlist, Calibre 3DSTACK uses the attached text in the layout
to trace connectivity by matching the text labels on each placement.
Tip
Calibre 3DSTACK can check the syntax of your source netlist without performing a
full verification run. To do so, specify the following invocation arguments:
calibre -3dstack -cs 3dstack_rules
4. Specify the top cell name of the 3D-IC.

5. Save the file and continue to “Defining Layers” on page 315.

Results
The layout files are defined and ready to be placed in the assembly. The ideal electrical
connectivity between the chips is read from the source netlist.

Defining Layers
Examples
####################################################
# CALIBRE 3DSTACK RULES
# This 3DSTACK rule file assembles and verifies the
# 2.5D interposer used in this example
# 9/11/2014
####################################################
# Begin commands
##################
# Assembly Process
##################
###############################
# Create chips from existing GDS
###############################
-path ./designs/interposer.gds -system GDS -original_extent
-path ./designs/controller.gds -system GDS -original_extent
layout -chip_name ram -primary ram \
-path ./designs/ram.gds -system GDS -original_extent
###############################
# Specify top-level source netlist
###############################
source_netlist -file ./designs/top_cell.spi -format SPICE -case YES
Related Topics
source_filter
set_version
source_netlist
layout
Defining Layers
Calibre 3DSTACK requires that you define all layers used in the assembly of your IC. If your
layout files include detailed placement and routing, you only need to define the interface layers
used to connect the dies in the stack. This is a black-box verification flow.
Video
In the example shown in Figure B-3, the controller and ram die have pad shapes and text on
layer 255. These pads connect to the pads on the interposer that are also on layer 255.

Defining Layers
The interposer has landing pad shapes and text on layer 255, but also has additional metal
interconnect and vias that distribute connections between the dies. These metal and via shapes
are on layers 11 through 17.
The pad and redistribution layers define the connectivity of the 3D-IC, so they must be defined
in your rule file.
Prerequisites
• Completion of “Defining the Layout Components” on page 313
Procedure
1. Open your 3dstack.rules rule file.
2. Add the layer definitions after the layout and source_netlist statements as follows:
layer -layer interposer_pads -chip interposer -layer_number 255
layer -layer controller_pads -chip controller -layer_number 255
layer -layer ram_pads -chip ram -layer_number 255
The required -layer argument provides a unique name for the layer. This name is used in
connectivity assignments and in any verification checks. The -chip argument specifies
the chip to which the layer belongs. In this case, the ram, controller, and interposer all
have pad shapes on layer 255.

Defining Layers
3. Specify the interconnect layers used to connect the dies on the interposer as follows:
layer -layer RDL_M1 -chip interposer -layer_number 11
layer -layer RDL_V1 -chip interposer -layer_number 12
Tip
You can also specify layer derivations using the -svrf argument to the layer
command.
4. Save the file and continue to “Placing the Dies” on page 318.
Results
You have defined the pad layers from each of the chips in the stack. You have also defined the
redistribution layers of the interposer that are used to provide connectivity between the
controller and ram dies.
Examples
…layout_primary TOP_CELL
###############################
# Define layers used in design
###############################
#Pad Layers on each chip
layer -layer interposer_pads -chip interposer -layer_number 255
layer -layer ram_pads -chip ram -layer_number 255
#Metal layers on the interposer used to connect chips

Related Topics
layer

Placing the Dies
Placing the Dies

Assemble the 3D-IC by placing, rotating, and arranging the chips. This is the first physical
action in the rule file. The coordinates of each die should be made available by the layout
designer.
Video
In order for the pads on the chips to align with the landing pads on the interposer (shown in
Figure B-3) the placements must have the following lower-left coordinates:
Table B-1. Die Placement Coordinates

Placement Name X (um) Y (um)
controller 17 12
ram_0 80 12
ram_1 80 45
interposer 0 0
Figure B-4. Example Placement Coordinates
Prerequisites
• Completion of “Defining Layers” on page 315.
Procedure

Placing the Dies
2. Add the chip placements after the layer statements as follows:

place_chip -placement pInterposer -chip interposer \
-x_origin 0 -y_origin 0
place_chip -placement pRam0 -chip ram \
The -placement argument specifies a unique name for the chip placement. These names
are used in connectivity and other verification checks later in the rule file. Any errors
associated with a placement during verification are written to the report file with this
name.
Tip
It is recommended to define the -x_origin and -y_origin values as variables so that
they are easier to modify.
3. Save the rule file and close it.

4. Invoke Calibre 3DSTACK and generate the overlay view of the 3D-IC by entering the
following command:
calibre -3dstack -create_assembly 3dstack.assembly 3dstack.rules
The -create_assembly invocation argument only generates the physical view of the
stacked ICs. It does not perform any verification checks. The physical overlay view is
useful for checking the layout, layer, and placement definitions in your rule file without
performing a full run.
5. Open the assembly in Calibre DESIGNrev using the following command:
calibredrv -m 3dstack.assembly.gds.gz

Placing the Dies
6. Change the depth on the layout view by selecting View > Change Hierarchy Depth >
Depths. In the View Depth window, enter 9 in the End depth field and click OK.
This allows you to see the detailed layout within the placements. You can also use the
numpad to set the view depth.
7. Close Calibre DESIGNrev and continue to “Connecting Layers and Placements” on
page 321.
Results
You physically placed the chips in the 3D-IC assembly. You can check for placement errors as
described under “Writing Verification Checks in the Calibre 3DSTACK Rule File” on page 327
Examples
…
###############################
# Arrange chips in 3DSTACK
###############################
place_chip -placement pInterposer -chip interposer \
Related Topics
place_chip

Connecting Layers and Placements

Define how layers interact and attach text objects to layers to define the pin connectivity of the
stack.
Video
Before connectivity operations, your Calibre 3DSTACK rule file must already define the chip
layouts, layers, and placement layers (placed chips). To define the layer stackup connectivity
and how chips are connected, use the connect command.
Figure B-5 illustrates the layers on an interposer for the example design shown in Figure B-3.
Each of the drawn layers is on a separate layer. These layers cannot be used for any rule checks
until they are placed with either the place_chip or place_layer commands.
Figure B-5. Layer Definitions Before Placement
Figure B-6 shows the interposer layers after the interposer is placed. Since each placement uses
a unique name (pInt in this example), the layers on each placement are appended with the
placement name. You must use this placement name in connect operations or rule checks.
Figure B-6. Layer Definitions After Placement
Figure B-7 shows the first connect operation. In this example, the pInt_M1 and pInt_M2 layers
on the interposer are connected through via pInt_V1. The connect command uses the BY
keyword to indicate that these layers are connected with a via.

Figure B-7. Connect two Placed Layers by a Via
Figure B-8 shows how to directly connect two layers. In this example, the pads (pInt_pad) are
directly connected to the pInt_M1 layer.
Figure B-8. Connect Layers Directly
Prerequisites
• Completion of “Placing the Dies” on page 318.
• Layer stackup information (how layers and die placements are connected).
Procedure
2. Add the connect statements after the place_chip statements as follows:
connect pInterposer_RDL_M1 pInterposer_RDL_M2 BY pInterposer_RDL_V1
connect pInterposer_interposer_pads pInterposer_RDL_M1
connect pInterposer_interposer_pads pController_controller_pads
connect pInterposer_interposer_pads pRam0_ram_pads
The first three connect statements connect the metal layers on the interposer placement
through each via layer. The last four statements connect the pad layers on each chip to
the interposer pad layers and to the first metal layer on the interposer. This means that all
of the pads and metal layers are electrically connected.
3. Save the rule file.
4. Continue to “Attaching Text to Placements for LVS” on page 323.

Attaching Text to Placements for LVS
Results
The layers and placements defined earlier in the rule file are now electrically connected as
specified by the layer stackup design intent.
Examples
…
place_chip -placement pRam0 -chip ram -x_origin 80 -y_origin 12
place_chip -placement pRam1 -chip ram -x_origin 80 -y_origin 45
###############################
# Define layer connectivity stack
###############################
# connect interposer layers together
# connect pads on all chips to interposer layers
connect pInterposer_interposer_pads pInterposer_RDL_M1
connect pInterposer_interposer_pads pController_controller_pads
Related Topics
connect

Text that is placed on the pads or pins defines the names of the placement ports.
Video
The text objects allow Calibre 3DSTACK to extract the design schematic from the layout of the
chip with the correct pin names. Similar to the layer connect statements, you must associate text
objects with a text layer for the extraction engine to include the text during LVS operations.
Figure B-9 shows the three placements for the 3D-IC design example shown in Figure B-3. The
text and pad polygons are saved in each chip’s layout on layer 255.

Figure B-9. Placement with Text on Pads
Table B-2 shows the differences in the extracted layout netlist if you were to run
Calibre 3DSTACK without explicitly attaching the text to the polygons with the attach_text
command.
Table B-2. Layout Extraction With and Without attach_text

Without attach_text With attach_text
.SUBCKT pController .SUBCKT pController A<0> A<1> A<2>
.ENDS A<3>
.ENDS
.SUBCKT pRam_0
.ENDS .SUBCKT pRam_0 B<0> B<1>
.ENDS
.SUBCKT pRam_1
.ENDS .SUBCKT pRam_1 B<0> B<1>
.ENDS
.SUBCKT pInterposer
.ENDS .SUBCKT pInterposer C<0> C<1> C<2>
C<3> C<4> C<5> C<6> C<7>
.ENDS
Prerequisites
• Completion of “Placing the Dies” on page 318.
Procedure

2. Add the attach_text statements after the place_chip statements as follows:

attach_text -placement pController_controller_pads \
-text_placement pController_controller_pads
attach_text -placement pInterposer_interposer_pads \
-text_placement pInterposer_interposer_pads
attach_text -placement pRam1_ram_pads \
-text_placement pRam1_ram_pads
attach_text -placement pRam0_ram_pads \
-text_placement pRam0_ram_pads

4. Continue to “Checking Connectivity (LVS)” on page 327.
Results
Text is attached to the pad layer. Calibre 3DSTACK uses the text during layout extraction so
that the port names of the placement are defined in the circuit for LVS comparison. If your chip
definitions do not include text labels on the pins, you can use the import_text_labels command
to import text from a file into your chip.
The layer naming conventions in this assembly work as follows:
• The text and pad shapes in the controller are saved on layer 255 of the layout. The
combined text and polygon layer was defined as an assembly layer using the following
command:
• Any placements of the controller chip include the controller_pads layer. The following
command was used to place the controller:
This means that pController placement contains a layer called controller_pads. This
layer is referenced as pController_controller_pads.
• The attach_text command specifies that the text on this layer belongs to the pad layer on
the placed controller. It just so happens that the text and pad shapes in this example are
on the same layer. The following attach_text command performs this association:

Examples
…
###############################
# Associate text with geometry
###############################
attach_text -placement pInterposer_interposer_pads \
-text_placement pInterposer_interposer_pads
attach_text -placement pRam1_ram_pads -text_placement pRam1_ram_pads
attach_text -placement pRam0_ram_pads -text_placement pRam0_ram_pads
Related Topics
attach_text
import_text_labels

Writing Verification Checks in the Calibre 3DSTACK Rule File
Writing Verification Checks in the Calibre

3DSTACK Rule File
LVS and DRC rules are written using Calibre 3DSTACK rule file commands. They must be
written after all assembly operations are complete.
Checking Connectivity (LVS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Checking Spacing Between Placements (DRC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Checking For Sufficient Pad Overlap (DRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Checking Connectivity (LVS)

Connectivity checks are performed on your 3D-IC using the placement information, source
netlist connectivity, assembly connect statements, and attached text.
Video
To verify the connectivity between chip placements, you use the connected rule file command.
During a Calibre 3DSTACK verification run, the net connectivity between layout instances in
your assembly is generated based on the layer stackup design you specified with the connect
statement. Any text is also attached to the layout pins and traced to the pin names on each
placement. If you specified a source netlist, the original connectivity is compared to the
extracted netlist.
This is a continuation of the assembled design shown in Figure B-3.
Prerequisites
• Completion of “Connecting Layers and Placements” on page 321.
• Layers connected with the connect command.
• Port text attached to each chip placement with the attach_text command.
Procedure

Checking Connectivity (LVS)
2. Add the connected statements after the assembly statements as follows:

###############################
# LVS Checks
###############################
connected -check_name CONNECT_Cont_to_Int \
-placement1 pController_controller_pads \
-placement2 pInterposer_interposer_pads \
-detailed -comment "CONNECT::Controller to Interposer check"
connected -check_name CONNECT_Cont_to_Ram_0 \
-placement2 pRam0_ram_pads \
-detailed -comment "CONNECT::Controller to Ram0 check"
connected -check_name CONNECT_Ram0_to_Int \
-detailed -comment "CONNECT::Ram0 to Interposer check"
Each rule check must have a unique name. In this example, the connection rules are
prefixed with CONNECT, a placement name, and destination placement name.
The -placement1 and -placement2 commands specify the chips placements that are
should be connected.
The -detailed option writes out additional information to the report file.
4. Continue to “Checking Spacing Between Placements (DRC)” on page 329.
Results
Connectivity rules are established. Calibre 3DSTACK uses the layer connectivity and text on
the port shapes (pins) to determine the net connectivity between chip placements. If a source
netlist is specified, the tool compares the connectivity extracted from the layout to the source
connectivity. If no source netlist is specified (not recommended), you must specify the
trace_text command in your assembly. In this case, the comparison is performed by text
matching only (port text on the placements should match).

Checking Spacing Between Placements (DRC)
Examples
…
#End Assembly commands
###############################
# LVS Checks
###############################
-detailed -comment "CONNECT::Controller to Interposer check"
Related Topics
connect
connected

Calibre 3DSTACK includes a number of physical checks that operate similar to SVRF spacing
checks. It is recommended that you use the internal Calibre 3DSTACK commands to check for
spacing violations.
Video
The enclosure, external, and internal commands provide basic spacing checks.
Prerequisites
• Completion of “Writing Assembly Operations in the Calibre 3DSTACK Rule File” on
page 313.

Procedure
2. To check spacing between dies, add external statements after the connected statements
as follows:
external -check_name DIE_SPACE_Cont -placement1 pController \
-constraint "< 65 REGION" -comment "ERR:Placement within 65um!"
external -check_name DIE_SPACE_RAM0 -placement1 pRam_0 \
Each rule check must have a unique name. If specified the layout command with the
-original_extent option, all polygon layers on the chip are used to determine the extent
of the chip in the x and y directions.
The external command automatically uses this extent when you specify the two
placements. This effectively checks the spacing between the edges of the dies.
3. To check spacing between other layers, such as the metal interconnect on the interposer,
specify the following commands:
external -check_name RDL_M1.1 -placement1 pInterposer_RDL_M1 \
-constraint "< 1 REGION" -comment "ERR: Spacing < 1um on RDL_M1!"
-constraint "< 0.5 REGION" -comment "ERR: Space < 0.5um on \
RDL_M2!"
…
4. Add enclosure, external, and internal commands for each layer as appropriate.
6. Continue to “Checking For Sufficient Pad Overlap (DRC)” on page 331.
Results
Spacing rules between dies were created. The extent of the die is automatically created from the
layout polygons if -original_extent is specified when applying the layout command.

Checking For Sufficient Pad Overlap (DRC)
Examples
…
###############################
# DRC Checks
###############################
external -check_name DIE_SPACE_Cont -placement1 pController \
-constraint "< 1 REGION" -comment "ERR: Spacing < 1um on RDL_M1!"
-constraint "< 0.5 REGION" -comment "ERR: Space < 0.5um on RDL_M2!"
Related Topics
enclosure
external
internal

If a chip is placed slightly off of its target, or the geometry of the pads do not match exactly
between chips, the pads may still be electrically connected, but not acceptable for
manufacturing. The overlap tolerance must be checked to avoid false connected check reports.
Video
Prerequisites
• Completion of “Writing Assembly Operations in the Calibre 3DSTACK Rule File” on
page 313.
Procedure

2. To check for sufficient pad overlap by the percentage of the overlap, add overlap
commands after the assembly operations as follows:
overlap -check_name "OVERLAP_Cont_to_Int_percent" \
-constraint " < 99" -intersection \
-comment "Pad overlap must be greater than 99%!"
In this case, if the overlap between the controller and interposer pads is not greater than
99%, then the rule check fails.
3. To specify the pad overlap by the area of the overlap, use the -by_area command as
follows:
overlap -check_name "OVERLAP_Cont_to_Int_area" \
-comment "Pad overlap must be greater than 13 um^2!"
4. In this case, if the overlap between the controller and interposer pads is not greater than
13 um2, then the rule check fails.
5. Save the rule file and close it.
6. Continue to “Running a Calibre 3DSTACK Verification from the Command Line” on
page 32.
Results
Pad overlap rules were created to ensure that tolerance in overlap is acceptable.
Examples
…
-constraint "< 0.5 REGION" -comment "ERR: Space < 0.5um on RDL_M2!"
overlap -check_name "OVERLAP_Cont_to_Int_area" \
-constraint " < 13" -intersection -by_area\
-comment "Pad overlap must be greater than 13um^2!"
Related Topics
overlap

centers


Appendix C
Examples
The Calibre 3DSTACK rule file contains assembly operations that build an equivalent model of
your 3D-IC and a set of verification rules.
Tip
“Calibre 3DSTACK Flow Example” on page 309 steps you through creating a Calibre
3DSTACK rule file for a 2.5D IC from scratch. “System Netlist Generator Example” on
page 230 steps you through the creation of a source netlist for your 3D-IC. “Calibre 3DSTACK
Verification Examples” on page 31 and “Calibre 3DSTACK Results Analysis Examples” on
page 38 show how to run Calibre 3DSTACK and debug results.
Calibre 3DSTACK+ Extended Syntax Example

Extended syntax rule files are more flexible than conventional Calibre 3DSTACK rule files
because the assembly operations can be separate from the rules.
The following example creates a simple 2.5D IC with a controller die and two memory dies
stacked on a passive interposer.
Opening Statements
Extended syntax rules must begin with the following line:
#!3dstack+
The next statement must be the set_version command to set the syntax version of the rule file.
The only supported version is “1.0”
#!3dstack+
######################################################################
#
# CALIBRE 3DSTACK+ Rule File for 2.5D Interposer
#
######################################################################
Calibre 3DSTACK Settings

Apply the config command to set up layout, connectivity, and output options. In this example,
the rule file provides a name for the generated stack assembly, specifies a source netlist for the
complete assembly (highly recommended), specifies that a detailed report be output, and
exports the generated assembly netlist to a Verilog file.

Examples
###########################
# Configure run
###########################
config \
-layout_primary TOP_CELL \
-source_netlist {-file ./design/top_cell.spi -format SPICE -case YES }\
-report {-file output/3dstack.report} \
-export_connectivity {-file output/3dstack.v -format verilog }
Die and Layer Definitions

The next section defines each die used in the stack. The die definitions must include paths to
layout files and any layers used for connectivity in the stack. The first die definition is the
interposer, which includes a number of metal layers used to connect the dies. In order for
Calibre 3DSTACK to understand how these layers interact, you must define the layer-to-layer
interactions with the die -wb_connect argument. This is referred to as white-box connectivity
because you are defining layer connectivity within a die and not just the external interfaces. To
indicate that a layer is part of an connectivity stack external to the die (for connectivity tracing
between dies), apply the -layer_info … -ext_connect option.
Note, that this section only defines the dies used in the stack. How these dies are physically
placed in the assembly is performed with the stack command.
###########################
# Define dies in stack
###########################
die -die_name interposer \

-layout { \
-path ./design/interposer.gds \
-type gdsii \
-primary interposer \
-depth all \
} \
-layer_info { \
-type pad \
-name interposer_pads \
-ext_connect \
-layer { \
255 \
-depth all \
} \
-text { 255 } \
-bottom \
} \

Examples
-layer_info { \
-type RDL_M1 \
-name RDL_M1 \
-ext_connect \
-layer { \
11 \
-depth all \
} \
-bottom \
} \
-layer_info { \
-type RDL_V1 \
-name RDL_V1 \
-layer { \
12 \
-depth all \
} \
-bottom \
} \
-layer_info { \
-type RDL_M2 \
-name RDL_M2 \
-layer { \
13 \
-depth all \
} \
-bottom \
} \

Examples
-layer_info { \
-type RDL_V2 \
-name RDL_V2 \
-layer { \
14 \
-depth all \
} \
-bottom \
} \
-layer_info { \
-type RDL_M3 \
-name RDL_M3 \
-layer { \
15 \
-depth all \
} \
-bottom \
} \
-layer_info { \
-type RDL_V3 \
-name RDL_V3 \
-layer { \
16 \
-depth all \
} \
-bottom \
} \
-layer_info { \
-type RDL_M4 \
-name RDL_M4 \
-layer { \
17 \
-depth all \
} \
-bottom \
} \
-interposer \
-wb_connect RDL_M1 RDL_M2 BY RDL_V1 \
-wb_connect interposer_pads RDL_M1

Examples
die -die_name controller \

-layout { \
-path ./design/controller.gds \
-type gdsii \
-primary controller \
-depth top-only \
} \
-layer_info { \
-type pad \
-name cont_c4 \
-ext_connect \
-layer { \
255 \
-depth top-only \
} \
-text { 255 } \
-bottom \
}
die -die_name ram \

-layout { \
-path ./design/ram.gds \
-type gdsii \
-primary ram \
-depth top-only \
} \
-layer_info { \
-type pad \
-name ram_c4 \
-ext_connect \
-layer { \
255 \
-depth top-only \
} \
-text { 255 } \
-bottom \
}
Assembly Operations
Up to this point in the rule file, all dies and layers are defined. The next step is to define how
these dies are placed (assembled) using the stack command. In this example, the bottom die is
placed first using the -die argument. The -placement argument determines the horizontal x and y
placement of the interposer. The controller and two ram dies are on the same vertical plane
(their initial z-coordinates are the same). This is referred to as a tier. The tier is stacked on top of
the interposer, where the initial z-coordinate of the tier is determined implicitly from the
thickness and specified -z_origin of the interposer.
Figure C-1 and Figure C-2 show the assembly generated by the statements in this example.

Examples
###############################
# Arrange chips in 3DSTACK
###############################
stack -stack_name assembly \

-die { \
-name interposer \
-placement 0 0 \
-invert \
} \
-z_origin 0 \
-tier { \
-die {-name controller -placement 14 12}\
}
Figure C-1. Overhead View of the Example Assembly
Figure C-2. Side View of the Example Assembly
Verification Rules
The verification rules in the 3DSTACK+ extended syntax are layer-based, unlike the
placement-based syntax used in the conventional Calibre 3DSTACK syntax. This enables you
to write rules that can be used for any assemblies that use the same design kit layer definitions.

Examples
The examples in this section demonstrate just a few of the available verification checks. See
“Rule Check and Analysis Commands for the Calibre 3DSTACK+ Extended Syntax” on
page 185 for a complete description of the verification commands for the extended syntax file.
###############################
# LVS Checks
###############################

-layer_type1 pad \
-layer_type2 pad \
-detailed -black_box \
-comment "CONNECT::Controller to Interposer check"

-detailed \
-comment "CONNECT::Controller to Ram0 check"

-detailed \
-comment "CONNECT::Controller to Ram1 check"

-detailed \
-comment "CONNECT::Ram0 to Interposer check"

-detailed \
-comment "CONNECT::Ram1 to Interposer check"

Examples
Conventional Syntax — Example 1
###############################
# DRC Checks
###############################
external -check_name DIE_SPACE_Cont -layer_type1 pad \
-layer_type2 pad \
external -check_name RDL_M1.1 -layer_type1 RDL_M1 \

-constraint "< 1 REGION" -comment "ERR: Spacing < 0.1um on RDL_M1!"
internal -check_name RDL_M1.2 -placement1 pInterposer_RDL_M1 \

-constraint "< 1 REGION" -comment "ERR: Metal smaller than 1um on
RDL_M1!"

-constraint "< 0.07 REGION" -comment "ERR: Spac < 0.5um on
RDL_M2!"

-layer_type1 pad \
-layer_type2 pad \
select_checks -check_names {OVERLAP_Cont_to_Int_percent DIE_SPACE_Cont

CONNECT_Cont_to_Int}

A typical example using the conventional Calibre 3DSTACK rule file syntax.
# This file includes a 3D-IC Description Language ("3DIC_DL")
# used within/by Mentor Graphics’ products supporting 2.5D/3D-IC IC
# applications. You shall not use this 3DIC_DL # unless you are a Mentor
# Graphics customer. The exact terms of your obligations and rights are
# governed by your respective license.
# You shall not use this 3DIC_DL except:
# (a) for your internal business purposes and
# (b) for use with Mentor Graphics' Calibre(r) tools.
# The 3DIC_DL may constitute or contain trade secrets and confidential
# information of Mentor Graphics or its licensors. You shall not make the
# 3DIC_DL available in any form to any person other than your employees
# and on-site contractors, excluding Mentor Graphics competitors, whose
# job performance requires access and who are under obligations of
# confidentiality.

Examples
# Ensure layouts are LVS/DRC clean by running Calibre
# declare layouts
layout -chip_name c1 -primary TOPCELL -path ./chip1.gds -system GDS \

-original_extent
layout -chip_name c2 -primary TOPCELL -path ./chip2.gds -system GDS \
-original_extent
layout -chip_name ip -primary TOPCELL -path ./interposer.gds -system GDS
# declare layers


layer -layer m13 -chip ip -layer_number 0

layer -layer m23 -chip ip -layer_number 1
# declare additional layers
# Note that TVF code inside the tvf_block check is stand-alone and is
# outside the scope of the chip stack rule file.
tvf_block additional_layers {
tvf::SETLAYER m11_m21 = c1p_m11 AND c1p_m21;
tvf::SETLAYER m12_m22 = c2p_m12 AND c2p_m22;
} -export_layers [list m11_m21 m12_m22]
# export connectivity
export_connectivity -file spice_output.spi -format SPICE
# import connectivity
source_netlist -file spice_input.spi -format SPICE
# place chip2 and the interposer
place_chip -placement c2p -chip c2 -x_origin 1.85 -y_origin 0

place_chip -placement ipp -chip ip -x_origin 0 -y_origin 0

Examples
# create a 2x3 array of chip1 placements
for { set x 1 } { $x < 3 } { incr x } {
for { set y 1 } { $y < 4 } { incr y } {
place_chip -placement c1p_$x\_$y -chip c1 -x_origin [expr $x+1] \

-y_origin [expr $y+1] -flip y
}
}
# dimensional checks
#results highlighted in Calibre RVE only show layers used in checks:

enclosure -check_name enc_check -placement1 ipp_m13 \

-placement2 c2p_m12 -constraint "<= 0.03 REGION" \
-comment "enclosure check" -set_rve_highlight_color blue
external -check_name ext_check -placement1 ipp_m13 \
-constraint "<= 0.05 REGION" \
-comment "external check" -set_rve_highlight_color yellow
internal -check_name int_check -placement1 ipp_m13 \
-constraint "<= 0.17 REGION" \
-comment "internal check"
# connectivity check

attach_text -placement ipp_m13 -text_placement ipp_m13
connected -check_name con_check -placement1 c2p_m12 \

-placement2 ipp_m13 -comment "connectivity check" \
-set_rve_priority 1
# output report
report -file report.txt

Simplified method for creating regular assemblies and connectivity checks using the
conventional Calibre 3DSTACK rule file syntax.

Examples
# This file includes a 3D-IC Description Language ("3DIC_DL")

# used within/by Mentor Graphics’ products supporting 2.5D/3D-IC IC
# applications. You shall not use this 3DIC_DL # unless you are a Mentor
# Graphics customer. The exact terms of your obligations and rights are
# governed by your respective license.
# You shall not use this 3DIC_DL except:
# (a) for your internal business purposes and
# (b) for use with Mentor Graphics' Calibre(r) tools.
# The 3DIC_DL may constitute or contain trade secrets and confidential
# information of Mentor Graphics or its licensors. You shall not make the
# 3DIC_DL available in any form to any person other than your employees
# and on-site contractors, excluding Mentor Graphics competitors, whose
# job performance requires access and who are under obligations of
# confidentiality.
layout_primary TOPCELL_3DIC
# stack three chips together (chip1.gds through chip3.gds)
for { set i 1 } { $i <= 3 } { incr i } {

layout -chip_name c$i -primary TOPCELL -path ./chip$i\.gds \
-system GDS
layer -layer m$i -chip c$i -layer_number 0
place_chip -placement c$i\p -chip c$i -x_origin [expr $i-1] \
-y_origin 0
attach_text -placement c$i\p_m$i -text_placement c$i\p_m$i
}
# perform verification checks
for { set i 1 } { $i <= 2 } { incr i } {
connect c$i\p_m$i c[expr $i+1]p_m[expr $i+1]

connected -check_name con_check$i -placement1 c$i\p_m$i \
-placement2 c[expr $i+1]p_m[expr $i+1]
internal -check_name int_check$i -placement1 c$i\p_m$i \
-placement2 c[expr $i+1]p_m[expr $i+1] -constraint "<= 0.5" \
-comment "internal check$i\, c$i\p_m$i to c[expr $i+1]p_m[expr $i+1]"\
-set_rve_show_layers AUTO
}
# output report
report -file report.txt

Examples

Appendix D
Error and Warning Messages
Error and warning messages are generated by the Calibre 3DSTACK tool at run time.
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Error Messages
Error messages must be corrected to continue a Calibre 3DSTACK run.
Error messages take the following form:
3DSTACK_ERROR_number: error_message
Table D-1. Calibre 3DSTACK Error Messages

Number Description Possible Causes
3DSTACK_ERROR_100 Unable to find the Invalid Calibre installation.
executable file, please
check your installation.
3DSTACK_ERROR_101 Unable to find layout file. The value of the -path argument for a
layout command is incorrect.
3DSTACK_ERROR_102 Unable to find 3DSTACK The path to the rule_file_name is
file. incorrect for the 3DSTACK run.
3DSTACK_ERROR_103 Unable to find rule file. The value of the -rule_deck
argument for a run command is
incorrect.
3DSTACK_ERROR_104 Unable to find NetList The value of the -file argument for a
file. source_netlist command is incorrect.
3DSTACK_ERROR_105 Unable to find cell. The value specified for the -primary
argument in a layout command does
not match the top cell name for the
design.
3DSTACK_ERROR_106 Unable to find layer or This error is caused by a reference to
placement. an invalid layer or placement name.

Error Messages
Table D-1. Calibre 3DSTACK Error Messages (cont.)

3DSTACK_ERROR_107 Unable to find anchor. This error is caused by a reference to
an invalid anchor name. Ensure that
the value of the -name argument for
each anchor command is correct, and
that the values of the -anchor_from
and -anchor_to arguments for
place_chip and place_layer are
correct.
3DSTACK_ERROR_108 No placement definition The chip stack configuration file
found. does not contain any place_chip nor
any place_layer commands.
3DSTACK_ERROR_109 Unable to find import file.
3DSTACK_ERROR_110 Unable to find the Assembly file specified with the
3DSTACK assembly file. -use_assembly invocation argument
cannot be found.
3DSTACK_ERROR_111 Unknown extension for
the 3DSTACK assembly
file.
3DSTACK_ERROR_112 Unable to find type file
file_name
3DSTACK_ERROR_117 The -overlapping flag of The -overlapping option of the
centers command can be centers command checks the overlap
applied only when between pads of two placements.
-placement2 is specified! You must specify a second
placement for this option to be used.
3DSTACK_ERROR_118 There are text renaming By default, text errors are reported
rule(s) for placement(s) by chip instead of by placement. If
placement_list. Chip this warning is issued, the text
based text check reporting reporting is performed for each
is disabled! placement in the connectivity stack
because there is a rename_text
operation on the placement.
3DSTACK_ERROR_200 The displayed argument is The displayed command is missing a
a mandatory option for mandatory argument.
the displayed command.
3DSTACK_ERROR_201 The displayed value is The displayed value is invalid;
invalid for the displayed replace it with a value from the
option. displayed list.

Error Messages

3DSTACK_ERROR_202 The displayed option is
invalid for the displayed
command.
3DSTACK_ERROR_203 Wrong number of The number of specified arguments
arguments. does not match the number of
expected arguments.
3DSTACK_ERROR_204 Wrong argument. The name of the specified argument
does not match the name of the
expected argument.
3DSTACK_ERROR_205 Incorrect input argument. The name of the specified input
argument does not match the name
of the expected argument.
3DSTACK_ERROR_206 Unknown tag. Please The displayed option is invalid;
specify a valid tag from replace it with an option from the
the following list. displayed list.
3DSTACK_ERROR_207 Expecting a non-zero The syntax of the input file for
integer number of the import_text_labels is incorrect.
displayed argument value.
3DSTACK_ERROR_208 Expecting keyword - The -export_layers keyword must
export_layers after check appear after each check body. Refer
body. to Conventional Syntax — Example
1.
3DSTACK_ERROR_209 Expecting a value of the The datatype specified for the
displayed type for the displayed parameter is incorrect.
displayed parameter.
3DSTACK_ERROR_210 Failed to import the The input netlist was not specified
netlist. correctly. Check the source_netlist
command in your rule deck, or the
Inputs > Netlist tab in
Calibre Interactive 3DSTACK.
3DSTACK_ERROR_211 Failed to export the Writing of the netlist failed.
netlist.
3DSTACK_ERROR_212 -x_origin, -y_origin and The syntax for place_chip or
anchor definition are place_layer is incorrect.
mutually exclusive
options.

Error Messages

3DSTACK_ERROR_213 Expecting: check/ The syntax of the rule check is
tvf_block name body incorrect. Refer to Conventional
-export_layers layer_list Syntax — Example 1.
[-attach_to_placement
placement].
3DSTACK_ERROR_215 A required command is
missing from the
argument list.
3DSTACK_ERROR_216 Unable to read the netlist.
3DSTACK_ERROR_217 Unable to compile the
specified custom check.
3DSTACK_ERROR_218 Filtering expression is
invalid.
3DSTACK_ERROR_219 Identical placements are Identical placements are specified in
illegally specified in the the connected check command.
connected command. Correct your rule file to remove the
identical instances for this check.
3DSTACK_ERROR_220 Invalid value value for The highlighted rule check uses a
option option_name. name that is a protected
Should not be a 3dstack Calibre 3DSTACK file format
rule file format keyword. keyword. Change the name of the
rule check.
3DSTACK_ERROR_221 placement1 and You cannot specify a layer
placement2 arguments placement and a chip placement in a
both should be either single geometrical check. The two
layer placements or chip placement arguments in the
placements. command must be of the same type.
See enclosure, external, or internal
for more details on the correct
syntax.
3DSTACK_ERROR_300 Net, pin or placement
already exists in the
displayed cell.
3DSTACK_ERROR_301 Layer or placement with
the displayed name
already exists.
3DSTACK_ERROR_302 Layout with the displayed There is more than one layout
name already declared. command with the same -chip_name
value.

Error Messages

3DSTACK_ERROR_303 Anchor with the displayed Duplicate anchor -name value for the
name already declared in same chip.
layout.
3DSTACK_ERROR_304 The displayed placement There is more than one attach_text
already has text- command with the same -placement
placement attached. value.
3DSTACK_ERROR_305 Only single occurrences There is more than one instance of
of source_netlist the source_netlist command.
statement are allowed.
3DSTACK_ERROR_306 There are multiple text-
labels overlapping with
the pads on the displayed
layer.
3DSTACK_ERROR_307 Multiple definitions of the
same placed layer are not
allowed.
3DSTACK_ERROR_308 A layout filename already The same filename or filepath has
exists that is the same as been specified in the
the filename specified in export_template and layout
export_template. commands. Modify one of the
commands accordingly. The
export_template command is located
under Outputs > Export Data in
Calibre Interactive.
3DSTACK_ERROR_309 An undefined check name
is specified in the
select_checks command.
3DSTACK_ERROR_310 The placement already
has a specified tracer
placement.
3DSTACK_ERROR_311 Placement Placements in a connected check
$placement_name need to have corresponding connect
specified in connected statements.
command must be part of
a connectivity stack.
3DSTACK_ERROR_312 The specified placement A placement may be missing text.
used in a trace_text Verify that your trace_text command
operation must have references a placement that has
attached text. attached text (see the attach_text
command).

Error Messages

3DSTACK_ERROR_313 The specified placement There may be a conflict in your
already has attached text trace_text and attach_text
and cannot be part of a operations.
trace_text operation.
3DSTACK_ERROR_314 The specified placement There may be a conflict in your
used in a trace_text trace_text, attach_text, and
operation cannot be part connected operations.
of a connected check.
3DSTACK_ERROR_315 Cascade tracing is not This error is issued when a trace_text
allowed. operation attempts to reference a
placement specified in another
trace_text command. In other words,
the connectivity data for the tracer-
placement cannot be traced from a
different one. Verify your trace_text,
attach_text, and connect operations.
3DSTACK_ERROR_316 Source filtering is already The source_filter command has been
defined for the listed applied multiple times to the same
items. components. Correct your
source_filter command.
3DSTACK_ERROR_317 The specified placement A placement in your design is
should have connectivity missing connectivity information.
information attached in The connected operation cannot be
order for the connected performed correctly. Verify your
check to work. connect operations for the specified
placement.
3DSTACK_ERROR_318 The derived placement A placement exported from a
cannot be used as text tvf_block operation has been
placements for an incorrectly used in an attach_text
attach_text command. operation.
3DSTACK_ERROR_319 Cannot retrieve the
specified property from
the specified layer.
3DSTACK_ERROR_400 Missing cell or placement. This error can be issued if your
design is missing a placement used
in a connected rule check. Cross
check any placement and connect
assembly operations with the
connected checks used in your rule
file.

Error Messages

3DSTACK_ERROR_401 The displayed cell already
exists in the connectivity
database.
3DSTACK_ERROR_402 Incomplete definition of
check. Connect check
should be defined for two
layers.
3DSTACK_ERROR_403 Connect check pre-
requisites not met. Please
extract connectivity first.
3DSTACK_ERROR_404 Prototype cell mismatch. A topcell name from a source netlist
does not match the value of a layout
-primary option.
3DSTACK_ERROR_406 Connectivity check error. The source_netlist input file is
invalid.
3DSTACK_ERROR_407 The displayed pin is
connected to different
nets.
3DSTACK_ERROR_500 The displayed application Check your Calibre installation.
is not executable. Please
check your installation.
3DSTACK_ERROR_501 Unable to read directory. There was a problem accessing a
temporary directory. Check ⁄tmp,
⁄var⁄tmp, or ⁄usr⁄tmp.
3DSTACK_ERROR_502 Given directory is not Check the permissions on the
writable. directory specified with the
“run -directory” option.
3DSTACK_ERROR_503 The displayed value is a Ensure that the “run -directory”
file, not a directory. option points to a directory.
3DSTACK_ERROR_504 The displayed value is a Ensure that the “run -directory”
directory, not a file. option points to a file.
3DSTACK_ERROR_505 The displayed file is not
writable.
3DSTACK_ERROR_506 The displayed file is not Verify the location and contents of
readable. the file.
3DSTACK_ERROR_600 Please provide a version A set_version command is required.
number by invoking
set_version command.

Error Messages

3DSTACK_ERROR_601 Negative magnify factor, The -magnify value for place_chip
please specify a positive and place_layer must be a positive
number. number.
3DSTACK_ERROR_602 Only orthogonal rotations The -rotate value for place_chip and
are allowed in place_chip place_layer must be either 0 or a
or place_layer commands. multiple of 90 (positive or negative).
3DSTACK_ERROR_603 No layers are defined for No layer statements exist for the
the displayed layout. displayed chip name.
3DSTACK_ERROR_604 Poorly formed anchor The syntax for the anchor definition
definition for the in a place_chip or place_layer
displayed placement. command is incorrect.
3DSTACK_ERROR_605 The Calibre run failed. One possible cause is the value of the
Refer to the run log for -directory argument for a run
further details. command is incorrect.
3DSTACK_ERROR_606 No text placement is An attach_text command is missing
attached to the displayed for the displayed placement.
placement.
3DSTACK_ERROR_607 Syntax error.
3DSTACK_ERROR_608 <error message> This error number is used in multiple
cases; the message describes the
specific case.
3DSTACK_ERROR_609 Syntax Error
3DSTACK_ERROR_610 Unknown Version. The version you are currently using
is not supported.
3DSTACK_ERROR_611 The check source Your source_netlist is not SPICE
operation can only be formatted and you have specified the
applied for SPICE calibre -3dstack -cs invocation
netlists. argument (or Inputs > Netlist >
Check source netlist only in
Calibre Interactive) to verify the
source netlist syntax. SPICE is the
only supported format for -cs.
3DSTACK_ERROR_700 The specified data does The Calibre 3DSTACK database is
not exist. missing data. This error is issued in
Calibre YieldServer when a handle
to a non-existent netlist database
object is requested with the
3dstack::get_netlist command.

Warning Messages

3DSTACK_ERROR_701 The specified data already This is issued in Calibre YieldServer
exists. if a netlist database object in the
Calibre 3DSTACK DFMDB already
exists with the same name.
3DSTACK_ERROR_702 Missing a prototype cell. This is issued in Calibre YieldServer
The database may be if the Calibre 3DSTACK DFMDB
corrupted. may have become corrupted.
3DSTACK_ERROR_1106 Unable to find package You specified a package with the
die with the name -pkg option that does not exist in
<package-name> your design. See config for the
extended syntax rules or
export_connectivity for 3DSTACK
rules.
Warning Messages
Warning messages should be reviewed to determine if they indicate a real problem in your
design.
Warning messages take the following form:
3DSTACK_WARNING_number: warning_message
Table D-2. Calibre 3DSTACK Warning Messages

3DSTACK_WARNING_100 Unable to find specified An incorrect argument may be
argument. specified.
3DSTACK_WARNING_101 No connectivity is In order for text tracing and attach
defined for the operations to occur, the placement
placement must have its connectivity
placement_name. defined. Refer to the connected,
Should be part of trace_text, and attach_text
connectivity stack or commands for examples.
selected connected
statement. No text
attachment is performed.

Warning Messages
Table D-2. Calibre 3DSTACK Warning Messages (cont.)

3DSTACK_WARNING_102 No checks are selected This message occurs when you
or defined. Only the 3D have invoked Calibre 3DSTACK
assembly generation is with the -create_assembly
performed. assembly_name invocation
argument. This limits a run to only
generate an assembly view file.
See Calibre 3DSTACK Invocation
and Specifying Assembly
Instructions for complete details.
3DSTACK_WARNING_103 Unable to find specified The assembly operations may not
values. Any connected be fully defined for the object
checks may produce specified in the warning message.
incorrect results!
3DSTACK_WARNING_104 Overriding mapping.
3DSTACK_WARNING_105 Multiple pads from You may have attached text to two
tracer layer layer are or more pads erroneously. This
connected to the same can produce connectivity errors.
net despite of having Verify any attach_text operations.
different texts attached.
Connectivity checking
may produce incorrect
results.
3DSTACK_WARNING_106 The check statement will The check command is
not be supported in the deprecated. You are most likely
next version of the using an old 3DSTACK rule file
3DSTACK rule file. in a newer version of Calibre
Please use tvf_block. 3DSTACK. Replace all check
statements with corresponding
tvf_block commands.
3DSTACK_WARNING_107 source_filter The source_filter command can
statement(s) can be only be used if your source_netlist
applied only for source file is formatted in SPICE and the
netlist files of flat SPICE -hier option is not used in the
format. Ignoring all source_netlist command.
occurrences for
source_filter statement.
3DSTACK_WARNING_108 No matching renaming Your rename_text commands may
rules are found for contain errors.
placements or chips.
Text renaming is not
applied.

Warning Messages

3DSTACK_WARNING_109 No source_netlist You may have invoked
statement is defined in Calibre 3DSTACK with the -cs
rule file. Nothing to do. option, but did not specify a
source_netlist to verify. See
“Calibre 3DSTACK Invocation”
on page 23 and “Specify Inputs”
on page 58 for more details on the
-cs option and how to specify a
netlist file.
3DSTACK_WARNING_110 Unable to find chip The source_netlist file does not
chip_name in the source contain a chip specified in the
netlist. Filtering for the source_filter command.
specified chip will not be
applied.
3DSTACK_WARNING_111 The pin pin_name You may have incorrectly
specified in the specified a pin or subcircuit in the
source_filter command source_filter command.
does not exist in the
given subcircuit
subcircuit_name.
3DSTACK_WARNING_112 All nets connected to
single pin instances are
ignored.
3DSTACK_WARNING_113 Failed to set RVE Link.
Reason: text
3DSTACK_WARNING_114 -set_rve_highlight_index You have specified two
cannot be specified with conflicting Calibre RVE options.
- Remove one of the options from
set_rve_highlight_color. the check.
The latter is ignored.
3DSTACK_WARNING_115 -anchor_tag and The -anchor_tag and -display_text
-display_text options can arguments for Calibre RVE check
be used only with - text override commands can only
set_rve_link be specified with -set_rve_link.
They are not standalone
arguments.

Warning Messages

3DSTACK_WARNING_116 -precision option is only The -precision argument for the
needed for layer layout rule file command is only
derivation, otherwise - it required when specifying layer
will be ignored derivation with the -svrf argument
to the layer command and if the
precision differs from the default
of 1000. When layer derivation is
not used, precision handling is
performed automatically and the
-precision argument is not used.
3DSTACK_WARNING_117 The -overlapping flag of You must specify two placements
the centers command can in the centers command when
be applied only when using the -overlapping option.
-placement2 is specified.
3DSTACK_WARNING_119 Hierarchical The -hier option can only be used
source_netlist/ in the source_netlist and
export_connectivity is export_connectivity commands if
allowed for SPICE the netlist format is SPICE.
format only. -hier option
is ignored.
3DSTACK_WARNING_306 Unable to find You specified a package with the
<package-name> with -pkg option that does not exist in
the name <file-name> . your design. See config for the
Ignoring... extended syntax rules or
export_connectivity for
3DSTACK rules.
3DSTACK_WARNING_307 The package die You specified an interposer die
<package-name> cannot with the -pkg option. This is not
be interposer. Ignoring allowed. See config for the
-pkg for <file-name> extended syntax rules or
export_connectivity for
3DSTACK rules.
3DSTACK_WARNING_308 There should be exactly You specified a package with the
one placement of the -pkg option that has more than one
given package layout placement. There can only be one
<package-name>. package in your design. See
Ignoring -pkg for config for the extended syntax
<file-name> rules or export_connectivity for
3DSTACK rules.

Warning Messages

3DSTACK_WARNING_309 No text attachments are You specified a package with the
detected for package -pkg option that does not have text
layout <package-name>. for connectivity. See config for
Ignoring -pkg for the extended syntax rules or
<file-name> export_connectivity for
3DSTACK rules.
3DSTACK_WARNING_1306 No interacting layers are This warning is likely caused by a
detected for check mistake in your die layer or stack
check_name. Ignoring... definitions. Check that the
interacting layers are defined on
the correct surface of the die (-top
or -bottom) and check to ensure
that the die placement in the stack
is of the correct vertical
orientation (apply the -invert
keyword to flip the die vertically).
WARNING There are multiple Overlapping text warnings are
text-labels overlapping generated even if both of the text
with the pads on layer labels contain identical strings.
layer. "connected" check Calibre 3DSTACK does not
may produce incorrect distinguish between multiple
results! overlapping labels.

Warning Messages

Appendix E
Report File Format
The Calibre 3DSTACK report file is generated using the report command.
The sections of the report appear in the order that they are generated.
Report Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Summary of Drawn Layers, Placements, and Text Layers . . . . . . . . . . . . . . . . . . . . . . . 361
Verification Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Report Header
The report begins with a summary of the input, output, user, and design information.
##################################################
## C A L I B R E S Y S T E M ##
## 3 D S T A C K R E P O R T ##
##################################################
## # # ~ ~ ##
## # # x x ##
## # @ ##
## # # ___ ##
## # # / \ ##
##################################################
REPORT FILE NAME: /home/userDir/3dstack_report.rpt
MAXIMUM RESULTS: 50
LAYOUT CHIP NAME: controller - ./designs/controller.gds ('controller')
LAYOUT CHIP NAME: myram - ./designs/fullchip_clean_myram.gds ('myram')
LAYOUT CHIP NAME: interposer - ./designs/interposer.gds ('interposer')
SOURCE NETLIST: /home/userDir/designs/system_netlist.spi ('TOP_3D')
3DSTACK ASSEMBLY: /home/userDir/3dstack_assembly.gds.gz ('TOP_3D')
RULE FILE: /home/userDir/3dstack.rules
CREATION TIME: 07/17/13 16:28:59
CURRENT DIRECTORY: /home/userDir
USERNAME: user
CALIBRE VERSION: Calibre v2013.3_x.xxxx Tue Jul 16 13:25:32 PDT 2013
RENAMING: NO
Summary of Drawn Layers, Placements, and

Text Layers
The report summarizes the layers, placements, and text that were specified in your rule file.

Report File Format
Summary of Drawn Layers, Placements, and Text Layers
RENAMING RULES:
LAYERS:
Layer Name: INTERP_FRONT_if
Chip: interposer
Layer Number: 100
Layer Name: bmet1
Chip: interposer
Layer Number: 51
Layer Name: bmet2
Chip: interposer
Layer Number: 53
Layer Name: tsv
Chip: interposer
Layer Number: 50
Layer Name: INTERP_BACK_if
Chip: interposer
Layer Number: 200
Layer Name: CONTROLLER_if
Chip: controller
Layer Number: 100
Layer Name: via_rdl1
Chip: interposer
Layer Number: 20
Layer Name: bvia1
Chip: interposer
Layer Number: 52
Layer Name: metal_rdl1
Chip: interposer
Layer Number: 19
Layer Name: RAM_if
Chip: myram
Layer Number: 100
Layer Name: metal_rdl2
Chip: interposer
Layer Number: 21
Report of Chip and Layer Placements in the Stack

All layers and placements are written to the report. This is useful for verifying the assembly.

Report File Format
Summary of Drawn Layers, Placements, and Text Layers
ANCHOR PLACEMENT(S):
PLACEMENT(S):
Chip Placement: pCont
Layout: controller
x-origin: 0.000
y-origin: 0.000
Magnification: 1.0
Rotation: 0
Flip Axis: y
Chip Placement: pRAM_stack3
Layout: myram
x-origin: -780.000
y-origin: 520.000
Magnification: 1.0
Rotation: 180
Flip Axis: y
Layout: myram
x-origin: -740.000
y-origin: 80.000
Magnification: 1.0
Rotation: 270
Flip Axis: y
Layout: myram
x-origin: -740.000
y-origin: 80.000
Magnification: 1.0
Rotation: 270
Flip Axis: y
Layout: myram
x-origin: 280.000
y-origin: 65.000
Magnification: 1.0
Rotation: 0
Flip Axis: y
Chip Placement: pInterp
Layout: interposer
x-origin: 0.000
y-origin: 0.000
Magnification: 1.0
Rotation: 0.0
Flip Axis: NONE
Layout: myram
x-origin: 230.000
y-origin: 505.000
Magnification: 1.0
Rotation: 90
Flip Axis: y
Details on Text Layers Defined in the Stack

Each defined layer is listed separately.

Report File Format
Verification Results
TEXT LAYER(S):
Layer: pRAM_stack2_RAM_if (pRAM_stack2_RAM_if)
Layer: pCont_CONTROLLER_if (pCont_CONTROLLER_if)
Verification check results are reported under the RULECHECK SUMMARY section.
OVERALL VERIFICATION RESULTS
*************************************************************************
RULECHECK SUMMARY
*************************************************************************
Status Result Count Rule
-------------------------------------------------------------------------
COMPLETED 0 Floating_Text ( Selecting text labels from
pCont_CONTROLLER_if not having overlap with any of the pads. Selecting
text labels from pRAM_stack1_RAM_if not having overlap with any of the
pads (the same as for pRAM_stack2_RAM_if, pRAM_stack3_RAM_if,
pRAM_stack4_RAM_if). )
COMPLETED 5 No_Text ( Selecting pads from pCont_CONTROLLER_if
not having text-labels attached. Selecting pads from pRAM_stack1_RAM_if
not having text-labels attached (the same as for pRAM_stack2_RAM_if,
pRAM_stack3_RAM_if, pRAM_stack4_RAM_if). )
COMPLETED 0 Multi_Text ( Shapes from placement
pCont_CONTROLLER_if overlap multiple text labels from text placement
pCont_CONTROLLER_if. Shapes from placement pRAM_stack1_RAM_if overlap
multiple text labels from text placement pRAM_stack1_RAM_if (the same as
for pRAM_stack2_RAM_if, pRAM_stack3_RAM_if, pRAM_stack4_RAM_if). )
COMPLETED 0 ExtraPorts
Physical Verification Results

COMPLETED 1 PLACEMENT_check
( RAM should be more than 70 um from controller. )
COMPLETED 50 (of 56) offgrid1
COMPLETED 1 centers_interposer
( Pad centers must be within exactly 80 um )
Connected Check Verification Results

COMPLETED 2 CONNECT_RAM2_to_CONTROLLER
( CONNECTION CHECK between LAYER:pRAM_stack2_RAM_if and
LAYER:pCont_CONTROLLER_if )

Report File Format
Missing Placements in Source and Layout

*************************************************************************
MISSING PLACEMENTS
*************************************************************************
LAYOUT NAME SOURCE NAME
NONE
Missing Ports in the Layout

*************************************************************************
SOURCE PORTS MISSING LAYOUT PORTS
*************************************************************************
RuleCheck: CONNECT_RAM1_to_CONTROLLER ( CONNECTION CHECK between
LAYER:pRAM_stack1_RAM_if and LAYER:pCont_CONTROLLER_if )
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
NONE
Missing Ports in the Source

*************************************************************************
LAYOUT PADS MISSING SOURCE PORTS
*************************************************************************
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
NONE

Report File Format
Net Differences Between Source and Layout

*************************************************************************
INCORRECT NETS
*************************************************************************
LAYOUT NAME SOURCE NAME
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
Net 105 ADR<0>
** missing connection ** pCont:ADR<0>
Net 61 ADR<0>
** missing connection **
pRAM_stack2:ADR<0>
-------------------------------------------------------------------------
NONE
-------------------------------------------------------------------------
NONE
Connectivity Results
*************************************************************************
CONNECTIVITY RULECHECK RESULTS
*************************************************************************
-------------------------------------------------------------------------
1
Port: pCont:adr<0>
Net: 61
SourceNet: ADR<0>
LNC: pCont:adr<0>
SNC: pCont:ADR<0> pRAM_stack2:ADR<0>
2
Port: pRAM_stack2:adr<0>
Net: 105
SourceNet: ADR<0>
LNC: pRAM_stack2:adr<0>
SNC: pCont:ADR<0> pRAM_stack2:ADR<0>
-------------------------------------------------------------------------
-------------------------------------------------------------------------
-------------------------------------------------------------------------

Index
Run 3DSTACK, 35, 56

Index
— Symbols — Select Checks, 76

[], 19 Show results in RVE, 35, 72
{}, 19 Source Netlist, 67
|, 19 Text Labels table, 64
—A— Texts tab, 64
Analysis flow, 39 Top Cell, 75
Anchors, 62 Transcript, 56
Assembly operations, 74 Use Generated, 75
Write 3DSTACK Summary Report File,
—B— 35, 72
Black Box, 188 Calibre RVE
Bold words, 18 cross-referencing, 41
highlight DRC results, 39
—C— Internal Schematic Viewer, 42, 49
Calibre 3DSTACK flow, 18 LNC, 45
Calibre Interactive SNC, 45
3DSTACK Options, 74 SourceNet, 45
Anchors table, 62 CALIBRE_HOME, 18
automatically load rules file, 55 Chip stack rule file, 14, 16
Create Only, 75
Commands
Create&Use, 74 anchor, 107
Customization button, 78
attach_text, 109
Customization file, 76
centers, 138
Export Connectivity, 73 connect, 111
Export Data, 73
connected, 142
Export Template, 73 copy, 147
Ignore Pins, 69 density, 148
Invocation, 53 enclosure, 156
Layer table, 61 export_connectivity, 84
Layout tab, 59 export_template, 90
Layouts table, 60 external, 158
Load, 35, 55 ignore_pin, 113
loading a rule file, 54 import_text_labels, 116
Misc tab, 69 internal, 161, 170, 172, 174
Netlist tab, 66, 68 layer, 117
Outputs, 71, 72, 73 layout, 120
Placement tab, 62 layout_primary, 123, 124, 134
Placement table, 62 map_placement, 124
Rename Texts, 65 offgrid_centers, 166

overlap, 168 MGC_HOME, 18
place_chip, 126 Micro bumps, 14
place_layer, 129 Minimum keyword, 19
rename_text, 132
report, 95 —N—
run, 97 Notifications, 27
select_checks, 170, 172, 214 —P—
set_version, 99 Parentheses, 19
source_filter, 100 Pipes, 19
source_netlist, 102 Placement, 62
trace_text, 134
tvf_block, 174 —Q—
unselect_checks, 172 Quotation marks, 19
Connectivity files, 73
Courier font, 19 —R—
Requirements, 18
—D— Rule file, 27, 55
Double pipes, 19
—S—
—E— Slanted words, 18
Error messages, 347 SNC, 45, 142
Source net, 45
—H— Source netlist, 68
Heavy font, 18 Square parentheses, 19
—I— System Netlist Generator workflow, 225
Inputs and outputs, 16 System Netlister Configuration File, 251
Invocation, 23 CONNECTIVITY, 253
-3dstack, 24 EXPORTS, 255
Calibre Interactive, 25 PLACEMENTS, 252
-compile_only, 25 —T—
-create_assembly, 24 Text, 64
-cs, 24 Transcript output, 56
-help, 24 TSVs, 13
rule_file_name, 24
-run_dir, 24 —U—
-system, 24 Underlined words, 19
-turbo, 24
-use_assembly, 24 —V—
Verification
Italic font, 18
command line, 32, 33
—L— examples, 31
License requirements, 18
LNC, 142 —W—
White Box, 188
—M— Workflow, 18
MGC format, 85, 88, 102

Third-Party Information
For third-party information, refer to Third-Party Software for Calibre Products.

End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula
IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (“Agreement”)
This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties’ entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT.
1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any
additional or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order
management system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and
physically signed by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month
or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes
or other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a
valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all
applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all
payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by
Customer hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or
make payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event
of default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision
of both a primary and an alternate e-mail address.
2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation, setup files and design data (“Software”) are copyrighted, trade secret and
confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not
expressly granted by this Agreement. Except for Software that is embeddable (“Embedded Software”), which is licensed pursuant to
separate embedded software terms or an embedded software supplement, Mentor Graphics grants to Customer, subject to payment of
applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form
(except as provided in Subsection 4.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer
may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as
the employee’s residence, an airport or hotel, provided that such employee’s primary place of employment is the site where the
Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid
or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to
execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be
technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including
eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer provides any
feedback or requests any change or enhancement to Products, whether in the course of receiving support or consulting services,
evaluating Products, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made
by Mentor Graphics (at Mentor Graphics’ sole discretion) will be the exclusive property of Mentor Graphics.
3. BETA CODE.
3.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to
test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.
3.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
3.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 3.3 shall survive termination of this Agreement.
4. RESTRICTIONS ON USE.
4.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices
and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall
remain the property of Mentor Graphics or its licensors. Except for Embedded Software that has been embedded in executable
code form in Customer’s product(s), Customer shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Customer acknowledges that Software provided hereunder may contain source code which is proprietary and
its confidentiality is of the highest importance and value to Mentor Graphics. Customer acknowledges that Mentor Graphics
may be seriously harmed if such source code is disclosed in violation of this Agreement. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
disassemble, reverse-compile, or reverse-engineer any Product, or in any way derive any source code from Software that is not
provided to Customer in source code form. Log files, data files, rule files and script files generated by or for the Software
(collectively “Files”), including without limitation files containing Standard Verification Rule Format (“SVRF”) and Tcl
Verification Format (“TVF”) which are Mentor Graphics’ trade secret and proprietary syntaxes for expressing process rules,
constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding
Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as
Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer
may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use
Products or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way
competitive with Products, or disclose to any third party the results of, or information pertaining to, any benchmark.
4.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use, or as permitted for Embedded Software under separate
embedded software terms or an embedded software supplement. Customer shall not disclose or permit disclosure of source
code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or on-site
contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in
any manner except to support this authorized use.
4.3. Customer agrees that it will not subject any Product to any open source software (“OSS”) license that conflicts with this
Agreement or that does not otherwise apply to such Product.
4.4. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written consent and
payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in
interest and assigns.
4.5. The provisions of this Section 4 shall survive the termination of this Agreement.
5. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics’ then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.
6. OPEN SOURCE SOFTWARE. Products may contain OSS or code distributed under a proprietary third party license agreement, to
which additional rights or obligations (“Third Party Terms”) may apply. Please see the applicable Product documentation (including
license files, header files, read-me files or source code) for details. In the event of conflict between the terms of this Agreement
(including any addenda) and the Third Party Terms, the Third Party Terms will control solely with respect to the OSS or third party
code. The provisions of this Section 6 shall survive the termination of this Agreement.
7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed,
will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not
warrant that Products will meet Customer’s requirements or that operation of Products will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must
notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty
applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a)
Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty
shall not be valid if Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in
compliance with this Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE
REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON
RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE
PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF
WHICH ARE PROVIDED “AS IS.”
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.
8. LIMITATION OF LIABILITY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS
AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS
LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8
SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
9. THIRD PARTY CLAIMS.
9.1. Customer acknowledges that Mentor Graphics has no control over the testing of Customer’s products, or the specific
applications and use of Products. Mentor Graphics and its licensors shall not be liable for any claim or demand made against
Customer by any third party, except to the extent such claim is covered under Section 10.
9.2. In the event that a third party makes a claim against Mentor Graphics arising out of the use of Customer’s products, Mentor
Graphics will give Customer prompt notice of such claim. At Customer’s option and expense, Customer may take sole control
of the defense and any settlement of such claim. Customer WILL reimburse and hold harmless Mentor Graphics for any
LIABILITY, damages, settlement amounts, costs and expenses, including reasonable attorney’s fees, incurred by or awarded
against Mentor Graphics or its licensors in connection with such claims.
9.3. The provisions of this Section 9 shall survive any expiration or termination of this Agreement.
10. INFRINGEMENT.
10.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired
by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics
will pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and
agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics
promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the
action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.
10.2. If a claim is made under Subsection 10.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
10.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of
other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that
Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; (h) OSS, except to the extent that
the infringement is directly caused by Mentor Graphics’ modifications to such OSS; or (i) infringement by Customer that is
deemed willful. In the case of (i), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.
10.4. THIS SECTION 10 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
11. TERMINATION AND EFFECT OF TERMINATION.
11.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon
written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement
or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped or licenses granted prior to
the termination, which amounts shall be payable immediately upon the date of termination.
11.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination of this Agreement and/or any license granted under this Agreement, Customer shall ensure that
all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in
Customer’s possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business
days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form.
12. EXPORT. The Products provided hereunder are subject to regulation by local laws and European Union (“E.U.”) and United States
(“U.S.”) government agencies, which prohibit export, re-export or diversion of certain products, information about the products, and
direct or indirect products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products
in any manner without first obtaining all necessary approval from appropriate local, E.U. and U.S. government agencies. If Customer
wishes to disclose any information to Mentor Graphics that is subject to any E.U., U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export Administration
Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure, that such information
is subject to such export restrictions.
13. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.
14. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.
15. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 15 shall survive the termination of this Agreement.
16. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America or Japan, and the laws of Japan if Customer is located in Japan. All disputes arising out of or in relation to this
Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin,
Ireland when the laws of Ireland apply, or the Tokyo District Court when the laws of Japan apply. Notwithstanding the foregoing, all
disputes in Asia (excluding Japan) arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a
single arbitrator to be appointed by the chairman of the Singapore International Arbitration Centre (“SIAC”) to be conducted in the
English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be
incorporated by reference in this section. Nothing in this section shall restrict Mentor Graphics’ right to bring an action (including for
example a motion for injunctive relief) against Customer in the jurisdiction where Customer’s place of business is located. The United
Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.
17. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.
18. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Any translation of this Agreement is provided to comply with local legal requirements only. In the
event of a dispute between the English and any non-English versions, the English version of this Agreement shall govern to the extent
not prohibited by local law in the applicable jurisdiction. This Agreement may only be modified in writing, signed by an authorized
representative of each party. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver
or excuse.
Rev. 151102, Part No. 265968

Calbr 3dstack User

Uploaded by

Copyright:

Available Formats

Calbr 3dstack User

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Calbr 3dstack User

Uploaded by

Copyright:

Available Formats

Calibre® 3DSTACK User's Manual

Software Version 2016.2

© 2012-2016 Mentor Graphics Corporation

Mentor Graphics Corporation

Send Feedback on Documentation: supportnet.mentor.com/doc_feedback_form

Calibre® 3DSTACK User's Manual, v2016.2 3

Writing a Calibre Interactive Customization File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4 Calibre® 3DSTACK User's Manual, v2016.2

Calibre® 3DSTACK User's Manual, v2016.2 5

6 Calibre® 3DSTACK User's Manual, v2016.2

Calibre® 3DSTACK User's Manual, v2016.2 7

8 Calibre® 3DSTACK User's Manual, v2016.2

Figure 1-1. TSV-based 3D-IC Cross-section (Conceptual Illustration) . . . . . . . . . . . . . . . . 14

Calibre® 3DSTACK User's Manual, v2016.2 9

10 Calibre® 3DSTACK User's Manual, v2016.2

Table 1-1. Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Calibre® 3DSTACK User's Manual, v2016.2 11

12 Calibre® 3DSTACK User's Manual, v2016.2

You shall not use this 3DIC_DL except:

Calibre® 3DSTACK User's Manual, v2016.2 13

Figure 1-1. TSV-based 3D-IC Cross-section (Conceptual Illustration)

Calibre 3DSTACK operates on these configurations by supplementing your existing Calibre

14 Calibre® 3DSTACK User's Manual, v2016.2

Figure 1-2. 3DSTACK Assembly (Conceptual Illustration)

Calibre® 3DSTACK User's Manual, v2016.2 15

Figure 1-3. Inputs and Outputs

16 Calibre® 3DSTACK User's Manual, v2016.2

Figure 1-4. Calibre 3DSTACK Flow

Calibre® 3DSTACK User's Manual, v2016.2 17

• Calibre nmDRC-H and Calibre nmDRC.

The following inputs must be defined:

Table 1-1. Syntax Conventions

18 Calibre® 3DSTACK User's Manual, v2016.2

Table 1-1. Syntax Conventions (cont.)

Calibre® 3DSTACK User's Manual, v2016.2 19

20 Calibre® 3DSTACK User's Manual, v2016.2

Calibre 3DSTACK Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Calibre® 3DSTACK User's Manual, v2016.2 21

22 Calibre® 3DSTACK User's Manual, v2016.2

Calibre 3DSTACK Invocation

Calibre® 3DSTACK User's Manual, v2016.2 23

24 Calibre® 3DSTACK User's Manual, v2016.2

calibre -3dstack rules.3dstack

calibre -gui -3dstack [-runset runset] [gui_options]

calibre -gui -3dstack -runset runset [gui_options] -batch

calibre -3dstack -compile_only extended_rules.3dstack

Calibre® 3DSTACK User's Manual, v2016.2 25

Calibre 3DSTACK Output

• 3dstack.log — the complete transcript from a run.

26 Calibre® 3DSTACK User's Manual, v2016.2

Run Time Status Notifications

• Chips currently being processed.

Calibre 3DSTACK Rule File

Calibre® 3DSTACK User's Manual, v2016.2 27

o Use the source_netlist command.

28 Calibre® 3DSTACK User's Manual, v2016.2

Calibre® 3DSTACK User's Manual, v2016.2 29

The following is an example for 3DSTACK+:

die -die_name interposer \

die -die_name ram \