Calbr 3dstack User
Calbr 3dstack User
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.
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
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
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
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
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
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
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.
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
(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.
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
interposer is rotated clockwise by 90 degrees. Figure 1-2 summarizes the necessary inputs and
outputs to a 3DSTACK assembly operation.
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.
The following figure illustrates the typical workflow for verifying a design with Calibre
3DSTACK.
Related Topics
Requirements
Calibre 3DSTACK Invocation
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:
• 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
Calibre 3DSTACK Invocation
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.
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.
Assembly Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Calibre 3DSTACK Verification Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Calibre 3DSTACK Results Analysis Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
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.
• -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:
Invoke Calibre Interactive for Calibre 3DSTACK with the following command:
Invoke Calibre Interactive batch mode for Calibre 3DSTACK with the following command:
Generate a compiled version of a 3DSTACK+ rule file in your working directory without
performing any other operations.
Related Topics
System Netlist Generator Flow and Invocation
Invoking Calibre Interactive for Calibre 3DSTACK
Output Files
The following output files are created in your working directory during a run:
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.
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
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
CALIBRE_3DSTACK_DEFAULT_THICKNESS environment variable to set a global
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.
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
Calibre 3DSTACK Invocation
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 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 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).
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
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
Calibre 3DSTACK Invocation
Calibre 3DSTACK Results Analysis Examples
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.
3. 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.
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
Calibre 3DSTACK Invocation
Calibre 3DSTACK Results Analysis Examples
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
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 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.
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
Calibre 3DSTACK Invocation
Calibre 3DSTACK Verification Examples
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).
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 …
Related Topics
Highlighting DRC Results from a Calibre 3DSTACK Run
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.
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
Calibre 3DSTACK Invocation
Calibre 3DSTACK Verification Examples
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
Calibre 3DSTACK Invocation
Calibre 3DSTACK Verification Examples
• 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.
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.
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
Running Calibre 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
Calibre 3DSTACK Results Analysis Examples
Specify Outputs
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.
• You have completed the procedure “Invoking Calibre Interactive for Calibre
3DSTACK” on page 53.
• You have completed the procedure “Specifying and Loading a Rule File” on page 54.
• You have layout files in GDS or OASIS format that compose the 3D assembly.
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
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
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
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 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.
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 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).
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
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
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
3DSTACK” on page 44.
If your source netlist was clean, the report contains the following text:
*************************************************************************
OVERALL SYNTAX CHECK RESULTS
*************************************************************************
####################
# #
# SYNTAX OK #
# #
####################
# # #########################
# # # #
# # SYNTAX CHECK FAILED #
# # # #
# # #########################
Related Topics
Specify Inputs
Command Reference
Specify Outputs
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
1. Click on the Inputs button in the left panel of the CI window, if it is not already
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
The outputs pane of Calibre Interactive allows you to specify the files and paths for the
verification output.
• You have completed the procedure “Specifying and Loading a Rule File” on page 54.
• (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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Exporting Connectivity and Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
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
Specify Outputs
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.
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
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.
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
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 \
-master [list $_customMaster_0 1]
CUSTOM::CHECK -name "internal" -choices {internal} -initval {internal} \
-select 1 -boolean 1 -prompt "internal" -display 1 -tool 3DSTACK \
-master [list $_customMaster_0 1]
CUSTOM::CHECK -name "external" -choices {external} -initval {external} \
-select 0 -boolean 1 -prompt "external" -display 1 -tool 3DSTACK \
-master [list $_customMaster_0 1]
CUSTOM::CHECK -name "enclosure" -choices {enclosure} -initval {enclosure}\
-select 0 -boolean 1 -prompt "enclosure" -display 1 -tool 3DSTACK \
-master [list $_customMaster_0 1]
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
To access the Trigger options in Calibre Interactive 3DSTACK, select Setup > Preferences and
click on the Triggers tab. The following trigger parameters are available.
Related Topics
Specify Inputs
Command Reference
Specify Outputs
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.
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
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:
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.
The chip stack rule file for this example is shown as follows:
#define layouts
layout -chip_name c1 -primary TOPCELL -path ./chip1.gds -system GDS
layout -chip_name c2 -primary TOPCELL -path ./chip2.gds -system GDS
#define connectivity
connect c1p_m1 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
Xc2p 4 3 2 1 TOPCELL
.ENDS TOPCELL_3DIC
• VERILOG
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}
add_connection -connection1 {c1p TOPCELL net2 net2} -connection2\
{c2p TOPCELL net2 net2}
add_connection -connection1 {c1p TOPCELL net3 net3} -connection2\
{c2p TOPCELL net3 net3}
add_connection -connection1 {c1p TOPCELL net4 net4} -connection2\
{c2p TOPCELL net4 net4}
Example 2
This example demonstrates the export_connectivity -hier option. Assume you have the
following chips in your assembly:
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:
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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.
• -system {GDS | OASIS}
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
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.
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.
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.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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:
where:
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:
Examples
Use the following command to generate a report file with no reported result limitations.
Use this command to limit the reported results for each rule check to a maximum of 30.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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”
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
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
set_version -version 1.0
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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.
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.
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.
Example 3
Different constraint expression examples. See the -constraint argument for a description of the
required format.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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.
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.
The chip stack rule file for this example is shown as follows:
Assume that the spice.spi file contains the results of the export_connectivity command with the
SPICE option specified:
.SUBCKT TOPCELL_3DIC
Xc1p 4 3 2 1 TOPCELL
Xc2p 4 3 2 1 TOPCELL
.ENDS TOPCELL_3DIC
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:
.SUBCKT TOPCELL_3DIC
Xc1p 4 9 2 1 TOPCELL
Xc2p 4 3 2 1 TOPCELL
.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.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
System Netlist Generator Flow and Invocation
Assembly Commands
Commands that specify assembly operations for the chip stack.
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.
where anchor a1 is relative to the origin of chip C1, and anchor a2 is relative to the origin of
chip C2.
Examples
anchor -name interposer_mem -chip interposer -x_origin 30.0 \
-y_origin 14.0
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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).
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.
Examples
Example 1
attach_text -placement m_mtsv -text_placement m_mtxt
attach_text -placement l_ltsv -text_placement l_ltxt
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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:
placement_name'_'layer
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.
Examples
connect c1p_m1 c1p_m2 BY c1p_v1
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
ignore_pin
Excludes specified pins from a Calibre 3DSTACK run.
Usage
ignore_pin -placement placement_name -pin ‘{’expression‘}’
Arguments
• -placement placement_name
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.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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:
ignore_trailing_chars ":.,"
The following nets are extracted during connectivity analysis as a result of the command:
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
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
• -layer layer_name
Required argument and value set that specifies the name of the layer.
• -chip chip_name
Required argument and value set that specifies the chip name being referenced (chip names
are defined using the layout command).
• -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.
• -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.
Example 3
This example uses the -svrf argument to supply a layer derivation.
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:
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
• -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.
• -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.
• -system {GDS | OASIS}
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.
• -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
CALIBRE_3DSTACK_DEFAULT_THICKNESS environment variable to set a global
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.
Examples
Example
Import three chips into the assembly.
Example
Import the controller.gds layout into the assembly, but do not include the PLL and cap_array
cells.
Example
Declare a chip as an interposer and export a hierarchical SPICE netlist of the assembly.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
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.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
• -placement placement_name
Required argument and value set that specifies a unique placement name that can be
referenced with other commands in the following format:
placement_name'_'layer
• -chip chip_name
Required argument and value set that specifies the chip name being referenced (chip names
are defined using the layout command).
• -x_origin x_offset
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
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.
• -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
• -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.
placement_name'_'layer
Examples
place_chip -placement place_base_bottom_interface_shapes -flip x \
-chip chip1 -x_origin 0 -y_origin 0
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
• -placement placement_name
Required argument and value set that specifies a unique placement name that can be
referenced with other commands.
• -layer layer_name
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.
• -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. This argument set only applies to -layer.
• -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.This argument set only applies to -layer.
placement_name'_'layer
Examples
Example
Use the -layer argument to place the bottom interface layer at the origin and flip it over the x-
axis.
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.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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.
• -placement placed_layer
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.
If the placed_layer value references a placement that is defined using place_chip, the value
must be specified in the following format:
chip_placement_name'_'layer
If the value references a placement defined using place_layer, the placement name is specified
directly.
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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:
TRACE TEXT:
FROM: TO:
------------------------------------
die1_M7 die1_RDL1
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.
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:
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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.
• -placement2 placed_layer2
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.
• -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.
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.
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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]
[-comment “comment”] [rve_option …]
Arguments
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
out results. If this command 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 placed layer. The layer
must be defined in the Calibre 3DSTACK rule file and cannot be a derived layer.
• -placement2 placed_layer2
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.
• 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.
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:
placement_name'_'layer
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.
• 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
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:
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
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.
Example 2
This example compares the connectivity information extracted from the chip stack to the
connectivity information defined in the input.spi file.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
copy
Exports specified layer contents.
Usage
copy -check_name check_name -placement placement_name [-comment “comment”]
Arguments
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
output results. If copy is specified multiple times, each check_name must be unique.
• -placement placement_name
Required argument and value set that specifies the name of the placement.
• -comment “comment”
Optional argument and value set that specifies a rule check comment. You can specify
multi-line comments using the “\n” escape sequence.
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
Required argument and value set that specifies a check name, which is used when writing
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 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.
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
Optional keyword that specifies if a window overlaps the right-hand or top edges of
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
Optional keyword that specifies if a window overlaps the right-hand or top edges of
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
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.
For further details, refer to the Density command described in the Standard Verification
Rule Format (SVRF) Manual.
• -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.
For further details, refer to the Density command described in the Standard Verification
Rule Format (SVRF) Manual.
• -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
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.
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"
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
out results. If this command is specified multiple times, each check_name must be unique.
• -placement1 placement1
Required argument and value set that specifies the name of the first layer, which must be a
polygon layer or chip placement. The placement1 value must be of the same type as the
placement2 value.
• -placement2 placement2
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.
• -constraint “constraint_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
Verification Rule Format (SVRF) Manual.
• -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 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
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.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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]
-constraint “constraint_value” [-comment “comment”] [rve_option …]
Arguments
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
out results. If this command is specified multiple times, each check_name must be unique.
• -placement1 placement1
Required argument and value set that specifies the name of the first layer, which must be a
polygon layer or chip placement. The placement1 value must be of the same type as the
placement2 value.
• -placement2 placement2
Optional 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.
• -constraint “constraint_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.
• -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
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.
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
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
Check spacing between two placed layers:
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:
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.
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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]
-constraint “constraint_value” [-comment “comment”] [rve_option …]
Arguments
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
out results. If this command is specified multiple times, each check_name must be unique.
• -placement1 placement1
Required argument and value set that specifies the name of the first layer, which must be a
polygon layer or chip placement. The placement1 value must be of the same type as the
placement2 value.
• -placement2 placement2
Optional 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.
• -constraint “constraint_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
Verification Rule Format (SVRF) Manual.
• -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
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.
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
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.
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
• -check_name check_name
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
Required argument and value set that specifies the name of a placed layer.
• -placement2 placement_layer2
Required argument and value set that specifies the name of a placed layer.
• -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.
• 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
• -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.
• -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 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:
Examples
set_version -version 1.0
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 }
[-comment “comment”] [rve_option …]
Arguments
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
out results. If this command is specified multiple times, each check_name must be unique.
• -placement placed_layer
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.
• -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 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.
Example 2
Check that pads are aligned to a 5 um by 10 um (x by y) grid.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
• -check_name check_name
Required argument and value set that specifies a check name, which is used when writing
out results. If this command 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 polygon layer.
• -placement2 {placed_layer2 [placed_layer2 …]}
Required argument and value set that specifies the name of one or more secondary polygon
layers.
• -constraint “constraint_value”
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.
• -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 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.
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.
Example 2
Measure the overlap by area.
Example 3
Check that all of the interposer pads have suitable overlap with all of the pads of the chips
placed on the interposer.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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.
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.
Examples
Example 1
Specify a single check to run:
Example 2
Specify multiple checks to run using either of the following methods:
or
Example 3
Execute only the checks that are used in the interposer and any of the ram placements:
Example 4
Execute internal and external checks only.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
• -check_names ‘{’check_name_pattern [check_name_pattern …]‘}’
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.
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.
Examples
Example 1
Unselect a single check:
Example 2
Unselect multiple checks using either of the following methods:
or
Example 3
Exclude checks that are used in the interposer and ram placements:
Example 4
Exclude internal and external check types from the verification run.
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
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.
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:
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.
Example
Multiple check comment options may also be specified as follows:
Example
To assign priorities to text-related checks, include a CTO in your 3DSTACK rule file as
follows:
my_connected_check_1
RVE Priority: 1
No_Text
RVE Priority: 2
Floating_Text
RVE Priority: 2
Multi_text
RVE Priority: 2
Related Topics
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE 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.
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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
System and Miscellaneous Commands
Assembly Commands
Rule Check Commands
Calibre RVE Commands
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.
• 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
Examples
#!3dstack+
#===========================================#
# Calibre 3DSTACK+ Rule File
# ==========================================#
set_version -version 1.0
<die commands>
…
<stack commands>
…
<verification commands>
…
• 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).
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.
• 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:
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
<check-name>_<check-index>
where:
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.
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
• 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).
The following check performs white box checking. It checks the physical connection of the pad
layers through the interposer.
Related Topics
Calibre 3DSTACK+ Extended Syntax File Format
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
• _layer_types
• _layer_type1
• _layer_type2
The following examples demonstrate how to apply the variables in your rule file:
die . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
custom_check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
select_checks (Extended Syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
unselect_checks (Extended Syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
3dstack_block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
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}
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
CALIBRE_3DSTACK_DEFAULT_THICKNESS environment variable to set a global
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.
• -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.
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.
• -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.
• -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:
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.
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_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:
• 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/”.
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.
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.
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
Calibre 3DSTACK+ Extended Syntax File Format
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.
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.
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,
where the value is a distance in microns. This option enables the generation of a cross-
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-name>_tier<tier-index>_<die-name><placement-id>
where:
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 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.
o MEM die placement at position (0, 500, 200) calculated by anchor definition.
o MEM die placement at position (0, 1500, 200) calculated by anchor definition.
• MEM die placement at position (100, 100, 300).
Related Topics
Calibre 3DSTACK+ Extended Syntax File Format
die
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
• -check_name check_name
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 …]).
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.
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:
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.
• 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.
• 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.
Example 2
A custom check that checks the ratio of the die area to package area.
Related Topics
Calibre 3DSTACK+ Extended Syntax File Format
Rule Check and Analysis Commands for the Calibre 3DSTACK+ Extended Syntax
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.
• -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.
• -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.
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:
Related Topics
Calibre 3DSTACK+ Extended Syntax File Format
3dstack_block
Examples
Example 1
Specify a single check to run:
Example 2
Specify a single layer type to run (this can result in multiple rule check selection):
Example 3
Specify multiple layer types to run:
or
Example 4
Specify single stack to run (this can result in multiple rule check selection).
Related Topics
Calibre 3DSTACK+ Extended Syntax File Format
Rule Check and Analysis Commands for the Calibre 3DSTACK+ Extended Syntax
unselect_checks (Extended Syntax)
Examples
Example 1
Specify a single check to exclude:
Example 2
Specify a single layer type to exclude (this can result in multiple rule check selection):
Example 3
Specify multiple layer types to exclude:
or
Example 4
Specify single stack to exclude (this can result in multiple rule check selection).
Related Topics
Calibre 3DSTACK+ Extended Syntax File Format
Rule Check and Analysis Commands for the Calibre 3DSTACK+ Extended Syntax
select_checks (Extended Syntax)
3dstack_block
Used in the 3DSTACK+ extended syntax file.
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.
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.
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}
map_placement -placement Memory_1 -source memory_block_1
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_auto_rve_show_layers YES
set_rve_cto_file -file ./custom_rve_settings.cto
}
Related Topics
config
Calibre 3DSTACK+ Extended Syntax File Format
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
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
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
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.
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.
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
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
• 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
.SUBCKT base 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
.SUBCKT stack 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
PLACEMENTS {
# placementName chipName fileFormat filePath topCell analysingMode
pbase base SPICE base.spi base
pstack stack SPICE stack.spi stack
}
.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
.SUBCKT stack sclk_1 sclk_2 sgnd sin_1 sin_2 sout_1 sout_2 svdd
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
.SUBCKT base bclk_1 bclk_2 bgnd bin_1 bin_2 bout_1 bout_2 bvdd
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.”
The SPICE netlists for the memory and controller are defined in Table 6-1.
The desired net connectivity of the chips on the interposer design is defined in Table 6-2.
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:
Examples
The following statements achieve the same steps using the Tcl console prompt:
Related Topics
System Netlist Generator Example
Workflow
sng::import_chip
sng::remove_chip
3. For the reset pin in this example, change the type to INPUT.
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.
Related Topics
System Netlist Generator Example
Workflow
sng::add_pin
sng::remove_pin
sng::set_property
sng::get_property
Prerequisites
• You have imported at least one chip definition as described under “Importing Chips into
the Database” on page 232.
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.
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
System Netlist Generator Example
Workflow
sng::create_placement
sng::remove_placement
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]
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
System Netlist Generator Example
Workflow
sng::get_ports
sng::incr
sng::connect
sng::unconnect
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:
The following SPICE netlist is the completed assembly netlist for this design:
.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[1] write_data2[2] write_data2[3] write_data2[4]
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[1] write_data1[2] write_data1[3] write_data1[4]
write_data1[5]
+ write_data1[6] write_data1[7] read_data1[0] read_data1[1] read_data1[2]
+ read_data1[3] read_data1[4] read_data1[5] read_data1[6] read_data1[7]
myram
XpRam2 mode enable_2 address[0] address[1] address[2] write_data2[0]
+ write_data2[1] write_data2[2] write_data2[3] write_data2[4]
write_data2[5]
+ write_data2[6] write_data2[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]
myram
.ENDS TOP_CELL
Related Topics
System Netlist Generator Example
Workflow
sng::export_netlist
source_netlist
Specifying a Source Netlist
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-5. Shift-Select and Paste Into Multiple 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
System Netlist Generator Main Window.
Figure 6-7. Main Window
Objects
Usage Notes
Enter the following command to invoke the System Netlist Generator main window:
sng -gui
Properties Panel
Properties button
Shows detailed properties about objects in the design tree.
Figure 6-8. Properties Panel
Objects
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.
Related Topics
Main Window
Objects
Related Topics
sng::connect
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.
PLACEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
CONNECTIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
EXPORTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
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
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}
}
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 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
Tip
All commands support the -help option. Use the -help option in the System Netlist
Generator shell to report the usage for each command.
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
sng::create_journal_file
Arguments
None.
Examples
sng::create_journal_file
Related Topics
System Netlist Generator Commands
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
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
Required argument that specifies the database 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
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
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:
Related Topics
sng::save_db
sng::remove_chip
sng::save_db
Saves the current state of the project.
Usage
sng::save_db db_instance -path file_path [-compact]
Arguments
• db_instance
Required argument that specifies the database 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
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 filtered to equal only those pins that include the bus name adr<>
set filtered [ sng::filter $pins -expression "$propName == \"adr<>\""]
Example
This example demonstrates how to achieve the same result as the first example using a different
method.
Related Topics
sng::unconnect
sng::incr
sng::get_begin
Moves the specified iterator to the first element of the container.
Usage
sng::get_begin iterator
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.
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 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
Returns an iterator for all buses defined in the specified chip.
Usage
sng::get_buses db_instance -chip_name name
Arguments
• db_instance
Required argument that specifies the database 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.
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
Returns an iterator for all chips defined in the current project.
Usage
sng::get_chips db_instance
Arguments
• db_instance
Required argument that specifies the database instance.
Examples
This example retrieves the names of all chips in the database.
Related Topics
sng::incr
sng::get_pins
sng::get_nets
sng::get_placements
sng::get_ports
sng::get_property
sng::get_property_names
sng::get_buses
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
Required argument that specifies the database instance.
Examples
This example retrieves the names of all nets in the database.
Related Topics
sng::incr
sng::get_chips
sng::get_pins
sng::get_placements
sng::get_ports
sng::get_property
sng::get_property_names
sng::get_buses
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
Required argument that specifies the database 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.
Related Topics
sng::get_buses
sng::get_chips
sng::get_nets
sng::get_placements
sng::get_ports
sng::get_property
sng::get_property_names
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
Required argument that specifies the database 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.
Related Topics
sng::get_pins
sng::get_chips
sng::get_nets
sng::get_property_names
sng::get_ports
sng::get_property
sng::get_buses
sng::create_placement
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
Required argument that specifies the database instance.
• -placement_name placement_name
Required keyword and name of a placement 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 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.
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”.
Related Topics
sng::incr
sng::get_chips
sng::get_nets
sng::get_placements
sng::get_property_names
sng::get_property
sng::get_pins
sng::get_buses
sng::get_property
Returns a list of property values for the specified iterator.
Usage
sng::get_property iterator [-property property_name]
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::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_property_names
sng::get_pins
sng::get_property_names
Returns a list of property names.
Usage
sng::get_property_names iterator
Arguments
• iterator
Required argument that specifies an iterator returned by one of the following commands:
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:
Examples
Get a list of ports from the mem_die_placement placement.
Related Topics
sng::incr
sng::get_chips
sng::get_nets
sng::get_placements
sng::incr
Increments the specified iterator.
Usage
sng::incr iterator [step]
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.
• 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.
sng::set_property
Changes the value of specified properties.
Usage
sng::set_property iterator -property property_name -value property_value
Arguments
• iterator
Required argument that specifies an iterator returned by one of the following commands:
sng::get_nets, sng::get_buses, sng::get_placements, and sng::get_pins.
• -property property_name
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.
Related Topics
sng::get_property_names
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 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.
• -property property_name
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.
Related Topics
sng::get_property
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.
• -chip_name chip_name
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.
• -bus_name bus_name
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.
Related Topics
sng::remove_pin
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
Required argument that specifies the database instance.
• -net_name net_name
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.
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.
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.
Related Topics
sng::unconnect
sng::incr
sng::set_net_name_template
sng::create_chip
Creates a new chip.
Usage
sng::create_chip db_instance -chip_name name [-cell_name cell_name]
Arguments
• db_instance
Required argument that specifies the database 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
sng::create_placement
Creates a new placement.
Usage
sng::create_placement db_instance -chip_name chip_name
-placement_name placement_name
Arguments
• db_instance
Required argument that specifies the database instance.
• -chip_name chip_name
Required keyword and name of an existing chip in the project.
• -placement_name placement_name
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
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
Required argument that specifies the database 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+)_.* }
#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
sng::import_chip my_db –chip_name memory –type SPICE –path ./mem.spi \
–cell_name mem_die –bus_detection YES –bus_pattern {(\D+)_(\d+)_(. *)}
#do not use smart detection
sng::import_chip my_db –chip_name memory –type SPICE –path ./mem.spi \
–cell_name mem_die –bus_detection NO
Related Topics
sng::create_chip
sng::remove_chip
Removes the selected chip definition.
Usage
sng::remove_chip db_instance -chip_name chip_name
Arguments
• db_instance
Required argument that specifies the database 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_placement
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
Required argument that specifies the database 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.
Related Topics
sng::remove_chip
sng::remove_placement
sng::remove_placement
Removes a placement from the project.
Usage
sng::remove_placement db_instance -placement_name placement_name
Arguments
• db_instance
Required argument that specifies the database instance.
• -placement_name placement_name
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
sng::set_net_name_template
Sets the net name template.
Usage
sng::set_net_name_template db_instance prefix [-delimiters ‘{’ delimiter_pair ‘}’]
Arguments
• db_instance
Required argument that specifies the database 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:
Examples
sng::set_net_name_template my_db {Net_} -delimiters {\<\>}
Related Topics
sng::connect
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 argument that specifies the database instance.
• -net_name net_name
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.
Related Topics
sng::connect
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 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
• [DATABASE]
• [DIE]
• [MCM_DIE]
• [BGA]
• [PADS]
• [NETLIST]
• [RINGS]
• [BONDABLE_RING_AREA]
• [WIRE]
• [FIDUCIALS]
• [DIE_LOGO]
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:
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
Required argument and path to an AIF file. See “AIF Support” on page 296 for details on
supported AIF statements.
• -oasis oas_file
Required argument and path to the OASIS output file.
Examples
Enter the following commands from the command-line:
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
Required argument and path to an AIF file. See “AIF Support” on page 296 for details on
supported AIF statements.
• -spice spice_file
Required argument and path to the SPICE output file.
Examples
Enter the following commands from the command-line:
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.
3dstack::ss2gds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
3dstack::ss2oasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
3dstack::ss2spice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
3dstack::xpi2spice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
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
[-vertices {x1 y1 ... xn yn}]
‘}’
]...
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.
-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
calibre -ys -3dstack
3dstack::ss2oasis
Creates OASIS layouts that include pin and die boundary locations from a spreadsheet (CSV)
file.
Usage
3dstack::ss2oasis -ss ss_file
[-order column_list]
[-die_info OASIS ‘{’
-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
[-vertices {x1 y1 ... xn yn}]
‘}’
]...
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 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.
exit
3dstack::ss2spice
Converts a CSV input file to a SPICE netlist.
Usage
3dstack::ss2spice -ss ss_file
-spice spice_file
[-order column_list]
[-top_cell top_cell_name]
[-hier]
[-subckt_pins {NET_NAME | PIN_NUMBER | PIN_NAME}]
Arguments
• -ss ss_file
Required path to the spreadsheet (CSV) input file.
• -spice spice_path
Required path to the SPICE output 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.
• -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:
exit
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:
exit
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.
Video
This example is part of the Calibre 3DSTACK Tutorial video.
Related Topics
Calibre 3DSTACK Flow Example
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
Calibre 3DSTACK Flow Example
Example Design Information
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:
set_version -version 1.0
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
####################################################
set_version -version 1.0
# Begin commands
…
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
Writing Verification Checks in the Calibre 3DSTACK Rule File
set_version
Video
This procedure is part of the Calibre 3DSTACK Tutorial 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:
layout -chip_name interposer -primary interposer \
-path ./design/interposer.gds -system GDS -original_extent
layout -chip_name controller -primary controller \
-path ./design/controller.gds -system GDS -original_extent
layout -chip_name ram -primary ram
-path ./design/ram.gds -system GDS -original_extent
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
Examples
####################################################
# CALIBRE 3DSTACK RULES
# This 3DSTACK rule file assembles and verifies the
# 2.5D interposer used in this example
# 9/11/2014
####################################################
set_version -version 1.0
# Begin commands
##################
# Assembly Process
##################
###############################
# Create chips from existing GDS
###############################
layout -chip_name interposer -primary interposer \
-path ./designs/interposer.gds -system GDS -original_extent
layout -chip_name controller -primary controller \
-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
layout_primary TOP_CELL
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
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
This procedure is part of the Calibre 3DSTACK Tutorial 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.
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.
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
layer -layer RDL_M2 -chip interposer -layer_number 13
layer -layer RDL_V2 -chip interposer -layer_number 14
layer -layer RDL_M3 -chip interposer -layer_number 15
layer -layer RDL_V3 -chip interposer -layer_number 16
layer -layer RDL_M4 -chip interposer -layer_number 17
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 controller_pads -chip controller -layer_number 255
layer -layer ram_pads -chip ram -layer_number 255
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
layer
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:
Prerequisites
• Completion of “Defining Layers” on page 315.
Procedure
1. Open your 3dstack.rules rule file.
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.
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
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
…
layer -layer RDL_M3 -chip interposer -layer_number 15
layer -layer RDL_V3 -chip interposer -layer_number 16
layer -layer RDL_M4 -chip interposer -layer_number 17
###############################
# Arrange chips in 3DSTACK
###############################
place_chip -placement pInterposer -chip interposer \
-x_origin 0 -y_origin 0
place_chip -placement pController -chip controller \
-x_origin 17 -y_origin 12
place_chip -placement pRam0 -chip ram \
-x_origin 80 -y_origin 12
place_chip -placement pRam1 -chip ram \
-x_origin 80 -y_origin 45
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
place_chip
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-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-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-8 shows how to directly connect two layers. In this example, the pads (pInt_pad) are
directly connected to the pInt_M1 layer.
Prerequisites
• Completion of “Placing the Dies” on page 318.
• Layer stackup information (how layers and die placements are connected).
Procedure
1. Open your 3dstack.rules rule file.
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_RDL_M2 pInterposer_RDL_M3 BY pInterposer_RDL_V2
connect pInterposer_RDL_M3 pInterposer_RDL_M4 BY pInterposer_RDL_V3
connect pInterposer_interposer_pads pInterposer_RDL_M1
connect pInterposer_interposer_pads pController_controller_pads
connect pInterposer_interposer_pads pRam0_ram_pads
connect pInterposer_interposer_pads pRam1_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.
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 pInterposer_RDL_M1 pInterposer_RDL_M2 BY pInterposer_RDL_V1
connect pInterposer_RDL_M2 pInterposer_RDL_M3 BY pInterposer_RDL_V2
connect pInterposer_RDL_M3 pInterposer_RDL_M4 BY pInterposer_RDL_V3
# connect pads on all chips to interposer layers
connect pInterposer_interposer_pads pInterposer_RDL_M1
connect pInterposer_interposer_pads pController_controller_pads
connect pInterposer_interposer_pads pRam0_ram_pads
connect pInterposer_interposer_pads pRam1_ram_pads
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
connect
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.
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.
Prerequisites
• Completion of “Placing the Dies” on page 318.
Procedure
1. Open your 3dstack.rules rule file.
• Any placements of the controller chip include the controller_pads layer. The following
command was used to place the controller:
place_chip -placement pController -chip controller \
-x_origin 17 -y_origin 12
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:
attach_text -placement pController_controller_pads \
-text_placement pController_controller_pads
Examples
…
connect pInterposer_interposer_pads pRam0_ram_pads
connect pInterposer_interposer_pads pRam1_ram_pads
###############################
# Associate text with geometry
###############################
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
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
attach_text
import_text_labels
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.
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
1. Open your 3dstack.rules rule file.
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.
3. Save the rule 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).
Examples
…
#End Assembly commands
###############################
# 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 \
-placement1 pController_controller_pads \
-placement2 pRam0_ram_pads \
-detailed -comment "CONNECT::Controller to Ram0 check"
connected -check_name CONNECT_Cont_to_Ram_1 \
-placement1 pController_controller_pads \
-placement2 pRam1_ram_pads \
-detailed -comment "CONNECT::Controller to Ram1 check"
connected -check_name CONNECT_Ram0_to_Int \
-placement1 pRam0_ram_pads \
-placement2 pInterposer_interposer_pads \
-detailed -comment "CONNECT::Ram0 to Interposer check"
connected -check_name CONNECT_Ram1_to_Int \
-placement1 pRam1_ram_pads \
-placement2 pInterposer_interposer_pads \
-detailed -comment "CONNECT::Ram1 to Interposer check"
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
connect
connected
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
1. Open your 3dstack.rules rule file.
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 \
-constraint "< 15 REGION" -comment "ERR:Placement within 15um!"
external -check_name DIE_SPACE_RAM1 -placement1 pRam_1 \
-constraint "< 15 REGION" -comment "ERR:Placement within 15um!"
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!"
external -check_name RDL_M2.1 -placement1 pInterposer_RDL_M2 \
-constraint "< 0.5 REGION" -comment "ERR: Space < 0.5um on \
RDL_M2!"
…
4. Add enclosure, external, and internal commands for each layer as appropriate.
5. Save the rule file.
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.
Examples
…
connected -check_name CONNECT_Ram1_to_Int \
-placement1 pRam1_ram_pads \
-placement2 pInterposer_interposer_pads \
-detailed -comment "CONNECT::Ram1 to Interposer check"
###############################
# DRC Checks
###############################
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 \
-constraint "< 15 REGION" -comment "ERR:Placement within 15um!"
external -check_name DIE_SPACE_RAM1 -placement1 pRam_1 \
-constraint "< 15 REGION" -comment "ERR:Placement within 15um!"
external -check_name RDL_M1.1 -placement1 pInterposer_RDL_M1 \
-constraint "< 1 REGION" -comment "ERR: Spacing < 1um on RDL_M1!"
external -check_name RDL_M2.1 -placement1 pInterposer_RDL_M2 \
-constraint "< 0.5 REGION" -comment "ERR: Space < 0.5um on RDL_M2!"
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
enclosure
external
internal
Prerequisites
• Completion of “Writing Assembly Operations in the Calibre 3DSTACK Rule File” on
page 313.
Procedure
1. Open your 3dstack.rules rule file.
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" \
-placement1 pController_controller_pads \
-placement2 pInterposer_interposer_pads \
-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" \
-placement1 pController_controller_pads \
-placement2 pInterposer_interposer_pads \
-constraint " < 13" -intersection \
-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
…
external -check_name RDL_M2.1 -placement1 pInterposer_RDL_M2 \
-constraint "< 0.5 REGION" -comment "ERR: Space < 0.5um on RDL_M2!"
overlap -check_name "OVERLAP_Cont_to_Int_percent" \
-placement1 pController_controller_pads \
-placement2 pInterposer_interposer_pads \
-constraint " < 99" -intersection \
-comment "Pad overlap must be greater than 99%!"
overlap -check_name "OVERLAP_Cont_to_Int_area" \
-placement1 pController_controller_pads \
-placement2 pInterposer_interposer_pads \
-constraint " < 13" -intersection -by_area\
-comment "Pad overlap must be greater than 13um^2!"
Related Topics
Calibre 3DSTACK Flow Example
Writing Assembly Operations in the Calibre 3DSTACK Rule File
overlap
centers
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.
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
#
######################################################################
###########################
# 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 }
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
###########################
-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 \
} \
-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 RDL_M2 RDL_M3 BY RDL_V2 \
-wb_connect RDL_M3 RDL_M4 BY RDL_V3 \
-wb_connect interposer_pads RDL_M1
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.
###############################
# Arrange chips in 3DSTACK
###############################
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.
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
###############################
###############################
# DRC Checks
###############################
external -check_name DIE_SPACE_Cont -layer_type1 pad \
-layer_type2 pad \
-constraint "< 65 REGION" -comment "ERR:Placement within 65um!"
# declare layouts
# declare 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
}
}
# dimensional checks
# connectivity check
# output report
report -file report.txt
layout_primary TOPCELL_3DIC
# output report
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
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
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
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
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
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
Chip Placement: pRAM_stack4
Layout: myram
x-origin: -740.000
y-origin: 80.000
Magnification: 1.0
Rotation: 270
Flip Axis: y
Chip Placement: pRAM_stack5
Layout: myram
x-origin: -740.000
y-origin: 80.000
Magnification: 1.0
Rotation: 270
Flip Axis: y
Chip Placement: pRAM_stack1
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
Chip Placement: pRAM_stack2
Layout: myram
x-origin: 230.000
y-origin: 505.000
Magnification: 1.0
Rotation: 90
Flip Axis: y
TEXT LAYER(S):
Layer: pRAM_stack2_RAM_if (pRAM_stack2_RAM_if)
Layer: pCont_CONTROLLER_if (pCont_CONTROLLER_if)
Layer: pRAM_stack3_RAM_if (pRAM_stack3_RAM_if)
Layer: pRAM_stack4_RAM_if (pRAM_stack4_RAM_if)
Layer: pRAM_stack1_RAM_if (pRAM_stack1_RAM_if)
Verification Results
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
Connectivity Results
*************************************************************************
CONNECTIVITY RULECHECK RESULTS
*************************************************************************
RuleCheck: CONNECT_RAM2_to_CONTROLLER ( CONNECTION CHECK between
LAYER:pRAM_stack2_RAM_if and LAYER:pCont_CONTROLLER_if )
-------------------------------------------------------------------------
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>
RuleCheck: CONNECT_RAM3_to_CONTROLLER ( CONNECTION CHECK between
LAYER:pRAM_stack3_RAM_if and LAYER:pCont_CONTROLLER_if )
-------------------------------------------------------------------------
RuleCheck: CONNECT_RAM4_to_CONTROLLER ( CONNECTION CHECK between
LAYER:pRAM_stack4_RAM_if and LAYER:pCont_CONTROLLER_if )
-------------------------------------------------------------------------
RuleCheck: CONNECT_RAM1_to_CONTROLLER ( CONNECTION CHECK between
LAYER:pRAM_stack1_RAM_if and LAYER:pCont_CONTROLLER_if )
-------------------------------------------------------------------------
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.
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.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.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.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.