HeatWave

2019.02

Reference Manual
Notices

© Keysight Technologies, Inc. 1983-2019

1400 Fountaingrove Pkwy., Santa Rosa, CA 95403-1738, United States

All rights reserved.

No part of this documentation may be reproduced in any form or by any means (including electronic stor-
age and retrieval or translation into a foreign language) without prior agreement and written consent from
Keysight Technologies, Inc. as governed by United States and international copyright laws.

Restricted Rights Legend

If software is for use in the performance of a U.S. Government prime contract or subcontract, Software is
delivered and licensed as "Commercial computer software" as defined in DFAR 252.227-7014 (June 1995),
or as a "commercial item" as defined in FAR 2.101(a) or as "Restricted computer software" as defined in
FAR 52.227-19 (June 1987) or any equivalent agency regulation or contract clause.

Use, duplication or disclosure of Software is subject to Keysight Technologies’ standard commercial li-
cense terms, and non-DOD Departments and Agencies of the U.S. Government will receive no greater than
Restricted Rights as defined in FAR 52.227-19(c)(1-2) (June 1987). U.S. Government users will receive
no greater than Limited Rights as defined in FAR 52.227-14 (June 1987) or DFAR 252.227-7015 (b)(2)
(November 1995), as applicable in any technical data.

Portions of this software are licensed by third parties including open source terms and conditions.
For detail information on third party licenses, see Notice.

Publication Date: February 13, 2019

Table of Contents

1 HeatWave 1
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Power Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Input/Output Text Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 OpenAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Interrupting HeatWave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.7 Text Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8 Using Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.9 Input Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.9.1 Common Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.9.2 Text Input Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.9.3 Scripting Primitives Input Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.9.4 Tcl Utility Input Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.10 Transient Thermal Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.11 HeatWave Interface to Cadence Virtuoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Power Source Files 10

2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Power Source Extent Table (.ptab) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Power Value File (.pval) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Model Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Temperature-to-Power Table Lookup . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Technology File 13
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Thermal Layer Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Thermal Layer Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Mask Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Mask Layers Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Package and Bond Model Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1 Bond Model Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.2 Package Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.3 Boundary Heat Transfer Coefficients . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Complete Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.8 Temperature Dependent Conductivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
 TABLE OF CONTENTS

3.9 Orthotropic Conductivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Mesh Initialization File 24

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 initial_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2 resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3 reseed_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4 reseed_pwr_grad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.5 refine_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.6 refine_temp_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.7 refine_temp_grad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.8 pwr_update_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.9 k_update_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Electrical Solvers 27
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.2 Electrical Solver Initialization File . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.3 Instance Cross-Reference File <cellname>.gdai . . . . . . . . . . . . . . . . . . . 28
5.2 Electrical Solver Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Temperature to Power Table Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 ADS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.1 ADS Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.2 ADS Invocation Script hw_ads . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.3 ADS Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5 Eldo Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5.1 Eldo Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5.2 Eldo Invocation Script hw_eldo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5.3 Eldo Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.5.4 Eldo Premier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6 FineSim Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.1 FineSim Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.2 FineSim Invocation Script hw_finesim . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.3 FineSim Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.7 HSPICE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.7.1 HSPICE Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

ii
 TABLE OF CONTENTS

5.7.2 HSPICE Invocation Script hw_hspice . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.7.3 HSPICE Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.8 Spectre Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.8.1 Spectre Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8.2 Spectre Invocation Script hw_spectre . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8.3 Spectre Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.9 Ultrasim Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.9.1 Ultrasim Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.9.2 Ultrasim Invocation Script hw_ultrasim . . . . . . . . . . . . . . . . . . . . . . . . 50
5.9.3 Ultrasim Data Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.10 Multiple Electrical Solvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Scripting Primitives 53
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.2 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Vars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.4 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.5 Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.6 Function1d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3 Using Tcl in your HeatWave scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.1 HeatWave Flow object in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.2 HeatWave methods in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.3 HeatWave procedures in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.4 HeatWave vars in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.5 Lists in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.6 HeatWave Vectors in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.7 HeatWave Function1d in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4 Scripting Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.1 How Vars, Methods and Procedures are described . . . . . . . . . . . . . . . . . 64
6.5 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5.1 log_time_stamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5.2 run_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.5.3 Flow::vars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.5.4 Flow::designVars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.5.5 Flow::meshVars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

iii
 TABLE OF CONTENTS

6.5.6 Flow::tsolveVars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.5.7 Flow::transientVars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5.8 Flow::getTech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5.9 Flow::getDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5.10 Flow::getMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5.11 Flow::getTSolve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5.12 Flow::getTransient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5.13 Flow::getGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5.14 Flow::libName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5.15 Flow::cellName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5.16 Flow::loadDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5.17 Flow::archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5.18 Flow::restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.5.19 Flow::continueOnError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.5.20 Flow::setXYScale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.5.21 Flow::runSteadyState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.5.22 Flow::runTransient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.5.23 Flow::transientStatisticsReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.5.24 Flow::reloadTransient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.6 PlotVars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.6.1 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6.2 quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6.3 inst_quantity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6.4 style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6.5 range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6.6 view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6.7 z_values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6.8 z_layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6.9 window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6.10 axes_n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6.11 axes_d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6.12 contour_count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6.13 contour_delta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6.14 isosurface_count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.6.15 grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.6.16 file_prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.6.17 file_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

iv
 TABLE OF CONTENTS

6.6.18 temp_histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.6.19 power_histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.6.20 power_density_histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.7 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.7.1 GUI::show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.7.2 GUI::saveDefaultPlots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.7.3 GUI::savePlots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.7.4 HistogramPlot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.8 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.8.1 max_power_density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.8.2 Design::vars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.8.3 Design::isLoaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.8.4 Design::setBounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.8.5 Design::createPowerSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.8.6 Design::setProbe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.9 Tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.9.1 Tech Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.9.2 Tech::load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.9.3 Tech::addMaterial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.9.4 Tech::addLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.9.5 Tech::addMaskToLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.9.6 Tech::encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.9.7 proc gdWriteTechTcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.9.8 proc gdDefineTech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.9.9 Complete Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.10 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.10.1 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.10.2 thermal_conductivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.10.3 heat_capacity_per_unit_volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.10.4 size_dependent_conductivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.10.5 metal_electron_mean_free_path . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.11 Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.11.1 initial_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.11.2 initial_seed_x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.11.3 initial_seed_y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.11.4 power_source_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.11.5 spatial_resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

v
 TABLE OF CONTENTS

6.11.6 refine_temp_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.11.7 power_update_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.11.8 k_update_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.11.9 refine_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.11.10 refine_temp_grad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.11.11 reseed_iter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.11.12 reseed_power_grad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.11.13 balance_extraction_threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.11.14 store_extracted_geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.11.15 max_threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.11.16 Mesh::vars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.11.17 Mesh::outputTemperatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.11.18 Mesh::printLayerTemperatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.11.19 proc gdSetModerateResolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.11.20 proc gdSetHighResolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.12 Thermal Solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.12.1 transient_solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.13 Transient Thermal Solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7 Thermal Technology Definition 93

7.1 Complete Thermal Technology Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.1.1 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.1.2 substrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.1.3 oxide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.1.4 channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.1.5 thinox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.1.6 poly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.1.7 contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.1.8 metal1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.1.9 via1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.1.10 metal2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.1.11 passivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.2 Compact Technology Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3 Text Technology Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

8 Transient Electro-Thermal Simulation 105

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.2 Transient Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

vi
 TABLE OF CONTENTS

8.3 Transient Electro-Thermal Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

8.4 Transient Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.5 Transient Solver Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.6 Transient Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.7 Transient Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.7.1 Scope of Transient Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.7.2 start_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.7.3 stop_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.7.4 time_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.7.5 time_steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.7.6 initial_time_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.7.7 minimum_time_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.7.8 maximum_time_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.7.9 epsilon1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.7.10 epsilon2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.7.11 step_reduction_factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.7.12 low_error_threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.7.13 snapshot_temperature_change . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.7.14 snapshot_time_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.7.15 snapshot_step_interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.7.16 verbosity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.8 Transient Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.8.1 Transient::vars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.8.2 Transient::criticalTemperatureChange . . . . . . . . . . . . . . . . . . . . . . . . 115
8.8.3 Transient::criticalTemperatureChangeRate . . . . . . . . . . . . . . . . . . . . . . 115
8.8.4 Transient::criticalTemperatureChange . . . . . . . . . . . . . . . . . . . . . . . . 115
8.8.5 Transient::criticalTemperatureChangeRate . . . . . . . . . . . . . . . . . . . . . . 115
8.9 Transient Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.9.1 proc gdTranTemp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.9.2 proc gdTranPower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.9.3 proc gdTranDTemp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.9.4 proc gdTranDPower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.10 Transient Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.10.1 proc gdTranMeasureTemp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.11 Transient Tcl Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.12 Power Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.12.1 Constant Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

vii
 TABLE OF CONTENTS

8.12.2 Step Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

8.12.3 Linear Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.12.4 Pulse Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.12.5 Piece Wise Linear Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.12.6 Exponential Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.12.7 Sine Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

9 Tcl Utilities 124

9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.2 Using HeatWave Tcl Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2.1 HeatWave Context in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2.2 Context Callbacks in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.3 Context Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3.1 proc gdNewVars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3.2 proc gdGetVar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3.3 proc gdSetVar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3.4 proc gdRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3.5 proc gdIsTransientMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.3.6 proc gdCxtInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.3.7 proc gdCxtLogVars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.4 Context Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.4.1 batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.2 run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.3 summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.4 archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.5 restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.6 package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.7 txttech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.8 cellname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.9 libname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.10 scalexy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.11 composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.12 verbosity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.13 userdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.14 trans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.15 trtimes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.16 trsteps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

viii
 TABLE OF CONTENTS

9.4.17 reloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

9.5 Context Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.5.1 Context Callback Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.5.2 callback cxtTech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.5.3 callback cxtPreLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.5.4 callback cxtPower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.5.5 callback cxtBlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.5.6 callback cxtPostPower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.5.7 callback cxtPreRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.5.8 callback cxtLocalPreRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.5.9 callback cxtPostRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
9.5.10 callback cxtLocalPostRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
9.6 Customizable Thermal Simulation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

10 Complete Examples 138

10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.2 Common Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.2.1 OpenAccess Layout Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.2.2 Ptab File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.2.3 Pval File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.2.4 ESolve Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.2.5 Package Model file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
10.2.6 Spectre run directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.3 Using Text Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.3.1 Text Techfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10.4 Using Tcl Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.4.1 Complete Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
10.5 Using Tcl Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
10.5.1 Transient Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.5.2 Complete Transient Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.5.3 Steady State Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.5.4 Complete Steady State Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

11 Using HeatWave’s Virtuoso GUI 151

11.1 HeatWave Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
11.2 Thermal Analysis Setup Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
11.3 Power Source Extraction Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
11.4 Simulation Setup Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

ix
 TABLE OF CONTENTS

11.5 Thermal Analysis Invocation Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

12 Customizing HeatWave’s Virtuoso GUI 157

12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
12.2 Configuring HeatWave using SKILL and Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . 159
12.3 Virtuoso Interface SKILL Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
12.4 Example of GUI Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
12.5 GUI structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
12.5.1 hwModeTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
12.5.2 hwCurrentMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
12.5.3 hwCdsLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
12.5.4 hwCdsCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.5.5 hwCdsSch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.5.6 hwCdsInstInSch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.5.7 hwOaLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.5.8 hwOaCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.5.9 hwLockMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.5.10 hwPtabLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
12.5.11 hwExtView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.12 hwExtViewList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.13 hwLayoutView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.14 hwPowerLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.15 hwPowerProp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.16 hwValidPropName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.17 hwValidPropVal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.18 hwValidLayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
12.5.19 hwExtractionMethod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
12.5.20 hwTryAlternates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
12.5.21 hwGrowPowerBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
12.5.22 hwUserContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
12.6 Mode GUI structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
12.6.1 hwSimTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
12.6.2 hwCurrentSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
12.6.3 hwExecName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
12.6.4 hwRunDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
12.6.5 hwTranTimes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
12.6.6 hwTranSteps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

x
 TABLE OF CONTENTS

12.6.7 hwTranReloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

12.6.8 hwRunResultDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.6.9 hwLoadResultDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.6.10 hwLockSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.6.11 hwRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.6.12 hwBatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.6.13 hwSaveShapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.6.14 hwRunLogFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.6.15 hwTclTech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6.16 hwTechIni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6.17 hwEsolveIni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6.18 hwMeshIni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6.19 hwReadArchive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6.20 hwWriteArchive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6.21 hwTcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6.22 hwSummarizeTemps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
12.7 Simulator GUI structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
12.7.1 hwSimName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
12.7.2 hwSimRunDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.7.3 hwSimNetlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.7.4 hwSimOutRelPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.7.5 hwSimScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.7.6 hwSimMaxTemp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.7.7 hwSimTempStr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.7.8 hwSimSubckt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.7.9 hwSimLocDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
12.7.10 hwSimOverwriteLocDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
12.7.11 hwSimCmdStr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
12.8 SKILL Globals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
12.8.1 gdaDefaultMenuTrigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
12.8.2 gdaSourceSelector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
12.9 SKILL Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
12.9.1 procedure gdaIsSteadyState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
12.9.2 procedure gdaModeGui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
12.9.3 procedure gdaSimGui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
12.9.4 procedure gdaCreateGradientPullDownMenu . . . . . . . . . . . . . . . . . . . . 177
12.9.5 procedure gdaGuiSetupPowerSources . . . . . . . . . . . . . . . . . . . . . . . . 177

xi
 TABLE OF CONTENTS

12.9.6 procedure gdaGuiSetupSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

12.10 SKILL Callback Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.10.1 procedure gdaConfigureHwGui . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.10.2 procedure gdaPostInitGuiData . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
12.10.3 procedure gdaPostGuiSetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
12.10.4 procedure gdaPreGuiPsrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
12.10.5 procedure gdaPreWritePtabInstLayer . . . . . . . . . . . . . . . . . . . . . . . . . 180
12.10.6 procedure gdaPreWritePtabGeometry . . . . . . . . . . . . . . . . . . . . . . . . 181
12.10.7 procedure gdaPostGuiPsrc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
12.10.8 procedure gdaPreGuiSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
12.10.9 procedure gdaPostGuiSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
12.10.10 procedure gdaPreGuiRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
12.10.11 procedure gdaPreCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
12.10.12 procedure gdaPostGuiRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

xii
 HeatWave

1 HeatWave

1.1 Overview

This manual is a reference resource for the HeatWave thermal simulator, describing its invocation, the types
and formats of inputs and outputs, and the command-syntax in various modes of use. This manual is also
provided in html format in your HeatWave software installation hierarchy.
HeatWave comprises a 3D thermal extraction and simulation engine that computes temperature within a
chip, given a power profile, layout geometries, thermal properties of materials in the chip, and a package-
model for the integrated circuit. HeatWave’s usage-models and their implementations are described in the
HeatWave User Interface Guide (UserGuide). The Graphical User interface (GUI) and its operation are
described in a separate HeatWave User Interface Guide (UIGuide).
HeatWave’s thermal solver may be used to compute both steady-state and transient temperature profiles,
in an electro-thermal loop. In either case, the power values used as inputs may be obtained from transient
thermal simulations. HeatWave computes temperature at the length scales of your power sources, which
may be as small as transistors or other active devices, or interconnect.
HeatWave may obtain power values from your circuit simulator, returning it instance-specific tempera-
ture values, so voltages, currents and power waveforms from your circuit simulator are more accurate
or "temperature-aware". HeatWave integrates smoothly into standard analog and mixed-signal IC design
flows.
Transient thermal analysis is useful in designs where peak hot-spots and temperature differences (∆T ) may
be missed by steady-state analysis. Examples of the above are high power-density transistors driving trans-
ducers, including actuators such as stepper motors, airbag detonators etc. High-power densities are also
present in switching power regulators and pulsed RF power transistors, for example in avionics, radar, and
other high peak-to-average-ratio applications including CDMA, W-CDMA, TD-SCDMA and OFDM systems.
HeatWave integrates the thermal analysis engine with the simulation environment for analog circuit design.
The benefits of such an integration with the analog design environment are:

• electrical circuit-simulation now uses the temperature profile to assign each instance a distinct tem-
perature, that is consistent with the electrical power dissipated as heat
• simulation of temperature sensitive circuits that could previously only be characterized with bench,
wafer or package tests.
• package and bond-wire thermal effects modify instance temperatures in circuit-simulation
• estimates of power dissipation enable analog chip floorplanning for temperature

To automate, or assist in, the preparation of the data-files described below, and in the setup of electrical-
simulators used by HeatWave, an interface from Cadence’s Virtoso and Analog Design Environment, to
the HeatWave environment, is available, as summarized in the Cadence HeatWave Interface section, and
described in the sections on Using HeatWave’s Virtuoso GUI and Customizing HeatWave’s Virtuoso GUI.
The thermal simulator is invoked as heatwave, with inputs, outputs and switches as described below.

1.2 Power Sources

In order to correctly define HeatWave’s inputs and obtain accurate results, you should clearly understand
the concept of a power-source in HeatWave.
Power that is dissipated as heat by the devices in your circuit, varies by location and over time within your
chip. The materials within your chip are not perfect thermal conductors. So, even if your chip was made of
a single material, temperatures within it would vary by location, and in time.

1
 HeatWave

This is further complicated by the fact that your chip contains several distinct materials including metals,
one or more semiconductors, glasses, and passivation, of varied sizes, with significantly different thermal
properties. The chip may even be a stack of several thin dice.
These factors determine the temperature variations across your chip, by location, and over time. If the
variation in power by location, or over time is significant, the temperature variation is probably significant
too.
A HeatWave power-source is a three-dimensional region within your chip that dissipates power, as heat. A
power source may be a single transistor, a metal wire-segment or bus-segment, or a via. A power-source
may be also be a larger design-block or macro, for which you only have a single power value. From this
definition, it should be clear that a "power-source" does not refer to your design’s power supply .
You use HeatWave to compute the temperature of each power-source, and throughout your chip. A power-
source has two attributes that you should clearly understand.

• a power-source extent is the three-dimensional region on the chip within which the power-source
object dissipates power, as heat. Therefore a power-source is not a point, or a plane, or a width,
length and height. To define a power-source, you need to specify its extent to HeatWave, in an input
file or as a command in a script.
• a power-source has a power value, representing the power dissipated as heat, which may vary over
time. HeatWave does not compute the power value. You may obtain the power value from your circuit-
simulator, power-analysis tools, or equations and a spreadsheet. To define a power-source you need
to specify its power value to HeatWave, in an input file or as a command in a script. The default power
dissipated by a power-source is 0 W.

A power-source is often, but not always, an instance in your circuit-simulation netlist, or in your OpenAccess
database. You may define power-sources which do not exist in your design data-base, to model regions
of the die that have not yet been designed (but whose power you can estimate).You may also define a
power-source and never assign any power to it (so it dissipates zero power), in order to define a thermal
probe whose volume-averaged temperature is reported.

1.3 Input/Output Text Files

The inputs to HeatWave using the text input model are:

• technology information :
– gdatech.ini (or -t <techfile> ): The technology file (or "techfile") describes physical
properties of the chip and package under thermal analysis, as well as properties of the envi-
ronment.
• design information :

– <lib-name>.ptab : The power source file lists the power sources in the input design, and op-
tionally, an area of interest on which to focus the analysis.
– <cell-name>.pval : The power value file specifies initial power values on the sources.
– <cell-name>.tpl : The table data file contains 1-D table data of temperature versus power for
each source, to enable source updates in the program flow. This is used when the table lookup
model is used for temperature-dependent power estimation.
– <lib-name>/ : This directory contains the OpenAccess library <lib-name> including the
OpenAccess layout (binary data) for <cell-name>. The OpenAccess layout-data should be
created using stream commands such as strm2oa in HeatWave’s OpenAccess tool-set.

2
 HeatWave

– lib.defs : If an OpenAccess database is present, a lib.defs file is required. Among other

things, this file indicates where OpenAccess may locate a given library . Typically this contains
DEFINE <library-name> <path-name>
For example: DEFINE myLib ./myLib

The program can generate the following output files:

• <cell-name>.tval : This text file lists all power sources, their volume-averaged temperatures, and
the final power value used to calculate that temperature.
• <cell-name>.gval : This text file contains a listing of all layout polygons with mask layer and
coordinates (in database units (dbu), usually 1nm or 0.1nm) and the associated average temperature
of the volume implied by the polygon. This file is generated using the -p command-line option, or
through selection of the File->Write->"Geometry Temperature" pulldown in the GUI.

The base-names of the output files may be specified using the -o command-line option.

1.4 OpenAccess

The HeatWave physical database uses the OpenAccess (OA) schema, common to many integrated circuit
design databases. The design is identified, at least, by an OA library name and and OA cell name. A layout
in OpenAccess has two characteristic values

• layout "database units" or dbu are integer units using which the layout geometries are defined. In
practice dbu values are typically, but not always, 1nm or 0.1nm.
• layout "user units" or uu are real values in which the layout geometries may eventually be expressed.
User units are typically microns (µm)

OpenAccess layout-data must be created using stream commands such as strm2oa in HeatWave’s
OpenAccess tool-set, since HeatWave implements a customized version of the OpenAccess schema.

1.5 Usage

This section describes basic HeatWave invocation, without the use of any input script-files. HeatWave
must be invoked in the directory containing all the input data files, with the library and cell name of interest
specified using the following command-line switches:

• -L <lib-name> : OpenAccess library name

• -C <cell-name> : cell name within library lib-name

or HeatWave may be invoked to read data from a HeatWave archive file:

• -r <gda-archive> : ∗.gda archive file

The HeatWave archive contains steady-state data, or a single transient snapshot, so the -r
<gda-archive> switch should only be used to load steady state data. Tcl scripting primitives or Tcl
utilities should be used to load transient data.
If an OpenAccess library by the specified name is not found, a dummy library hierarchy is created, with an
empty layout.oa file.
Other options that may be specified in the command-line include the following (default values specified in
brackets):

3
 HeatWave

• -h : print help message

• -b : batch mode [false]
• -g : GUI mode [true]
• -i <file> :mesh init file [gdamesh.ini]

• -l <file> : set log file [<stdout>]

• -m <name> : messaging prefix [heatwave]
• -o <name> : output file prefix [<cell-name>]

• -p : save polygon shape temperatures [false]

• -e <file> :electrical solver init file [gdaesolve.ini]
• -s <file> : thermal solver init file [gdatsolve.ini]
• -t <file> :text (not Tcl) technology file [gdatech.ini]

• -v <level>: verbosity level [0]

• -w <file>.gda : save gda archive file [false]
• -x <value>: spatial resolution along the x-axis, in meters

• -y <value>: spatial resolution along the y-axis, in meters

The optional mesh initialization file specified using the -i option allows control of the spatial resolution of
the temperature solution of the design under test. If not specified, the program will load a default file named
gdamesh.ini, if present in the dataset directory.
The optional -t switch only accepts a plain-text (i.e. non-Tcl) technology file, as described in the text
technology file section. A Tcl Thermal Technology definition (or a compact Tcl Technology definition) should
be loaded using Tcl Utilities.
The -x and -y options are yet another means of specifying the initial spatial resolution of the temperature
solution. These values override the setting of the initial_seed parameter in the mesh initialization file,
if loaded.
If none of the preceding methods for setting initial resolution are specified, default initial resolution settings
apply.
Once invoked with the appropriate arguments and inputs, HeatWave’s simplified internal flow is as shown
in the following figure. At branches in the flow, the thermal solver and an external electrical-solver such as
a circuit-simulator for power may be re-run, if the temperature difference between iterations exceeds user-
specifiable thresholds. HeatWave proceeds to the next step in the flow only if the computed temperatures
are consistent with the current mesh and power-values.

4
 HeatWave

Figure 1: HeatWave program flow

The inputs in the preceding flow-chart are described generally, by type. The specific form each input is not
shown, because it varies depending on the types and organization of your design-data, as described in the
section on input models.
Computed temperatures of the individual power sources (defined in the .ptab file) are written out to the .tval
file.
If HeatWave is invoked with the -g option, a graphical user interface is launched, to enable visual analysis
of the computed temperature field. Users may plot thermal iso-surfaces and contours, or plot power and
(area) power-density . These, among other graphical capabilities, allow interactive analysis of the thermal
simulation results. The Graphical User interface (GUI) and its operation are described in the HeatWave
User Interface Guide (UIGuide). With the appropriate licensing, -g enables a GUI-only (or "viewer") mode
in which existing results (e.g. loaded using -r) are viewable, but all solvers are disabled.

1.6 Interrupting HeatWave

When a command-line (non-batch) invocation of HeatWave is interrupted by a <ctrl><c> , HeatWave

presents the following text menu.

5
 HeatWave

Interrupt options:
------------------
0: Terminate program
1: Interrupt flow
2: Continue
Enter choice [0]:

Selecting the default 0 makes HeatWave exit immediately, saving nothing. Type 1 to make HeatWave write
the current, perhaps incomplete, solution to the usual output files. This allows you to interrupt or truncate a
transient simulation, to view partial or incomplete results. Type 2 to resume execution of HeatWave. While
running in batch mode, HeatWave may be interrupted by creating an empty file named .gda_intr in the Heat-
Wave run-directory, after which HeatWave terminates as if you selected 1 above. No menu is presented,
and the .gda_intr file is deleted before HeatWave exits.

1.7 Text Inputs

The HeatWave usage described so far describes plain text (i.e. not an executable script) data-formats
for the input control-files, and some of the input data-files needed to run HeatWave. All the steady-state
usage models for HeatWave described in the HeatWave User Guide may be exercised using such plain text
input-files. However, the text input-file formats have limitations. Also, transient electro-thermal simulation
is not accessible via plain text input-files. HeatWave’s full functionality is only accessible using its scripting
interface.

1.8 Using Scripts

In addition to the text-input based usage, HeatWave accepts inputs in a scripting language. At present a
Tcl scripting interface is enabled.
You may append the name of a Tcl script-file to your command-line using the switches above. If you do
so, the Tcl script will be executed after completion of the flow previously described. This is equivalent to
specifying the -c switch to load a Tcl file, as described below. If -g was also specified (with appropriate
licensing) the GUI-only mode described earlier is activated, and the Tcl script will launch a GUI when it
finishes, or when it encounters commands to launch a solver.
Alternatively you may treat all command-line options as optional and simply provide a single script-file as
the argument to HeatWave. This is equivalent to specifying -c <script-file-name>
More heatwave options, applicable when used with Tcl scripts, are summarized below. They may be used
in combination with the previously described options. These following switches have no default values.

• -I : launch an interactive Tcl shell

• -c <file> : run Tcl script
• <file> : shorter form of -c <Tcl-script>

The <file> arguments above are Tcl scripts that invoke scripting primitives or scripting utilities and follow
Tcl v8.5 syntax

1.9 Input Models

An input model refers to the type and organization of input-data provided to a program. This is a part of the
usage model that includes the functional context of the program, i.e. what the program does, rather than
the inputs it accepts.

6
 HeatWave

The "HeatWave program flow" figure in the preceding Usage section, described the general types of inputs
to HeatWave. The following figure summarizes the specific inputs used in the text, Scripting primitives, and
Tcl Utilities input models.

Figure 2: HeatWave Input Models

Detailed descriptions of the specific inputs shown are provided throughout this manual. For your con-
venience, links to these items are summarized in sections below, for each input model. The Complete
Examples section illustrates the use of each input model summarized above.

1.9.1 Common Inputs

The links listed below provide descriptions of the "Text Inputs" The preceding figure on "HeatWave input
models" showed the specific inputs used for each input model.
Several specific inputs are common to all the input models. Links to these common inputs are summarized
below:

• Layout is defined in an OpenAccess database

• Power Source extents are defined in a <libname>.ptab file , as seen in this example

7
 HeatWave

• Initial power-source power-values are defined in a <cellname>.pval file, as seen in this example
• Electrical Solver interface controls are defined in a control file typically named gda_sim.ini
• Package boundary conditions are defined in a package file, as seen in this example.

1.9.2 Text Input Model

The text input model is useful for new users, defining simply-specifiable problems, or running a prototype
analysis where not all inputs are systematically obtainable (e.g. from your production CAD environment).
The links listed in the Common Inputs section may be used in this input model. Additionally, the links
listed below provide descriptions of the "Text Inputs" shown in in the preceding figure on "HeatWave input
models".

• Thermal technology is defined in a text thermal techfile as seen in this example.

• The Package boundary conditions should not be in a distinct package file but should be appended to
the text thermal techfile. This applies only to the text input model.
• The Mesh controls are defined in mesh control-file, typically named gdamesh.ini
• Transient controls and the HeatWave’s Virtuoso Interface are not accessible with the input model.

The Using Text Inputs section contains a complete example using this input model.

1.9.3 Scripting Primitives Input Model

The Scripting primitives input model is useful for modeling problems that require some level of detail and
flexibility, or for running complex prototyping analyses, outside your production CAD environment.
The links listed in the Common Inputs section may be used in this input model. Additionally, the links
listed below provide descriptions of the "Scripting Primitives" inputs shown in in the preceding figure on
"HeatWave input models".

• Power sources may be defined in a Tcl script using the Design object’s createPowerSource method.
This supplements the usual <libname>.ptab file
• A Thermal technology may be defined in Tcl using scripting methods of the Tech object, as seen in
this basic example or this more compact example.
• Mesh controls may be defined in Tcl using Mesh vars.
• Transient controls may be defined in Tcl using Transient vars and methods, as seen in this example
• HeatWave’s Virtuoso Interface may be made to work with this input-model. However, the interface is
designed to work with the Tcl Utility Input Model.

The Using Tcl Primitives section contains a complete example using this input model.

1.9.4 Tcl Utility Input Model

This model with Tcl Utilities using a HeatWave Context, is designed for enterprise application in a produc-
tion design environment. Centralized Tcl callbacks to define default controls and design-kit (PDK) specific
controls, as well as Skill callbacks to customize HeatWave’s Virtuoso interface should be provided by your

8
 HeatWave

CAD support group, so that only a few design-specific settings, if any, need to be made by an end-user.
The $TCLLIBPATH and tclIndex constructs, may be used to centralize Tcl definitions and automatically
load them into an end-user’s environment, as summarized in the overview of utilities section.
The links listed in the Common Inputs section may be used in this input model. Additionally, the links listed
below provide descriptions of the "Tcl Utilities" inputs shown in in the preceding figure on "HeatWave input
models".

• Power sources may be defined in a Tcl script using the power definition procedure. This supplements
the usual <libname>.ptab file
• A Thermal technology is defined in Tcl using the gdDefineTech procedure as seen in this example.
• Mesh controls may be defined in Tcl using Mesh utilities such as gdSetModerateResolution or gdSet-
HighResolution, within centralized Tcl callbacks such as cxtPreRun.
• Transient controls may be defined in Tcl using Transient vars and methods, within centralized Tcl
callbacks such as cxtPreRun.
• HeatWave’s Virtuoso Interface produces run∗.tcl command files for HeatWave, that use the Tcl Utility
Input Model.

The Using Tcl Utilities section contains a complete example using this input model.

1.10 Transient Thermal Simulation

Transient electro-thermal simulation is available in HeatWave. Many of its inputs may be text input-files.
However, additional controls for, and the execution of, the transient electro-thermal simulation may only be
specified in scripts which use primitives or utilities.

1.11 HeatWave Interface to Cadence Virtuoso

As stated in the Overview, an interface from Cadence’s Analog Design Environment is provided by Heat-
Wave as a set of encrypted Skill files in $GDA_ROOT/etc/il and is loaded during a Cadence-tool invo-
cation from the user’s .cdsinit file. This interface simplifies the creation of the power-source (ptab) file,
the setup of a Spectre run directory for use in thermal analysis, and the invocation of Spectre within the
electro-thermal analysis loop.
The Virtuoso-HeatWave interface enables

• automatic generation of a power-source (ptab) file from a Cadence extracted cellview with
recognition-layer shapes OR from a Cadence extracted cellview with user-defined shapes on an
arbitrary layer
• setup of a Spectre simulation run directory for thermal analysis, given a working Spectre run directory.
The new directory contains a netlist modified to accept temperature on each device
• execution of heatwave on a valid HeatWave run directory running electrical simulation as needed to
measure device powers using computed device temperatures

Use of the interface is described in the section on Using the Virtuoso GUI. The interface is designed to be
customized to generate the required inputs for HeatWave, from your particular design environment. The
section on Customizing the Virtuoso GUI describes how such customizations may be done.
Use of HeatWave’s interface to Virtuoso is also illustrated in a HeatWave Tutorial, and in design examples,
provided with HeatWave.

9
 Power Source Files

2 Power Source Files

2.1 Overview

The Power Sources section that begins the HeatWave Reference Manual, describes the concept of a power-
source, that is an essential requirement for thermal simulation.
The extents of power sources in the design being simulated by HeatWave are defined in a text file named
<library-name>.ptab where <library-name> is the name of the OpenAccess library specified to
HeatWave. You may restrict the simulation-domain to a specific region within the design by specifying the
co-ordinates of a bounding box in the <library-name>.ptab file, as described in the Power Source
Extent Table (.ptab) section.
The values of power sources, are specified in a file named <cell-name>.pval, as described in the Power
Value File (.pval) section.
The variation of power with temperature for power sources is specified in a file named <cell-name>.tpl,
as described in the Temperature-to-Power Table Lookup section.
The <cell-name> prefix of both the preceding files is the name of the OpenAccess cell specified to Heat-
Wave as the container of the design’s layout.

2.2 Power Source Extent Table (.ptab)

The <library>.ptab file defines power-source positions and cell extents in a simple text format. There
are two types of definitions; power source definitions and an optional cell bounds definition:

• distinct definitions are required for each power source in the design. Their syntax is:
<cell> <name> <thermal layer name-or-number> <x1> <y1> <x2> <y2>
where
– <cell> is the name of the cell being thermally simulated. This field may be omitted if a preceed-
ing cell definition statement was made, as described below
– name is a string which is used as the power source identifier
– <thermal layer name-or-number> is either the number (i.e. index) of the thermal layer,
or the name (without quotes) of the thermal layer (not the mask-layer) occupied by the power
source
– x1, y1, x2, y2 are the coordinates of the bounding box of the power source (only rectangular
power source shapes are specifiable) in OpenAccess user units, usually microns.
• an optional cell bounds definition, that limits the simulation to a defined region. If not specified, the
bounds are defined by the smallest box that encloses all the layout and all power-sources. The syntax
of this statement is:
<cell> bounds <x1> <y1> <x2> <y2>
where x1, y1 are the coordinates of the lower left corner and x2, y2 are the coordinates of the upper
right corner of the bounding box, and are specified as OpenAccess integer database units or dbu,
usually 1nm or 0.1nm.
• an optional cell keyword enables the definition of a default cellname. The syntax of this statement,
which must occur before any power source definition within the <library>.ptab file, is:
cell <cell-name>
Example: An example <library>.ptab file is shown below:

10
 Power Source Files

lab bounds 0 0 135300 217000

lab I_0_0_61.04_207.555 1 61.04 207.555 61.34 207.855
lab I_0_0_63.25_182.82 2 63.25 182.82 63.55 183.12
lab I_0_0_62.4_158.615 2 62.4 158.615 62.7 158.915
lab I_0_0_61.51_85.49 3 61.51 85.49 61.81 85.79
lab I_0_0_66.65_107.5 1 66.65 107.5 68.65 108.5

Using the cell statement described above, the preceding <library>.ptab file could be more
compactly written as:

lab bounds 0 0 135300 217000

cell lab
I_0_0_61.04_207.555 1 61.04 207.555 61.34 207.855
I_0_0_63.25_182.82 2 63.25 182.82 63.55 183.12
I_0_0_62.4_158.615 2 62.4 158.615 62.7 158.915
I_0_0_61.51_85.49 3 61.51 85.49 61.81 85.79
I_0_0_66.65_107.5 1 66.65 107.5 68.65 108.5

2.3 Power Value File (.pval)

Initial values of power for each of the sources in the <library>.ptab file are specified in the
<cell>.pval file. This is also in ASCII format, and has one or more lines in the following syntax:
<name> <value>
where name is a valid power source descriptor, and value is specified in Watts.
An example .pval file corresponding to the .ptab file listed earlier is shown below.

I_0_0_61.04_207.555 0.00132
I_0_0_63.25_182.82 0.00132
I_0_0_62.4_158.615 0.00132
I_0_0_61.51_85.49 0.00132
I_0_0_66.65_107.5 0

2.4 Model Files

Updates of power values of the sources based on temperature may be done in one of several ways, in the
program flow. Any such method may require one or more model files from you. to enable its use.

2.4.1 Temperature-to-Power Table Lookup

This model employs a simple 1-D table of temperature versus power to calculate the value of power at a
specified temperature. The table data is supplied in a <cell>.tpl file, with the i-th entry in the table for
a source specified using the syntax:
<name> <temperaturei > <poweri >
where name is a valid power source descriptor, and power is specified in Watts. The units of temperature
should be consistent with those used to specify the ambient temperature in the tech file. The number of
lines for each source is the number of data points used to characterize the source over the temperature
range of interest. Obviously, the resolution of the table determines the accuracy of the model.
An example .tpl file corresponding to the .ptab file listed earlier is shown below.

I_0_0_61.04_207.555 0 0.00132
I_0_0_61.04_207.555 100 0.00132

11
 Power Source Files

I_0_0_63.25_182.82 0 0.00132
I_0_0_63.25_182.82 40 0.00136
I_0_0_63.25_182.82 80 0.00139
I_0_0_63.25_182.82 100 0.00140
I_0_0_62.4_158.615 0 0.00132
I_0_0_62.4_158.615 40 0.00136
I_0_0_62.4_158.615 80 0.00139
I_0_0_62.4_158.615 100 0.00140
I_0_0_61.51_85.49 0 0.00132
I_0_0_61.51_85.49 40 0.00136
I_0_0_61.51_85.49 60 0.00139
I_0_0_61.51_85.49 100 0.00140
I_0_0_66.65_107.5 0 0
I_0_0_66.65_107.5 100 0

12
 Technology File

3 Technology File

3.1 Overview

The HeatWave technology file, or "techfile", describes physical properties of the chip and package under
thermal analysis, as well as properties of the environment. The types of properties may be summarized as
follows:

• chip properties: material extents in z, material thermal conductances and power-source identifiers
• package properties: extent and composite conductance in x, y, z.
• environment properties: ambient temperature in x, y, z.

These properties are used in the process of extracting a thermal network from mask-layout shapes.
The default technology file sought by HeatWave upon invocation is gdatech.ini . An arbitrary technology
file may be loaded via heatwave -t <techfile-name>.
Techfile statements are of the following basic types:

• thermal layer definitions and attributes (syntax in Thermal Layer Syntax section)
• optional mask layer declarations
• bond material declarations
• definitions of ambient properties

3.2 Thermal Layer Definition

A thermal layer spans the full extent of the die in x and y, and some continuous interval in z. It’s a horizontal
"slice", which may (optionally) be associated with at most one layout mask layer. Each thermal layer has
an integer index (increasing from 0 as z increases), and a thickness (in m) defining its extent in z above the
previous layer. Layer 0 always starts at z = 0.0m .
The optional mask layer defines the type of "material" present on a given thermal layer.
A given mask layer contains OpenAccess shapes in the design database, which are defined in x and y
(but not z). Where shapes exist on the mask layer (in x and y), there is "material" on the thermal layer
throughout its vertical extent (i.e. z). The "material" has conductivity k and volumetric heat-capacity c.
Where no shapes exist on its mask-layer, the thermal layer is considered to be "not material", with conduc-
tivity k̄ (kbar) and volumetric heat-capacity c̄ (cbar).
If no mask layer is declared for a thermal layer, the entire thermal layer is considered to be made of "not
material" with conductivity k̄ and volumetric capacitance c̄.

3.3 Thermal Layer Syntax

A thermal layer is defined as follows:

index: thermal-layer-name thickness k kbar c cbar mask
where:

• index is a sequentially increasing (with z) integer id from 0

13
 Technology File

• thermal-layer-name is a non-numeric string identifying the thermal layer

• thickness is the layer thickness in meters
• k is "material" conductivity in W/(mK)
• kbar is "not material" conductivity in W/(mK)
• c is "material" volumetric capacitance in J/(m3 K). Required only for transient analysis
• cbar is "not material" volumetric capacitance in J/(m3 K). Required only for transient analysis
• mask is an optional mask layer, defining where on the thermal layer "material" is present.

Example:

# chip thermal model (includes adhesive to package)

# ------------------
#
# z=901u +-----------------------------+
# ^ | channel ~ 1u |
# ^ +-----------------------------+
# ^ | substrate ~ 850u |
# ^ +-----------------------------+
# ^ | adhesive (to pkg) ~ 50u |
# z=0 +-----------------------------+
#
# name thickness k kbar
#-------------------------------------------
0: adhesive 50e-6 50 50
1: substrate 850e-6 90 100 NWELL
2: channel 1e-6 80 100 DIFF

The resulting thermal layer stack is shown in the following figure:

Figure 3: Mask geometries in the thermal layer stack

3.4 Mask Layer

The concept of a mask-layer is central to defining a practical thermal-technology. A mask layer is the name
of a layer in your OpenAccess layout database. The geometries on a mask-layer are used to represent

14
 Technology File

the shapes of physical objects in 3D that will compose your HeatWave thermal model. This is done by
associating one mask-layer (or, if using Tcl, several mask-layers) with a thermal layer. Two-dimensional
shapes on a mask-layer (associated with a given thermal layer) are assigned the thickness you defined
for the thermal layer, which defines them as three-dimensional objects. The material composition of these
3D objects, and that of the "space" outside or between them, is determined by the parameters in your
techfile_thermal_layer definition.

3.5 Mask Layers Declaration

The Mask Layer concept is essential to HeatWave.

The optional mask_layers statement , however, merely affects how layers are ordered in the GUI display
menus, so the declaration below is not essential to HeatWave’s operation, and may be omitted. When
defining a technology procedurally , (e.g. in Tcl) this declaration should be avoided.
Mask layers whose order in the GUI display menus is to be controlled, are declared as follows:
mask_layers <maskname> ... <maskname>
where:

• each <maskname> is interpreted as describing a layer in the die’s stack-up :

pad well diffusion poly contact metal1 via1 metal2 via2 metal3 via3 metal4 via4 metal5 via5 metal6
via6 metal7 via7 metal8
The maskname should refer to a valid OpenAccess layer name in the design database, or be the
empty string (""), indicating no mask-layer. A maskname not found in the database is replaced by "".

The display of mask layers is further described in the HeatWave User Interface Guide.

3.6 Package and Bond Model Declarations

The temperature of the die is determined by the power dissipated by power-sources within the die and by
the heat conduction paths from the die to the ambient. The following figure illustrates the heat conduction
paths from the die to the ambient. Clearly the package and bond wires (for relevant package types) both
provide paths through which heat may escape the die. The package model alone provides reasonable
accuracy in the the computed temperature profile. The bond wire model further adds to the accuracy of
the analysis by enabling computation of temperature variations within the die due to the connectivity to the
bond wire. The availability of bond wire models enables a more accurate analysis of temperature-gradient
sensitive circuits located near bond wire connections to the die.
The following sections provide a description of the data needed and the process used to build a model at
the die boundary, for the heat flow from the die through the bond wires and the package.
The package model and bond or I/O model which follow may be generated using a graphical package-model
calculator, provided in the HeatWave release as the gda_pkgcalc utility. The inputs to, and actions of, the
package-model calculator are among the items described in the following sections.

3.6.1 Bond Model Declaration

The bond model refers to the materials which electrically "bond" the chip to its package. These may be
gold "bond wires", metal "bumps" distributed over the die surface or other connection methods. The bond
declaration models the effect of the heat-conduction path from the metal pad at the surface of the die

15
 Technology File

through the bond wire, lead-frame, package, board and air to the "ambient". The bond declaration models
the effect of the heat-conduction path described above, as a boundary condition at the die surface.

Figure 4: Package model for ’bond’ statement

The techfile bond statement allows a declaration of a composite material conductivity and extent:
bond <mask-layer> <conductivity> <length>
where:

• <mask-layer> is the name of the mask-layer of the highest (largest index) or lowest (smallest index)
thermal layer. Thus bond connections are modelled only at the z+ (top) or z- (bottom) die faces.
The bond material extends out from the die face only where the given <mask-layer> has shapes. Its
"far" end is assumed to be at the appropriate (z+ or z- ) ambient temperature. The shape models
the directed heat transfer path from the die through the bond wire and other materials as described
above.
• <conductivity> is the composite thermal conductivity in W/(mK) of the materials in the heat-conduction
path from the pad through the bond-material to the "ambient". The bond material is attached to shapes
on <mask-layer> at the z+ (top) or z- (bottom) die face. The composite conductivity models material
between the pad and the "far" end of the bond wire to represent the heat transfer path through the
package to ambient (e.g. air) as in the preceding figure. The value of the composite conductivity must
exceed zero.

• <length> is the length in meters of bond material which extends out of the z+ or z- die face, wherever
<mask-layer> shapes exist. The value must exceed zero.

Example: Model a conduction path (through bond wires) with composite conductivity 31 W/(mK) for each
2mm of extent from the top (z+) face of the die. The composite material extends out only where a shape
is defined on the PAD mask-layer (see bond statement below). At the boundary of the chip the this 2mm
of composite material models the heat conduction effect of the bond wire through lead-frame, package,
air etc. The 2mm is an arbitrary length. Thus every via1 shape is extended 2mm "out" of the die and
is modelled as a material with conductivity 31 W/(mK). The "far" end of this material has the z+ ambient
temperature. The composite conductivity modelling the bond-wire heat-conduction is calculated using the
utility gda_pkgcalc, described in the following section.

# chip thermal model (bond wires)

# ------------------
#

16
 Technology File

# name thickness k kbar

#----------------------------------------
0: substrate 0.000500 80 100 NWELL
1: channel 0.0000004 80 80
2: contact 0.000001 150.0 1.0 CONT
3: metal1 0.000001 240.0 1.0 MET1
4: via1 0.000003 150.0 1.0 VIA1
5: metal2 0.000001 244.0 1.0 MET2
6: passiv 0.000006 244.0 1.0 PAD

# mask layer declaration (if any mask-layers exist)

mask_layers PAD NWELL COMP NPLUS PPLUS POLY CONT $\$
MET1 VIA1 MET2

# bond <mask-layer> <conductivity> <length>

bond PAD 31 2e-3

3.6.2 Package Model

HeatWave’s thermal analysis computes the temperature within the die, which is modelled using design and
technology data. Since heat is conducted through the chip boundary, to the package, circuit board, and
surrounding air, the die boundary conditions must be accurately modelled. The ambient materials and
conditions are modelled in these six directions:

Figure 5: Directions used in package-model

At any face of the 6-sided die (chip) the following are specifiable:

• a composite conductivity kamb for materials between the die-face and the ambient
• a length of the composite material lamb

• the ambient temperature tamb in that direction

• a composite volumetric heat capacity camb for all ambient material (including bond wires), that is only
required for transient analysis The syntax of the package model, typically in gdatech.ini (default),
or pkg.ini (when technology is specified in Tcl) follows.

• kamb in W/(mK) and lamb in m, respectively define the composite conductivity, and length of material
extending out at a given boundary. Each of these values must be positive.

17
 Technology File

kamb: kX− kX+ kY − kY + kZ− kZ+

lamb: lX− lX+ lY − lY + lZ− lZ+
tamb: tX− tX+ tY − tY + tZ− tZ+
camb: cX− cX+ cY − cY + cZ− cZ+

Table 1: Basic Package Model Syntax

• camb in J/(m3 K) specifies the composite volumetric heat capacity. It represents the total heat ca-
pacity of the ambient material at a given face i, the material volume being lambi ∗ areai .
• tamb in temperature units (typically ◦ C) defines the ambient temperature at each boundary (die face);
it must exceed Absolute Zero in the scale being used.
• Each definition consists of six numbers representing the appropriate ambient parameter at the chip’s
surface in each of the six directions (x- x+ y- y+ z- z+) as described above.
• The parameter values should be consistent with the lumped thermal resistance (θJA or ψ) of the
package, and the heat transfer coefficient hi , at each die face i. Several methods are recommened
below for generation of the package model, using the package calculator utility gda_pkgcalc, in the
HeatWave release. The die dimensions are required by gda_pkgcalc. In each method the ambient
temperature must be uniform. The thermal resistors mentioned below are accessible using package
modeling software usually available to IC package analysis groups.
1. The first method uses a two thermal resistor model. The side walls of the package are modeled
as near-perfect thermal insulators. The user specifies the thermal resistance from the z+ face to
ambient (Rz+) and from the z- face to ambient (Rz-). Theta_JA of the package is (Rz+ || Rz-),
the effective resistance of the 2 resistors in parallel. The package calculator computes the kamb
and lamb values described above from the Rz+ and Rz- resistor values.
2. The second method requires (θJA or ψ) and the relative heat-flow (e.g. percentage) or heat
tranfer coefficient h through the z- face and through the z+ face of the die. The reciprocals of
these heat-transfer coefficients (h), together with (θJA or ψ), are input to the package calculator,
which computes values for kamb and lamb. This method is an alternative for users who cannot
obtain values for Rz+ and Rz- .
3. The third method requires six thermal resistors (Rx- Rx+ Ry- Ry+ Rz- Rz+) which are used
by the package calculator utility or script to compute kamb and lamb.
4. The fourth method requires (θJA or ψ) and heat transfer coefficients h (as described in the second
method) in all six directions. The reciprocals of these heat-tranfer values, together with (θJA or
ψ), are provided to the package calculator, which computes values for kamb and lamb. This
method is an alternative for users who cannot obtain resistance values in each direction.
• With any of the above package-calculation methods, the heat-transfer due to the presence of bond
wires may be modelled. This requires the effective resistance from the die surface touching the
bond wire, to ambient (derived from a package modeling tool) or the relative heat-flow (i.e. a ratio or
percentage) indicating what fraction of the total heat escapes through the bond-wires. In combination
with the input-data for any methods above, this data is used by the package calculator to generate
kamb, lamb and bond statements.

• The above models are constructed with uniform ambient temperatures in all directions. Once such
models (i.e. kamb and lamb) are built, the ambient temperature tamb may be defined as non-uniform
in the technology file. In this case, the die temperature computation includes the effect of the non-
uniform ambient temperatures on the package (θJA or ψ), resulting in a (θJA or ψ) which is dependent
on die temperature.

Example: package model syntax

18
 Technology File

# define a package with typical (0.125) conductivity

# and 2mm of material in the x-, y-, x+, y+ and z+
# directions. In the z- direction, a 1mm piece
# of metal (conductivity 250W/mK) is modelled.
#
# name x- x+ y- y+ z- z+
#--------------------------------------------------
kamb: 0.125 0.125 0.125 0.125 250 0.125
lamb: 2e-3 2e-3 2e-3 2e-3 1e-3 1e-3

# if undefined, tamb is 25 Celsius in all directions

Example: orthotropic ambient temperature model syntax

# define a package whose upper ambient temperature is

# 20 Celsius, with all other directions at 25 Celsius
#
# name x- x+ y- y+ z- z+
#--------------------------------------------------
tamb: 25 25 25 25 25 20

3.6.3 Boundary Heat Transfer Coefficients

Geometries (polygons) on masks in your design may be used to apply specified heat transfer coefficients
at the top or bottom domain boundaries.
At either or both of the z- (bottom) or z+ (top) faces you may specify a list of mask-names and heat transfer
coefficient(htc) values. The htc value is specified in W/(m2 K). Any geometry on a specified mask causes
that mask’s htc value to be applied at the z- or z+ face specified.
Overlapping geometries on htc mask-layers are handled as follows. At either face, if multiple geometries
on distinct masks overlap, the htc values for the overlapping regions are the sum of the htc values of the
distinct masks containing the overlapping geometries. This only applies to geometries on multiple masks.
Multiple overlapping geometries on the same mask simply result in that mask’s htc value being applied in
the overlap region.
For regions without any geometries, a required background htc value htc_bkgnd takes effect. Where
geometries do exist, the htc_bkgnd value has no effect.
The htc value results in an effective thermal resistance extending out of each point on the z+ or z- face. At
the other end of this resistance, the kamb , lamb and tamb parameters take effect. At the z- or z+ faces,
the htc specification is typically combined with an isothermal condition, where kamb is large (e.g. 1e9),
lamb is small (e.g. 1e-9) and tamb is the isothermal temperature.
The syntax of the htc declaration is summarized in the "htc specification syntax" table. The first word must
be htc: including the colon. The second word must specify one of the horizontal faces, z- or z+ . The third
value htc_bkgnd specifies the background heat transfer coefficient in W/(m2 K) as described above. This
is followed by an even number of space-separated mask-name htc-value pairs that specify the OpenAccess
mask-layer names and respective heat-transfer coefficients to be applied at the specified face.
The heat transfer coefficients are always non zero positive values. If two masks on a boundary layer overlap,
their heat transfer coefficient values are added to determine the resultant htc values.
Example:

# Define boundary conditions that use mask-layers from the design to specify varying

19
 Technology File

htc: z+ htc_ mask1 htc1 mask2 htc2 ... mask n htc n

bkgnd
htc: z- htc_ mask1 htc1 mask2 htc2 ... mask n htc n
bkgnd

Table 2: htc specification syntax

# boundary conditions at the horizontal faces of the domain.

# Geometries on each mask-layer represent distinct heat transfer coefficients
# that are in effect as boundary conditions.
#
#keyword face htc_bkgnd mask1 htc1 mask2 htc2 ... etc.
#
htc: z+ 1e-3 BUMP 5e3 RDL1 1e3
htc: z- 1e-3 BUMP 5e3 RDL1

3.7 Complete Example

Following is a thermal layer stack definition for a fictitious single-poly digital CMOS process:

Figure 6: Thermal layer stack in techfile

This structure is described by the following techfile:

# name thickness k kbar mask

20
 Technology File

#--------------------------------------------
0: adhesive 0.000050 100 100
1: bsubstrate 0.000850 120 120
2: tsubstrate 0.000150 80 120 NWELL
3: channel 0.0000001 80 1.4 DIFF
4: poly 0.000001 100 1.4 POLY
5: contact 0.000001 150 1.4 CONT
6: metal1 0.000001 400 1.4 MET1
7: via1 0.000001 150 1.4 VIA1_2
8: metal2 0.000001 400 1.4 MET2
9: via2 0.000001 150 1.4 VIA2_3
10: metal3 0.000001 400 1.4 MET3
11: via3 0.000001 150 1.4 VIA3_4
12: metal4 0.000001 400 1.4 MET4
13: via4 0.000001 150 1.4 VIA4_5
14: metal5 0.000001 400 1.4 MET5
15: via5 0.000001 150 1.4 VIA5_6
16: metal6 0.000001 400 1.4 MET6
17: via6 0.000001 150 1.4 VIA6_7
18: metal7 0.000001 400 1.4 MET7
19: via7 0.000001 150 1.4 VIA7_8
20: metal8 0.000001 400 1.4 MET8
21: pad 0.000002 400 1.4 PAD

# mask layer declaration (if any mask-layers exist)

mask_layers PAD NWELL DIFF POLY CONT $\$
MET1 VIA1_2 MET2 VIA2_3 MET3 VIA3_4 $\$
MET4 VIA4_5 MET5 VIA5_6 MET6 VIA6_7 $\$
MET7 VIA7_8

# bond <mask-layer> <conductivity> <length>

bond PAD 10 1e-3

# kamb = ambient conductivity W/(K*m)

# lamb = length of thermal resistor m
# tamb = ambient temperature deg Celsius
#
# model package with 2mm approx. adiabatic sides,
# resistive z+, conductive z-, each 1mm
#
# name x- x+ y- y+ z- z+
#--------------------------------------------------
kamb: 1e-10 1e-10 1e-10 1e-10 2.0 0.125
lamb: 2e-3 2e-3 2e-3 2e-3 1e-3 1e-3
tamb: 25 25 25 25 25 25

3.8 Temperature Dependent Conductivity

HeatWave’s thermal analysis takes into account the variation of material thermal conductivity with tem-
perature , resulting in improved accuracy and correlation with measured data. The variation of thermal
conductivity with the temperature of the material in the thermal layers may be described in the form of look-
up tables in a file with the same prefix as the techology file, but with a .tkl extension. This file is loaded
immediately after the tech file if it is present in the data directory.
The .tkl file is in ASCII format and contains table lookup data for thermal conductivity. Each point in a
table is specified using the following syntax:

21
 Technology File

<name> <temperaturei > <thermal_conductivityi >

where name is the name of the table. The units of temperature and thermal_conductivity should
be consistent with those used in the tech file. The number of lines for each table is the number of data
points used to characterize the variation of thermal conductivity over the temperature range of interest. The
resolution of the table determines the accuracy of the model.
The association of a table model of thermal conductivity variation with a thermal layer is made using one or
more lines with the following syntax:
use k|kbar <name> <layer1> <layer2> ...
where name is the name of a look-up table defined earlier in the file, and layer1, layer2 are the names
of thermal layers in the thermal stack. The keyword k or kbar must be specified to indicate which of the
thermal conductivities associated with the specified thermal layers is to ebe modeled using the table. One
or more thermal layers may be specified to use the same table model.
A complete example of a .tkl file follows:

siliconTable 25 156.1425
siliconTable 40 146.2506
siliconTable 55 137.4056
siliconTable 70 129.4560
siliconTable 85 122.2778
siliconTable 100 115.7683
siliconTable 115 109.8419
siliconTable 130 104.4268
siliconTable 145 99.46221
siliconTable 160 94.89642
siliconTable 175 90.68520
siliconTable 190 86.79047
siliconTable 205 83.17932
siliconTable 220 79.82315
use kbar siliconTable bsubstrate tsubstrate

The updating of thermal conductivity is may be controlled by any of the following:

• specifying an additional parameter k_update_iter in the mesh initialization file

• writing a script to set Mesh Var k_update_iter
• using the Incr Conductivity option in the Analyze menu in the graphical user interface, as described in
the HeatWave User Interface Guide.

3.9 Orthotropic Conductivity

HeatWave can now thermally simulate materials whose thermal conductivity may be modeled as or-
thotropic.
A common case of orthotropic conductivity is when in-plane conductivity (kx= ky) is distinct from cross-
plane conductivity kz. A thermal layer composed of such an orthotropic material may be modeled by using
adjacent horizontal layers made of distinct isotropic materials.
Let us consider a requirement. You need to model a 100um thick graphite thermal layer with orthotropic
thermal conductivity. This thermal layer consists of a mask GRAPHITE of material graphene.

# {thermallayername thickness(m) bkgnd-material {mask1 material1}}

set layerList
"
graphite 100e-6 Air {GRAPHITE graphene}
"

22
 Technology File

The solution to this requirement is to replace the thermal layer with a stack of three thermal layers in the
tech file as follows:

1. 15um (upper graphite layer)

2. 70um (middle graphite layer)

3. 15um (lower graphite layer)

Here, the middle graphite layer (#2) has a small conductivity, K1, to model poor cross-plane conduction. The
other graphite layers (#1 and #3) have a large conductivity, K2, to model high in-plane conduction. This also
adds two materials, namely, graphene1 and graphene2, with thermal conductivity K1 and K2 respectively,
computed from Kxy (in-plane conduction) and Kz (cross-plane conduction).
Now, you can replace the 100um graphite thermal layer with three thermal layers in the layerList as follows:

# {thermallayername thickness(m) bkgnd-material {mask1 material1}}

set layerList
"
graphite_l 15e-6 Air {GRAPHITE graphene1}
graphite 70e-6 Air {GRAPHITE graphene2}
graphite_u 15e-6 Air {GRAPHITE graphene1}
"

There are two methods to achieve this configuration automatically. Both the methods work additively when
used together. If there is a layer name conflict, the conflicting layers configuration in the method 2 is ignored.
In both the methods,

• graphite is name of the thermal layer to be split,

• graphene is name of the material with orthotropic thermal conductivity on the thermal layer,
• 700 is the Kxy value and 6 is the Kz value, and

• 0.7 is the ratio of thickness of middle layer to the total thickness of graphite thermal layer.

1. Define a TCL procedure gdOrthotropicLayers to return the specification used to split the orthotropic
thermal layers. These specifications are referred to here as orthotropicLayerSpecs:

proc gdOrthotropicLayers { } {
set orthotropicLayerSpecs
{
{ graphite graphene 700 6 0.7 }
};
return $orthotropicLayerSpecs
}

2. Create an orthotropic_layers.ini file in the thermal directory with orthotropic thermal layer specs as
follows:

graphite graphene 700 6 0.7

The temperature dependent conductivity is not supported with this feature.

23
 Mesh Initialization File

4 Mesh Initialization File

4.1 Overview

The HeatWave mesh initialization file (abbreviated "meshfile") allows the user to control the discretization,
and consequently, the spatial resolution of the temperature solution.
The default mesh initialization file read by HeatWave upon invocation is gdamesh.ini. An arbitrary mesh-
file may be loaded by specifying the command line option heatwave -i <meshfile-name>.

4.2 Syntax

The meshfile is in ASCII format with the following simple syntax:

<parameter_name> <value>
Lines starting with the "#" symbol are considered comments and are ignored. Trailing inline comments
can also be used if preceded by the "#" symbol or C++-style identifiers ("//"). A sample meshfile is shown
below:

initial_seed 1
reseed_iter 2 // successively reseed this number of times
reseed_pwr_grad 1e2 // sets power gradient threshold for splitting
refine_iter 0 // successively refine this number of times
refine_temp_grad 5e-6 // determines how many refine_iter splits occur
refine_temp_value 0.25 // determines when refine_iter may split
pwr_update_iter 0 // electro-thermal iteration-count
k_update_iter 0 // thermal conductivity update iteration-count

4.3 Parameters

4.3.1 initial_seed

This parameter is one or two positive, integer values that specify the initial discretization in the x and y
directions respectively. If only one value is specified, the same value is applied to both directions. This
translates to 2initial_seed uniformly spaced elements along the x and y axes, and determines the initial
spatial resolution. Note that this resolution is maintained across all layers in the design. An example of a
die with an initial seed of 2 is shown below:

24
 Mesh Initialization File

Figure 7: Mesh due to initial_seed 2

The default value is 5.

4.3.2 resolution

An alternate method of specifying the initial mesh seed is as one or two positive non-zero real-valued
parameters that specify the spatial resolution (in meters) in the x and y directions respectively. If only one
value is specified, the same value is applied in both directions. The resulting mesh-seed value will override
any value(s) of initial_seed that may also be specified. By default, the variable is inactive.

4.3.3 reseed_iter

This parameter is as described in the section reseed_iter

This is the first phase of the adaptive mesh generation scheme, and is designed to improve resolution of the
temperature, in areas where power gradients are high. Subsequent mesh refinements are driven by other
parameters discussed below.

4.3.4 reseed_pwr_grad

This parameter is as described in the Scripting Primitives section on reseed_power_grad.

4.3.5 refine_iter

This parameter is as described in the Scripting Primitives section on refine_iter.

4.3.6 refine_temp_value

This parameter is as described in the Scripting Primitives section on refine_temp_value

25
 Mesh Initialization File

4.3.7 refine_temp_grad

This parameter is as described in the Scripting Primitives section on refine_temp_value It is used to deter-
mine the number of splits of an element during the refinement phase (see refine_iter).

4.3.8 pwr_update_iter

This parameter is as described in the Scripting Primitives section on power_update_iter

4.3.9 k_update_iter

This parameter is as described in the Scripting Primitives section on k_update_iter

26
 Electrical Solvers

5 Electrical Solvers

5.1 Overview

• Electrical Solver Interfaces

• Table lookup
• ADS Interface: setup, hw_ads script, data preparation
• Eldo Interface: setup, hw_eldo script, data preparation, Eldo Premier

• FineSim Interface: setup, hw_finesim script, data preparation

• HSPICE Interface: setup, hw_hspice script, data preparation
• Spectre Interface: setup, hw_spectre script, data preparation
• Ultrasim Interface: setup, hw_ultrasim script, data preparation

HeatWave typically needs to interface with an electrical solver (abbreviated ESolve), to obtain the power
dissipated by instances in your design. The power dissipated by an instance may be significantly dependent
on the temperature. In such cases the solver that produces the power-values (typically a circuit-simulator or
power-analysis tool) may need to be updated with an instance-specific temperature, in an "electro-thermal"
loop, as shown in the figure below. This loop iterates until the temperature and power are mutually consis-
tent.

Figure 8: Electro-thermal loop

The electrical solver (ESolve) computes power dissipated by each instance. If the electrical-solver is a circuit
simulator, please ensure the simulator’s device-models properly consume instance-specific temperatures,
and accurately compute the dissipated power. In may cases, circuit simulator models ignore instance-
specific temperature, or the power-reporting functions have not been fully verified.
The electrical-solver’s results are used to update power-source power values based on temperature as
part of the HeatWave thermal simulation flow. Power for each source is obtained by simulating the design
annotated with the latest temperature values, using user-provided stimuli where needed.

5.1.1 Implementation

The electrical solver interfaces currently implemented are

27
 Electrical Solvers

• Table lookup that stores a table of power dissipated by a given instance (power source) over a range
of temperature values described further in the Temperature to Power Table Lookup section.
• ADS Interface to Keysight’s ADS circuit simulator described further in the ADS Interface
section.
• Eldo Interface to the Eldo circuit simulator described further in the Eldo Interface section.
• FineSim Interface to the FineSim circuit simulator described further in the FineSim Interface
section.
• HSPICE Interface to the HSPICE circuit simulator described further in the HSpice Interface
section.
• Spectre Interface to the Spectre circuit simulator described further in the Spectre Interface
section.
• Ultrasim Interface to the Ultrasim circuit simulator described further in the Ultrasim Interface
section.

Each solver has its own set of variables, for several reasons:

• the configuration requirements for each simulator vary, so one set of variable names is not adequate.
Wherever possible, the semantics of variables are the same.
• you may wish to change solver_type and it is convenient for your CAD department, or whoever sets
up the initialization file, to define the variables for all simulators, and simply change solver_type later,
if needed
• multiple electrical solvers may be run, as described below

As described in the Multiple Electrical Solvers section it is possible to run a sequence of these individual
electrical solvers or ESolves in a single electrical solve phase. Such a sequence might be needed if, for
example, you use table-based models to model macro-cell or block powers as a function of temperature,
and you use circuit simulators such as Spectre or Eldo for device-level simulation to obtain power dissipated
in designed or parasitic devices.
Back to Overview of Electrical Solvers

5.1.2 Electrical Solver Initialization File

An optional electrical solver initialization file specifies the type of electrical solver and defines its config-
uration variables, for use in HeatWave. The default filename sought by HeatWave is gdaesolve.ini.
If it does not exist, a second default named gda_sim.ini is sought. You may specify the name of this
initialization file using the HeatWave -e <filename> option. Parameters defined in this file should have no
leading spaces (i.e. start at the beginning of each line); if such spaces exist, the parameter definition is
ignored.
Back to Overview of Electrical Solvers

5.1.3 Instance Cross-Reference File <cellname>.gdai

In general, an instance-name in the Cadence name-space (e.g. from an extracted-view) as used in the
<libname>.ptab file, is translated to each simulator’s name-space, and may end up appearing quite
different. The rules for this translation can be complex, and vary over time, so they are not encoded in
HeatWave.

28
 Electrical Solvers

However, for circuit simulators (such as Spectre or Eldo), HeatWave’s interface to Virtuoso automatically
creates a cross-reference file named <cellname>.gdai in HeatWave’s run-directory for circuit simulation
(e.g. spectre/ or eldo/). A distinct <cellname>.gdai file is needed for each simulator.
The <cellname>.gdai file for a given simulator contains comments prefixed by # , and consists of lines
of the form:
<inst_name_in_simulator > <inst_name_in_extracted_view>
where the first field is the full instance-name in the particular simulator (e.g. Spectre or Eldo) and the second
is the full name in the Cadence name-space (e.g. a test-bench containing an extracted-view).
If you do not use the HeatWave interface to Virtuoso, you will need to create this cross reference file, so
HeatWave can correctly identify instances in the netlist used by each circuit simulator.
The <cellname>.gdai file is needed by the scripts that control the setup and execution of a circuit simulator,
such as spectre_script or eldo_script. Instance-names vary considerably between simulators, as seen in
the .gdai examples for Eldo and Spectre (the .gdai file for other simulators is similar), provided below

# Excerpt from a typical Eldo .gdai file:

# format:
# # precedes comments
# <Eldo_name> <extracted_view_name>
#
XIL1234.XI1|I23|D1 /Il1234/I1|I23|D1
XIL1234.DI1|I45|D2 /Il1234/I1|I45|D2
XIL1234.DI1|D3 /Il1234/I1|D3
XIL1234.XIBLK|IPWR|MX@123 /Il1234/IBLK|IPWR|MX@123

# Excerpt from a typical Spectre .gdai file:

# format:
# # precedes comments
# <Spectre_name> <extracted_view_name>
#
Il1234.I1|I23|D1 /Il1234/I1|I23|D1
Il1234.DI1|I45|D2 /Il1234/I1|I45|D2
Il1234.DI1|D3 /Il1234/I1|D3
Il1234.IBLK|IPWR|MX@123 /Il1234/IBLK|IPWR|MX@123

At present the <cellname>.gdai file is not required by ads_script, and is not used anywhere within the
ADS Interface
Back to Overview of Electrical Solvers

5.2 Electrical Solver Interfaces

An optional electrical solver initialization file specifies the type of electrical solver and its configuration.

• solver_type may be one of table, ads, eldo, finesim, hspice or spectre.

The default solver is table. It is possible to specify multiple solver_type declarations in the Electrical Solver
Initialization File as discussed in the Multiple Electrical Solvers section.
Each of the remaining variables is relevant to a particular solver_type. All pathnames specified as relative
are interpreted with respect to the directory in which HeatWave was invoked.

29
 Electrical Solvers

The variables specifiable in the Electrical Solver Initialization file for each solver are summarized in the
following sections:

• variables for Temperature to Power Table Lookup

• variables for ADS Interface

• variables for Eldo Interface
• variables for FineSim Interface
• variables for HSPICE Interface

• variables for Spectre Interface

• variables for Ultrasim Interface

Back to Overview of Electrical Solvers

5.3 Temperature to Power Table Lookup

This implementation is selected if the Electrical Solver initialization variable solver_type is set to "table".
Power dissipated by the instance at an arbitrary temperature is determined by linear interpolation between
points (or linear extrapolation at table "edges"), depending on the smallest table interval containing the
arbitrary temperature. The lookup table data is stored in a temperature-to-power lookup (.tpl) file whose
location may be specified by table_file. If an instance is not found to have any lookup-table data, its power
value is unchanged by the electrical solver.
The Electrical Solver Initialization file variables relevant to solver_type "table" are listed below.

• table_file specifies a temperature-to-power lookup data filename. Default <cellname>.tpl

• table_script specifies the name of a user-defined executable, typically a script, that HeatWave will
invoke after the temperature-to-power lookup table (if any) has been used to modify and write power
values. This script may read temperatures from .<cellname>.tval and write new power val-
ues as needed to .<cellname>.pval . HeatWave invokes table_script with one argument,
<cellname> . The default value of table_script is an empty string (i.e. no script).

Back to Overview of Electrical Solvers

5.4 ADS Interface

This implementation is selected if the Electrical Solver initialization variable solver_type is set to "ads".
Power dissipated by each source at the temperature last computed by HeatWave’s thermal simulation is
obtained from Keysight’s ADS circuit simulator
The user is assumed to have a basic working knowledge of ADS.
The Electrical Solver Initialization file variables relevant to solver_type "ads" are listed below.

• ads_script string name of the script that will be invoked to run ADS, analyze its output and update
instance powers for the next iteration of thermal simulation. The script must handle all options of
hw_ads as described in the ADS Invocation Script hw_ads "hw_ads script" section Default script is
"hw_ads"

30
 Electrical Solvers

• ads_netlist string name of the netlist on which the ads_script will invoke Keysight’s ADS
circuit simulator. This netlist must be prepared as described in the ADS Data Preparation sec-
tion for use in the HeatWave interface. The recommended ADS netlist-name is ../netlist.log , where
the path is relative to the directory in which HeatWave is run. Default ../netlist.log
• ads_command quoted string name of the shell command the ads_script will use to invoke ADS,
in the circuit simulation run-directory. So, relative pathnames specified in ads_command are relative
to the circuit simulation run-directory (usually ../). The default value of this variable is "adssim ". The
netlist name in ads_netlist will be appended to this string by the ads_script, so it must not be
present in this string.
• ads_dir string name of the path to the directory in which ADS will be run. If a relative pathname
is provided, it is relative to the directory in which HeatWave is invoked. Default ../ (relative to the
HeatWave run-directory).
• ads_log string name of top-level logfile to which the ads_script will write. This is not the same as
the logfile written by the ADS simulator. Default "ads_flow.out"

A simulation run-directory ../ (relative to the HeatWave run directory) in which ADS may be invoked by
applying ads_command to ads_netlist without errors, should be prepared.
Using the values in the Electrical Solver initialization file ADS is invoked, temperatures from HeatWave’s
thermal simulation are read by the ADS simulator, simulation is run and power values are output in the
.<cellname>.pval file read by HeatWave during the next iteration of thermal simulation.
At the end of a transient thermal simulation plots of instance temperature or power over time may be made
from the solution and mesh archives saved by HeatWave. After steady-state thermal simulation, the final
instance temperatures and powers, and mesh archive, may be saved.

5.4.1 ADS Setup

Using the default Electrical Solver initialization settings with solver_type set to "ads" the following are needed

• run directory ../ (relative to HeatWave run directory) containing the ADS netlist specified by ads_-
netlist (typically netlist.log)

• the user’s path must be set to find ads_script (default hw_ads). Typically, this means including $GDA_-
ROOT/wrap or $GDA_ROOT/bin in the path.
• the user’s path should include the location of Keysight’s ADS executable

With the conditions above met the ADS simulator will be invoked to obtain power given the temperature
profile last computed in thermal simulation.
Back to Overview of Electrical Solvers

5.4.2 ADS Invocation Script hw_ads

An executable, hw_ads , that accepts the control variables above to setup, run ADS and obtain device
powers, is provided by HeatWave. Its location is specifiable using ads_script.
Under the following assumptions ...

• netlist is error free, ready for ADS simulation

31
 Electrical Solvers

• instances in the ADS netlist have the same names as the power sources defined in HeatWave’s
<libname>.ptab file.
... the script will invoke ADS and obtain power-source powers from the results

Any script that accepts the switches below and performs the same basic operations (netlist setup, ADS
invocation, power reporting) may be used in place of hw_ads Details (current switch settings, defaults,
examples, assumptions) may be obtained by invoking hw_ads without arguments.
Example: [Note that "..." indicates text deleted for brevity]

Usage[v...]: ads.pl [OPTIONS] <cell>

INPUTS:
<cell> name of cell to be simulated

OUTPUTS:
.<cell>.pval HeatWave pval (power values)
Format:
# comment
<power-source-name> <power>

OPTIONS : -l error/warning/info logfile [ads_flow.out]

-n ADS netlist path from . [../netlist.log]
-r ADS run command (no netlist) [adssim ]
-d relative path to ADS run-dir [..]

If environment variable "HW_SKIP_SIM" is defined, and

contains the word "ads", the electrical simulation
is skipped. Post-simulation result traversal *is* attempted.

If script "hwpre" exists in the simulation run-directory

it will be run before the simulation is launched.

If script "hwpost" exists in the simulation run-directory

it will be run after the simulation is completed, and after power
values are written to the <cellname>.pval file.

Back to Overview of Electrical Solvers

5.4.3 ADS Data Preparation

• the ads_netlist must be ready for use with the specified ads_command.
• your netlist must define a global temperature, consistent with the temperature specified by you in the
package model for HeatWave. This ensures consistency between temperatures in the thermal and
electrical simulations.

Back to Overview of Electrical Solvers

32
 Electrical Solvers

5.5 Eldo Interface

This implementation is selected if the Electrical Solver initialization variable solver_type is set to "eldo".
Power dissipated by each source at the temperature last computed by HeatWave’s thermal simulation is
obtained from the Eldo circuit simulator The user is assumed to have a basic working knowledge
of Eldo.
The Electrical Solver Initialization file variables relevant to solver_type "eldo" are listed below.

• eldo_script string name of the script that will be invoked to run Eldo, analyze its output and update
instance powers for the next iteration of thermal simulation. The script must handle all options of
hw_eldo as described in the Eldo Invocation Script hw_eldo "hw_eldo script" section Default script is
"hw_eldo"
• eldo_netlist string name of the netlist on which the eldo_script will invoke the Eldo circuit
simulator This netlist must be prepared as described in the Eldo Data Preparation section for
use in the HeatWave interface. It is strongly recommended that you rename your Eldo netlist to
eldo/input.cir . Default eldo/input.cir
• eldo_subckt string name of the subcircuit in which the eldo_script searches for instances
(power-sources) whose temperature is annotated and whose power-dissipation is measured. Default
<cellname>
• eldo_command quoted string name of the shell command the eldo_script will use to invoke Eldo,
in the circuit simulation run-directory. So, relative pathnames specified in eldo_command are relative
to the circuit simulation run-directory (usually eldo/).
Default "eldo -noconf -b -silent -outpath . -o eldo.out "
The netlist name or Eldo Interactive Language script-name (.eil file), and related switches (-i or -eil)
will be appended by the eldo_script, so they must not be present in this string.

• eldo_pwr string name of the Eldo output file that reports the average power for each instance (pow-
ersource). To make Eldo report the average power per instance in a transient simulation, add a
command to your Eldo netlist, like
.extract tran -r average(pow(IX.∗)),
replacing IX with the actual instance-name of the extracted-view in your netlist. The output will appear
in Eldo’s ∗.chi file and in the output logfile. If you specify ".option aex ..." in your netlist, Eldo
will additionally output a ∗.aex file, that you may use instead of the ∗.chi file. By default, ".option
aex ..." is assumed to be specified. Yet another alternative is to specify the output logfile, that
should contain the average power report. Default "eldo/<cellname>.aex"
• eldo_log string name of top-level logfile to which the eldo_script will write. This is not the same
as the logfile written by Eldo. Default "eldo_flow.out"

A simulation run-directory in which Eldo can be invoked with eldo_command on eldo_netlist without errors
should be present. The eldo_netlist must be prepared for use with this interface as indicated in the Eldo
Data Preparation section.
Using the values in the Electrical Solver initialization file Eldo is invoked, temperatures from HeatWave’s
thermal simulation are annotated into the eldo_netlist, simulation is run and power values are read from the
eldo_pwr simulation output, for use in the next iteration of thermal simulation.
At the end of the steady state or transient thermal simulation a single ∗.wdb file is available, containing the
concatenated waveforms from all the circuit-simulation runs. Plots of instance temperature or power over
time may be made from the solution and mesh archives saved by HeatWave. After steady-state thermal
simulation, the final instance temperatures and powers, and mesh archive, may be saved.

33
 Electrical Solvers

5.5.1 Eldo Setup

Using the default Electrical Solver initialization settings with solver_type set to "eldo" the following are
needed

• run directory eldo containing netlist input.cir The eldo_command string should be carefully set
to specify search-paths or special usage modes as required.
• eldo_netlist input.cir must be prepared as indicated in the Eldo Data Preparation section.
• the user’s path must be set to find eldo_script (default hw_eldo). Typically, this means including
$GDA_ROOT/wrap or $GDA_ROOT/bin in the path.
• the user’s path should include the location of Mentor Graphics’ eldo executable

With the conditions above met, and a HeatWave run-directory set up as described and exemplified in this
manual, the Eldo simulator will be invoked to obtain power, given the temperature profile last computed in
thermal simulation.
Back to Overview of Electrical Solvers

5.5.2 Eldo Invocation Script hw_eldo

An executable, hw_eldo , that accepts the control variables above to setup, run Eldo and obtain device
powers, is provided by HeatWave. Its location is specifiable using eldo_script.
Under the following assumptions ...

• netlist is error free, ready for Eldo dc or transient simulation

• extracted devices are one level below the top level in the netlist e.g. extracted device M25 is named
I∗.M25
• extracted devices are in the subcircuit specified to hw_eldo via the -s switch. By default this name,
specified in eldo_subckt, is the same as <cellname>
• eldo_command and your netlist are setup to produce a report of average powers for instances within
extracted-cell, in the filename you specified for eldo_pwr. Please ensure the Eldo run produces log
messages in "eldo.out" (not the same as eldo_log)
... the script will invoke Eldo and obtain power-source powers from the results

Any script that accepts the switches below and performs the same basic operations (netlist setup, Eldo
invocation, power measurement) may be used in place of hw_eldo Details (current switch settings, defaults,
examples, assumptions) may be obtained by invoking hw_eldo without arguments.
Example: [Note that "..." indicates text deleted for brevity]

Usage[v...]: hw_eldo [OPTIONS] <cell>

INPUTS:
<cell> name of cell to be simulated

OUTPUTS:
.<cell>.pval HeatWave pval (power values)
Format:
# comment
<power-source-name> <power>

34
 Electrical Solvers

OPTIONS : -l error/warning/info logfile [eldo_flow.out]

-n eldo netlist path from . [eldo/<cell>.cir]
-p eldo dc/trans power summary (chi) [eldo/<cell>.chi]
-s eldo subckt to analyze [<cell>]
-m max temp increase (C) on a device [250 Celsius]
-w temperature-rise parameter name [T]
-f for devices in given file replace []
or add "T=" in netlist and
write to stdout; skip eldo run.
file format: (one name per line)
<power-source-name> [... ignored]
-c [no arg] checks netlist power-srcs [0]
-r eldo run command (no netlist) [eldo ... -silent -o eldo.out ...]
-d relative path to eldo run-dir [eldo]

If environment variable "HW_SKIP_SIM" is defined, and

contains the word "eldo", the electrical simulation
is skipped. Post-simulation result traversal *is* attempted.

If the Eldo instance-temperature parameter is set to "DTEMP",

(see -w) the temperature *difference* (to global TEMPER) is
annotated on to each instance

If script "hwpre" exists in the simulation run-directory

it will be run before the simulation is launched.

If script "hwpost" exists in the simulation run-directory

it will be run after the simulation is completed, and after power
values are written to the <cellname>.pval file.

TRANSIENT THERMAL-SIMULATION:

If file hwtranopts.inc exists in the Eldo run directory, it is

included in the netlist and takes effect before the power
computation for each thermal time-step.

If files hw_start.iic and hw_wdb.wdb *both* exist in the

Eldo run directory, and the start-time is > 0, initial
conditions are read from them by the first Eldo simulation,
before transient thermal simulation.

EXAMPLE 1. hw_eldo -n eldo/input.cir -p eldo/eldo.aex -l myCell.log myCell

simulates eldo/input.cir with temperatures in .myCell.tval
to produce powers in .myCell.pval with messages in myCell.log
EXAMPLE 2. hw_eldo -n orig/input.cir -f myLib.ptab myCell >&! input.cir
produces a new input.cir by modifying the original,
orig/input.cir, as described above.

ASSUMPTIONS: ...

Back to Overview of Electrical Solvers

35
 Electrical Solvers

5.5.3 Eldo Data Preparation

The eldo_netlist must be prepared for temperature annotation of each powersource with the following

• the global simulation temperature value must be the ambient temperature used in thermal simulation,
e.g. tnom= <ambient_temp> must be specified. This ensures consistency between temperatures
in the thermal and electrical analyses.

• simulations must .plot at least one waveform, in a .wdb waveform file in the simulation run-directory.
• Eldo Interactive Language or EIL, is activated by the -eil option to Eldo. Despite its name EIL is
executable in batch mode. EIL is used to define parameters relevant to the electro-thermal loop.
Please ensure the Eldo Interactive Language feature is usable in your installation. If you specify the
-premier switch in your eldo_command, then EIL is not used, since Eldo Premier does not support
EIL.
• your netlist must define a global temperature, e.g. .option TNOM=27, consistent with the tempera-
ture specified by you in the package model for HeatWave.
• all instances for which thermal annotation is desired, that support the Eldo T parameter must have
T=parameter-name or a similar parametrized expression in their declaration. The hw_eldo script
can output a temperature (T) annotated version of a given netlist as described below The DTEMP
parameter may be specified instead of T using hw_eldo ... -w DTEMP ... , in which case it
is understood to be a temperature difference.
• include ../.<cellname>.tval.eldo must be present at the head of the eldo_netlist where
cellname is the name of the cell under thermal simulation. The ../.<cellname>.tval.eldo
file sets temperatures on instances (devices) in the Eldo netlist and is produced by the hw_eldo
script
• if your eldo_command contains -define HW_EIL_TEMP, temperature parameters are set in the EIL
file HeatWave creates to run Eldo, using the syntax below:
set <inst-name>.T=<temperature-expression> where T is the instance-specific-
temperature parameter. Otherwise temperatures are set using HW_T... parameters. In general, you
should not need to set this switch.
• in AMS version 12.2 or later RC-reduction is performed by default on a netlist when it is saved by Eldo.
Later the saved netlist is not compatible with the original netlist during a re-start of Eldo, resulting
in a failed Eldo simulation. To avoid such failures, you must specify either .option reduce_-
activation=0 or .option premier_mode=1 within your Eldo netlist.

The insertion of temperature parameters, and of control commands needed by HeatWave, may be done
automatically by using a special mode of eldo_script (default hw_eldo)
hw_eldo -n <orig_netlist> -f <inst_file> <cell> writes a new netlist, ready for thermal an-
notation, to stdout
where

• orig_netlist is the name of the original Eldo netlist with any T=... statements removed
• inst_file list all instances (power-sources) to be annotated, one name per line. A file in Heat-
Wave’s ptab or pval formats is also accepted

• cell is the name of the cell under thermal analysis. A subckt with this name (or a name specified
using -s) must exist in orig_netlist

36
 Electrical Solvers

Example:
hw_eldo -n orig.cir -f insts.txt myCell >&! input.cir
writes a modified version of orig.cir to input.cir, containing T statements
The netlist produced by use of the -f switch replaces existing .TRAN statements in the netlist file by
a parametrized .TRAN statement, and related parameters, enclosed within a #ifdef HW_TRAN ...
#endif block. The netlist also contains commands enclosed within a #ifdef HW_RESTART ...
#endif block, which are only intended for iterations after the first iteration. You should not set -define
HW_TRAN or -define HW_RESTART within your eldo_command as both these variables are automati-
cally defined by Eldo Invocation Script hw_eldo, within the electro-thermal loop.
If the netlist-file does not contain a .TRAN statement (i.e. it is within included files, or was omitted), then
using the -f switch results in a .TRAN statement-block as described above, being added at the end of the
netlist file. This final .TRAN statement supercedes any that preceded it.
An Eldo netlist, when modified as in the preceding description, is ready for thermal annotation. The user
must ensure temperature effects in all models are enabled, and power is computed for all devices.

5.5.4 Eldo Premier

The use of Eldo Premier is supported. The items described in the preceeding Eldo Data Preparation
section still apply, except that Eldo Interactive Language or EIL is not supported in Eldo Premier. To use
Eldo Premier, simply specify eldo -premier instead of eldo within your eldo_command string. The
-premier switch runs Eldo Premier. HeatWave detects the -premier switch, and automatically uses the
appropriate interface.
Back to Overview of Electrical Solvers

5.6 FineSim Interface

This implementation is selected if the Electrical Solver initialization variable solver_type is set to "finesim".
Power dissipated by each source at the temperature last computed by HeatWave’s thermal simulation is ob-
tained from the FineSim circuit simulator The user is assumed to have a basic working knowledge
of FineSim.
The Electrical Solver Initialization file variables relevant to solver_type "finesim" are listed below.

• finesim_script string name of the script that will be invoked to run FineSim, analyze its output
and update instance powers for the next iteration of thermal simulation. The script must handle
all options of hw_finesim as described in the hw_finesim script section. The finesim_script en-
sures that the FineSim circuit simulator saves the power dissipated by each instance in the
"finesim/<prefix>.log" file, given a finesim_netlist named "finesim/<prefix>.sp". To
make FineSim report the average power per instance in a transient simulation, finesim_script auto-
matically adds a command to your finesim_netlist, such as
.MEASURE TRAN hw_pwr AVG pd(∗.∗)
resulting in powers prefixed by hw_pwr in the "finesim/<prefix>.log" file described above.
Default script is "hw_finesim"
• finesim_netlist string name of the netlist on which the finesim_script will invoke the FineSim
circuit simulator This netlist must be prepared as described in the FineSim Data Preparation
section for use in the HeatWave interface. It is strongly recommended that, after preparation, you
name your FineSim netlist finesim/input.sp.
Default finesim/input.sp

37
 Electrical Solvers

• finesim_subckt string name of the subcircuit in which the finesim_script searches for instances (i.e.
power sources) whose temperature is annotated and whose power-dissipation is measured.
Default <cellname>
• finesim_command quoted string name of the shell command the finesim_script will use to invoke
FineSim, in the circuit simulation run-directory. So, relative pathnames specified in finesim_command
are relative to the circuit simulation run-directory (finesim/). The netlist name and related switches
(e.g. -out ) will be appended to finesim_command by the finesim_script, so they must not be
present in the finesim_command string.
Default "finesim "

• finesim_log string name of top-level logfile to which the finesim_script will write. This is not the same
as the logfile written by FineSim during circuit-simulation.
Default "finesim_flow.out"

A simulation run-directory in which FineSim can be invoked with finesim_command on finesim_netlist with-
out errors should be present. The finesim_netlist must be prepared for use with this interface as indicated
in the FineSim Data Preparation section.
Using the values in the Electrical Solver initialization file FineSim is invoked, temperatures from Heat-
Wave’s thermal simulation are annotated into the finesim_netlist, simulation is run and power values are
read from the FineSim output files, for use in the next iteration of thermal simulation.
At the end of the steady state or transient thermal simulation a set of ∗.fsdb waveform files is available,
one for each circuit-simulation run. Plots of instance temperature or power over time may be made from the
solution and mesh archives saved by HeatWave.

5.6.1 FineSim Setup

Using the default Electrical Solver initialization settings with solver_type set to "finesim" the following are
needed

• run directory finesim containing netlist input.sp The finesim_command string should be set to
specify any user-defined settings.
• finesim_netlist input.sp must be prepared as indicated in the FineSim Data Preparation section.

• the user’s path must be set to find finesim_script (default hw_finesim). Typically, this means includ-
ing $GDA_ROOT/wrap or $GDA_ROOT/bin in the path.
• the user’s path should include the location of Synopsys’ finesim executable

With the conditions above met, and a HeatWave run-directory set up as described and exemplified in this
manual, the FineSim simulator will be invoked to obtain power given the temperature profile last computed
in thermal simulation.
Back to Overview of Electrical Solvers

5.6.2 FineSim Invocation Script hw_finesim

An executable, hw_finesim , that accepts the control variables above to setup, run FineSim and obtain
device powers, is provided by HeatWave. Its location is specifiable using finesim_script.
Under the following assumptions ...

38
 Electrical Solvers

• netlist is error free, ready for FineSim dc or transient simulation

• extracted devices are one level below the top level in the netlist e.g. extracted device M25 is named
I∗.M25
• extracted devices are in the subcircuit specified to hw_finesim via the -s switch. By default this
name, specified in finesim_subckt, is the same as <cellname>
• finesim_command and your netlist are setup to produce a report of average powers for instances
within extracted-cell. Please ensure that the FineSim run produces log messages in "finesim.out" (not
the same as finesim_log)
... the script will invoke FineSim and obtain power-source powers from the results

Any script that accepts the switches below and performs the same basic operations (netlist setup, FineSim
invocation, power measurement) may be used in place of hw_finesim Details (current switch settings,
defaults, examples, assumptions) may be obtained by invoking hw_finesim without arguments.
Example: [Note that "..." indicates text deleted for brevity]

Usage[v...]: hw_finesim [OPTIONS] <cell>

INPUTS:
<cell> name of cell to be simulated

OUTPUTS:
.<cell>.pval HeatWave pval (power values)
Format:
# comment
<power-source-name> <power>

OPTIONS : -l error/warning/info logfile [finesim_flow.out]

-n FineSim netlist path from . [finesim/input.sp]
-s FineSim subckt to analyze [<cell>]
-m max temp increase (C) on a device [250 Celsius]
-w temperature-rise parameter name [DTEMP]
-f for devices in given file replace []
or add "DTEMP=" in netlist and
write to stdout; skip FineSim run.
file format: (one name per line)
<power-source-name> [... ignored]
-c [no arg] checks netlist power-srcs [0]
-r FineSim run command (no netlist) [finesim ]
-d relative path to FineSim run-dir [finesim]

If environment variable "HW_SKIP_SIM" is defined, and

contains the word "finesim", the electrical simulation
is skipped. Post-simulation result traversal *is* attempted.

If script "hwpre" exists in the simulation run-directory

it will be run before the simulation is launched.

If script "hwpost" exists in the simulation run-directory

it will be run after the simulation is completed, and after power
values are written to the <cellname>.pval file.

TRANSIENT THERMAL-SIMULATION:

39
 Electrical Solvers

If file hwtranopts.inc exists in the FineSim run directory, it is

included in the netlist and takes effect before the power
computation for each thermal time-step.

If file hw_start.snapshot exists in the FineSim run directory, and

the start-time is > 0, initial conditions are read from it
by the first FineSim simulation, before transient thermal
simulation.

EXAMPLE 1. hw_finesim -n finesim/input.sp -p finesim/myCell.log -l myCell.log myCell

simulates finesim/input.sp with temperatures in .myCell.tval
to produce powers in .myCell.pval with messages in myCell.log
EXAMPLE 2. hw_finesim -n orig/input.sp -f myLib.ptab myCell >&! input.sp
produces a new input.sp by modifying the original,
orig/input.sp, as described above.
ASSUMPTIONS: ...

Back to Overview of Electrical Solvers

5.6.3 FineSim Data Preparation

The finesim_netlist must be prepared for temperature annotation of each powersource with the following

• the global simulation temperature value must be the ambient temperature used in thermal simulation,
e.g. .option tnom=<ambient_temp> must be specified. This temperature must be consistent
with the temperature that you specify in the package model for HeatWave. This ensures consistency
in the thermal and electrical simulations.
• the finesim_subckt must be defined directly within the finesim_netlist, and not buried in an .include
statement (i.e. an included file)
• all instances for which thermal annotation is desired, that support the FineSim DTEMP parameter
must have DTEMP=parameter-name or a similar parametrized expression in their declaration. The
hw_finesim script can output a temperature (DTEMP) annotated version of a given netlist as de-
scribed below. The DTEMP parameter is understood to be a temperature difference.

• .include ../.<cellname>.tival.finesim must be present at the head of the finesim_-

netlist where cellname is the name of the cell being thermally simulated. The
../.<cellname>.tival.finesim file sets temperatures on instances (devices) in the FineSim
netlist and is produced by the hw_finesim script, which also adds the .include ... statement
to the finesim_netlist

The insertion of temperature parameters, and of control commands needed by HeatWave, may be done
automatically by using a special mode of finesim_script (default hw_finesim)
hw_finesim -n <orig_netlist> -f <inst_file> <cell> writes a new netlist, ready for ther-
mal annotation, to stdout
where

• orig_netlist is the name of the original FineSim netlist with any DTEMP=... statements removed

• inst_file list all instances (power sources) to be annotated, one name per line. A file in HeatWave’s
ptab or pval formats may be used

40
 Electrical Solvers

• cell is the name of the cell under thermal analysis. A subckt with this name (or a name specified
using -s) must exist in orig_netlist

Example:
hw_finesim -n orig/input.sp -f <libname>.ptab myCell >&! new/input.sp
writes a modified version of orig/input.sp to new/input.sp, containing DTEMP statements
The netlist produced by use of the -f switch replaces existing .TRAN statements in the netlist file by
a parametrized .TRAN statement, and related parameters, enclosed within a .IF (HW_TRAN ==1) ...
.ENDIF block. The netlist also contains .INCLUDE hw_cur.inc, where hw_cur.inc is created on the
fly by finesim_script , and contains parameters controlling the transient simulation interval, as well
commands (.snapshot) to save the current simulation state, or restore a prior simulation state, during
individual electro-thermal simulations.
If the netlist-file does not contain a .TRAN statement (i.e. it is within included files, or was omitted), then
using the -f switch results in a .TRAN statement-block as described above, being added at the end of the
netlist file. This final .TRAN statement supercedes any that preceded it.
A FineSim netlist, when modified as in the preceding description, is ready for thermal annotation. The user
must ensure temperature effects in all models are enabled, and power is computed for all devices.
Back to Overview of Electrical Solvers

5.7 HSPICE Interface

This implementation is selected if the Electrical Solver initialization variable solver_type is set to "hspice".
Power dissipated by each source at the temperature last computed by HeatWave’s thermal simulation is
obtained from the HSPICE circuit simulator described further in the HSpice Interface section. The
user is assumed to have a basic working knowledge of HSPICE .
The Electrical Solver Initialization file variables relevant to solver_type "hspice" are listed below.

• hspice_script string name of the script that will be invoked to run HSPICE, analyze its output and
update instance powers for the next iteration of thermal simulation. The script must handle all options
of hw_hspice as described in the hw_hspice script section.
Default script is "hw_hspice"
• hspice_netlist string name of the netlist on which the hspice_script will invoke the HSPICE circuit
simulator This netlist must be prepared as described in the HSPICE Data Preparation section for
use in the HeatWave interface. It is strongly recommended that, after preparation, you name your
HSPICE netlist hspice/input.ckt.
Default hspice/input.ckt.
• hspice_subckt string name of the subcircuit in which the hspice_script searches for instances (power
sources) whose temperature is annotated and whose power-dissipation is measured.
Default <cellname>
• hspice_command quoted string name of the shell command the hspice_script will use to invoke
HSPICE, in the circuit simulation run-directory. So, relative pathnames specified in hspice_command
are relative to the circuit simulation run-directory (hspice/). The netlist name and related switches
(e.g. -o , -i ) will be appended to hspice_command by the hspice_script, so they must not be
present in the hspice_command string.
Default "hspice "

41
 Electrical Solvers

• hspice_pwr_dir string name of the HSPICE output directory relative to the local HSPICE run directory
hspice. This directory contains the files that report the average power for each instance (power
source). The hspice_script ensures that the HSPICE circuit simulator saves power values in
files within the named directory. To make HSPICE report the average power per instance in a transient
simulation, hspice_script automatically adds a command to your hspice_netlist like
.MEASURE TRAN hw_pwr AVG p(∗.∗)
resulting in powers prefixed by hw_pwr in files ∗.lis within the hspice_pwr_dir directory.
Default "hw_out" (relative to hspice/ )
• hspice_log string name of top-level logfile to which the hspice_script will write. This is not the same
as the logfile written by HSPICE during circuit-simulation.
Default "hspice_flow.out"

A simulation run-directory in which HSPICE can be invoked with hspice_command on hspice_netlist without
errors should be present. The hspice_netlist must be prepared for use with this interface as indicated in the
HSPICE Data Preparation section.
Using the values in the Electrical Solver initialization file HSPICE is invoked, temperatures from HeatWave’s
thermal simulation are annotated into the hspice_netlist, simulation is run and power values are read from
HSPICE output files ∗.lis within hspice_pwr_dir, for use in the next iteration of thermal simulation.
At the end of the steady state or transient thermal simulation a set of ∗.tr0 waveform files is available,
one for each circuit-simulation run. Plots of instance temperature or power over time may be made from the
solution and mesh archives saved by HeatWave.

5.7.1 HSPICE Setup

Using the default Electrical Solver initialization settings with solver_type set to "hspice" the following are
needed

• run directory hspice containing netlist input.sp The hspice_command string should be set to
specify any user-defined settings (see hspice_command above).
• hspice_netlist input.sp must be prepared as indicated in the HSPICE Data Preparation section.
• the user’s path must be set to find hspice_script (default hw_hspice). Typically, this means including
$GDA_ROOT/wrap or $GDA_ROOT/bin in the path.
• the user’s path should include the location of Synopsys’ hspice executable

With the conditions above met, and a HeatWave run-directory set up as described and exemplified in this
manual, the HSPICE simulator will be invoked to obtain power given the temperature profile last computed
in thermal simulation.
Back to Overview of Electrical Solvers

5.7.2 HSPICE Invocation Script hw_hspice

An executable, hw_hspice , that accepts the control variables above to setup, run HSPICE and obtain
device powers, is provided by HeatWave. Its location is specifiable using hspice_script.
Under the following assumptions ...

• netlist is error free, ready for HSPICE dc or transient simulation

42
 Electrical Solvers

• extracted devices are one level below the top level in the netlist e.g. extracted device M25 is named
I∗.M25
• extracted devices are in the subcircuit specified to hw_hspice via the -s switch. By default this
name, specified in hspice_subckt, is the same as <cellname>
• hspice_command and your netlist are setup to produce a report of average powers for instances
within extracted-cell, in the directory you specified for hspice_pwr_dir. The HSPICE run produces log
messages in in files ∗.lis within the hspice_pwr_dir that you specify. Note that these are distinct
from the logfile referenced by hspice_log, which contains the output of hspice_script.
... the script will invoke HSPICE and obtain power-source powers from the results.

Any script that accepts the switches below and performs the same basic operations (netlist setup, HSPICE
invocation, power measurement) may be used in place of hw_hspice . You may obtain details (current
switch settings, defaults, examples, assumptions) by invoking hw_hspice without arguments.
Example: [Note that "..." indicates text deleted for brevity]

Usage[v...]: hw_hspice [OPTIONS] <cell>

INPUTS:
<cell> name of cell to be simulated

OUTPUTS:
.<cell>.pval HeatWave pval (power values)
Format:
# comment
<power-source-name> <power>

OPTIONS : -l error/warning/info logfile [hspice_flow.out]

-n HSPICE netlist path from . [hspice/input.ckt]
-p output dir, relative to hspice/ [hw_out]
-s HSPICE subckt to analyze [<cell>]
-m max temp increase (C) on a device [250 Celsius]
-w temperature-rise parameter name [DTEMP]
-f for devices in given file replace []
or add "DTEMP=" in netlist and
write to stdout; skip HSPICE run.
file format: (one name per line)
<power-source-name> [... ignored]
-c [no arg] checks netlist power-srcs [0]
-r HSPICE run command (no netlist) [hspice ]
-d relative path to HSPICE run-dir [hspice]

If environment variable "HW_SKIP_SIM" is defined, and

contains the word "hspice", the electrical simulation
is skipped. Post-simulation result traversal *is* attempted.

If script "hwpre" exists in the simulation run-directory

it will be run before the simulation is launched.

If script "hwpost" exists in the simulation run-directory

it will be run after the simulation is completed, and after power
values are written to the <cellname>.pval file.

TRANSIENT THERMAL-SIMULATION:

43
 Electrical Solvers

If file hwtranopts.inc exists in the HSPICE run directory, it is

included in the netlist and takes effect before the power
computation for each thermal time-step.

If file hw_start.ic0 exists in the HSPICE run directory, and

the start-time is > 0, initial conditions are read from it
by the first HSPICE simulation, before transient thermal
simulation.

EXAMPLE 1. hw_hspice -n hspice/input.ckt -p power_out -l myCell.log myCell

simulates hspice/input.ckt with temperatures in .myCell.tval
to produce powers in .myCell.pval with messages in myCell.log
EXAMPLE 2. hw_hspice -n orig/input.ckt -f myLib.ptab myCell >&! input.ckt
produces a new input..ckt by modifying the original,
orig/input.ckt, as described above.

ASSUMPTIONS:...

Back to Overview of Electrical Solvers

5.7.3 HSPICE Data Preparation

The hspice_netlist must be prepared for temperature annotation of each powersource with the following

• the global simulation temperature value must be the ambient temperature used in thermal simulation,
e.g. .temp <ambient_temp> must be specified. This temperature must be consistent with the
temperature that you specify in the package model for HeatWave. This ensures consistency in the
thermal and electrical simulations.
• the hspice_subckt must be defined directly within the hspice_netlist, and not buried in an .include
statement (i.e. an included file)
• all instances for which thermal annotation is desired, that support the HSPICE DTEMP parameter
must have DTEMP=parameter-name or a similar parametrized expression in their declaration. The
hw_hspice script can output a temperature (DTEMP) annotated version of a given netlist as de-
scribed below. During netlist preparation, the hspice_script ensures that the DTEMP parameter is
a temperature difference, because hspice_script specifies .OPTIONS ... XDTEMP=1 within and
hspice_netlist
• .include ../.<cellname>.tival.hspice must be present at the head of the hspice_-
netlist where cellname is the name of the cell being thermally simulated. The
../.<cellname>.tival.hspice file sets temperatures on instances (devices) in the HSPICE
netlist and is produced by the hw_hspice script, which also adds the .include ... statement
to the hspice_netlist

The insertion of temperature parameters, and of control commands needed by HeatWave, may be done
automatically by using a special mode of hspice_script (default hw_hspice)
hw_hspice -n <orig_netlist> -f <inst_file> <cell> writes a new netlist, ready for thermal
annotation, to stdout
where

• orig_netlist is the name of the original HSPICE netlist with any DTEMP=... statements removed

44
 Electrical Solvers

• inst_file list all instances (power sources) to be annotated, one name per line. A file in HeatWave’s
ptab or pval formats may be used.
• cell is the name of the cell under thermal analysis. A subckt with this name (or a name specified
using -s) must exist in orig_netlist

Example:
hw_hspice -n original.ckt -f <libname>.ptab myCell >&! new/input.ckt
writes a modified version of original.ckt to new/input.ckt, containing DTEMP statements
The netlist produced by use of the -f switch replaces existing .TRAN statements in the netlist file by
a parametrized .TRAN statement, and related parameters, enclosed within a .IF (HW_TRAN ==1) ...
.ENDIF block. The netlist also contains .INCLUDE hw_cur.inc, where hw_cur.inc is created on the
fly by hspice_script , and contains parameters controlling the transient simulation interval, as well com-
mands to save ( .snapshot) the current simulation state, or restore a prior simulation state, during individual
electro-thermal simulations.
If the netlist-file does not contain a .TRAN statement (i.e. it is within included files, or was omitted), then
using the -f switch results in a .TRAN statement-block as described above, being added at the end of the
netlist file. This final .TRAN statement supercedes any that preceded it.
A HSPICE netlist, when modified as in the preceding description, is ready for thermal annotation. The user
must ensure temperature effects in all models are enabled, and power is computed for all devices.
Back to Overview of Electrical Solvers

5.8 Spectre Interface

This implementation is selected if the Electrical Solver initialization variable solver_type is set to "spectre".
Power dissipated by each source at the temperature last computed by HeatWave’s thermal simulation is ob-
tained from the Spectre circuit simulator The user is assumed to have a basic working knowledge
of Spectre.
The Electrical Solver Initialization file variables relevant to solver_type "spectre" are listed below.

• spectre_script string name of the script that will be invoked to run Spectre, analyze its output and
update instance powers to HeatWave for the next iteration of thermal simulation. The script must
handle all options summarized in the Spectre Invocation Script hw_spectre section. Default script is
"hw_spectre"
• spectre_netlist string name of the netlist on which the spectre_script will invoke the Spectre
circuit simulator. This netlist must be prepared as described in section Spectre Data Prepara-
tion for use in the HeatWave interface. Default "spectre/input.scs"
• spectre_subckt string name of the subcircuit in which the spectre_script searches for instances
(power sources) whose temperature is annotated and whose power-dissipation is measured. Note
that when the testbench references a Cadence "extracted" view of the design during netlisting (as
recommended), the resulting subcircuit name in the netlist from Cadence may be "<cellname>_-
extracted". Default <cellname>
• spectre_command quoted string name of the shell command the spectre_script will use to
invoke Spectre, in the circuit simulation run-directory. So, relative pathnames specified in spectre_-
command are relative to the circuit simulation run-directory (usually spectre/).
Default "spectre -f psfascii =l spectre.out -r ./psf -Ispectre/models"

45
 Electrical Solvers

The netlist name will be appended by the spectre_script, so it must not be present in this string.
To run APS, you may specify aps instead of spectre above, as long as you ensure all the power values
are reported in the file named by spectre_psf. If psfascii produces unacceptably large result-
files, you may invoke the spectremdl executable instead of spectre, as follows. Specify a command
similar to
"spectremdl -b input.mdl -format psfbin =l spectre.out -raw psf -design "
making sure the command contains -b input.mdl and ends with -design , so the netlist name
may be appended to it. spectre_script will automatically create input.mdl containing power-
reporting commands, in the Spectre run-directory. The waveform directory you specify with -raw
(in this case, psf) must match the directory specified in spectre_psf (if using spectremdl , the
file-name in spectre_psf is ignored). In all cases spectre_script parses Spectre’s power report
and converts it to HeatWave’s input format.
• spectre_psf string name of Cadence’s PSF (or other) format file of dc or transient simulation results
containing a power for each instance (powersource) over time. With spectremdl only the directory-
name is needed (the file-name is ignored) by spectre_script. spectremdl saves power mea-
surements in "input.measure". Default "psf/dcOp.dc"
• spectre_log string name of top level logfile to which the spectre_script will write. Default
"spectre_flow.out"

A simulation run-directory in which Spectre can be invoked with spectre_command on spectre_netlist with-
out errors should be present. The spectre_netlist must be prepared for use with this interface as indicated
in the Spectre Data Preparation section.
Using the values in the Electrical Solver initialization file Spectre is invoked, temperatures from HeatWave’s
thermal simulation are annotated into the spectre_netlist, simulation is run and power values are read from
the spectre_psf simulation output, for use in the next iteration of thermal simulation.

5.8.1 Spectre Setup

Using the default Electrical Solver initialization settings with solver_type set to "spectre" the following are
needed

• run directory spectre containing netlist input.scs with all referenced models found in
spectre/models (that may be a link). Alternatively, modify the spectre_command string to in-
clude the search path to model-libraries used in the netlist.
• spectre_netlist input.scs must be prepared as indicated in the Spectre Data Preparation section.
• the user’s path must be set to find spectre_script (default hw_spectre). Typically, this means includ-
ing $GDA_ROOT/wrap or $GDA_ROOT/bin in the path.
• the user’s path must include the location of Cadence’s spectre executable

With the above present, and a HeatWave run-directory set up as described and exemplified in this manual,
the Spectre simulator will be invoked to obtain power given the temperature profile last computed in thermal
simulation.
Back to Overview of Electrical Solvers

5.8.2 Spectre Invocation Script hw_spectre

An executable, hw_spectre , that accepts the control variables above to setup, run Spectre and obtain
device powers is provided by HeatWave. Its location is specifiable using spectre_script.

46
 Electrical Solvers

Under the following assumptions ...

• netlist is error free, ready for Spectre dc or transient simulation

• extracted devices (i.e. power sources) are one level below the top level in the netlist e.g. extracted
device M25 is named I0.M25
• extracted devices are in the subcircuit specified to hw_spectre via the -s switch. By default this
name, specified in spectre_subckt, is <cellname>
• spectre_command is setup to produce ascii PSF in the file named in spectre_psf (or use
spectremdl, as described in the spectre_command section). spectre_command should also pro-
duce log messages in "spectre.out" (not the same as spectre_log)
... the script will invoke Spectre and obtain power-source powers from the results

Any script that accepts the switches below and performs the same basic operations (netlist setup, Spectre
invocation, power measurement) may be used in place of hw_spectre Details (current switch settings,
defaults, examples, assumptions) may be obtained by invoking hw_spectre without arguments.
Example: [Note that "..." indicates text deleted for brevity]

Usage[v...]: hw_spectre [OPTIONS] <cell>

INPUTS:
<cell> name of cell to be simulated

OUTPUTS:
.<cell>.pval HeatWave pval (power values)
Format:
# comment
<power-source-name> <power>

OPTIONS : -l error/warning/info logfile [spectre_flow.out]

-n spectre-netlist path from . [spectre/input.scs]
-p spectre analysis outfile (psf) [psf/dcOp.dc]
-s spectre subckt to analyze [<cell>]
-m max temp increase (C) on a device [250 Celsius]
-w temperature-rise parameter name [trise]
-f for devices in given file replace []
or add "trise" in netlist and
write to stdout; skip spectre run.
file format: (one name per line)
<power-source-name> [... ignored]
ptab or pval format file accepted
-c [no arg] checks netlist power-srcs [0]
-r spectre run command (no netlist) [spectre ...]
-d relative path to spectre run-dir [spectre]

If environment variable "HW_SKIP_SIM" is defined, and

contains the word "spectre", the electrical simulation
is skipped. Post-simulation result traversal *is* attempted.

If environment variable "HW_ALT_TEMP" has a non-zero value,

trise is a temperature (C), *not* the usual delta-T

If script "hwpre" exists in the simulation run-directory

it will be run before the simulation is launched.

47
 Electrical Solvers

If script "hwpost" exists in the simulation run-directory

it will be run after the simulation is completed, and after power
values are written to the <cellname>.pval file.

TRANSIENT THERMAL-SIMULATION:

The transient-simulation state is always saved with "writefinal"

(not "write") and is read with "readic" (not "readns")
If environment variable "HW_ALT_IC" has a non-zero value,
DC analysis is skipped ("skipdc=yes") before each transient
simulation. If "HW_ALT_IC" is "0" or is not defined, DC
analysis is done ("skipdc=no") before each transient.

If file hwtranopts.scs exists, it is merged into one line,

and appended to transient control-file hwtransient.scs,
before the power computation for each thermal time-step.

If file gdainit.fc exists, initial conditions are read

from it by the first Spectre simulation, before transient
thermal simulation.

EXAMPLE 1. hw_spectre -c -l myCell.log myCell

simulates spectre/input.scs with temperatures in .myCell.tval
to produce powers in .myCell.pval with messages in myCell.log
EXAMPLE 2. hw_spectre -n input.scs -m 99 -f myLib.ptab myCell >&! input.scs.new
produces input.scs.new by modifying input.scs as
described above. Limits max TRISE to 99. Does not run spectre.

ASSUMPTIONS: ...

Back to Overview of Electrical Solvers

5.8.3 Spectre Data Preparation

The spectre_netlist must be prepared for temperature annotation of each powersource with the following

• the global simulation temperature value must be the ambient temperature used in thermal simulation,
e.g. temp=<ambient_temp> must be specified. This ensures consistency between temperatures
in the thermal and electrical analyses, i.e. the trise values obtained by subtracting temp from the
instance temperatures are correct.
• all instances for which thermal annotation is desired, that support the Spectre trise parameter must
have trise=<instance_name>-temp or a similar expression in their declaration. The hw_spectre
script can output a trise annotated version of a given netlist as described below
• include ../.<cellname>.tival.scs (that refers to a file created from ../.<cellname>.tval)
must be present at the head of the spectre_netlist where cellname is the name of the cell under
thermal simulation.

The above may be automatically done by using a special mode of spectre_script (default hw_spectre)
hw_spectre -n <orig_netlist> -f <inst_file> <cell> writes a new netlist, ready for ther-
mal annotation, to stdout
where

48
 Electrical Solvers

• orig_netlist is the name of the original Spectre netlist with any trise=... statements removed
• inst_file list all instances (power-sources) to be annotated, one name per line. A file in Heat-
Wave’s ptab or pval formats is also accepted
• cell is the name of the cell under thermal analysis. A subckt with this name (or a name specified
using -s) must exist in orig_netlist

Example:
hw_spectre -n orig.scs -f insts.txt myCell >&! input.scs
writes a modified version of orig.scs to input.scs, containing trise statements.
For transient thermal simulation, hw_spectre will remove .tran commands in the netlist specified by
spectre_netlist and replace them with a single .include "hwtransient.scs" . HeatWave will
later create the hwtransient.scs file based on your transient settings.
A Spectre netlist, when modified as described above, is ready for thermal annotation. The user must ensure
temperature effects in all models are enabled, and power is computed for all devices.
Back to Overview of Electrical Solvers

5.9 Ultrasim Interface

This implementation is selected if the Electrical Solver initialization variable solver_type is set to "ultrasim".
Power dissipated by each source at the temperature last computed by HeatWave’s thermal simulation is
obtained from the Ultrasim circuit simulator The user is assumed to have a basic working knowl-
edge of Ultrasim. The Electrical Solver Initialization file variables relevant to solver_type "ultrasim" are
listed below.

• ultrasim_script string name of the script that will be invoked to run Ultrasim, analyze its output and
update instance powers for the next iteration of thermal simulation. The script must handle all options
summarized in the Ultrasim Invocation Script hw_ultrasim section. Default script is "hw_ultrasim"
• ultrasim_netlist string name of the netlist on which the ultrasim_script will invoke the Ultrasim
circuit simulator. This netlist must be prepared as described in section Ultrasim Data Prepara-
tion for use in the HeatWave interface. Default "ultrasim/input.ckt"
• ultrasim_subckt string name of the subcircuit in which the ultrasim_script searches for in-
stances (power-sources) whose temperature is annotated and whose power-dissipation is measured.
Note that when the testbench references a Cadence "extracted" view of the design during netlisting (as
recommended), the resulting subcircuit name in the netlist from Cadence may be "<cellname>_-
extracted". Default <cellname>

• ultrasim_command is the quoted string containing the shell command the ultrasim_script will
use to invoke Ultrasim, in the circuit simulation run-directory. So, relative pathnames specified in
ultrasim_command are relative to the circuit simulation run-directory (usually ultrasim/).
Default "ultrasim =l ultrasim.out -raw ./psf -Iultrasim/models "
The netlist name will be appended by the ultrasim_script, so it must not be present in this string.
• ultrasim_psf string name of Ultrasim’s power-analysis (.pa) file produced by the .usim_pa command,
containing a power for each instance (powersource) at each timestep. Default "psf/input.pa"
• ultrasim_log string name of top level logfile (not the Ultrasim logfile) to which the ultrasim_script
will write. Default "ultrasim_flow.out"

49
 Electrical Solvers

A simulation run-directory in which Ultrasim can be invoked with ultrasim_command on ultrasim_netlist

without errors should be present. The ultrasim_netlist must be prepared for use with this interface as
indicated in the Ultrasim Data Preparation section.
Using the values in the Electrical Solver initialization file Ultrasim is invoked, temperatures from HeatWave’s
thermal simulation are annotated into the ultrasim_netlist, simulation is run and power values are read from
the ultrasim_psf simulation output, for use in the next iteration of thermal simulation.

5.9.1 Ultrasim Setup

Using the default Electrical Solver initialization settings with solver_type set to "ultrasim" the following are
needed

• run directory ultrasim containing netlist input.ckt with all referenced models found in
ultrasim/models , that may be a link. Alternatively, modify the ultrasim_command string to
include the search path to model-libraries used in the netlist.
• ultrasim_netlist input.ckt must be prepared as indicated in the Ultrasim Data Preparation section.
• the user’s path must be set to find ultrasim_script (default hw_ultrasim). Typically, this means
including $GDA_ROOT/wrap or $GDA_ROOT/bin in the path.
• the user’s path must include the location of Cadence’s ultrasim executable

With the above present, and a HeatWave run-directory set up as described and exemplified in this manual,
the Ultrasim simulator will be invoked to obtain power given the temperature profile last computed in thermal
simulation.
Back to Overview of Electrical Solvers

5.9.2 Ultrasim Invocation Script hw_ultrasim

An executable, hw_ultrasim , that accepts the control variables above to setup, run Ultrasim and obtain
device powers is provided by HeatWave. Its location is specifiable using ultrasim_script.
Under the following assumptions ...

• netlist is error free, ready for Ultrasim dc or transient simulation

• extracted devices are one level below the top level in the netlist e.g. extracted device M1 is named
I0.M1
• extracted devices are in the subcircuit specified to hw_ultrasim using the -s switch. By default this
name, specified in ultrasim_subckt, is <cellname>
• ultrasim_command is setup (using .usim_pa) to produce text power-analysis results, in the file speci-
fied in ultrasim_psf, and to produce log messages in "ultrasim.out" (not the same as ultrasim_log)
... the script will invoke Ultrasim and obtain power-source powers from the results

Any script that accepts the switches below and performs the same basic operations (netlist setup, Ultrasim
invocation, power measurement) may be used in place of hw_ultrasim Details (current switch settings,
defaults, examples, assumptions) may be obtained by invoking hw_ultrasim without arguments.
Example: [Note that "..." indicates text deleted for brevity]

Usage[v...]: hw_ultrasim [OPTIONS] <cell>

50
 Electrical Solvers

INPUTS:
<cell> name of cell to be simulated

OUTPUTS:
.<cell>.pval HeatWave pval (power values)
Format:
# comment
<power-source-name> <power>

OPTIONS : -l error/warning/info logfile [ultrasim_flow.out]

-n ultrasim netlist path from . [input.ckt]
-p ultrasim analysis outfile (psf) [psf/input.pa]
-s ultrasim subckt to analyze [<cell>]
-m max temp increase (C) on a device [250 Celsius]
-w temperature-rise parameter name [trise]
-f for devices in given file replace []
or add "trise" in netlist and
write to stdout; skip ultrasim run.
file format: (one name per line)
<power-source-name> [... ignored]
ptab or pval format file accepted
-c [no arg] checks netlist power-srcs [0]
-r ultrasim run command (no netlist) [ultrasim ... ]
-d relative path to ultrasim run-dir [ultrasim]

EXAMPLE 1. hw_ultrasim -c -l myCell.log myCell

simulates input.ckt with temperatures in .myCell.tval
to produce powers in .myCell.pval with messages in myCell.log
EXAMPLE 2. hw_ultrasim -n input.ckt -m 99 -f myLib.ptab myCell >&! input.ckt.new
produces input.ckt.new by modifying input.ckt as described
above. Limits max TRISE to 99. Does not run ultrasim.

ASSUMPTIONS: ...

Back to Overview of Electrical Solvers

5.9.3 Ultrasim Data Preparation

The ultrasim_netlist must be prepared for temperature annotation of each powersource with the following

• the global simulation temperature value must be the ambient temperature used in thermal simulation,
e.g. temp=<ambient_temp> must be specified. This ensures consistency between temperatures
in the thermal and electrical analyses, i.e. the trise values obtained by subtracting temp from the
instance temperatures are correct.

• all instances for which thermal annotation is desired, that support the Ultrasim trise parameter must
have trise=<instance_name>-temp or a similar expression in their declaration. The hw_ultrasim
script can output a trise annotated version of a given netlist as described below
• include ../.<cellname>.tival.scs (that refers to a file created from ../.<cellname>.tval)
must be present at the head of the ultrasim_netlist where cellname is the name of the cell under
thermal analysis.

51
 Electrical Solvers

The above may be automatically done by using a special mode of ultrasim_script (default hw_ultrasim)
Ensure that Ultrasim’s Power Analysis is enabled, by adding a .usim_pa statement similar to: .usim_pa
subckt depth=2 sort=avg power=on start=... stop=...
hw_ultrasim -n <orig_netlist> -f <inst_file> <cell> writes a new netlist, ready for ther-
mal annotation, to stdout
where

• orig_netlist is the name of the original Ultrasim netlist with any trise=... statements removed
• inst_file list all instances (power-sources) to be annotated, one name per line. A file in Heat-
Wave’s ptab or pval formats may be used
• cell is the name of the cell under thermal simulation. A subckt with this name (or a name specified
using -s) must exist in orig_netlist

Example:
hw_ultrasim -n orig.scs -f insts.txt myCell >&! input.scs
writes a modified version of orig.scs to input.scs, containing trise statements.
Transient thermal simulation is not currently supported in ultrasim.
A Ultrasim netlist, when modified as described above, is ready for thermal annotation. The user must ensure
temperature effects in all models are enabled, and power is computed for all devices.
Back to Overview of Electrical Solvers

5.10 Multiple Electrical Solvers

HeatWave supports the use of multiple electrical-solvers during a single power-calculation iteration within an
electro-thermal loop. This can be enabled by providing multiple solver_type declarations in the initialization
file.
For example, specifying

• solver_type table
• solver_type spectre
in the initialization file. would first run the table-based model to update the cell or block level power
sources and then run spectre to update the device (e.g. transistor) power sources, all within one
single Electrical Solver iteration.

Back to Overview of Electrical Solvers

52
 Scripting Primitives

6 Scripting Primitives

6.1 Overview

Many of the data and control input-files to HeatWave may be in plain text, with use-models as explained
in the HeatWave User Guide. The formats of these text-files are specified in the HeatWave Reference
Manual in the sections on HeatWave’s power files, technology file, and initialization files for the mesh, and
electrical-solvers. Such inputs may be produced manually, or by automated scripts.
Some data and control input-files may, alternatively, be written in a scripting language as explained in the
descriptions of use-models in the HeatWave User Guide. At present Tcl is supported. Scripting enables
the following:

• functionalities that require flexibility and expressiveness, including procedures that accept more com-
plex data-structures, HeatWave database-objects, and optional arguments.

• access to more control variables, or more detailed settings of existing ones

• use of basic programming data-structures (e.g. lists, arrays, lookup-tables), and constructs (e.g.
branches, loops) for more compact and flexible specification of controls and representation of data.

A primitive refers to the simplest element in a programming language or system. This section of the manual
describes the scripting access to the "low-level" control-variables and basic procedures that will help you
define and control your thermal simulation flow. The following figure, which is fully described in the Scripting
Data Model section, is used here to explain the scope and context of the material in this section.

Figure 9: Scripting Primitives in the HeatWave Data Model

The shaded box representing scripting primitives has arrows indicating that some objects and methods (i.e.
data and functions) defined in the HeatWave executable are bound to constructs in the scripting interface.
So, these HeatWave objects may be accessed and modified by scripts, in particular, using Tcl. This section
describes some procedures written in Tcl, that are not strictly primitives, but are simple enough to be
conceptually grouped with them.

53
 Scripting Primitives

The top-most box in the figure represents utility procedures written in Tcl, that invoke the primitives de-
scribed in this section. The utilities offer more compact specifications, and flexibility, but require descriptions
beyond the scope of this section. They are described in the Tcl Utilities section.
The primitive scripting section of this manual does not assume any particular scripting language in its
descriptions of inputs, outputs and functionality. However, Tcl examples are provided throughout.
The utility section comprises procedures written in Tcl , invoking primitives.
The description of control-variables or procedures may refer to data-structures including lists, arrays, and
one-dimensional functions, or lookup-tables. The Tcl declaration (syntax) and use of these data-types is
documented in the section on Tcl in HeatWave, and is not repeated elsewhere in the descriptions of Heat-
Wave database objects, their control-variables and procedures.

6.2 Basic Concepts

The descriptions in this manual often refer to several basic types of objects. A conceptual description of
these objects is provided here. The particular syntax you use to define such objects or to perform actions
related to them, is summarized, for the Tcl scripting language, in the section on HeatWave Tcl. To follow the
general concepts in this section, you do not need detailed knowledge of the objects mentioned in examples
below. The later data-model section, and subsequent sections on each HeatWave data object, provide that
detailed information.

6.2.1 Methods

HeatWave methods are commonly referenced in the description of scripting primitives. A HeatWave
method is an action or "function" which is associated with, and operates on, a HeatWave database object.
For example, a flow object’s getGUI method returns a reference to a gda::GUI object from the gda::Flow
container.
The Tcl syntax for methods is described in the section on HeatWave methods in Tcl More documentation
on methods is in the sections describing the Flow, Design, Tech, Mesh, TSolve, Transient. and GUI objects

6.2.2 Procedures

A HeatWave procedure is conceptually identical to a Tcl procedure A HeatWave procedure operates

on several (or no) database objects. In either case, it is not primarily associated with a data-base object.
For example, the procedure gdWarn prints a warning message that you provide, to the HeatWave logfile.
Procedures are written in Tcl, or are directly bound to functions in the heatwave binary executable. The
standard Tcl syntax for procedures is accessible in the section on HeatWave procedures in Tcl .

6.2.3 Vars

HeatWave vars and var are commonly used terms in the description of the scripting primitives. A HeatWave
var is distinct from a script variable, such as a Tcl variable. It is one of a group of heterogeneous variables
in a HeatWave vars object. Each var has a name and a value. Each group of vars is treated as a single
object, composed of the individual var names and values, similar to a struct in the C language. You may
also think of vars as a container, or a group, of var names and associated values. These values typically
control the thermal discretization, model-building (thermal-extraction), and solution processes. HeatWave
manuals may also refer to a var as a parameter. The vars for a given object are named <object>Vars, so
a Flow object has gda::FlowVars, a Mesh object has gda::MeshVars, etc. This section on HeatWave
database objects shows the objects that have vars.

54
 Scripting Primitives

The Tcl syntax for reading and configuring vars is described in the section on HeatWave vars in Tcl More
documentation on vars is in the sections describing the Flow, Design, Mesh, TSolve and Transient objects.

6.2.4 Lists

A list is conceptually identical to a Tcl list The Lists in Tcl section further discusses the Tcl syntax of
lists.

6.2.5 Vectors

A vector is a homogeneous array of data, such as strings, integers, and float or double values. The
following HeatWave vector objects may be created.

• gda::Ints <variable-name> <list of ints> creates a gda::Ints object named

<variable-name> that is a vector of int values ordered as in the <list of ints>

• gda::Floats <variable-name> <list of floats> creates a gda::Floats object named

<variable-name> that is a vector of float values ordered as in the <list of floats>
• gda::Strings <variable-name> <list of strings> creates a gda::Strings object
named <variable-name> that is a vector of string values ordered as in the <list of
strings>

All vectors have some accessor methods in common:

<vector> size returns the size of the vector, an integer
<vector> empty returns 1 if the vector is empty, else 0
<vector> clear clears the vector’s contents, making it empty
<vector> push <v> appends the value v to the vector
<vector> pop removes/returns the value at the vector’s end
<vector> get <j> returns the value at index j
<vector> set <j> <v> sets the value at index j to v
Note that the lowest vector index is 0, referring to the first element in the vector. The Tcl syntax for these
objects, and compact equivalents, are described in the section on HeatWave Vectors in Tcl .

6.2.6 Function1d

A Function1d is a one-dimensional mapping or function, y=f(x), specified as a discrete set of values of the
independent variable x and the function’s corresponding value y (at each x). It may also be thought of as
a one-dimensional look-up table, i.e. a series of points xi yi where the xi values increase monotonically
with i. The function’s values are not extrapolated outside the range of specified x values, but are instead
"clipped" to the y values (at the smallest or largest specified x). A single input value implies a constant y for
all x. Several syntaxes for a Function1d exist:

gda::Function1d <object-name> <float>

gda::Function1d <object-name> <list of x values> <list of y values>
gda::Function1d <object-name> <list of alternating x y values>

55
 Scripting Primitives

The first form defines a constant function. The second defines a Function1d using the list of N x values and
list of N y values. The third defines a Function1d set of N (x, y) points, from a list of 2∗N values in the
order x1 y1 x2 y2 ... xN yN.
Function1d objects have the following Methods:
<vector> evaluate <x> returns the value y=f(x)
<vector> isDefined returns 1 if the vector has content, else 0
<vector> isConstant returns 1 if the vector is constant, else 0
<vector> dumpTcl prints the Tcl contents of the vector
<vector> scaleX <s> scales the x values in the function by float s
<vector> scaleY <s> scales the y values in the function by float s
The Tcl syntax for this object, and compact equivalents, are described in the section on HeatWave Func-
tion1d in Tcl .

6.3 Using Tcl in your HeatWave scripts

Tcl is a simple scripting language that requires virtually no programming experience. It is intended
to enable the rapid development of your thermal simulation flow, using HeatWave’s functionality in your
design environment.
The section on using scripts describes how to invoke an interactive HeatWave Tcl shell, or run a Heat-
Wave Tcl script. Many of HeatWave’s control variables and functional modules are bound to Tcl objects or
procedures, so they are accessible in Tcl interactive session, or in scripts.
A working knowledge of the basic Tcl syntax is assumed. When you invoke heatwave -I you should
see the following ("..." indicates deleted text, for brevity):

[inf] ...
[inf] Keysight Technologies
[inf] ...
[inf] program start : ...
[inf] program options : -I
[inf] loading licenses from ... setting
[inf] HeatWave Tcl Library [version ...]
[inf] HeatWave Tcl Context Library [version ...]
gd[0]>

The lines containing "HeatWave Tcl ..." indicate that Tcl is correctly installed for HeatWave, and that the
library of HeatWave Tcl procedures is loaded. If these lines are missing, or you see errors referring to
$TCLLIBPATH, your installation is incomplete. Review and follow the instructions in README.INSTALL in
HeatWave’s release hierarchy.
The command prompt gd[0]> lists the index of the current command, starting at 0. As in the standard
tclsh, you may now run commands such as ls , or shell commands such as history.
Additional Tcl constructs specific to the HeatWave Tcl environment are now described. Example listings in
the following descriptions are from the interactive shell, including its prompts and selected output lines.

6.3.1 HeatWave Flow object in Tcl

This section describes the Tcl syntax you use to create a Flow object. The concept underlying this object
was described in the Flow section.

56
 Scripting Primitives

In general, you invoke a method using the following syntax: The data-model section describes the concept
of HeatWave’s gda::Flow object, which is declared using the following syntax.
gda::Flow <flow-name>
creates a Flow object named <flow-name>. An example in HeatWave’s Tcl shell follows:

gd[0]> gda::Flow flow

[inf] _........_p_gda__Flow

The Tcl interpreter outputs an identifier for the flow object, which you may ignore. While you may use any
flow-name, the names flow , or f are commonly used in HeatWave’s documentation, by convention. Note
that the identifier flow should later be passed to procedures without a leading $, (i.e. use flow , not
$flow) to represent the flow object in your scripts
However, a subsequent declaration like

gd[1]> set f flow

creates a reference f , to flow. While $f refers to flow it is not a copy of flow. Both flow and $f will
work equivalently in your scripts.

6.3.2 HeatWave methods in Tcl

This section describes the Tcl syntax you use to invoke a method. The concept of a method is described in
the HeatWave Methods section. In general, you invoke a method using the following syntax:

set result [<object> <method> <argument-1> ... <argument-N>]

If a method has no return value, or you wish to ignore it, the invocation syntax is:
<object> <method> <argument-1> ... <argument-N>
The following example assumes that, after defining a flow object, a method to compute temperature is
invoked (not shown below). After this step, you may obtain a reference to the GUI object in Tcl, from a flow
object by invoking the flow’s getGUI method. You may then launch the GUI from Tcl, by invoking its show
method, as follows:

gd[0]> gda::Flow flow

..... after computing temperature ...
gd[5]> set GUI [flow getGUI] ;# get reference to a GUI
gd[6]> $GUI show ;# launch a GUI (note the $)
gd[7]> [flow getGUI] show ;# alternative to above (note no $)
gd[8]> [flow getDesign] setBounds 0 0 10000 10000 ;# in dbu (usually nm)

Command #5 invokes the getGUI method of gda::Flow. The return value is stored in the GUI variable,
accessible as $GUI.
Command #6 invokes the show method of the gda::GUI object referenced by $GUI, which launches a
GUI. When the GUI is closed or exited, control returns to the Tcl script.
Command #7 is equivalent to Commands #5 and #6 taken together. The gda::GUI object obtained by
the getGUI method of gda::Flow getGUI , has its show method invoked. This compact invocation avoids
using an intermediate $GUI variable.
Command #8 shows the passing of four integer arguments to a method; in this case the setBounds method
of the gda::Design object, obtained from gda::Flow by invoking the getDesign method.
The syntax specification, and examples above should enable you to invoke any of the methods later de-
scribed for HeatWave’s Flow, Tech, Design, GUI, Mesh, TSolve or Transient objects.

57
 Scripting Primitives

6.3.3 HeatWave procedures in Tcl

A procedure or proc, in Tcl syntax is a standard Tcl construct.

To enable you to invoke HeatWave procedures defined in Tcl files without needing to source these files
explicitly in your scripts, HeatWave uses Tcl’s automatic procedure-loading capability. You will smoothly
and automatically access HeatWave’s Tcl library, and be able to organize your own HeatWave Tcl library
for automatic access by others, if you understand:

• the Tcl commands auto_mkindex, auto_load and auto_reset

• how the your shell environment variables TCLLIBPATH and TCL_LIBRARY are related to the Tcl
commands mentioned above

• what a tclIndex file is, how you use it to automatically access the HeatWave Tcl library, and how
others may load your Tcl library of procedures (such as a HeatWave technology definition proc)
without needing to explicitly source your Tcl files

The preceding are standard capabilities of the Tcl environment. Any HeatWave procedure described in this
manual is implemented in Tcl as a proc.

6.3.4 HeatWave vars in Tcl

This section describes the Tcl syntax you use to get or create vars, and how to configure a var. The
concept of vars, and a var, are described in the HeatWave vars section
You generally obtain a vars object from a HeatWave object, as described in the sections on Flow, Design,
Mesh, TSolve and Transient. You may then set or configure a var value as follows:

<vars-object> configure -<var-name1> <var-value1>

-<var-name2> <var-value2>
...
-<var-nameN> <var-valueN>

where each line above (except the last) needs a backslash \ at the end to escape the carriage-return. An
equivalent syntax, depending on your preference, is:

<vars-object> configure -<var-name1> <var-value1>

<vars-object> configure -<var-name2> <var-value2>
<vars-object> configure ...
<vars-object> configure -<var-nameN> <var-valueN>

and you may read a var value as follows

<vars-object> cget -<var-name> <var-value>
where, whether reading or writing a value, <var-name> and <var-value> must be valid for the particular
<var-object>
A few specific syntax examples follow:

gd[0]> gda::Flow flow

gd[1]> [flow vars] configure -log_time_stamps 1
gd[2]> [flow vars] cget -log_time_stamps
[inf] 1
gd[3]> set design [flow getDesign]
gd[4]> set maxPD [[$design vars] cget -max_power_density]

58
 Scripting Primitives

[inf] 2500000.0
gd[5]> [flow designVars] configure -max_power_density 5e6
gd[6]> [flow designVars] cget -max_power_density
[inf] 5000000.0

Command #1 invokes the Flow’s var method, to obtain a FlowVars object, that is directly configured to set
its log_time_stamps var value to 1.
Command #2 obtains the current value of log_time_stamps The information statement [inf] 1 from Heat-
Wave shows the value is what was set in Command #1.
Command #3 gets the Flow’s Design object.
Command #4 reads the value of the max_power_density var, which is 2.5e6 (W/m2 ), and represents a
flux threshold for warnings about power-value inputs. Note that the Design object’s vars were obtained by
invoking Design’s vars method. The vars method is provided on all objects which have vars.
Command #5 shows an alternate, and more compact way of setting the max_power_density value,
where the Flow’s designVars method directly obtains the Design’s vars, without getting the Design
object.
Command #6 uses the same compact syntax (as #5) to obtain the max_power_density value set in the
previous step.
Like designVars, Flow provides methods to access the vars of all objects which have vars. The sections
on individual design objects describe the names and values of each accessible var.
The syntax specification, and examples above should enable you read or set the values of Vars for Heat-
Wave’s Flow, Design, GUI, Mesh or Transient Thermal Solver objects,

6.3.5 Lists in Tcl

A HeatWave list is conceptually identical to a Tcl list Note that lists containing Tcl variables must
be enclosed in in quotes if you wish the variables to be evaluated (e.g. "$myVariable1 {a literal
string} $myVariable2"). If you enclose the variables in braces (e.g. {$myVariable1 {a literal
string} $myVariable2} they will not be evaluated, and will be treated as literals. This is standard Tcl
syntax. Strings within a quoted list need to have their quotes escaped with a leading backslash " \"like
this\" " .

6.3.6 HeatWave Vectors in Tcl

This section describes the Tcl syntax you use to create a HeatWave vector, the concept behind which is
explained in the HeatWave HeatWave Vectors section
The arguments to some methods and procedures, or the value of a var may be a gda::Ints, a gda::Floats,
or a gda::Strings, as explained in the section on HeatWave Vectors. You may define these objects in Tcl as
follows:

gda::Ints <int-vector-name> {<int_1> <int_2> ... <int_n>}

gda::Ints <int-vector-name> "<int> $<int-tcl-var> ... "
gda::Floats <float-vector-name> {<float_1> <float_2> ... <float_n>}
gda::Floats <float-vector-name> "<float> $<float-tcl-var> ... "
gda::Strings <string-vector-name> {<string_1> <string_2> ... <string_n>}
gda::Strings <string-vector-name> "<string> $<string-tcl-var> ... "
where
<int-vector-name> is the name of the vector of N int values
<float-vector-name> is the name of the vector of N float values

59
 Scripting Primitives

<string-vector-name> is the name of the vector of N string values

<int...> is a single int value
<float...> is a single float value
<string...> is a single string value in quotes ("like this")
<int-tcl-var> is the name of a Tcl variable containing an int
<float-tcl-var> is the name of a Tcl variable containing a float
<string-tcl-var> is the name of a Tcl variable containing a string

The Lists in Tcl section describes the standard Tcl effects of enclosing your list items in quotes "" or braces
{}. You should clearly understand the effects of quotes and braces in Tcl lists. Since <float-vector-name>
and <string-vector-name> are both objects they may be passed to Methods or Procedures without a leading
$.
A second, more compact way of defining a HeatWave Vector of int, float or string objects uses the
procedures gdInts, gdFloats and gdStrings , as follows:

set <tcl-variable-name> [gdInts {<int_1> <int_2> ... <int_n>}]

set <tcl-variable-name> [gdInts "<int> $<int-tcl-var> ... "]
set <tcl-variable-name> [gdFloats {<float_1> <float_2> ... <float_n>}]
set <tcl-variable-name> [gdFloats "<float> $<float-tcl-var> ... "]
set <tcl-variable-name> [gdStrings {<string_1> <string_2> ... <string_n>}
set <tcl-variable-name> [gdStrings "<string> $<string-tcl-var> ... "]
where
<tcl-variable-name> is the name of a Tcl variable, which now refers to
a gda::Ints, gda::Floats or gda::Strings object
<int...> is a single int value
<float...> is a single float value
<string...> is a single string value in quotes ("like this")
<int-tcl-var> is the name of a Tcl variable containing an int
<float-tcl-var> is the name of a Tcl variable containing a float
<string-tcl-var> is the name of a Tcl variable containing a string

The Lists in Tcl section describes the effect of quotes and braces.
Since <tcl-variable-name> for any vector is a reference to the object, the variable may be passed to Methods
or Procedures with a leading $
All vectors have a few basic Methods including size, empty, clear, push, pop, get, and set
which are described in the section on HeatWave Vectors. These methods may be used to read or modify
the vector, after it is defined.
A few specific syntax examples for gda::Floats follow. The syntax for gda::Ints or gda::Strings is
essentially identical, so is not shown.

gd[0]> gda::Flow flow

gd[1]> proc vectorSize {v} {puts "vector size is [$v size]"}
gd[2]> vectorSize [gdFloats {1e-9 .2 345}]
[inf] vector size is 3
gd[3]> set v1 [gdFloats {-0.3 2e7 89 -1}]
gd[4]> vectorSize $v1 ;# note the $
[inf] vector size is 4
gd[5]> gda::Floats v2 {.2 345}
gd[6]> vectorSize v2 ;# note no $
[inf] vector size is 2
gd[7]> set thirdElement [$v1 get 2]
[inf] 89.0
gd[8]> v2 pop
[inf] 345.0
gd[9]> $v1 clear

60
 Scripting Primitives

gd[10]> $v1 empty

[inf] 1

To show how vectors are defined, examined, modified and passed as arguments to procedures, we define
a simple procedure that accepts a vector object (and prints its size). The syntaxes shown below will apply
just as well when you need to pass vector objects to HeatWave Methods or Procedures , or use them to
define more complex database objects.
Command #1 defines a proc vectorSize which prints the size of a given vector v.
Command #2 uses the compact gdFloats syntax to define a vector of float values. The return value
from gdFloats is directly passed to vectorSize, which prints the correct vector-size, 3.
Commands #3 and #4 are a longer way of doing the actions of #2, by defining an intermediate Tcl variable
$v1 which refers to the vector. This is useful if you later need the vector.
Command #5 uses the first syntax defined above, creating a gda::Floats object and setting its values.
Command #6 invokes vectorSize to prints the correct vector-size (2). Note the lack of $ , as in the syntax
descriptions above.
Command #7 invokes the vector’s get method to obtain the third element’s value, at vector index 2.
Command #8 invokes the vector’s pop method to obtain its last element’s value. Note the lack of a $ before
v2, as it is an object, not a Tcl variable.
Command #9 invokes the vector’s clear method, to empty the vector $v1.
Command #10 invokes the vector’s empty method, which returns a 1, confirming that vector $v1 is empty.
The syntax specification, and examples above should enable you create, read or modify the values of
Vectors and pass them as required to Methods or Procedures.

6.3.7 HeatWave Function1d in Tcl

This section describes the Tcl syntax you use to create a HeatWave one-dimensional function, the concept
behind which is explained in the HeatWave Function1d section. The arguments to some Methods and
Procedures , or the value of a var may be a gda::Function1d, the general syntaxes for which were described
in the Function1d section. The specific Tcl syntaxes are as follows:

gda::Function1d <Function1d-name> {<constant-y-value>}

gda::Function1d <Function1d-name> {<x1> <x2> ... <xn>} {<y1> <y2> ... <yn>}
gda::Function1d <Function1d-name> {<x1> <y1> <x2> <y2> ... <xn> <yn>}
where
<Function1d-name> is the name of the Function1d object created
<constant-y-value> defines a constant function value for any input
<x...> or <y...> are float values

Since <Function1d-name> is an objects it may be passed to Methods or Procedures without a leading $.

A second, more compact way of defining a Function1d uses the procedure gdFunction1d as follows:

set <tcl-variable-name> [ gdFunction1d <constant-y-value> ]

set <tcl-variable-name> [ gdFunction1d {<x1> <x2> ... <xn>} {<y1> <y2> ... <yn>} ]
set <tcl-variable-name> [ gdFunction1d {<x1> <y1> <x2> <y2> ... <xn> <yn>} ]
where
<tcl-variable-name> is the name of a Tcl variable, which now refers
to a gda::Function1d object
<constant-y-value> defines a constant function value for any input
<x...> or <y...> are float values

61
 Scripting Primitives

Since <tcl-variable-name> for any Function1d is a reference to the object, the variable may be passed to
Methods or Procedures with a leading $. The semantics of the lists above are described in the Function1d
section. In either form above, you may replace the braces {} by quotes "" above, to allow evaluation of the
contents of lists. The Lists in Tcl section describes the effect of quotes and braces.
A Function1d has the Methods evaluate, check, isDefined, dumpTcl, isConstant, scale-
X, and scaleY which are described in the section on Function1d . These methods may be used to
examine or evaluate an existing Function1d.
A few specific syntax examples for gda::Function1d follow.

gd[0]> gda::Flow flow

gd[1]> proc lookup {f x} {puts "f($x) is [$f evaluate $x]"}
gd[2]> gda::Function1d c 1234
gd[3]> c isConstant
[inf] 1
gd[4]> lookup c 1e6
[inf] f(1e6) is 1234.0
gd[5]> gda::Function1d f {0 50 100} {0 50 200}
gd[6]> lookup f 50
[inf] f(50) is 50.0
gd[7]> lookup f 75
[inf] f(75) is 125.0
gd[8]> set g [gdFunction1d {0 0 50 50 100 200}]
gd[9]> lookup $g 75
[inf] f(75) is 125.0
gd[10]> $g scaleY 10.0
gd[11]> lookup $g 75
[inf] f(75) is 1250.0

To show how a Function1d is defined, examined, evaluated and passed as an argument to procedures,
we define a simple procedure that accepts a Function1d f and a value x, and prints the value of f(x). The
syntaxes shown below will apply just as well when you need to pass Function1d objects to HeatWave
Methods or Procedures, or use them to define more complex database objects.
Command #1 defines a proc lookup which prints the value of a given Function1d f at a given input value
x.
Command #2 uses the first group of syntax descriptions to define a constant function c.
Command #3 shows how to invoke a method of a Function1d , namely the isConstant method, which
returns 1, confirming that c is a constant function.
Command #4 shows how to pass a Function1d to a proc, in this case the simple lookup we just defined.
lookup is invoked to evaluate function c at the value 1e6. The [inf] information line contains the expected
constant value 1234 .
Command #5 uses the first set of syntax descriptions to define a gda::Function1d f, containing three pairs
of (x, y) values.
Command #6 invokes the lookup proc to evaluate f at x = 50.0, yielding the expected result f(x) = 50.0.
Note f is specified without a leading $.
Command #7 invokes the lookup proc to evaluate f at x = 75.0, yielding the expected result f(x) = 125.0.
Command #8 uses the second, more compact set of syntax descriptions to define a reference g to a
Function1d, containing the same three pairs of (x, y) values as f , defined earlier.
Command #9 invokes the lookup proc to evaluate g at x = 50.0 Note $g is specified with a leading $ ,
since it not a Function1d object, but a reference to one.
Command #10 invokes Function1d’s scaleY "method" to scale function g (i.e. its (y) values) by 10.0 .

62
 Scripting Primitives

Command #11 invokes the lookup proc to evaluate the newly-scaled function g at x = 75.0 . The result of
1250.0 is that of Command #9, scaled by 10.0, as expected.
The syntax specification, and examples above should enable you create and read the values of Function1d
and pass them as required to Methods or Procedures.

6.4 Scripting Data Model

A gda::Flow object is a HeatWave database object that you create in your scripts to store references to
your data, and the simulation-controls and processes needed to run the electro-thermal simulation flow. The
gda:: prefix is the name-space within which all HeatWave database objects, including Flow, are defined.
HeatWave’s scripting interface relies on the existence of a gda::Flow object, though, in many cases, you
do not explicitly create it. The section Flow further describes this object.
The schema or data-model used in HeatWave’s scripting Procedures, and the Methods of HeatWave objects
is as follows.

Figure 10: HeatWave Data Model for Scripts

As shown, the gda::Flow object provides access to several HeatWave objects, whose methods may be
invoked to define a thermal-simulation flow, and whose vars may be modified to control the simulation.

• gda::Design contains the physical design data

• gda::Tech contains the thermal technology data, such as layer thicknesses, and material composition,
including the thermal properties of materials
• gda::Mesh contains and controls the discretized domain, or mesh, that is the simulation-model for the
thermal solver
• gda::TSolve controls the solver that computes temperatures in the simulation model

• gda::Transient controls the transient thermal solver, which also invokes the core thermal solver TSolve
• gda::GUI when appropriately invoked, can launch a GUI that returns control to your script when it is
exited.

63
 Scripting Primitives

• gda::PlotVars is a GUI configurable var for image Plotting to used by GUI::savePlots.

The Flow object also provides the main simulation methods for steady-state and transient simulation.
The HeatWave Data Model diagram shows the objects listed above, enclosed in boxes, within the HeatWave
binary executable. The arrows indicate that the HeatWave objects are bound to constructs in HeatWave’s
Tcl shell. So, these objects may be accessed and modified by scripts. The text outside each box is an
example of the objects’ methods that, in this case, provide access to they data they contain. For example,
the vars method of gda::Flow provides access to a FlowVars object.

6.4.1 How Vars, Methods and Procedures are described

Descriptions of the vars , methods and other specifications for each object follow. For simplicity, the gda::
namespace prefix for HeatWave objects is often omitted, so the documentation refers to database objects
as Design , Tech , Mesh ,TSolve,Transient, and GUI . Each of these objects is described in a separate
section, which contains further sub-sections. The sub-sections are named, or titled, in a manner that you
should clearly understand:

• Method descriptions are titled: <object>::<method name> e.g. Mesh::outputTemperatures.

• Procedure descriptions are titled: proc <proc name>, e.g. proc gdDefineTech
• Var description section titles have no prefix, and are simply titled with the name of the particular
parameter, e.g. log_time_stamps. Since log_time_stamps is listed in the Flow section, it is obviously
a var, or parameter, of FlowVars.

The examples of Tcl code that follow assume that a Flow object named flow was previously defined as
in the section on the HeatWave Flow object in Tcl . Non-literals are enclosed in angle-brackets <like this>,
while optional parameters are enclosed in square brackets [like this]
The term domain used in several sections refers to the volume within which HeatWave computes tempera-
ture. This is typically part or all of your chip, perhaps including adjacent thermal-interface materials.

6.5 Flow

gda::Flow is a HeatWave database object that you create in your HeatWave scripts to store references to
your data, simulation-controls and processes needed to run the electro-thermal simulation flow. You should
only define this object once in your script. The gda:: prefix is the name-space within which all HeatWave
database objects, including Flow, are defined. HeatWave’s scripting interface relies on the existence of a
gda::Flow object, as does the thermal simulation program. So, a gda::Flow object is created by Heat-
Wave even when your data and controls are in plain text, or when using Context based Tcl utilities, where
you do not explicitly create a Flow object in a script. The Tcl syntax for the definition of a gda::Flow is in
the HeatWave Flow object in Tcl section.
To understand the format of this section, you should read How Vars, Methods and Procedures are de-
scribed. The next table summarizes the name, value, type, and default-value for each var or parameter,
following which are descriptions of each parameter.
The following sections describe the vars and methods associated with the Flow object.

6.5.1 log_time_stamps

This boolean value specifies whether time-stamps are written into the HeatWave logfile at significant points
in the simulation-flow. The default value is 0 (false).

64
 Scripting Primitives

FlowVars var Type Units Default Description

name
log_time_stamps boolean none 0 controls printing
of time-stamps, at
significant points
in logfiles

run_name string none "" directory that

stores transient
results

Table 3: FlowVars parameters

6.5.2 run_name

This string value is only used in Transient Thermal Simulation, and specifies a directory-name in which
transient results are stored. If no name is specified (the default case) HeatWave creates a name using of the
form <year>-<month>-<day>-<hour>-<minute>-<second>. If you specify a directory that already
exists, HeatWave creates a new name by appending a unique positive-integer to the original name (after
stripping integer suffixes). The appended integer values increase sequentially. All directories in the path
preceding the final name must exist. For example if you specify "transient/testResults", you should ensure
the "transient/" directory exists. HeatWave will create "testResults".

6.5.3 Flow::vars

Flow vars --> <FlowVars>

# Tcl example that gets FlowVars and configures one of its parameters:
> [flow vars] configure -log_time_stamps 1

6.5.4 Flow::designVars

Flow designVars --> <DesignVars>

#Tcl example that gets DesignVars and configures one of its parameters:
> [flow designVars] configure -max_power_density 5e6 ;# W/m^2

6.5.5 Flow::meshVars

Flow meshVars --> <MeshVars>

# Tcl example that gets MeshVars and configures one of its parameters:
> [flow meshVars] configure -initial_seed 6

6.5.6 Flow::tsolveVars

Flow tsolveVars --> <TSolveVars>

TSolveVars are the configuration variables associated with the Thermal Solver .

65
 Scripting Primitives

# Tcl example that gets TSolveVars and configures one of its parameters:
> [flow tsolveVars] configure -transient_solver 1

6.5.7 Flow::transientVars

Flow transientVars --> <TransientVars>

# Tcl example that gets TransientVars and configures one of its parameters:
> [flow transientVars] configure -stop_time 1e-5

6.5.8 Flow::getTech

Flow getTech --> <Tech>

# Tcl example that gets a Tech object,

# and makes it read a model package model
> [flow getTech] pkg.ini

6.5.9 Flow::getDesign

Flow getDesign --> <Design>

# Tcl example that gets a Design object and queries whether it was
# correctly loaded
> set isDesignLoaded [[flow getDesign] isLoaded]

6.5.10 Flow::getMesh

Flow getMesh --> <Mesh>

# Tcl example that gets a Mesh object and outputs temperature values
> [flow getMesh] outputTemperatures

6.5.11 Flow::getTSolve

Flow getTSolve --> <TSolve, or Thermal Solver object>

# Tcl example that gets a Thermal Solver and sets one of its parameters
> [[flow getTSolve] vars] configure -transient_solver 1

6.5.12 Flow::getTransient

Flow getTransient --> <Transient>

# Tcl example that gets a Transient Thermal Solver object and sets a critical threshold
> [flow getTransient] criticalTemperatureChange 5

66
 Scripting Primitives

6.5.13 Flow::getGUI

Flow getGUI --> <GUI>

# Tcl example that gets a GUI object and shows a graphics window
> [flow getGUI] show

6.5.14 Flow::libName

Flow libName --> <string library-name>

returns the name of the OA library containing the cell under analysis.

# Tcl example stores the OA library name containing your design in $myLibName
> set myLibName [flow libName]

6.5.15 Flow::cellName

Flow cellName --> <string cell-name>

returns the name of the OA cell under analysis.

# Tcl example that stores the current OA cell name in $myCellName

> set myCellName [flow cellName]

6.5.16 Flow::loadDesign

Flow loadDesign <string OA library-name> <string OA cell-name> [ <tech-file name> ]

requires 2 string inputs which respectively specify the OA library-name and OA cell-name of the design to
be read by HeatWave. The optional <tech-file name> specifies the name of the Thermal Technology File
that is later used to interpret the design’s layout-data. The default tech-file name is gdatech.ini
The loadDesign method loads the design layout data from the OpenAccess database, and the thermal
technology specification, both of which are later used to build the thermal simulation model of your design.

# Tcl example that loads specified design data, and technology from "gdatech.ini"
> flow loadDesign "testLibrary" "testCell"

6.5.17 Flow::archive

Flow archive <string archive file name>

writes a HeatWave archive file to the <archive-file-name> provided as a required input. You may later
restore the solution in the archive for review, or to use as the set of initial values for a transient thermal
simulation. By convention, the archive files have the suffix .gda Flow::setXYScale describes how scaling
affects Flow::archive and Flow::restore.

# Tcl example that archives data in "myDesign.gda" after thermal simulation

> flow archive "myDesign.gda"

67
 Scripting Primitives

6.5.18 Flow::restore

Flow restore <string archive-file-name>

reads the solution stored in a HeatWave archive file into HeatWave. This method requires one input , the
<archive-file-name>. The <archive-file-name> must refer to a HeatWave archive file consistent with the
current release of HeatWave (as may be obtained by invoking Flow::archive) . If not, error messages are
issued. After the contents of the archive are loaded, they may be examined in the GUI, or used as the initial
values for a transient thermal simulation. Flow::setXYScale described how scaling affects Flow::archive and
Flow::restore.

# Tcl example that restores data from "myDesign.gda"

> flow restore "myDesign.gda"

6.5.19 Flow::continueOnError

Flow continueOnError [<boolean value>]

takes one optional boolean argument, that, if true or 1, makes HeatWave continue execution, if possible,
after an error occurs. The results may be used to better understand the error, or to review inputs. The
default value is false, or 0.

# Tcl example to continue execution after errors

> flow continueOnError 1

6.5.20 Flow::setXYScale

Flow setXYScale <float x-y-scale-factor>

requires a single positive float value that specifies a scale factor to be applied to all geometries in the
design, in the X and Y directions. All vertices of layout geometries and power-sources are snapped to
the nearest OA dbu grid. To scale the thermal-model in the Z direction you must redefine the thermal-
technology-file or Tcl technology specification. If used, this method must be invoked only after all controls,
power-sources, and layout are loaded, for example, by invoking Flow::loadDesign. Any output-data uses
the scaled X,Y co-ordinates, including results viewed in the GUI. If you archive the scaled solution the scale
factor is saved in the archive. When you later restore the archive, the saved scale-factor is automatically
applied, unless you invoked setXYScale before restore. In that case the scale factor you specified to
setXYScale (i.e. not the one saved in the archive) is applied to the restored data.

# Tcl example that sets the scale-factor for X,Y values to 0.9 x original
# ... after all controls, power-sources and layout are loaded
> flow setXYScale 0.9

6.5.21 Flow::runSteadyState

Flow runSteadyState

after you have prepared the appropriate input files, defined a thermal technology, loaded your design data
and loaded a package-model, this method launches a steady-state thermal simulation as described in
the usage section. Your electrical solver initialization file determines if a circuit simulator is invoked to
compute power, as part of an electro-thermal loop. If the electrical solver runs a transient circuit-simulation,

68
 Scripting Primitives

HeatWave averages the resulting powers over the the simulation interval. After invoking this method, you
may invoke Mesh::outputTemperatures and Flow::archive to respectively report temperatures and save the
solution.

# Tcl example that runs a steady-state thermal simulation

# ... after all power-sources, layout, technology, and package, are loaded
> flow runSteadyState

6.5.22 Flow::runTransient

Flow runTransient

after you have prepared the appropriate input files, defined a thermal technology, loaded your design data,
loaded a package-model and defined transient controls this method launches a transient thermal simulation.
Your electrical solver initialization file determines if a circuit simulator is invoked to compute power, as
part of an electro-thermal loop. Following this method, you may invoke Mesh::outputTemperatures and
Flow::archive to respectively report temperatures and save the solution. The transient solution is saved
in the directory specified by run_name. You may later invoke Flow::transientStatisticsReport to reload the
solution in a specified run directory. You may later also invoke Flow::reloadTransient to load the transient
results at a specific time-point.

# Tcl example that runs a transient thermal simulation

# ... after power-sources, layout, technology, and package are loaded
> flow runTransient

6.5.23 Flow::transientStatisticsReport

Flow transientStatisticsReport

this method accepts no arguments, but searches your specified transient run-directory for HeatWave tran-
sient thermal simulation results. It then reloads all the raw solution-data, and checks if any user-defined
assertions are violated. It also makes any specified user-defined measurements If a GUI is launched, you
may then view a "Movie" of the transient results, built from the re-loaded data.

# load previously saved transient results from transient/testResults

> flow configure -run_name "transient/testResults"
> flow transientStatisticsReport

6.5.24 Flow::reloadTransient

Flow reloadTransient <float time-value>

this method requires a single float argument, which specifies a time value. This method is only useful
after you have re-loaded existing transient simulation results. This method loads the temperature values at
the specified time-value specified in seconds. You may then save these values in a HeatWave archive
file using Flow::archive.
You may now start a new thermal-simulation at time-value, by restoring the saved archive.

# Tcl example that loads transient results , and saves a time-point

> flow transientStatisticsReport
> flow reloadTransient 5e-3
> flow archive "fiveMilliSec.gda" ;# ready to "restore"

69
 Scripting Primitives

6.6 PlotVars

The gda::PlotVars is a HeatWave var object that you define and configure to save 3D, surface, and histogram
plots automatically using the GUI::savePlots method. To understand the format of this section, see How
Vars, Methods and Procedures are described.
The PlotVars are categorized into Sweep Parameters which are used to generate 3D and Surface plots and
Histogram Parameters which are used to generate histogram plots.

PlotVars var name Type Units Default Description

type int none 3 3, 2

quantity List none {Temp} Temp,
HeatFluxMag,
HeatFluxMagZ,
HeatFluxX, Heat-
FluxY,HeatFluxZ
TempGradient-
Mag,
TempGradientX,
TempGradientY,
TempGradientZ
inst_quantity List none {PowerDensity} PowerDensity,
Temp, Power
style List none {Shaded} Shaded, Contour,
IsoSurfaces
range List none {All} All, Slice, Window,
Manual
view List none {Top} / {Iso} Iso, Top, Bottom,
Left, Right, Front,
Back
z_values List of floats microns none Vertical height
z_layers List of strings none none Names of the
thermal layers.
window List of four {<user-units> none Lower left and
floats <user-units> upper right XY
<user-units> coordinate of
<user-units>} zooming rect.
axes_d List of two {<user-units> none Interpolation of
floats <user-units>} tick marks in x
and Y axis.
axes_n List of two ints none none No. of tick marks
in X and Y axis.
contour_count int none none No of contour
lines
contour_delta float none none Temp. diff of
contour lines
isosurface_count int none none No of iso lines
grid int none 0 0, 1
file_prefix string none none filename prefix
file_name string none none filename

Table 4: PlotVars Sweep Parameters

70
 Scripting Primitives

6.6.1 type

This int value specifies the window type to be used while saving the plots. Use 3 to specify MainWindow
and 2 to specify Surface Plot Window. The default value is 3.

# Tcl example that defines gda::PlotVars var type.

gda::PlotVars myBasicPlot
myBasicPlot configure -type 2

6.6.2 quantity

This string vector specifies the data to be plotted, for example, Temperature, Temperature Gradient, and
HeatFluxMag in the x, y, and z plane. Multiple values are supported and the possible values are listed under
Description in Sweep Parameters table.
This var cannot be used with inst_quantity var.

# Tcl example that defines gda::PlotVars var quantity.

gda::PlotVars myBasicPlot
myBasicPlot configure -quantity {Temp HeatFluxMag}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.3 inst_quantity

This string vector specifies the data to be plotted, for example, PowerDensity, Power, and Temperature.
Multiple values are supported and the possible values are listed under Description in Sweep Parameters
table. The "Temp" option is not applicable when type is 2.
This var cannot be used with quantity var.

# Tcl example that defines gda::PlotVars var inst_quantity.

gda::PlotVars myBasicPlot
myBasicPlot configure -inst_quantity {PowerDensity Power}}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.4 style

This string vector specifies the display settings to be used while saving the plots. Multiple values are
supported and the possible values are listed under Description in Sweep Parameters table.

# Tcl example that defines gda::PlotVars var style.

gda::PlotVars myBasicPlot
myBasicPlot configure -style {Shaded Isosurfaces Contour}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.5 range

This string vector specifies the different temperature ranges to be plotted. Multiple values are supported
and the possible values are listed under Description in Sweep Parameters table. To use "Manual", specify
lower and upper temperature values as shown in the following example.

71
 Scripting Primitives

# Tcl example that defines gda::PlotVars var range.

gda::PlotVars myBasicPlot
myBasicPlot configure -range {Window Slice {15 45} All}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.6 view

This string vector specifies the side of the chip to be used for saving the thermal profile images, for
example, Left, Right, Top, and Bottom. When GUI::savePlots API is invoked, all the plots corresponding to
each "view" is saved to the user specified location.

# Tcl example that defines gda::PlotVars var view.

gda::PlotVars myBasicPlot
myBasicPlot configure -view {Top}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.7 z_values

This float value specifies the vertical height from the bottom of the chip at which the thermal profile is
plotted and saved. Multiple values are supported and the values can be specified in exponential format as
shown in the following example.

# Tcl example that defines gda::PlotVars var z_values.

gda::PlotVars myBasicPlot
myBasicPlot configure -z_values {108.5e-6 97.5e-6}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.8 z_layers

This string value specifies a list of z-layer name to be plotted. Multiple values are supported and the
possible values are based on those defined in thermal technology file. For more information, see Thermal
Layer Definition.

# Tcl example that defines gda::PlotVars var z_layers.

gda::PlotVars myBasicPlot
myBasicPlot configure -z_layers {resistor metal1}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.9 window

This float values specifies the zoom area of the chip from "Top" view and saves the zoomed image when
GUI::savePlots API is invoked. Zooming is done into a rectangular area specified by the lower-left and
upper-right XY co-ordinates. The XY-axis and interpolation tick marks are drawn before saving the zoomed
image. The interpolation tick marks can be configured by using axes_d or axes_n vars. An extra portion
may be zoomed along with configured area to match aspect ratio of the chip.
This var is not applicable when type is 2.

# Tcl example that defines gda::PlotVars var window

# by lower-left and upper-right X,Y cordinates to zoom.
gda::PlotVars myBasicPlot

72
 Scripting Primitives

myBasicPlot configure -window {25.5 10 90.5 30}

# Draw interpolation tick mark in X and Y axis with 20um gap.
myBasicPlot configure -axes_d {20 20}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.10 axes_n

This float values specify the number of tick marks to be drawn along the X and Y axes respectively. This
var is applicable only when used with the window var.

# Tcl example that defines defines gda::PlotVars var axes_n.

gda::PlotVars myBasicPlot
myBasicPlot configure -window {25.5 10 90.5 30}
myBasicPlot configure -axes_n {10 20}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.11 axes_d

This float values specify the size of the interval (most of the time in <user-units>) between two tick marks
to be drawn along the X and Y axes respectively. This var is applicable only when used with the window
var.

# Tcl example that defines gda::PlotVars var axes_d.

gda::PlotVars myBasicPlot
myBasicPlot configure -window {25.5 10 90.5 30}
myBasicPlot configure -axes_d {20 20}
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.12 contour_count

This positive int value specifies the number of contour lines to be draw while saving the "Contour" plot.
This var is applicable only when "Contour" is specified as a parameter in style var. If not configured, the
default contour plot is saved.
This var cannot be used with contour_delta var.

# Tcl example that defines gda::PlotVars var contour_count.

gda::PlotVars myBasicPlot
myBasicPlot configure -style {Contour}
myBasicPlot configure -contour_count 43
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.13 contour_delta

This float value specifies the temperature difference between two contour lines. This var is applicable
only when "Contour" is specified in style and "Temp" is specified in quantity as one of the parameter. If you
do not configure this parameter, the default contour plot is saved.
This var cannot be used with contour_count var.

# Tcl example that defines gda::PlotVars var contour_delta.

gda::PlotVars myBasicPlot

73
 Scripting Primitives

myBasicPlot configure -style {Contour}

myBasicPlot configure -contour_delta 0.5
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.14 isosurface_count

This positive int value specifies the number of iso surfaces. This var is applicable only when "IsoSurfaces"
is specified as a parameter in style var. If you do not configure this parameter, the default IsoSurfaces plot
is saved.

# Tcl example that defines gda::PlotVars var isosurface_count.

gda::PlotVars myBasicPlot
myBasicPlot configure -style {IsoSurfaces}
myBasicPlot configure -isosurface_count 25
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.15 grid

This boolean value specifies whether grid points are drawn while saving the plots. The default value is 0.

# Tcl example that defines gda::PlotVars var grid.

gda::PlotVars myBasicPlot
myBasicPlot configure -grid 1

6.6.16 file_prefix

This string value specifies the <prefix> to be appended in the filename while saving the plots. Valid
characters for filename are alphanumeric characters, underscore (_), or hyphen (-).
This var cannot be used with file_name var.

# Tcl example that defines gda::PlotVars var file_prefix.

gda::PlotVars myBasicPlot
myBasicPlot configure -file_prefix steadyState_
[flow getGUI] savePlots myBasicPlot path/To/save

6.6.17 file_name

This string value specifies the filename used to save the plot image. Use this option only when a single
image needs to be saved. Valid characters for filename are alphanumeric characters, underscore (_), or
hyphen (-).
This var cannot be used with file_prefix var.

# Tcl example that defines gda::PlotVars var file_name.

gda::PlotVars myBasicPlot
myBasicPlot configure -file_name myDefaultPlot
[flow getGUI] savePlots myBasicPlot path/To/save

74
 Scripting Primitives

PlotVars var name Type Units Default Description

temp_histogram List of two {◦ C ◦ C <integer>} none Temperature

floats and one range and bin
int size.
power_histogram List of two {W W <integer>} none Power range and
floats and one bin size.
int
power_density_- List of two {W/m2 W/m2 none Power density
histogram floats and one <integer>} range and bin
int size.

Table 5: PlotVars Histogram Parameters

6.6.18 temp_histogram

This var is configured with a list of two floats and one positive int value. The first two floats specify
the temperature range and the last int specify the bin size of histogram to be plotted. Bin size cannot be
negative.

# Tcl example that defines gda::PlotVars var Temperature Histogram.

gda::PlotVars myHistPlot
myHistPlot configure -temp_histogram {12.8 152.8 65}
[flow getGUI] savePlots myHistoPlot "my/plots/"

6.6.19 power_histogram

This var is configured with a list of two floats and one positive int value. The first two floats specify the
power range and the last int specify the bin size of histogram to be plotted. Bin size cannot be negative.

# Tcl example that defines gda::PlotVars var Power Histogram.

gda::PlotVars myHistPlot
myHistPlot configure -power_histogram {-1 0.5 50}
[flow getGUI] savePlots myHistoPlot "my/plots/"

6.6.20 power_density_histogram

This var is configured with a list of two floats and one positive int value. The first two floats specify the
power density range and the last int specify the bin size of histogram to be plotted. The bin size cannot be
negative.

# Tcl example that defines gda::PlotVars var Power Denstity Histogram.

gda::PlotVars myHistPlot
myHistPlot configure -power_density_histogram {0 5 50}
[flow getGUI] savePlots myHistoPlot "my/plots/"

6.7 GUI

The gda::GUI object obtained by Flow::getGUI manages a Graphical User Interface to HeatWave. The
capabilities of GUI are described in the HeatWave User Interface Guide. To understand the format of this
section, read How Vars, Methods and Procedures are described.

75
 Scripting Primitives

6.7.1 GUI::show

> GUI show

launches a GUI with features as described in the HeatWave User Interface Guide.

# Tcl example that launches a GUI

[flow getGUI] show

6.7.2 GUI::saveDefaultPlots

NOTE: From this release, this method has been removed. Use the GUI::savePlots method instead.
You can use the GUI::savePlots API to save the default surface plot. To do so, define gda::PlotVars object
with type set to 2. When GUI::savePlots API is invoked, the default plot is saved to the user specified
location with user specified filename.

# Tcl example that saves default surface plot window.

gda::PlotVars myBasicPlot
myBasicPlot configure -type 2
myBasicPlot configure -file_name myDefaultPlot
[flow getGUI] savePlots myBasicPlot path/To/save

6.7.3 GUI::savePlots

> GUI savePlots <gda::PlotVars> <string>

requires 2 inputs, the first argument is a PlotVars object and the second argument is a string specifying the
absolute or relative path to the directory where images will be saved. The relative path is relative to the
location from where HeatWave is invoked.
The savePlots method saves multiple plots in PNG format to the user specified location. To use this method,
you must define gda::PlotVars object with the following properties: quantity, style, range, view, and z_-
values or z_layers. The plots are produced by "Cartesian Product" of the values specified in the PlotVars
variables. In a Cartesian product, value of one variable is kept constant while the values of other variables
are changed to cover all the possible combinations.
Invoke this method from cxtLocalPostRun or cxtPostRun callbacks in a batch mode. The method automat-
ically launches and closes an instance of the GUI to save plot images. When the method is invoked, it
uses the values of vars in the PlotVars object to save the images. If an error or if vars are not configured in
PlotsVars, the default values as specified in PlotVars Sweep Parameters table are used.
Example:
The following example code is based on the OPAMP example, as described in Complete Examples section.
This section shows how plots can be saved within a design flow based on HeatWave’s Tcl utilities, using
the HeatWave Context object, as described in the Using Tcl Utilities section.
This example covers default volume-plot of temperature, histograms of power, temperature and power den-
sity, and a few custom-configured plots.

# Tcl example that configure gda::PlotVars and save images.

# The below lines added to cxtLocalPostRun()procedure
# In our case it is inside gda_local.tcl file.

76
 Scripting Primitives

proc cxtLocalPostRun { flow } {

# Declaration of PlotVars, to used by save plot further.

gda::PlotVars myBasicPlot

# Save Default 3D Temperature volume Plot under defaultImages folder.

[flow getGUI] savePlots myBasicPlot defaultImages

#Configure and Save HistogramPlot

#Configure temperature histogram to range from 12.8 C to 152.8 C with bin size being 65
myBasicPlot configure -temp_histogram {100 130 65}

#configure power histogram to range from 0.0 Watt to 0.5 Watt with bin size being 50
myBasicPlot configure -power_histogram {0.0 0.5 50}

#configure power density histogram to range from 3.0+e07 to 4.0e+07 W/(m*m) with
#bin size being 50
myBasicPlot configure -power_density_histogram {30000000 40000000 50}

#save histograms plots inside "histogramImages" folder

[flow getGUI] savePlots myBasicPlot histogramImages

# Configure plot vars to save custom plots.

# Below section will save Shaded and Contour style plot of 3D Temperature volume in
# poly layer with window (10.5um 11um 30.5um 30um) and 3um,2um distant marker on x
# and y axis respectively.
myBasicPlot configure -type 3
myBasicPlot configure -quantity {Temp}
myBasicPlot configure -view {Top}
myBasicPlot configure -style {Shaded Contour}
myBasicPlot configure -z_layers {poly}
myBasicPlot configure -window {10.5 11 30.5 30}
myBasicPlot configure -axes_d {3 2}
[flow getGUI] savePlots myBasicPlot plotImages
}

6.7.4 HistogramPlot

GUI::savePlots API can save histogram plot images if the corresponding var in PlotVars is configured.
Histograms for Temperature, Power Density, and Power can be saved. All histogram var are configured with
a list of two floats and one int value. The float values specify the range and int value specify the bin
size of the histogram as explained in the following example scripts.

# Tcl example that saves Histogram Plot.

gda::PlotVars myHistPlot
myHistPlot configure -temp_histogram {12.8 152.8 65}
myHistPlot configure -power_histogram {-1 0.5 50}
myHistPlot configure -power_density_histogram {0 5 50}
[flow getGUI] savePlots myHistoPlot my/plots/

77
 Scripting Primitives

6.8 Design

The gda::Design object obtained by Flow::getDesign contains the layout and other physical data acces-
sible in the OpenAccess database. To understand the format of this section, you should read How Vars,
Methods and Procedures are described. The next table summarizes the name, value, type, and default-
value for each var or parameter, following which are descriptions of each parameter.

DesignVars var Type Units Default Description

name
max_power_- float W/m2 2.5e6 max
density power-density

Table 6: DesignVars parameters

6.8.1 max_power_density

This float value represents the maximum implied vertical heat-flux P/(w ∗ l) from a power source with
power P, width w and length l. A warning is issued if, for any power-source, this value exceeds max_-
power_density

6.8.2 Design::vars

Design vars --> <DesignVars>

This Design method takes no arguments and returns the DesignVars object. The same object is also directly
accessible using the Flow::designVars method.

# Tcl example that gets DesignVars and configures one of its parameters:
> [[flow Flow::getDesign] vars] configure -max_power_density 1e6

6.8.3 Design::isLoaded

Design isLoaded

requires no arguments, and returns a boolean value (0 or 1) indicating if the design was successfully
loaded.

# Tcl example that stores the method’s return value in Tcl variable $isLoaded
> set isLoaded [[flow Flow::getDesign] isLoaded]

6.8.4 Design::setBounds

Design setBounds <int left> <int bottom> <int right> <int top>

requires four int arguments which respectively define the left, bottom, right and top edges of a box, which
is the X,Y extent of the domain. This is the region at whose boundary your specified boundary-conditions
will apply. Your layout database may be larger than these bounds, in which case only layout data within the
specified bounds is used by HeatWave. The integer values are in OA database-units , usually nm. This
method has the same effect as the .ptab bounds statement.

# Tcl example that sets the bounds from (-1mm -1mm) to (1mm 1mm)
> [flow Flow::getDesign] setBounds -1000000 -1000000 1000000 1000000

78
 Scripting Primitives

6.8.5 Design::createPowerSource

Design createPowerSource <string name> <string layer> <float l> <float b>
<float r> < float t> [ <float power> ]

requires six arguments with a final optional argument. The string <name> is the name of the power-
source being defined. The string <layer> is the name of the thermal layer that the power source occupies.
The next four float arguments define respectively the left, bottom, right and top edges of a box, which is
the horizontal (X,Y) extent of the power source in OA user-units , usually microns. The vertical (Z) extent
of the power source is identical to that of the layer that you specify. The final optional float argument is
the power dissipated by this source in Watts; if unspecified it defaults to 0 Watts. If a power-source with the
specified name already exists, it is deleted, and the newly-defined source replaces it.

# Tcl example of a 10uW power-source in a region centered at the origin,

# with size X=100nm, Y=2um, Z="channel" thickness
> [flow Flow::getDesign] createPowerSource "P1" "channel" -5e-2 -1 5e-2 1 1e-5

6.8.6 Design::setProbe

Design setProbe <string power-source name> [ <int> ]

requires one argument with a further optional argument. The string <power-source name> is the name
of an existing power-source that will be defined (or undefined) as a probe. A probe is power-source for
which detailed temperature computations, currently the minimum and maximum temperatures within the
power-source’s volume, are stored.
The second optional input is an integer which, if non-zero, defines the named power-source as a probe. A
zero value undefines the probe, reverting to an ordinary power-source. The default value is 1.
The return value is non-zero if successful, and zero if an error occurred. All power sources are not probes
when originally created, but may be defined as probes using setProbe, after which they may continue to
dissipate power. If probes were defined the Mesh::outputTemperatures method outputs a file listing their
temperature details described above. Probe power-sources are plotted in the GUI without the usual cross-
filled "X" pattern.

# Tcl example that creates a power-source and further defines it as a probe.

# A power source may also be defined in the <libname>.ptab file
> [flow Flow::getDesign] createPowerSource "PROBE1" "channel" -0.5 -0.5 0.5 0.5
# Make the power source defined above a probe
> [flow Flow::getDesign] setProbe "PROBE1"

6.9 Tech

The gda::Tech object obtained by Flow::getTech contains a representation of the thermal-technology that
you define. The thermal-technology may be defined in a text technology-file, or procedurally, using the
methods in this section.

6.9.1 Tech Data Model

The following figure shows the schema, or data-model of the Tech object, for scripting.

79
 Scripting Primitives

Figure 11: Data Model of Tech Object for Scripts

As shown in the preceding figure, the Tech object may be obtained from a Flow by invoking Flow::getTech.
A thermal technology comprises the following:

• a set of one or more Materials with thermal properties defined. This set of Materials may be define by
repeated invocation of Tech::addMaterial, and is referenced by thermal-layer definition methods such
as Tech::addLayer and Tech::addMaskToLayer

• an ordered set of one or more thermal layers, each of which is a gda::Layer object. The first
declared layer is the lowest layer in the thermal stack, and is assigned the index 0. The bottom of
this layer is at Z=0 m, which is the lowest Z value in the thermal stack. The index is incremented by
one, for each subsequent layer. This set of thermal layers may be defined by repeated invocations of
Tech::addLayer . The gda::Layer object is described next.

The gda::Layer thermal layer object comprises the following:

• a thermal layer name

• a thermal layer thickness, in meters

• a background-material that, in the absence of further data, is the material that occupies the entire
volume of the the thermal layer.
• an ordered set of zero or more mask-layers, that defines the objects within the volume of a thermal
layer, and their material compositions. Each mask-layer is represented by a gda::Mask object, that is
automatically created when needed. Each mask-layer has an associated shape_material. The shapes
or geometries on each mask-layer imply 3D objects, made of shape_material, as described in the
Mask Layer section. Any mask-layer in the list has precedence over all mask-layers that follow it. So, if
shapes from multiple mask-layers overlap, the overlap region is composed of the shape_material
from the mask-layer that was earliest in the list. Note that the background-material has the lowest
precedence This set of mask-layers may be defined by repeated invocations of Tech::addMaskTo-
Layer .

The preceding concepts should be clearly understood before defining a thermal technology. Tech methods
are provided to define the Material objects and gda::Layer objects which compose a thermal technology.
To understand the format of this section, you should read How Vars, Methods and Procedures are de-
scribed. The Tech object has no accessible Vars. The description of Tech methods follows.

80
 Scripting Primitives

6.9.2 Tech::load

Tech load <string tech-or-pkg-file>

requires one string input, the name of a HeatWave technology or package definition file. The original text
technology-file contains definitions of both the thermal-layer stack and the package-model, or boundary-
conditions. In this case, load reads both technology-stack and package-model from the <tech-file>. If you
define your thermal-technology procedurally, using Tech methods, you still need to define a text package
model. Since the technology-stack is defined in Tcl, it is omitted. In this case load reads the package-
model from the <pkg-file>.

# Tcl example that loads technology or package definitions from "gdatech.ini"

> [flow Flow::getTech] load "gdatech.ini"

6.9.3 Tech::addMaterial

Tech addMaterial <Material>

requires one input, a Material object. The given Material is added to the set of materials defined in your
thermal-technology. The material is uniquely and fully identified by its Material name, which is distinct from
the name of the Material object. So, you may repeatedly provide the same Material object as the argument
to addMaterial, as long as the Material name is unique. If the argument you provide has a Material
name that is already in the Tech database, your new definition overwrites the existing one, and a warning is
issued. Once added to Tech, a Material may be referenced by name to other technology definition methods
such as Tech::addLayer and Tech::addMaskToLayer

# Tcl example that adds Materials to a thermal-technology

> gda::Material m
> m configure -name "Au" -thermal_conductivity [gdFunction1d {350}]
> [flow Flow::getTech] addMaterial m
> m configure -name "Ag" -thermal_conductivity [gdFunction1d {429}]
> [flow Flow::getTech] addMaterial m
> m configure -name "Au" -thermal_conductivity [gdFunction1d {318}]
> [flow Flow::getTech] addMaterial m
[WARN] overwriting existing material definition of Au

6.9.4 Tech::addLayer

Tech addLayer <string name> <float thickness> <Material background>

requires three inputs, to add a thermal-layer to the layer-stack. The section on the Tech data-model de-
scribes the gda::Layer object. The string <name> defines the name of the thermal-layer. The
float <thickness> in meters, defines the thickness of the thermal-layer. The <background> argu-
ment specifies the background material described in the Tech data model. The newly added thermal-layer
is topmost in the stack and has the highest layer-index, until another thermal-layer is added, as explained
in the Tech data model section, which also explains how Tech::addLayer may be repeatedly invoked, to add
an arbitrary number of thermal-layers to a given thermal-technology.

# Tcl example that adds a 2um gold thermal-layer to the thermal-technology

> gda::Material goldMat
> goldMat configure -name "Au" -thermal_conductivity [gdFunction1d {318}]
> [flow Flow::getTech] addMaterial goldMat
> [flow Flow::getTech] addLayer "gold_plane" 2e-6 goldMat

81
 Scripting Primitives

6.9.5 Tech::addMaskToLayer

Tech addMaskToLayer <string name> <string mask-name> <Material shape-material>

requires three inputs, to add a mask-layer to an existing thermal-layer. The string <name> identifies
the existing thermal-layer. The string <mask-name> identifies the existing mask-layer to add. The
shape-material argument has the effect described in the Tech data model section, which also explains how
Tech::addMaskToLayer may be repeatedly invoked, to add an arbitrary number of mask-layers to a given
thermal-layer.

# Tcl example that adds a metal thermal-layers to the thermal-technology

# assuming that an OpenAccess layer "M1" contains the geometries for this layer
> gda::Material Al
> Al configure -name "Al" -thermal_conductivity [gdFunction1d {200}]
> [flow Flow::getTech] addMaterial Al
> gda::Material oxide
> oxide configure -name "SiO2" -thermal_conductivity [gdFunction1d {1}]
> [flow Flow::getTech] addMaterial oxide ;# background is SiO2
> [flow Flow::getTech] addLayer "metal1" 5e-7 oxide
> [flow Flow::getTech] addMaskToLayer "metal1" "M1" Al

6.9.6 Tech::encrypt

Tech encrypt <string fileName> <string techProcName>

requires two inputs to encrypt technology file. The string <fileName> is the name of the input tech-
nology definition file and string <techProcName> is the name of the encrypted output file. The output
filename should be the tech callback name stored in Context variables. The encrypted output file is saved
in run directory with .enc extension. If an encrypted file is present in HeatWave run directory tech callback
will be ignored and technology information is loaded from encrypted file.

# TCL example of encrypting technology definition file anyTechFileName.tcl

# into myTechProc.enc."myTechProc" is the name of the Tcl technology procedure
# defined within "anyTechFileName.tcl"
> [flow Flow::getTech] encrypt "anyTechFileName.tcl" "myTechProc.enc"

6.9.7 proc gdWriteTechTcl

gdWriteTechTcl <Flow > [ < string outFile> [ < string outProc> ] ]

is a Tcl proc that unparses the thermal-technology currently in the database using Tech methods in Tcl,
and writes it to a file. The procedure requires one argument , a Flow object. Then next two arguments are
optional, the first being a string naming the output Tcl technology file. The default value of this parameter
is "gdatech.tcl". The technology is defined within a Tcl procedure whose name is defined by the second
(and final) optional argument. The default value of this parameter is "gdTechDefinition"

# Tcl example that unparses a loaded technology into Tech methods, in Tcl.
# assume that a thermal technology is defined
# define the technology within a proc named "myTechProc", in a file named "techfile.tcl"
> gdWriteTechTcl flow "techfile.tcl" "myTechProc"
# in another session, you may load the technology as follows:
# source techfile.tcl ; myTechProc flow

82
 Scripting Primitives

6.9.8 proc gdDefineTech

gdDefineTech <Flow> <material-list> <thermal-layer-list> [<heat-capacity-list>]

is a Tcl proc that enables you to define a thermal technology more compactly than when you use Tcl
methods. It requires three arguments; a Flow object, a Tcl <material-list> and a Tcl <thermal-layer-list>.
The fourth argument is optional and is a Tcl <heat-capacity-list>. The Tcl lists are described next.

• <material-list> is a list of sub-lists. Each sub-list has the format:

{material-name conductivity electron-mean-free-path}

where the items above are described in detail, in the Material section, except that the thermal_-
conductivity should be a list of table values, not a Function1d object. The electron-mean-free-path
value is optional.
• <thermal-layer-list> is a list of sub-lists. Each sub-list has the format:

{thermal layer-name thickness background-material [{l1 m1} {l2 m2} ... {lN mN}]}

where the first three (required) items are as described in the Tech Data Model and Material sections.
The remaining pairs define the (optional) set of mask-layers and corresponding materials associated
with this thermal layer. Each pair is a list of the form

{mask-layer-name shape-material}

as described for Tech::addMaskToLayer. A sub-list is completely ignored if its first element is the word
HW_IGNORE.

The final optional argument is described below:

• <heat-capacity-list> is a list of sub-lists. Each sub-list has the format:

{material-name heat_capacity_per_unit_volume }

where the items above are described in detail, in the Material section, except that heat_capacity_per_unit_-
volume
should be a list of table values, not a Function1d object.
gdDefineTech also loads a package file (default "./pkg.ini") if it exists. Otherwise, it issues a warning that
you may ignore.
The syntax above may appear complex, but it is actually fairly intuitive, and may be better understood by
reviewing the section on the Compact Technology Definition of a simple two-metal CMOS process, with a
pad layer on top.
After invoking gdDefineTech, it is still possible to incrementally further modify a thermal-technology, if you
have access to the appropriate Flow object. For example, Tech::addMaterial will fully overwrite an existing
Material object if the newly-added and existing Materials have identical Material::name fields.

6.9.9 Complete Example

The Complete Thermal Technology Example section describes the use of the Tech methods to fully define
the thermal technology for a simple two layer CMOS process. A compact definition of the same process
using proc gdDefineTech is in the section Compact Technology Definition.

83
 Scripting Primitives

6.10 Material

The gda::Material object is defined as a part of a thermal technology definition, represented within a
Tech object. Since a Material object has no current use outside a Tech object, it is treated as a nested or
subsidiary object within Tech and is omitted from the main data-model. However, it is an important element
of the Tech data model.
A Material is essentially a Vars object, and its member var or parameter values may be queried or configured
in Tcl accordingly. The relevant parameters in Material are shown in the Tech data model,
To understand the format of this section, you should read How Vars, Methods and Procedures are de-
scribed. The next table summarizes the name, value, type, and default-value for each Material var or
parameter, following which are descriptions of each parameter.

84
 Scripting Primitives

Material Type Units Default Description

parameter name
name string none "" material name

thermal_- Function1d W/(mK) undefined k(T ), T in ◦ C

conductivity
heat_capacity_- Function1d J/(m3 K) 1.63e6 CV (T ), T in ◦ C
per_unit_volume
size_dependent_- Function1d none 1.0 k(size)/
conductivity bulk_conductivity,
size in m

metal_electron_- float m bulk mean free path of

mean_free_path sentinel-value e− in metals

Table 7: Material parameters

6.10.1 name

This string value sets the name of the material. It is unrelated to the name of the Material object (e.g. in
a script), though they are often the same, for consistency.

# Tcl example, setting a Material name

> gda::Material goldObject
> goldObject configure -name "Au"
> goldObject cget -name
[inf] Au

6.10.2 thermal_conductivity

This Function1d defines thermal conductivity as a piece-wise function of temperature. The Thermal Solver
accounts for the temperature dependent thermal-conductivity in transient and steady-state thermal simula-
tions, as specified by Mesh k_update_iter .

# Tcl example, setting a Material thermal_conductivity

> gda::Material m
> m configure -thermal_conductivity [gdFunction1d {0 400 20 500 400 0.5}]

6.10.3 heat_capacity_per_unit_volume

This Function1d defines heat_capacity_per_unit_volume CV as a piece-wise function of temperature. The

Transient solver handles the temperature dependent CV .

# Tcl example, setting a Material heat_capacity_per_unit_volume

> gda::Material m
> m configure -heat_capacity_per_unit_volume [gdFunction1d {2e6}]

6.10.4 size_dependent_conductivity

The effective thermal conductivity of micro-scale objects can vary significantly from that of the bulk material.
This Function1d specifies the ratio of the effective thermal conductivity to the bulk thermal conductivity, as

85
 Scripting Primitives

a piece-wise function of the minimum dimension of an object, in meters. If size_dependent_conductivity is

defined, the parameter metal_electron_mean_free_path has no effect.

# Tcl example, setting a Material size_dependent_conductivity

> gda::Material m
> m configure -size_dependent_conductivity [gdFunction1d {0 1e-5 5e-8 1e-3 1e-5 1}]

6.10.5 metal_electron_mean_free_path

This float value in meters may only be set for metals in which heat is transported by electrons, such as
the metals found in typical ICs. This value specifies the electron mean free path at 300K in the material,
and is used to modify the thermal model when metal objects (usually wires) have dimensions comparable
to the metal_electron_mean_free_path. The default is a sentinel value that implies bulk properties.
Values above 1e6 are ignored. A typical value is around 50nm ; much larger values are non-physical and
should be avoided, as they imply tiny material conductivities.

# Tcl example, setting a Material metal_electron_mean_free_path

> gda::Material m
> m configure -metal_electron_mean_free_path 45e-9

6.11 Mesh

The gda::Mesh object obtained by Flow::getMesh contains the discretized domain, or mesh, that is the
simulation-model for the thermal solver. To understand the format of this section, you should read How
Vars, Methods and Procedures are described. The next table summarizes the name, value, type, and
default-value for each var or parameter, following which are descriptions of each parameter.

86
 Scripting Primitives

MeshVars var Type Units Default Description

name
initial_seed int none 5 initial meshing

initial_seed_x int none 0 initial meshing in

x

initial_seed_y int none 0 initial meshing in

y

power_source_- int none -1 (auto-set) meshing based

seed on power

spatial_resolution float OA user units -1 (auto-set) min. mesh size

◦
refine_temp_- float C 2.0 max. |∆T |, ∀
value elements

power_update_- int none 1 #iters of Power(T)

iter
k_update_iter int none 0 #iters of k(T)

refine_iter int none 0 ∇T based mesh

refine_temp_grad float m/◦ C 3e-6 #mesh-splits

based on T

reseed_iter int none 0 ∇P based mesh

reseed_power_- float W/m 1e2 #mesh-splits

grad based on P

balance_- int none 0 control thread

extraction_- work-load
threads
store_extracted_- int none 0 may reduce
geometry run-time

max_threads int none license-based thread-count

Table 8: MeshVars parameters

6.11.1 initial_seed

This int value results in an initial mesh with 2initial_seed elements in the x and y directions. The element
sizes in the x or y directions are uniform. The initial number of elements in the z direction is the number of
thermal layers. The default value of this parameter is 5.

87
 Scripting Primitives

Figure 12: Mesh due to initial_seed 2

6.11.2 initial_seed_x

If positive, this int value results in 2initial_seed_x uniformly sized elements in the x direction. At its default
value of 0, it has no effect on initial meshing, and initial_seed takes effect. The initial number of elements in
the z direction is the number of thermal layers.

6.11.3 initial_seed_y

If positive, this int value results in 2initial_seed_y uniformly sized elements in the y direction. At its default
value of 0, it has no effect on initial meshing, and initial_seed takes effect. The initial number of elements in
the z direction is the number of thermal layers.

6.11.4 power_source_seed

This positive int value specifies the number of times mesh-discretization is performed, using a fast tem-
perature estimator, that respects the spatial_resolution and refine_temp_value parameters. The default is
-1, which results in the value being automatically computed.

6.11.5 spatial_resolution

This positive float value determines the smallest element size. The default is -1.0, which results in
the value being automatically computed, and is the recommended setting. A tiny value may significantly
increase the mesh size. The units are Open Access user units.

6.11.6 refine_temp_value

This float value specifies the maximum temperature difference (◦ C) permitted within a mesh element, and
is used by all methods of mesh refinement. In particular it is used by refinement iterations due to refine_iter,

88
 Scripting Primitives

The default value is 2 temperature units, typically ◦ C.

6.11.7 power_update_iter

This int value specifies the number of iterations that compute power-source power-values at the current
temperature. Changes in power values result in a re-computation of temperature. The default value is 1.

6.11.8 k_update_iter

This int value specifies the number of thermal-solver iterations that use a temperature dependent thermal
conductivity, whether defined using a procedural technology file or a text tkl file. If temperatures converge,
the iterations stop. The default value is 0

6.11.9 refine_iter

This int value specifies the number of times the mesh may be refined, as one optional part of HeatWave’s
automatic mesh refinement. At each refinement iteration, the temperature difference (|∆T |) across each
element is checked. If this value is greater than the threshold
p specified by parameter refine_temp_value
, in any direction d, the number of splits is computed as 1 + ref ine_temp_grad ∗ |∇T | where ∇T is the
temperature gradient. A value above 2.0 is rounded up to the nearest integer power of 2, and the element
is discretized that many times in the direction d. The default value is 0.

6.11.10 refine_temp_grad

This float value determines the number of splits of an element during the refinement phase described for
parameter refine_iter. The default value is 3e-6.

6.11.11 reseed_iter

This int value specifies the number of times the discretization is refined to improve the spatial resolution of
the solution before temperature is calculated. The default value is 0. At each iteration, for each element, the
values of the power gradients with respect to its neighbors are checked. If the values exceed the threshold
value specified by the reseed_power_grad parameter, the element is split in the respective direction.A
negative number specifies the use of a newer alternate method that discretizes the domain similarly, but
with a smaller run-time.

6.11.12 reseed_power_grad

This float value specifies the maximum power gradient (W/m) during the initial discretization of the do-
main, and is only used during the reseeding iterations discussed above. The default value is 100.0 W/m.

6.11.13 balance_extraction_threads

This int value specifies the maximum number of elements to be processed as a set, in a thread, when
building a thermal model. If negative, auto-compute a value. Making this value small results in each thread
refreshing its data set more frequently, and balancing the work among the threads. The default , 0 , disables

89
 Scripting Primitives

this feature, using the default work-scheduler, which may lead to more unbalanced loading across threads.
If you use this setting , the recommended value is 1.

6.11.14 store_extracted_geometry

This int value specifies how the geometries processed by HeatWave are stored (as part of HeatWave’s
thermal model). If 0 (the default value) no geometry data is cached; it is re-loaded as needed. If 1, the
geometry data is stored in memory, which increases memory-use, but reduces run-time. The default value
is 0.

6.11.15 max_threads

This int value specifies the maximum number of threads a Mesh operation may launch. This value is
limited by the maximum number of threads allowed by your HeatWave license.

6.11.16 Mesh::vars

Mesh vars --> <MeshVars>

This Mesh method takes no arguments and returns the MeshVars object. The same object is also directly
accessible using the Flow::meshVars method.

Tcl example that gets MeshVars and configures one of its parameters:
> [[flow Flow::getMesh] vars] configure -initial_seed 6

6.11.17 Mesh::outputTemperatures

Mesh outputTemperatures [ <boolean do-annotate> ]

do-annotate is an optional boolean that controls whether temperatures are annotated from the mesh, onto
power-sources. The default is 1 (true). Setting it to 0 (false) is not recommended, unless you are sure that
the thermal simulation results from the previous iteration would not be significantly altered by annotation.
The output is a <cellname>.tval file containing the computed temperatures, and final-powers, of power-
sources. If Design::setProbe was invoked for any power-sources, their temperature details are reported in
a second output file named "<cellname>.tval.probe".

# Tcl example that writes power-source temperatures to file <cellname>.tval

# ... after commands to setup and run simulation
> [flow Flow::getMesh] outputTemperatures

6.11.18 Mesh::printLayerTemperatures

This function is for internal use only. Use summary instead.

6.11.19 proc gdSetModerateResolution

gdSetModerateResolution <Flow>

90
 Scripting Primitives

is a Tcl proc that sets Mesh controls for moderate thermal resolution, providing quicker access to a the
thermal profile of your design, and its effects on your circuit simulation. You may review the particu-
lar settings made by gdSetModerateResolution by reading its Tcl procedure definition in $GDA_-
ROOT/tcl/gdacontext.tcl

# Tcl example that sets moderate resolution for a thermal simulation

> gdSetModerateResolution flow
> flow Flow::runTransient runTransient

6.11.20 proc gdSetHighResolution

gdSetHighResolution <Flow>

is a Tcl proc that sets Mesh controls for a high thermal resolution, providing an accurate thermal profile
of your design, and its effects on your circuit simulation. You may review the particular settings made by
gdSetHighResolution by reading its Tcl procedure definition in $GDA_ROOT/tcl/gdacontext.tcl

# Tcl example that sets high resolution for a thermal simulation

> gdSetHighResolution flow
> flow Flow::runSteadyState runSteadyState

6.12 Thermal Solver

The gda::TSolve object obtained by Flow::getTSolve is the thermal solver that computes temperature in
the Mesh simulation model of the Design.
To understand the format of this section, you should read How Vars, Methods and Procedures are de-
scribed. The next table summarizes the name, value, type, and default-value for each var or parameter,
following which are descriptions of each parameter.

91
 Scripting Primitives

Thermal Solver Type Units Default Description

var name
transient_solver int none 0 transient-solver
type

Table 9: TSolveVars parameters

6.12.1 transient_solver

This int value selects the solver used for Transient thermal simulation. The default of 0 selects a moderate-
capacity solver which is fast on small designs, but may require large run-times on larger designs. The
current alternative is a setting of 1 , that enables a higher-resolution solver for larger designs. This setting
requires a license for HeatWave’s High Capacity transient-solver.

6.13 Transient Thermal Solver

The Vars, Methods, and Procedures associated with the transient thermal solver are described in a separate
section on Transient Electro-Thermal Simulation in HeatWave , whose principal sub-sections are as follows:

• Overview of transient electro-thermal simulation

• Transient Inputs
• Transient Electro-Thermal Loop

• Transient Solver Internals

• Transient Outputs
• Transient Parameters

• Transient Methods
• Transient Limits
• Transient Measures
• Transient Tcl Utilities

• Power Waveforms

92
 Thermal Technology Definition

7 Thermal Technology Definition

This section contains examples of thermal technology definitions using Tech methods and procedures It
contains links to many definitions and descriptions available only within this Reference Manual. This section
is also included in the HeatWave User Guide, since it contains several examples.

7.1 Complete Thermal Technology Example

This section describes the complete definition of a thermal technology, for a simple two-metal CMOS pro-
cess. The thermal technology definition is explained in a step-by-step manner, with illustrations of the
thermal-layer stack as defined up to that point. This should help you understand the distinct effect of each
set of layer-definition commands.
The HeatWave Reference Manual describes the thermal-layer, mask-layer, and material constructs, as
well as the Tech methods Tech::addLayer, and Tech::addMaskToLayer , that are used to define a thermal
technology.

Figure 13: Simple 2-metal CMOS layer-stack

The preceding "Simple 2-metal CMOS layer stack" figure shows the thermal layer stack that we will define,
by first creating a set of Material objects, and repeatedly invoking Tech methods addLayer and addMaskTo-
Layer.
The key above the layer-stack indicates the material (or, as in the case of "Power", the purpose) represented
by a given color in the thermal layer-stack. A colon ":" indicates that names following it are mask-layers (or
their complements) which are associated with the key-color. For example, the field-oxide below the Silicon
surface represents the complement of the DIFF mask-layer. The oxide surrounding metal segments and
vias is also defined by the complements of the respective mask-layers. The passivation Polyimide region
is defined by the complement of the PAD mask-layer. The "Power" regions represent where power-sources
will be defined in this example.
A few observations may help you to understand this example, and to better define your thermal technology.
Think thermally! Begin with a schema, or cross-section diagram of your layer-stack. Then, merge materials
(and the layers that represent them) in the stack if the materials do not have distinctly different thermal

93
 Thermal Technology Definition

properties. For example, wells, diffusion-islands, and bulk silicon materials may be approximated as the
same, and merged in many cases. The resulting thermal layer stack may be significantly less complex than
one that represents every material. It is also useful to note where horizontal lines appear in the cross-section
diagram of your technology’s layer-stack. Those horizontal locations are the boundaries of the thermal
layers in your thermal-technology definition, assuming they represent boundaries between materials with
significantly different thermal properties.

7.1.1 Materials

The materials in the thermal-layer stack are represented by the definitions of Material objects that have
thermal properties.
After defining a Flow object and getting a reference to its Tech object, the materials used in thermal-layer
stack are defined in Tcl as follows.

# Tcl definition of the thermal properties of the Silicon,

# Aluminum, Tungsten, Polysilicon , Oxide and Polyimide
# used in the thermal-layer stack

gda::Flow flow
set tech [flow getTech]

gda::Material Si
Si configure -name Si
Si configure -thermal_conductivity [gdFunction1d {
25 156.143 40 146.251 55 137.406
70 129.456 85 122.278 100 115.768
115 109.842 130 104.427 145 99.4622
160 94.8964 175 90.6852 190 86.7905
205 83.1793 220 79.8231 }]
Si configure -heat_capacity_per_unit_volume [gdFunction1d 1.63e6]

gda::Material Al
Al configure -name Al
Al configure -thermal_conductivity [gdFunction1d 237.0]
Al configure -metal_electron_mean_free_path 4e-08

gda::Material W
W configure -name W
W configure -thermal_conductivity [gdFunction1d 174.0]
W configure -electron_mean_free_path 4e-08

gda::Material PolySi
PolySi configure -name PolySi
PolySi configure -thermal_conductivity [gdFunction1d 100.0]

gda::Material SiO2
SiO2 configure -name SiO2
SiO2 configure -thermal_conductivity [gdFunction1d 1.0]

gda::Material Polyimide
Polyimide configure -name Polyimide
Polyimide configure -thermal_conductivity [gdFunction1d 0.5]

94
 Thermal Technology Definition

# add each material to the flow’s Tech object

# define only the materials you will later use in layer definitions
foreach m { Si Al W PolySi SiO2 Polyimide } {
$tech addMaterial $m
}

7.1.2 substrate

Figure 14: Layer 0: substrate

The Tcl definition of the substrate thermal-layer follows. When defining a thermal-stack, you should con-
sider omitting material distinctions, if their thermal properties are very similar. In this case, the wells and
bulk silicon have very similar thermal conductivities, which may be approximated as the same. You may
later define them as distinct materials, with different conductivities, to verify that the effects of the additional
detail are insignificant.

# Tcl definition of the substrate

# Layer number : 0
$tech addLayer substrate 0.00044 Si

7.1.3 oxide

Figure 15: Layer 1: oxide

95
 Thermal Technology Definition

The Tcl definition of the oxide thermal-layer follows. The Complete Thermal Technology Example section
explained how DIFF mask-layer is the complement or "negative" of the field-oxide pattern. So, geometries
on the DIFF mask-layer define where the Si material is present. All remaining areas of the DIFF mask-layer
are composed of SiO2 material. As explained in the substrate section, the wells, diffusion islands, and bulk
silicon have very similar thermal conductivities, which may be approximated as the same.

# Layer number : 1
$tech addLayer oxide 5e-06 SiO2
# Add masks to layer "oxide"
$tech addMaskToLayer oxide DIFF Si

7.1.4 channel

Figure 16: Layer 2: channel

The Tcl commands below define the channel thermal-layer, where power sources will be located, as shown
in the "Power" regions in the preceding figure . The Tcl may appear identical to that for the preceding oxide
thermal-layer, with the exception of the layer-thickness value. However, this thermal-layer could not be
omitted, or merged with the oxide thermal-layer. It must be defined as shown, because we wish to define
power-sources only within this thin "slice", and not within the rest of the "oxide" thermal-layer.
A thermal-layer does not exist simply to model the layout-data. It also determines the Z extent of power-
sources, i.e. the thickness of the region in which power is dissipated. This point should be clearly under-
stood.
The remaining parts of the "channel" thermal-layer definition have the same meaning as explained in the
preceding oxide section.

# Layer number : 2
$tech addLayer channel 1e-07 SiO2
# Add masks to layer "channel"
$tech addMaskToLayer channel DIFF Si

96
 Thermal Technology Definition

7.1.5 thinox

Figure 17: Layer 3: thinox

The Tcl commands below define the thinox thermal-layer, representing the "slice" of the chip containing the
thin-oxide under the gate. The command containing addMaskToLayer POLY ... requires some explanation.
It is needed to stop poly-contacts from extending down to the silicon surface, while allowing diffusion-
contacts to do so. If we removed this command all contacts (to poly or diffusion) would be present in this
thermal-layer (because of the addMaskToLayer CONT ... command).
By adding the command addMaskToLayer POLY and by defining the related shape-material as SiO2, we
ensure that wherever a shape exists on the POLY mask-layer the thinox thermal-layer is composed of SiO2
material. By defining the command addMaskToLayer POLY first, we ensure that wherever a CONT overlaps
a POLY shape, the shape on the POLY layer has precedence, and the overlap region is composed of SiO2.
The POLY mask-layer shapes are not part of the layer-stack at this point, but are shown in outline just
above the chip, as a reminder that the POLY mask-layer is of primary importance in the definition of this
thermal-layer.
The result is a thermal layer-stack as shown in the preceding "Layer 3: thinox" figure.

# Layer number : 3
$tech addLayer thinox 5e-08 SiO2
# Add masks to layer "thinox"
$tech addMaskToLayer thinox POLY SiO2
$tech addMaskToLayer thinox CONT W

97
 Thermal Technology Definition

7.1.6 poly

Figure 18: Layer 4: poly

The Tcl commands below define the poly thermal-layer, The command addMaskToLayer POLY , placed
first, ensures poly-contacts are not defined in this thermal-layer. Diffusion-contacts , which need to to touch
the silicon surface, are defined in this thermal-layer.

# Layer number : 4
$tech addLayer poly 2e-07 SiO2
# Add masks to layer "poly"
$tech addMaskToLayer poly POLY PolySi
$tech addMaskToLayer poly CONT W

98
 Thermal Technology Definition

7.1.7 contact

Figure 19: Layer 5: contact

The Tcl commands below define the contact thermal-layer, with contacts composed of Tungsten material,
and SiO2 material outside the contacts. Both poly-contacts and diffusion-contacts are defined in this layer.

# Layer number : 5
$tech addLayer contact 4.5e-07 SiO2
# Add masks to layer "contact"
$tech addMaskToLayer contact CONT W

7.1.8 metal1

Figure 20: Layer 6: metal1

99
 Thermal Technology Definition

The Tcl commands below define the metal1 thermal-layer, composed of Aluminum material , with SiO2
material outside the metal wires.

# Layer number : 6
$tech addLayer metal1 5.5e-07 SiO2
# Add masks to layer "metal1"
$tech addMaskToLayer metal1 M1 Al

7.1.9 via1

Figure 21: Layer 7: via1

The Tcl commands below define the via1 thermal-layer, composed of Tungsten material, with SiO2 material
outside the vias.

# Layer number : 7
$tech addLayer via1 5.5e-07 SiO2
# Add masks to layer "via1"
$tech addMaskToLayer via1 VIA1 Al

100
 Thermal Technology Definition

7.1.10 metal2

Figure 22: Layer 8: metal2

The Tcl commands below define the metal2 thermal-layer, composed of Aluminum material, with SiO2
material outside the metal wires.

# Layer number : 8
$tech addLayer metal2 6e-07 SiO2
# Add masks to layer "metal2"
$tech addMaskToLayer metal2 M2 Al

7.1.11 passivation

Figure 23: Layer 9: passivation

The Tcl commands below define the passivation thermal-layer, where shapes on the PAD mask-layer are
composed of Aluminum material. The pads fill openings in the Polyimide passivation material.

101
 Thermal Technology Definition

# Layer number : 9
$tech addLayer passivation 1.7e-06 Polyimide
# Add masks to layer "passivation"
$tech addMaskToLayer passivation PAD Al

7.2 Compact Technology Definition

This section describes a more compact definition of the same technology defined in the Complete Thermal
Technology Example section, using a procedure described in the HeatWave Reference Manual section on
proc gdDefineTech,

gdDefineTech <flow> <material-list> <thermal-layer-list> [<heat-capacity-list>]

The example defines the thermal technology for the same layer-stack described in the Complete Thermal
Technology Example section , and shown in the "Simple 2-metal CMOS layer stack" figure that follows:

Figure 24: Simple 2-metal CMOS layer-stack

In this case, the technology is defined within a Tcl procedure named twoMetalCMOSTech.

# Tcl example of a complete thermal technology description in Tcl.

gda::Flow flow
# invoke the following procedure to define the 2-metal CMOS thermal technology
proc twoMetalCMOSTech {flow} {
# silicon’s thermal_conductivity as a function of temperature
# Temperature dependent conductivity K(T): {T1 K1 T2 K2 ... TN KN}
set Si_K_T {
25 156.1425 40 146.2506 55 137.4056 70 129.4560
85 122.2778 100 115.7683 115 109.8419 130 104.4268
145 99.46221 160 94.89642 175 90.68520 190 86.79047
205 83.17932 220 79.82315
} ;# later automatically converted to a Function1d

#----------------------
# MATERIAL DEFINITIONS
#----------------------

102
 Thermal Technology Definition

# THERMAL CONDUCTIVITY
# { name thermal_conductivity W/(mK) [metal_electron_mean_free_path (m)] }
set K_list "
{Si {$Si_K_T} }
{PolySi 100 }
{SiO2 1 }
{Al 237 4e-8 }
{W 174 4e-8 }
{Polyimide 0.5 }
"
# K_list is enclosed in quotes, so $Si_K_T is evaluated

# VOLUMETRIC HEAT CAPACITY (use material names from K_list)

# {name heat_capacity_per_unit_volume J/(m^3 K)}
set Cv_list {
{Si 1.63e6}
} ;# no $variables used, so braces {} are ok

#----------------------------
# THERMAL LAYER DEFINITIONS
#----------------------------
# {name thickness(m) bkgnd-material {lyr1 mat1}...{lyrN matN}}
set layer_list {
{ substrate 440e-6 Si }
{ oxide 5e-6 SiO2 {DIFF Si} }
{ channel 0.1e-6 SiO2 {DIFF Si} }
{ thinox 0.05e-6 SiO2 {POLY SiO2} {CONT W} }
{ poly 0.2e-6 SiO2 {POLY PolySi} {CONT W} }
{ contact 0.45e-6 SiO2 {CONT W} }
{ metal1 0.55e-6 SiO2 {M1 Al} }
{ via1 0.55e-6 SiO2 {VIA1 Al} }
{ metal2 0.60e-6 SiO2 {M2 Al} }
{ passivation 1.7e-6 Polyimide {PAD Al} }
}
# the last parameter is optional, so $Cv_list may be omitted
gdDefineTech flow $K_list $layer_list $Cv_list
}

A thermal layer may effectively be ignored by making its first element the word HW_IGNORE, as described
in gdDefineTech.
Example: To ignore the poly thermal-layer, specify

{ HW_IGNORE poly 0.2e-6 SiO2 {POLY PolySi} {CONT W} }

7.3 Text Technology Definition

This section describes the same technology as do the Complete Thermal Technology Example and Com-
pact Technology Definition sections, but uses a plain-text format described in the Technology File section,
for comparison.
You should note the following limitations of the plain-text Technology File format:

• at most one mask-layer may be associated with a thermal layer

• all the Material object’s parameters are not available, since there is no explicit concept of a material

103
 Thermal Technology Definition

• scripting constructs such as loops and branches are not available

The preceding limitations make the thinox and poly thermal layers (defined in the Complete Thermal Tech-
nology Example and Compact Technology Definition sections) undefinable using this text syntax, since they
require multiple mask-layers per thermal layer. So, the thinox and poly thermal layers are omitted below,
resulting in a less accurate thermal model.

# plain text technology definition

#
# name thickness k kbar [mask]
#-------------------------------------------
0: substrate 440e-6 120 120
1: oxide 5e-6 120 1 DIFF
2: channel 0.1e-6 120 1 DIFF
3: contact 0.70e-6 174 1 CONT
4: metal1 0.55e-6 237 1 M1
5: via1 0.55e-6 174 1 VIA1
6: metal2 0.60e-6 237 1 M2
7: passivation 1.70e-6 237 0.5 PAD

In the previous sections temperature dependent conductivity was specified using Tcl. In this case, it is
specified in a file of the following format, which was described in the section on Temperature Dependent
Conductivity.

siliconTable 25 156.1425
siliconTable 40 146.2506
siliconTable 55 137.4056
siliconTable 70 129.4560
siliconTable 85 122.2778
siliconTable 100 115.7683
siliconTable 115 109.8419
siliconTable 130 104.4268
siliconTable 145 99.46221
siliconTable 160 94.89642
siliconTable 175 90.68520
siliconTable 190 86.79047
siliconTable 205 83.17932
siliconTable 220 79.82315
use k siliconTable oxide channel
use kbar siliconTable substrate

104
 Transient Electro-Thermal Simulation

8 Transient Electro-Thermal Simulation

8.1 Overview

HeatWave is capable of transient thermal simulation. If you configure an electrical solver, you may run
a transient electro-thermal simulation to obtain the temperature profile of your design and more accurate
circuit-simulation results, since instance specific time-varying temperatures are annotated into your simula-
tion netlist.
You run transient thermal simulation by invoking Flow::runTransient, so transient simulation must be
launched from a script using HeatWave’s Tcl primitives and utilities.
The concepts behind the electro-thermal loop, descriptions of the Transient Inputs and Transient Outputs
as well as the Vars, Methods, and Procedures related to transient thermal simulation follow.

8.2 Transient Inputs

Many of the inputs to transient thermal simulation are the same as for steady-state simulation, and are as
described in the section on Input/Output Text Files. In particular:

• you define power sources as described in the Power Source Extent Table (.ptab) section

• you may define initial power-values as described in the Power Value File (.pval) section
• you define a thermal technology procedurally or in a text technology-file
• you define electrical solver controls as described in the electrical solver initialization file section

• you define boundary conditions, including package and bond-wires as in the sections on Package
Model and Package and Bond Model Declarations.

Other inputs are, however, specific to transient thermal simulation. They are described in the following
sections, and are summarized here:

• you may define Transient vars to control transient simulation, and the Transient Electro-Thermal Loop.
• you should set up simulation netlists and HeatWave parameters for transient simulation as described
in the Electrical Solver section

• you add volumetric heat capacity specifications to the boundary conditions, as described in the Pack-
age Model section
• you add volumetric heat capacity specifications to the technology definition as described in the section
on heat_capacity_per_unit_volume

• you may define input power which varies with time, but not with temperature, as described in the
Power Waveforms section.

8.3 Transient Electro-Thermal Loop

This section describes the coupling between the electrical solver and the thermal solver, that implements
transient electro-thermal simulation in HeatWave
The concept of an electro-thermal loop is described in the Electrical Solvers Overview section and is shown
in the following figure:

105
 Transient Electro-Thermal Simulation

Figure 25: Electro-thermal loop

You may configure HeatWave to launch and manage an electro-thermal loop, where the power dissipated
by each instance is computed in a circuit-simulator and read into HeatWave’s thermal solver that computes
temperature per power source. These instance specific temperatures are annotated back into the circuit
simulator’s netlist, by HeatWave, to complete an iteration.
The time-steps taken within a circuit simulator are typically much smaller than those necessary in an intra-
die thermal solver, due to different physical "time-constants" in the two domains. Therefore, it is not nec-
essary to "fully couple" the two simulators, and solve the electrical and thermal problems simultaneously.
Instead, the electrical and thermal simulations are adaptively synchronized. This means that when user-
specified thresholds for temperature (or its rate of change) are exceeded, the electrical and thermal simu-
lations are forced to synchronize, and update their respective temperature and power inputs, in a "loosely
coupled" electro-thermal loop.
The following figure describes the iterations in such a transient electro-thermal loop, and the iterations within
the respective electrical and thermal solvers.

Figure 26: Transient Electro-Thermal Iterations

The preceding figure shows a sequence of steps in the electro-thermal loop, and the corresponding pro-
gression within the electrical solver (circuit-simulator) and thermal-solver, along a synchronous timeline
from time 0 to time 100 in arbitrary time-units (e.g. 10ns). Steps in the electro-thermal loop are labeled

106
 Transient Electro-Thermal Simulation

S0-S4, while the corresponding time-periods in the electrical and thermal-solvers are labeled e0-e4 and
t0-t4 respectively.
First consider only the uppermost timeline. Successful steps, whose |∆T emperature| and |∆P ower| are
both below user-specified thresholds, are shown as solid (green) arcs, while failed steps are shown as
dashed (red) arcs. The first electro-thermal step S0 from time 0 to time 40 is successful. HeatWave then
tries a longer step, S1, from time 40 to time 100, that fails. HeatWave then tries a shorter step, S2, from
the last successful time 40, to time 80, that also fails. Finally an even shorter step S3 from time 40 to time
60 succeeds. It is followed by another successful step S4 from time 60 to time 90. This progression should
give you a sense of the adaptive time-step control in the electro-thermal loop managed by HeatWave.
Next, consider events within the electrical and thermal solvers during the steps S0-S4. For clarity, only the
successful steps e0, e3, e4 and t0, t3, t4 are shown. At the start of e0, the electrical solver is initialized with
temperatures computed from the user specified boundary conditions for HeatWave. The circuit-simulator
runs from time 0 to time 40. As expected, the circuit simulator has internal timesteps shown by tick marks
along the e0 timeline, that are adaptively varied to compute converged currents, voltages, and power dissi-
pated per instance in the physical netlist.
These instance-specific power-values are read into HeatWave’s Thermal Solver, as shown by the e0-t0
arc. The power values are used to compute temperature throughout the die, including the temperature of
each instance, from time 0 to time 40. The thermal solver also has adaptive internal timesteps, shown by
tickmarks along the t0 timelines, that are typically larger than the internal timesteps of the circuit simulator,
as implied by the tick-marks. If instance powers and temperatures are both below user-specified thresholds,
the (time-averaged) instance temperatures are annotated into the circuit-simulator’s netlist as indicated by
the t0-e3 arc. This completes a successful iteration of the electro-thermal loop.
The power and temperature data for the steps e1, t1, e2 and t2, are discarded, since they were part of the
failed electro-thermal steps S1 and S2.
The temperatures computed by the last successful thermal step t0 are used to launch a circuit simulation
e3 . This leads to another successful iteration, with power-values read into HeatWave in e3-t3, transient
thermal simulation done in t3, and updated temperatures annotated into the circuit simulator in step t3-e4.
The steps within S4, namely e4, e4-t4, and t4 ... are similarly successful.
Some Transient vars described in Transient Parameters control the electro-thermal loop’s time-steps S0-S4
. Other Transient vars control the Transient Solver Internals, including the time-steps, for example, within
interval t0. The distinction between these two types of controls should be clearly understood.

8.4 Transient Invocation

After you have assembled the required inputs, you may only run transient thermal simulation by invoking
Flow::runTransient, which may only be invoked from a script. Your script may use any of HeatWave’s Tcl
primitives and utilities.

8.5 Transient Solver Internals

The internals of a single transient thermal-solver iteration (for example, t0 from time 0 to time 40 in the
Transient Electro-Thermal Iterations figure), are now described. The transient solver begins with an initial_-
time_step. For every step after the first step, the transient solver computes two error estimates which
roughly correspond to the first and second order terms of the temperature change during the step. If
these computed first and second order error terms exceed the respective Transient parameters epsilon1 or
epsilon2, the internal time-step is reduced by a pre-determined, but not necessarily fixed, amount. The new
time-step must exceed the minimum_time_step. Results are computed using the new time step. If both
error estimates are less than their respective limits, the time-step may be increased. At the end of each
time step an output snapshot storing the current state of the system may be created if the temperature

107
 Transient Electro-Thermal Simulation

change, time-interval, or number of time-steps since the last snapshot, respectively exceed the values of
the parameters snapshot_temperature_change, snapshot_time_interval, or snapshot_step_interval,

8.6 Transient Outputs

The main results of each electro-thermal simulation are saved within the transient run-directory specified
by the Flow parameter run_name. The outputs in this run-directory are:

• a transient HeatWave archive named Model.gda

• snapshots saved in a file named TransientSnapshots

• a nutmeg format waveform results in a file named Waveforms.raw You may invoke nutmeg
Waveforms.raw and plot power-source temperatures over time using commands like plot
T(<power-source1>) T(<power-source2>) ... . Please refer to the nutmeg manual.
Waveforms.raw may be viewed using several commercial or Open Source waveform viewers, in-
cluding the free GNU Waveform Viewer or the KJWaves viewer. Waveforms.raw may also be
post-processed by the Open Source POST package
• a tab-separated waveform-file named Waveforms.txt, that may be imported into a spreadsheet.

This data-set is automatically loaded by Flow::transientStatisticsReport, as described in that section.

8.7 Transient Parameters

This section describes the TransientVars, or parameters that control the transient electro-thermal simulation
launched by Flow::runTransient, and specify the information required in the solution.

8.7.1 Scope of Transient Parameters

The figure used to explain the Transient Electro-Thermal Loop is reproduced below, to clarify the scope of
various transient parameters.

108
 Transient Electro-Thermal Simulation

Figure 27: Scope of Transient Parameters

The section on the Transient Electro-Thermal Loop explained the difference between electro-thermal loop
time-steps, and the internal time-steps of the transient thermal solver. The preceding figure shows the
scope of various Transient parameters , which may be summarized as follows:

• electro-thermal loop simulation interval and time-steps are controlled by the TransientVars start_time,
stop_time, time_step and time_steps, described in their respective sections
• the remaining Transient parameters (i.e. those not named above) control the Transient Solver Inter-
nals, within a single step of the electrothermal loop. The section on Transient Solver Internals provides
details.

Note the degenerate case that occurs when you set time_step to 0, as described in the section on time_-
step.
To understand the format of the rest of this section, you should read How Vars, Methods and Procedures are
described. The next table summarizes the name, value, type, and default-value for each var or parameter,
following which are descriptions of each parameter. It is recommended that, at least initially, you set only
the parameters needed to control your simulation’s start_time, stop_time, time_step (or time_steps), and
possibly the "snapshot" parameters and the minimum_time_step. Modify the remaining parameters only if
results show that you need to tradeoff run-time for accuracy.

109
 Transient Electro-Thermal Simulation

Transient Type Units Default Description

parameter name
start_time float s 0.0 start simulation

stop_time float s 0.0 stop simulation

time_step float s 0.0 outer-loop

time_steps Function1d s undefined outer-loop

time-step(time)

initial_time_step float s 1e-6 internal scope

minimum_time_- float s 0 internal scope

step
maximum_time_- float s 0.1 internal scope
step
◦
epsilon1 float C 0.1 internal error
threshold

◦
epsilon2 float C 0.1 internal error
threshold

step_reduction_- float none 2.0 internal scope

factor
low_error_- float none 0.1 internal scope
threshold
◦
snapshot_- float C 2.0 max |∆T | since
temperature_- last snapshot
change
snapshot_time_- float s 0.1 max time since
interval last snapshot

snapshot_step_- int none 1000 max #time-steps

interval since last
snapshot

verbosity int none 0 solver verbosity

Table 10: Transient parameters

8.7.2 start_time

This float value in seconds specifies the time in the simulation-domain at which the electro-thermal sim-
ulation begins. The default value is 0.

8.7.3 stop_time

This float value in seconds specifies the time in the simulation-domain at which the electro-thermal sim-
ulation ends. The default value is 0.

110
 Transient Electro-Thermal Simulation

8.7.4 time_step

As explained in the sections on the Scope of Transient Parameters the time_step parameter controls the
"steps" taken in the electro-thermal loop, not the internal steps of the thermal solver.
This float value in seconds specifies the upper-bound for a single step in the electro-thermal loop. The
default value is 0 (see further below). The time-step is adaptive, which means that steps smaller than
time_step may be taken, if changes in temperature exceed thresholds that you specify.
If time_step is 0 (the default value), a degenerate case exists, where there is no electro-thermal loop. A
single thermal-simulation spans the entire interval from start_time to stop_time. For example, with time_-
step set to 0, in the "Scope of Transient Parameters" figure, t0 would extend from time 0 to time 100, as an
uninterrupted thermal simulation and the parameters controlling simulation internals apply in this interval.
This mode may be useful if all power definitions are fixed Power Waveforms that do not need to be updated
as temperature changes.
Being a single value, time_step has limitations. Though the thermal solver’s internal time-step is adaptively
varied, it may take several iterations to converge, particularly if significant changes in power-values occur
rapidly in your design. Since each electro-thermal iteration involves a circuit-simulation, setting a smaller
time_step speeds up this process. However, in intervals where the power varies insignificantly, the electro-
thermal loop uses at most the specified time_step, since it is an upper bound. In these intervals, a larger
time_step is preferred.
So, to enable a more efficient electro-thermal loop it is useful to be able to specify a time step which varies
as a function of the simulation-time. The time_steps parameter provides this capability. From your circuit-
simulation results, you can deduce which time-intervals have rapidly or slowly varying powers, so you can
directly specify a time-step as a function of simulation-time. A time_steps definition has precedence over a
time_step definition, so the latter is ignored if the former is defined.

8.7.5 time_steps

The limitations of a single-valued time_step are described in the section on time_step. To overcome these
limitations it is useful to be able to specify a time step that varies as a function of the simulation-time. The
parameter time_steps is a Function1d that you may define to specify time-step values (in seconds), as a
function of simulation-time values (in seconds). A time_steps definition has precedence over a time_step
definition, so the latter is ignored if the former is defined.
Your circuit simulation can produce power waveforms, that provide you knowledge of the time-intervals with
rapid and slowly changing power. Given this information, you may directly specify the time-step as a function
of time.
Time-values within time_steps are suggested upper-bounds, just as the single-valued time_step is. So,
time_steps need not exactly match power-changes, since the actual electro-thermal time-step is adapted
from the suggested value. However, the better the time_steps match changes in your circuit’s power, the
faster the electro-thermal simulation will advance. The following figure shows how to define time_steps(time)
so the transient thermal simulation will run more efficiently.

111
 Transient Electro-Thermal Simulation

Figure 28: Efficient Time-Step Control

The upper plot in the figure shows the total power (or the power on devices of interest) dissipated within a
design, over time t. The lower plot shows time-step ts (t), as function of time, in 2 curves. The "idealized"
curve represents what one might intuitively specify for time-steps as a function of time. Before time ti the
"idealized" plot shows we want a large time-step ta . When the power changes rapidly, between times ti and
ti+1 , we want a small time-step tb . When the power returns to a constant value at time ti+1 , we may again
take large time-steps of size tc . However, specifying the "idealized" values in your function for time_steps
could be very inefficient. For example, if HeatWave happened to query the function just before time ti , it
would try a large time-step ta . This would probably fail, due to the sudden change in power, and eventually
the adaptive time-step control would take small steps starting at ti . However, every failed step is inefficient,
particularly as it runs a circuit simulation.
We can best avoid the extra time-steps by specifying a function like the "actual, efficient" curve in the lower
plot. In this curve, the time-steps specified before ti are optimally decreased as the simulator approaches
time ti , ensuring that we do not take a time-step larger than tb after time ti . The "efficient" function begins
to reduce the time-step at time ti-2 (= ti - ta ), ensuring HeatWave does not "overshoot", and will use the
smaller time-step tb leading up to, and after, time ti . After using a small timestep tb while power changes,
between ti and ti+1 , we may relax the timestep back to a larger value tc at time ti+2 .
A review of the power dissipated by your design over the simulation period, should allow you to outline the
"idealized" function, and use it to define the "efficient" function to HeatWave, as the value for time_steps.
A Tcl example follows, for a circuit with modest power-changes from time 0 to time 0.2ms, large power-
changes from time 0.2ms to time 0.3ms, and low power-changes for times after 0.3ms. Note that the
timesteps begin to decrease at time 0.15ms, to avoid a sharp transition at time 0.2ms. Note also the
ramped increase from a timestep of 5e-7 at time 0.3ms to a timestep of 1e-5 at time 0.3095ms. Both points
are illustrated in the "Efficient Time-Step Control" figure above.

112
 Transient Electro-Thermal Simulation

# take small time-steps when power changes quickly (0.2ms to 0.3ms)

# take larger steps when power does not change (after 0.3ms)
set variableSteps [gdFunction1d {
0.0 50e-6 150e-6 50e-6
199.5e-6 5e-7 300e-6 5e-7
309.5e-6 1e-5 500-6 1e-5
500e-6 1e-4 5e-3 1e-4 } ]
[flow transientVars] configure -time_steps $variableSteps

8.7.6 initial_time_step

This float value in seconds specifies the initial internal time-step in a thermal solver iteration. The default
value is 1e-6.

8.7.7 minimum_time_step

This float value in seconds specifies the minimum internal time-step in a thermal solver iteration. The
default value is 0.

8.7.8 maximum_time_step

This float value in seconds specifies the maximum internal time-step in a thermal solver iteration. The
default value is 0.

8.7.9 epsilon1

This float value in ◦ C specifies the maximum internal first-order error allowed for computed temperature
values. The default value is 0.1.

8.7.10 epsilon2

This float value in ◦ C specifies the maximum internal second-order error allowed for computed tempera-
ture values. The default value is 0.1.

8.7.11 step_reduction_factor

This dimensionless float value > 1.0 specifies the factor by which the internal time-step may be increased
(or decreased) when the error is smaller (or larger) than the epsilon1 and epsilon2 thresholds. This factor
may be modified or ignored, depending on other computations. The default value is 2.0

8.7.12 low_error_threshold

This float value < 1.0 in ◦ C specifies how small the computed error must be before the step_reduction_-
factor may take effect. The default value is 0.1.

113
 Transient Electro-Thermal Simulation

8.7.13 snapshot_temperature_change

This float value in ◦ C specifies the largest |∆T emperature| permitted between snapshots. A new snap-
shot is taken if this threshold is exceeded. The default value is 2.0.

8.7.14 snapshot_time_interval

This float value in seconds specifies the largest time-interval permitted between snapshots. A new snap-
shot is taken if this threshold is exceeded. The default value is 0.1.

8.7.15 snapshot_step_interval

This dimensionless int count specifies the largest number of internal time-steps permitted between snap-
shots. A new snapshot is taken if this threshold is exceeded. The default value is 1000.

8.7.16 verbosity

This dimensionless int specifies how much detail the solver outputs to the HeatWave logfile, with 0 being
the quietest. A high value may result in a large HeatWave log-file. The default value is 0.

8.8 Transient Methods

This section summarizes the Methods that launch a transient simulation, monitor variables during the simu-
lation, and archive results or load existing archives. They are defined as Flow methods rather than Transient
methods, because they often require access to most of the objects within a Flow.
A summary of these methods, and the sections that describe them, follows.
You may set up and launch a transient electro-thermal simulation as described in the section on Flow::run-
Transient.
You may restore the previously archived results of a transient electro-thermal simulation as described in the
sections on Flow::transientStatisticsReport and Flow::restore. Flow::transientStatisticsReport also checks
for violations of the monitors and limits that you define, as described in the sections on Transient Limits and
Transient Measures.
You may also reload results at a specific time point, and archive them as the initial conditions for another
transient thermal simulation, as described in the section on Flow::reloadTransient.
You may view the previously archived results of a transient electro-thermal simulation, including a time-
varying "movie" of the thermal profile, as described in the sections on Flow::transientStatisticsReport and
GUI::show. GUI features are described in the HeatWave User Interface Guide.

8.8.1 Transient::vars

Transient vars --> <TransientVars>

This Transient method takes no arguments and returns the TransientVars object. The same object is also
directly accessible using the Flow::transientVars method.

# Tcl example that gets TransientVars and configures one of its parameters:
> [[flow Flow::getTransient] vars] configure -time_step 0

114
 Transient Electro-Thermal Simulation

8.8.2 Transient::criticalTemperatureChange

Transient criticalTemperatureChange <float>

This Transient method requires a single float value in ◦ C which defines a critical temperature-threshold.
When the temperature-change of any power source exceeds this threshold in a given time_step, the current
temperature-solution is discarded. Then the time-step is reduced and temperatures are re-computed, as
described in the Transient Electro-Thermal Loop section.

# Tcl example that sets the critical temperature threshold for all power-sources
# to 10 degC
> [flow Flow::getTransient] criticalTemperatureChange 10.0

8.8.3 Transient::criticalTemperatureChangeRate

Transient criticalTemperatureChangeRate <float>

This Transient method requires a single float value in ◦ C/s which defines a critical temperature-change
rate. When the rate of temperature-change for any power source exceeds this threshold in a given time_-
step, the current temperature-solution is discarded. Then the time-step is reduced and temperatures are
re-computed, as described in the Transient Electro-Thermal Loop section.

# Tcl example setting the critical temperature rate for all power-sources
# to 1e7 degC/s
> [flow Flow::getTransient] criticalTemperatureChangeRate 1e7

8.8.4 Transient::criticalTemperatureChange

Transient criticalTemperatureChange <string ps> <float>

This Transient method requires two arguments. The first is a string name of a power source ps, for
which the threshold is set. The second is a float value in ◦ C that defines a critical temperature-threshold
for ps. This setting overrides any general settings by Transient::criticalTemperatureChange. When the
temperature-change of the power source ps exceeds this threshold in a given time_step, the current
temperature-solution is discarded. Then the time-step is reduced and temperatures are re-computed, as
described in the Transient Electro-Thermal Loop section.

# Tcl example that sets the critical temperature threshold for power-source
# M9 to 5 degC
> [flow Flow::getTransient] criticalTemperatureChange "M9" 5.0

8.8.5 Transient::criticalTemperatureChangeRate

Transient criticalTemperatureChangeRate <string ps> <float>

This Transient method requires two arguments. The first is a string name of a power source ps, for which
the threshold is set. The second is a float value in ◦ C/s that defines a critical temperature-change rate
for ps. This setting overrides any general settings by Transient::criticalTemperatureChangeRate. When the
rate of temperature-change for the power source ps exceeds this threshold in a given time_step, the current
temperature-solution is discarded. Then the time-step is reduced and temperatures are re-computed, as
described in the Transient Electro-Thermal Loop section.

# Tcl example setting the critical temperature rate for power-source

# M2 to 5e6 degC/s
> [flow Flow::getTransient] criticalTemperatureChangeRate "M2" 5e6

115
 Transient Electro-Thermal Simulation

8.9 Transient Limits

This section describes the procedures that monitor variables during runtime, to detect when user-defined
limits (i.e. assertions) are violated. After simulation, Flow::transientStatisticsReport checks specified limits
and makes specified measurements when invoked.
Limits are conditions that you define, that should not be violated. For example, you specify that HeatWave
should report when the temperature of MOSFET instance M9 exceeds 125 ◦ C.
The section on Transient Measures defines a related concept, of which you should be aware.
Following are descriptions of the HeatWave procedures you may invoke in your thermal simulation scripts
to define Transient Limits.

8.9.1 proc gdTranTemp

gdTranTemp <Flow> <string src> -max <float m> -dmax <float dm>

This procedure requires a string power source name src and one or more float valued switches. The
-max switch accepts a float value m that specifies a maximum temperature in ◦ C for the power source
src. The -dmax switch accepts a float value dm that specifies the maximum temperature-difference in
◦
C that the power source src may experience over a single electro-thermal step. If either of these limits is
exceeded, the event is reported in HeatWave’s logfile. In this report, you may see the abbreviation CTI for
a "critical time step", which is the same as a single electro-thermal step.

# Tcl example setting a maximum temperature limit of 125 degC and a

# maximum temperature-difference per time-step of 7.5 degC for instance "M2"
> gdTranTemp flow "M2" -max 125 -dmax 7.5

8.9.2 proc gdTranPower

gdTranPower <Flow> <string src> -max <float m> -dmax <float dm>

This procedure requires a string power source name src and one or more float valued switches.
The -max switch accepts a float value m that specifies a maximum power in Watts for the power source
src. The -dmax switch accepts a float value dm that specifies the maximum difference in power that the
power source src may experience over a single electro-thermal step. If either of these limits is exceeded,
the event is reported in HeatWave’s logfile. In this report, you may see the abbreviation CTI for a "critical
time step", which is the same as a single electro-thermal step.

# Tcl example setting a maximum power limit of 3mW and a maximum

# power-difference per time-step of 0.1mW for instance "M2"
> gdTranPower flow "M2" -max 3e-3 -dmax 0.1e-3

8.9.3 proc gdTranDTemp

gdTranDTemp <Flow> <string to> <string from> -max <float m> -dmax <float dm>

This procedure sets a differential limit between two power sources and requires at least three inputs. Two
required string inputs are power source names to and from, with respective temperatures Tto and Tfrom
. The differential quantity measured is ∆T = Tto − Tf rom . At least one additional switch argument (-max
or -dmax) is required. The -max switch accepts a float value m that specifies a maximum value for ∆T
in ◦ C. The -dmax switch accepts a float value dm that specifies the maximum value for ∆T in ◦ C over a
single electro-thermal step. If either of these limits is exceeded, the event is reported in HeatWave’s logfile.

116
 Transient Electro-Thermal Simulation

In this report, you may see the abbreviation CTI for a "critical time step", which is the same as a single
electro-thermal step.

# Tcl example setting a maximum temperature-difference of 3.5 degC and a maximum

# temperature-difference per time-step of 0.5 degC from instance "M2"
# to instance "M9"
> gdTranDTemp flow "M9" "M2" -max 3.5 -dmax 0.5

8.9.4 proc gdTranDPower

gdTranDPower <Flow> <string to> <string from> -max <float m> -dmax <float dm>

This procedure sets a differential limit between two power sources and requires at least three inputs. Two
required string inputs are power source names to and from, with respective powers Pto and Pfrom .
The differential quantity measured is ∆P = Pto − Pf rom . At least one additional switch argument (-max or
-dmax) is required. The -max switch accepts a float value m that specifies a maximum value for ∆P in
Watts. The -dmax switch accepts a float value dm that specifies the maximum value for ∆P in Watts,
over a single electro-thermal step. If either of these limits is exceeded, the event is reported in HeatWave’s
logfile. In this report, you may see the abbreviation CTI for a "critical time step", which is the same as a
single electro-thermal step.

# Tcl example setting a maximum power-difference of 1mW and a maximum

# power-difference per time-step of 0.1 mW from instance "M4" to instance "M25"
> gdTranDPower flow "M25" "M4" -max 1e-3 -dmax 0.1e-3

8.10 Transient Measures

This section describes the Procedures that monitor variables during runtime to make temperature measure-
ments that you specify. After simulation Flow::transientStatisticsReport checks specified limits and makes
specified measurements when invoked.
Measures are measurements that you require HeatWave to make. For example, you may specify that
HeatWave should measure the maximum temperature of instance M2 between time 1.1ms and time 1.4ms.
The section on Transient Limits defines a related concept, of which you should be aware.
Following are descriptions of the HeatWave procedures you may invoke in your thermal simulation scripts
to define Transient Measures.

8.10.1 proc gdTranMeasureTemp

gdTranMeasureTemp <Flow> <string src> -avg|min|max <float-pair>

This procedure a requires one string input and at least one switch argument, to specify that HeatWave
measure some function of the time-varying temperature of a power source. The required string input src
specifies a power source name, whose temperature will be measured. One to three additional switches
-avg, -min, or -max may be specified. Each switch specified must be followed by a <float-pair>, that
is a vector of 2 time values, defining a time interval. The time interval extends from the first float time-
value (in seconds) to the second float time-value (in seconds) in the <float-pair>. Each switch has
a distinct <float-pair> time-interval. The -avg, -min, or -max switches respectively make HeatWave
measure the average, minimum or maximum temperatures of src over the time-interval specified for each
switch. The measurements are reported in HeatWave’s logfile.

# Tcl example reporting the average temperature from 0 to 2ms, the maximum

117
 Transient Electro-Thermal Simulation

# temperature from 1ms to 1.5 ms and the minimum temperature from 0.5ms to
# 1ms respectively, all for instance "M2"
> gdTranMeasureTemp flow "M2" -avg [gdFloats {0 2e-3}]
-max [gdFloats {1e-3 1.5e-3}]
-min [gdFloats {0.5e-3 1e-3}]

8.11 Transient Tcl Utilities

The invocation of transient electro-thermal simulation in a complex and general, but simply customizable
flow is described in the Tcl Utilities section. The HeatWave Context in Tcl, with its variables and utilities,
may be easily used to configure the customizable thermal simulation flow.

8.12 Power Waveforms

Power-waveforms may be defined by the HeatWave user, which have precedence over any power-values
computed in electrical solvers for a given power source. These power waveforms may only be specified
using HeatWave’s scripting interface. Following are descriptions of the Constant, Step, Linear, Pulse, PWL,
Exponential, and Sine waveforms, whose syntax resembles the voltage or current source definition syntax
used by circuit-simulators . The general syntax for waveform definition is:

gdTranSourcePower <flow> <power source> -<waveform-type> <float-vector>

where
<flow> is the name of the gda::Flow in your script
<power-source> is the name of the power source whose power is being defined
<waveform-type> is constant, step, linear, pulse, pwl, exp, or sine.
<float-vector> is a <vector of floats>, including power values in Watts

The particular syntax in Tcl should be obtained from the detailed descriptions in the sections on Using Tcl
in your HeatWave scripts , including HeatWave Flow object in Tcl, HeatWave procedures in Tcl, and Heat-
Wave Function1d in Tcl . Tcl examples are provided in the following sections. The <waveform-type> and
the contents of the <vector of floats> defined above are described for each waveform in the following
sections. Power is specified in Watts and time is specified in seconds, within the definitions of waveforms.

8.12.1 Constant Waveform

This power waveform has a specified constant value at any time:

The -<waveform-type> is -constant
The <vector of floats> is PCON ST AN T
where PCON ST AN T is the constant power value

# A Tcl example of a constant waveform definition follows:

gda::Flow flow
# assume a power-source named constSrc is defined elsewhere
gdTranSourcePower flow "constSrc" -constant [gdFloats 1.234e-5]

8.12.2 Step Waveform

This power waveform is a step function.

The -<waveform-type> is -step

118
 Transient Electro-Thermal Simulation

The <vector of floats> is { tST EP PST EP }

where the step waveform rises from an initial value of 0 Watts to a final value of PST EP (W ) at time
tST EP (s) .

# A Tcl example of a step waveform definition follows:

gda::Flow flow
# assume a power-source named stepSrc is defined elsewhere
# the step is from 0W to 1mW at 0.5 ms
gdTranSourcePower flow "stepSrc" -step [gdFloats {5e-4 1e-3}]

8.12.3 Linear Waveform

This power waveform is a step followed by a linear ramp.

The -<waveform-type> is -linear
The <vector of floats> is { tST ART PST ART dP/dt }
where the step waveform rises from an initial value of 0 Watts to a value of PST ART (W ) at time
tST ART (s), then increases linearly with a slope dP/dt (W/s) .

# A Tcl example of a linear waveform definition follows:

gda::Flow flow
# assume a power-source named linSrc is defined elsewhere
# define a step from 0W to 1mW at 0.5ms, then rising at a rate of 1000 (W/s)
gdTranSourcePower flow "linSrc" -linear [gdFloats {5e-4 1e-3 1e3}]

8.12.4 Pulse Waveform

This power waveform is a periodic pulse.

The -<waveform-type> is -pulse
The <vector of floats> is { P1 P2 TD TR TF W T }
Descriptions of the parameters, and a waveform annotated with the parameters, follow:

Figure 29: Pulse Waveform Parameters

119
 Transient Electro-Thermal Simulation

Figure 30: Pulse Waveform

# A Tcl definition of the pulse waveform plot above follows:

gda::Flow flow
set pulseSpec [gdFloats {0.3 1.8 1e-6 0.25e-6 0.5e-6 1e-6 2.5e-6}]
# assume a power-source named pulseSrc is defined elsewhere
gdTranSourcePower flow "pulseSrc" -pulse $pulseSpec

8.12.5 Piece Wise Linear Waveform

This power waveform is a piece-wise linear function.

The -<waveform-type> is -pwl
The <vector of floats> is { T0 P0 [ T1 P1 T2 P2 ... TN PN ]}
where only one pair given implies a constant source with power P0
Descriptions of the parameters, and a waveform annotated with the parameters, follow:

Figure 31: PWL Waveform Parameters

120
 Transient Electro-Thermal Simulation

Figure 32: PWL Waveform

# A Tcl definition of the PWL waveform plot above follows:

gda::Flow flow
set pwlSpec [gdFloats {0.0 0.25 5e-7 0.25 1e-6 1 2e-6 0.5 ...
3e-6 0.5 4e-6 1 ... 4.5e-6 1.1 }]
# assume a power-source named pwlSrc is defined elsewhere
gdTranSourcePower flow "pwlSrc" -pwl $pwlSpec

8.12.6 Exponential Waveform

This power waveform is a pair of exponentials, first rising then falling.

The -<waveform-type> is -exp
The <vector of floats> is { P1 P2 TD1 τ1 TD2 τ 2}
Descriptions of the parameters, and a waveform annotated with the parameters, follow:

Figure 33: Exponential Waveform Parameters

121
 Transient Electro-Thermal Simulation

Figure 34: Exponential Waveform

# A Tcl definition of the exponential waveform plot above follows:

gda::Flow flow
# assume a power-source named expSrc is defined elsewhere
gdTranSourcePower flow "expSrc" -exp [gdFloats {0.5 1.5 1e-6 3.5e-7 2e-6 1e-6}]

8.12.7 Sine Waveform

This power waveform is a sinusoid with an initial delay, damping factor, and phase.
The -<waveform-type> is -sine
The <vector of floats> is { P0 PA F TD Θ φ }
Descriptions of the parameters, and a waveform annotated with the parameters, follow:

Figure 35: Sine Waveform Parameters

122
 Transient Electro-Thermal Simulation

Figure 36: Sine Waveform

# A Tcl definition of the sinusoidal waveform plot above follows:

gda::Flow flow
# assume a power-source named sineSrc is defined elsewhere
gdTranSourcePower flow "sineSrc" -sine [gdFloats {1.1 0.8 2e6 1e-6 3e5 0}]

123
 Tcl Utilities

9 Tcl Utilities

9.1 Overview

HeatWave’s Tcl Utilities define a Customizable Thermal Simulation Flow that is capable of any combination
of thermal simulation actions needed by a typical user. The flow is controlled by a HeatWave Context in
Tcl, that is a collection of control variables. Your CAD organization may define one or more such Contexts,
as well as callback procedures, to configure the Customizable Thermal Simulation Flow. You may use
these Contexts and callbacks, as already defined, or easily modify them to customize an existing thermal
simulation flow.
The following figure shows the schema or data-model of the Tcl Utilities that define a simulation flow,
configurable using Contexts and callbacks.

Figure 37: Tcl Utilities in the HeatWave Data Model

The arrows from the shaded box indicate that utilities invoke the low-level scripting primitives to configure
and control HeatWave Objects.
This flow mentioned above is the union of all the actions a typical user is expected to take. Therefore it is
complex, as described the Customizable Thermal Simulation Flow section. However, the work of writing
commands to perform any step in this flow has been done for you. You need only specify which parts of the
configurable flow to run, what data to use, and add any special customizations, in callbacks.
Your CAD department will define most of the necessary Context variables and callback procedures to
configure a thermal simulation flow to meet your needs. You may then run a simulation by invoking gd-
Run with your Context as its only argument.
Your CAD department should use the Tcl features auto_mkindex, auto_load and auto_reset to define
and use tclIndex files, described in the section on HeatWave procedures in Tcl. This will allow you to
automatically load the callbacks for technology definition and other customizations, that are provided by
your CAD department, by simply setting the TCLLIBPATH environment variable to the location(s) containing
tclIndex files. You may need to customize the simulation flow by locally setting a few Context variables ,
or by defining a local callback procedure.

124
 Tcl Utilities

9.2 Using HeatWave Tcl Utilities

The descriptions of HeatWave Tcl Utilities often refer to several basic types of objects. Most are described
in the section on Basic Concepts for Scripting Primitives and the section on Using Tcl in your HeatWave
scripts.
Descriptions of the additional Tcl constructs used in Tcl Utilities follow.

9.2.1 HeatWave Context in Tcl

Tcl supports the definition of associative arrays in which the array index is a string, as explained in
this tutorial on Tcl associative arrays. The Tcl array command allows you to create and
manipulate associative arrays in Tcl.
A Tcl associative array is a set of elements, where each element associates a string name with its value.
A HeatWave Context or Cxt is simply a Tcl associative array. Each name in the associative array is called
a Context variable. Each variable in the associative array has an associated value. So, you may think
of a Context as a set of specific variable names, each of which has a value. A Tcl example of how to
define a Context and set or get one of its variable’s values follows

gd[0]> global runVars() ;# define a global array (empty)

gd[1]> gdNewVars runVars ;# runVars is now a default Context
gd[2]> set runVars(batch) 1 ;# batch variable is 1 ; run in batch
gd[3]> puts "batch is $runVars(batch)" ;# prints value of batch
[inf] batch is 1

Command #0 defines an empty associative array named runVars

Command #1 uses the HeatWave utility gdNewVars to define a set of default valued Context variables within
the runVars array
Command #2 shows the syntax to set the value of any associative array in Tcl. Note the absence of a $
when setting the array field. In this case the Context batch variable’s value is set to 1, specifying a batch
simulation.
Command #3 shows the syntax to get the value of any associative array in Tcl. Note the use of a $ when
accessing the array’s data. In this case the Context batch variable’s value is obtained, and printed.
HeatWave uses one Context at a time, and the current Context is named gdCxtVars. Many HeatWave
Context Procedures operate on gdCxtVars, but you need not set it directly. Instead, you define your
Context and pass it to HeatWave’s Utilities as an argument.
The values of Context variables define and control a Customizable Thermal Simulation Flow, as described
in the section on Context Variables.

9.2.2 Context Callbacks in Tcl

A callback is simply a Tcl procedure with a predetermined name and arguments, that you may optionally
define. HeatWave will invoke this procedure (if defined) during the Customizable Thermal Simulation Flow.
All Context callbacks that you define must take one required argument (and any number of optional argu-
ments). The required argument must be a gda::Flow object. HeatWave will invoke your callback procedure
with the current gda::Flow object as its only argument. If your callback accepts other (optional) arguments,
HeatWave will not define any, so they will have their default values.
The point within the customizable flow at which your callback procedure is invoked is determined by the
name of the procedure. For example, the actions you define within the callback cxtPreLoad are perfomed
just before your design is loaded.

125
 Tcl Utilities

The section on Context Callback Names describes how Context variables are also used to store the default
names of the callbacks that you define to customize actions within the thermal simulation flow

9.3 Context Procedures

This section describes the Tcl procedures that allow you to define a Context, and specify , or read, the
the values of its variables. These procedures also determine the actions within the Customizable Thermal
Simulation Flow.
As explained in the section on HeatWave Context in Tcl, HeatWave uses one Context at a time, and the
current Context is named gdCxtVars. Some of the following procedures operate on gdCxtVars, but you
never need to set it directly. Instead, you define your Context and pass it as an argument to some of the
following procedures.

9.3.1 proc gdNewVars

gdNewVars <context-name>

This HeatWave utility creates a HeatWave Context in the given context-name, with all its variables set
to their default values. Once you set the Context variables appropriately for your simulation (and perhaps
define a few callbacks), you simply invoke gdRun to run a thermal simulation.

> global myContext()

# Tcl example to run the Customizable Thermal Simulation Flow using the given Context settings
> gdNewVars myContext ;# build default Context
> gdRun myContext ;# run a simulation

9.3.2 proc gdGetVar

gdGetVar <variable-name> --> variable-value

This HeatWave utility returns the value of the given variable-name in HeatWave’s current Context.

# Tcl example that gets the current value of Context variable run
> set runValue [gdGetVar run]

9.3.3 proc gdSetVar

gdSetVar <variable-name> <variable-value>

This HeatWave utility sets the value of the given variable-name to the given value, in HeatWave’s current
Context.

# Tcl example that set the current value of Context variable run
> gdSetVar run 0 ;# load existing data, don’t run

9.3.4 proc gdRun

gdRun <context-name>

126
 Tcl Utilities

This HeatWave utility runs a thermal simulation that uses the given Context’s variables to configure the flow
described in the Customizable Thermal Simulation Flow section.

# Tcl example to run a Customizable Thermal Simulation Flow using given Context settings.
> global myContext()
> gdNewVars myContext ;# build default Context
> gdRun myContext ;# run a simulation using settings in "myContext"

9.3.5 proc gdIsTransientMode

gdIsTransientMode

This HeatWave utility returns 0 if the current Context’s trans variable is an empty string "", meaning that
a transient run-directory was not specified, so a steady-state thermal simulation will be run. If the trans
variable specifies a directory-name, then a non-zero value is returned, indicating that a transient thermal
simulation will be run.

# Tcl example with different actions for steady-state and transient thermal simulations
> if { ![gdIsTransientMode] } {
<steady-state thermal actions>
} else {
<transient thermal actions>
}

9.3.6 proc gdCxtInfo

gdCxtInfo <string message>

This HeatWave utility prints a given string message to the HeatWave log file

# Tcl example to log a given message

> gdCxtInfo "simulating cell [gdGetVars cellname]"

9.3.7 proc gdCxtLogVars

gdCxtLogVars

This HeatWave utility writes the names and values of the current Context’s variables to the HeatWave log
file.

# Tcl example to log the names and values of context variables

> gdCxtLogVars

9.4 Context Variables

The HeatWave Context in Tcl section introduced the concept of a Context. The following sections summa-
rize the particular variables stored in a the HeatWave Context. Your CAD software support group, or you,
may prepare multiple Contexts with varied variable-settings, allowing you to select the appropriate one to
configure the customizable flow as required. Examples of the use of these variables are in the Complete
Transient Script section.

127
 Tcl Utilities

CxtVars var name Type Units Default Description

batch boolean none 0 0=batch; else gui

run boolean none 1 0=load previous,

else run

summary boolean none 1 if not 0, log layer

temperatures

archive string none <cell>∗.gda write archive file

restore string none "" restore this

archive

package string none pkg.ini package definition

txttech string none gdatech.ini text techfile

cellname string none "" OpenAccess cell

libname string none "" OpenAccess lib

scalexy float none -1.0 scale input data

composite float W/(mK) -1.0 if > 0, use as K ∀

layers

verbosity int none 0 utilities’ verbosity

userdata Tcl data user-defined "" user-defined data

trans string none "" run/load transient

dir

trtimes list of floats s undefined {start stop step

min-step} times

trsteps list of floats s undefined list {time_steps}

reloads list of floats s undefined reload ∀ time in

list

Table 11: Context Variables

128
 Tcl Utilities

9.4.1 batch

This boolean value, if set to 0 will launch a GUI at the end of the configurable flow. If non-zero, the
configurable flow will be run in batch mode. The default value is 0

9.4.2 run

This boolean value, if set to a non-zero value, will enable a steady-state or transient thermal simulation.
If set to 0, no simulation will be run, and previously saved results will be loaded. If in transient mode, the
data-set in the directory specified by trans is loaded. Otherwise, in steady-state mode, the archive specified
in the restore variable is restored. The default is 1.

9.4.3 summary

This boolean value, if set to a non-zero value, will print a summary of the temperature values in each
thermal layer, to the HeatWave logfile. If 0, no such summary in printed. The default is 1.

9.4.4 archive

This string value, if set to a valid file-name will make HeatWave archive the current solution in the given
file-name. If the value is an empty string "", the file-name is set to <cellname>.gda in steady state, or
<cellname>_tran.gda in transient mode. If those file-names exist the respective archives written are <cell-
name>_out.gda or <cellname>_tran_out.gda. If you do not wish to archive the solution, set this variable to
"SKIP_ARCHIVE". The default value is "" (empty string).

9.4.5 restore

This string value, if set to a valid file-name, will make HeatWave restore the solution previously archived
in the given file-name. The solution will be restored before a transient or steady-state simulation is started.
If this value is an empty string and run is false, then some archive must be loaded; in this case the archive
<cellname>.gda is sought and loaded. The default value is "" (empty string).

9.4.6 package

This string value, if set to a valid file-name, provides HeatWave a package model or boundary conditions
for thermal simulation of the chip, as described in section on Package and Bond Model Declarations. This
file need not contain a Text Technology Definition. The default (file-name) value is "pkg.ini", in your thermal
simulation run directory.

9.4.7 txttech

This string value, if set to a valid file-name, specifies a Text Technology Definition for HeatWave, using
the syntax described in the sections on the Technology File. The default (file-name) value is "gdatech.ini",
in your thermal simulation run directory.

129
 Tcl Utilities

9.4.8 cellname

This string value specifies the OpenAccess cell-name that contains the layout data to be thermally simu-
lated. Since this variable is specific to your design data, this variable has no default value

9.4.9 libname

This string value specifies the OpenAccess library-name that contains the cellname to be thermally sim-
ulated. Since this variable is specific to your design data, this variable has no default value

9.4.10 scalexy

This float value , if above 0.0, specifies the scale factor to be applied, using Flow::setXYScale, to the
input layout and power-source data, as they are read in. If the given value is not positive, scaling is not
done. Then default value is -1.0.

9.4.11 composite

This float value in units of W/(mK), if above 0.0, sets the thermal-conductivity of all materials, and there-
fore all thermal-layers, to the given value. This is useful if you need to quickly model a die made of a single
homogeneous material. If the given value is not positive, this variable has no effect. The default value is
-1.0.

9.4.12 verbosity

This int value sets the verbosity of the Tcl Utilities. The verbosity increases with the integer value, with the
lowest value of 0 being quiet. The default value is 0.

9.4.13 userdata

This variable stores any Tcl data that you may need to access in the callbacks that you or your CAD
department define, to configure HeatWave. This variable’s value is specific to you , and is not used by any
of HeatWave’s methods, procedures, or utilities. The default value {} is an empty Tcl list.

9.4.14 trans

This string value, if a valid directory-name, specifies the transient run-directory from which HeatWave
loads pre-existing data, or in which HeatWave saves a solution, depending on the value of the run variable.
An empty string "" specifies a steady-state mode, in which steady-state thermal-simulation is started, or
HeatWave restores your specified archive. The default value is "" (empty string).

9.4.15 trtimes

This list of floats in units of seconds, specifies the transient start_time, stop_time, time_step and
minimum_time_step values for transient thermal simulation. You may specify zero or more of these four
values, and they must be specified in sequence, as above. If time_step and minimum_time_step are not

130
 Tcl Utilities

defined, and start_time and stop_time have valid values, the customizable thermal simulation flow will com-
pute reasonable values for time_step and minimum_time_step. You may also set these transient variables
in your callback definitions. The default value is "" (empty string)

9.4.16 trsteps

This list of floats, in units of seconds, specifies the value of the transient variable described in the
time_steps section. Since it is simply a Tcl list of float values, it is not exactly the same as the time_steps
variable, which is a HeatWave Vector of float values. You may also set this transient variable in your
callback definitions. The default value is "" (empty string).

9.4.17 reloads

This list of floats, in units of seconds, specifies a list of times at which HeatWave should reload data
from the directory you specified as the trans variable. After loading the solution at each time-value X, Heat-
Wave saves an archive named t_<X>.gda, from which you may later restart or continue a transient thermal
simulation. The default value is "" (empty string).

9.5 Context Callbacks

The concept and implementation of a callback were defined in the section on Context Callbacks in Tcl.
The following sections summarize callbacks’ names, and provide further details on their purposes.

9.5.1 Context Callback Names

The following section describes a special set of Context Variables, used to store the default names of the
callbacks that your CAD department, and you, may define to configure a customizable thermal simulation
flow.
Your CAD software support group, or you, may wish to change the names of these callbacks (for example,
to select one of several predefined technology definition procedures). However most callbacks will probably
not need to be renamed. Therefore, the sections below use the default name (e.g. cxtTech) rather than
the Context variable (e.g. tech) to identify the callback procedure.

131
 Tcl Utilities

CxtVars var name Type Units Default Description

tech string none cxtTech technology

definition

preload string none cxtPreLoad custom pre

design-load
actions

power string none cxtPower power source

definition

blocks string none cxtBlocks block power

source definitions

postpower string none cxtPostPower actions after all

power source
definitions

prerun string none cxtPreRun custom pre-solver

actions

userpre string none cxtLocalPreRun local pre-solver

customizations

postrun string none cxtPostRun custom

post-solver
actions

userpost string none cxtLocalPostRun local post-solver

customizations

Table 12: Context Callbacks

132
 Tcl Utilities

9.5.2 callback cxtTech

cxtTech is the default value of Context variable tech. You may modify this value using gdSetVar(tech).
cxtTech is a callback that your CAD software support group uses to defines a thermal technology (for
example within a Physical Design Kit or PDK). The technology is loaded prior to loading design data, as
shown in the Customizable Thermal Simulation Flow section. Defining this procedure is one of several
ways of defining a thermal technology". By default this procedure is undefined. A Tcl example showing two
ways of specifying your thermal-technology follows. It uses the twoMetalCMOSTech procedure example,
described in the section on Compact Technology Definition.

# Example 1: cxtTech contains the technology definition

> proc cxtTech {flow} { twoMetalCMOSTech flow}

# Example 2: rename your technology callback to twoMetalCMOSTech

> global runVars() ;# define a global Tcl array (empty)
> gdNewVars runVars ;# runVars is now a default Context
> set runVars(tech) twoMetalCMOSTech
# so HeatWave will invoke twoMetalCMOSTech, instead of cxtTech
# to define a technology within the Customizable Thermal Simulation Flow.

You can also define a thermal technology in an encrypted file. If an encrypted file with the same name as
the Context variable tech is present in the HeatWave run directory, HeatWave will load the technology from
the encrypted file instead of the callback. For example if a file named "twoMetalCMOSTech.enc" is present
in HeatWave run directory, it will be used instead of the callback. Please note the encrypted file must be
generated using HeatWave Tech::encrypt method.

9.5.3 callback cxtPreLoad

cxtPreLoad is the default value of Context variable preload. You may modify this value using gdSet-
Var(preload). cxtPreLoad is a callback that your CAD software support group may create, to define any
customizations needed before loading a design as shown in the Customizable Thermal Simulation Flow
section. The methods described in the section on scripting should be useful in your customizations. By
default this procedure is undefined.

# Tcl example defining actions before design-data is loaded:

# check that an OpenAccess database exists before loading it
> proc cxtPreLoad {flow} {<check-OA-database-exists>}

9.5.4 callback cxtPower

cxtPower is the default value of Context variable power. You may modify this value using gdSetVar(power).
cxtPower is a callback that you may create, to add to the existing set of power sources. The power sources
are loaded after the design data, and .ptab file, if any, as shown in the Customizable Thermal Simulation
Flow section. Defining this procedure is one of several ways of defining power sources. By default this
procedure is undefined.

# Tcl example defining device power:

> proc cxtPower {flow} {
# create a 10uW power-source in a region centered at the origin,
# with size X=100nm, Y=2um, Z="channel" thickness
[flow getDesign] createPowerSource "P1" "channel" -5e-2 -1 5e-2 1 1e-5
}

133
 Tcl Utilities

9.5.5 callback cxtBlocks

cxtBlocks is the default value of Context variable blocks. You may modify this value using gdSet-
Var(blocks). cxtBlocks is a callback that you may create, to add to the existing set of power sources
– in particular, larger regions where the power is estimated, or where coarsely modeled power is accept-
able. This use of cxtBlocks is only for your convenience. HeatWave does not rely on the powersources
within cxtBlocks, being large or coarsely modeled, but treats them like any other power sources. These
power sources are loaded after the design data, and .ptab file, if any, as shown in the Customizable Ther-
mal Simulation Flow section. Defining this procedure is one of several ways of defining power sources. By
default this procedure is undefined.

# Tcl example defining a block’s power :

> proc cxtBlocks {flow} {
# create a 1mW block power-source X1 near the origin,
# with size X=150um, Y=100um, Z="channel" thickness
[flow getDesign] createPowerSource "X1" "channel" 10 10 160 110 1e-3
}

9.5.6 callback cxtPostPower

cxtPostPower is the default value of Context variable postpower. You may modify this value using gd-
SetVar(postpower). The actions in this callback are performed after immediately after you have defined all
power sources. The methods described in the section on scripting should be useful in your customizations.
By default this procedure is undefined.

# Tcl example of user’s actions after defining all power sources:

> proc cxtPostPower {flow} {<user’s-post-power-source-definition-actions>}

9.5.7 callback cxtPreRun

cxtPreRun is the default value of Context variable prerun. You may modify this value using gdSet-
Var(prerun). cxtPreRun is a callback that your CAD software support group may create, to define any
customizations needed after loading a design and defining power sources, but before running a steady-
state or a transient thermal simulation, as shown in the Customizable Thermal Simulation Flow section.
The methods described in the section on scripting should be useful in your customizations. By default this
procedure is undefined.

# Tcl example of pre-run actions:

> proc cxtPreRun {flow} {<general-pre-run-actions>}

9.5.8 callback cxtLocalPreRun

cxtLocalPreRun is the default value of Context variable userpre. You may modify this value using gdSet-
Var(userpre). cxtLocalPreRun is a callback that your may create, to define any additional customizations
to those provided by your CAD software support group, in the callback cxtPreRun. The actions in this
callback are performed after loading a design, defining power sources, and cxtPreRun, but before running
a steady-state or a transient thermal simulation, as shown in the Customizable Thermal Simulation Flow
section. The methods described in the section on scripting should be useful in your customizations. By
default this procedure is undefined.

# Tcl example of user’s pre-run actions:

> proc cxtLocalPreRun {flow} {<user’s-pre-run-actions>}

134
 Tcl Utilities

9.5.9 callback cxtPostRun

cxtPostRun is the default value of Context variable postrun. You may modify this value using gdSet-
Var(postrun). cxtPostRun is a callback that your CAD software support group may create, to define any
customizations needed after loading a design, defining power sources, and running a steady-state or a
transient thermal simulation, as shown in the Customizable Thermal Simulation Flow section. The methods
described in the section on scripting should be useful in your customizations. By default this procedure is
undefined.

# Tcl example of post-run actions:

> proc cxtPostRun {flow} {<general-post-run-actions>}

9.5.10 callback cxtLocalPostRun

cxtLocalPostRun is the default value of Context variable userpost. You may modify this value using gd-
SetVar(userpost). cxtPostRun is a callback that you may create, to define any additional customizations to
those provided by your CAD software support group, in the callback cxtPostRun. The actions in this callback
are performed after loading a design, defining power sources, running a steady-state or a transient thermal
simulation, and callback cxtPostRun, as shown in the Customizable Thermal Simulation Flow section. The
methods described in the section on scripting should be useful in your customizations. By default this
procedure is undefined.

# Tcl example of user’s post-run actions:

> proc cxtLocalPostRun {flow} {<user’s-post-run-actions>}

9.6 Customizable Thermal Simulation Flow

This section describes the customizable thermal simulation flow that is controlled by the values you assign
to Context Variables , and customized by the callbacks you define, as described in the Context Callbacks
section.
The following figure shows the thermal simulation flow, as well as the data or controls defined by your CAD
software support group, and by you. As seen in the "Legend" box, <x> represents gdGetVar(x) , where
x is a context variable. Boxes with broken (dashed) outlines represent optional input-data. The rightmost
shaded column contains the simulation flow. It is documented in detail, so that you know which actions
are performed before your callback is invoked, and which actions will follow. The middle shaded column
represents the callbacks that your CAD software support group should define , and the leftmost column
describes the callbacks you (the end-user) may define to the to customize this flow. The callbacks are
described in the Context Callbacks section. For clarity, some data is not shown in the figure, such as the
circuit-simulation run-directory and the electrical solver initialization file which are assumed to be prepared.
One method of preparing these data is by using the HeatWave-Virtuoso interface, (as described in the
Complete Examples) that also prepares run.tcl or run_transient.tcl, which set Context variables,
and invoke gdRun .
The flow may be conceptually divided into four sections, represented as four horizontal slices that are
delineated by broken (dashed horizontal) lines, with (vertical) labels that read as follows:

• Setup, Load Technology and Design

• Load Power Source Extents and Archives

• Run Simulation
• Post Run

135
 Tcl Utilities

The first section loads a thermal technology from a text or Tcl definition, then loads your OA design data,
and as described for the package variable, loads your package definition. The second section loads power
sources from the <libname>.ptab file and, if defined, the power source definition callbacks cxtPower and
cxtBlocks. cxtPostPower, cxtPreRun and cxtLocalPreRun may define additional customizations, as stated
in the descriptions of those callbacks. If found, the archive specified by restore is restored. The third section,
depending on run, either runs steady-state or transient thermal simulation, or simply reloads data (in turn,
depending on the values of trans and reloads). Finally, in the fourth section, after the simulation is run
or reloaded, cxtPostRun and cxtLocalPostRun may implement additional customizations, as stated in the
descriptions of those callbacks. HeatWave’s outputs are specified by summary and archive, in addition to
the temperatures in <cellname>.tval.
After your CAD software support group has configured HeatWave as described, you should not have to
make modifications. However, the preceding documentation should allow you to easily make any changes
necessary.

136
 Tcl Utilities

Figure 38: Customizable Thermal Simulation Flow

137
 Complete Examples

10 Complete Examples

This section describes several ways in which HeatWave may be invoked with the different usages described
in the HeatWave User Guide. It contains links to many definitions and descriptions available only within this
Reference Manual. This section is also included in the HeatWave User Guide, since it contains several
examples.

10.1 Overview

This section provides examples of the ways in which HeatWave may be invoked, as described in the input
models section. Some input-files are common to all invocations, and are listed first.
Examples of each input model are shown:

• Text inputs are exemplified in the section Using Text Inputs.

• Scripting primitives are exemplified in the section Using Tcl Primitives.

• Tcl Utililties that use a HeatWave Context are exemplified in the section Using Tcl Utilities.

The listings of data and Tcl-scripts below are based on the OPAMP example available from Keysight, that
implements a simple single-stage opamp. The example provides all the simulation input-data and scripts
of the form described below, including an OpenAccess database, described further below. Some of these
inputs, may be built using the HeatWave interface to Virtuoso, as described below.

10.2 Common Inputs

This section describes the files common to all the input models mentioned in the Overview section.

10.2.1 OpenAccess Layout Database

The layout data is translated from GDSII into an OpenAccess database as described in the section on
OpenAccess in the HeatWave User Guide. The OpenAccess library is named OPAMP, within which the
cell opamp contains the layout of the design. The OpenAcess data is in a directory named OPAMP. This
may be built by the HeatWave interface to Virtuoso, if your CAD software department has defined the
appropriate SKILL callbacks.

10.2.2 Ptab File

The <libname>.ptab file (OPAMP.ptab in this example), has the syntax described in the Power Source
Extent Table section.

# OPAMP.ptab file (... indicates lines deleted for brevity)

# Power source extents in .ptab format:
#<cell-name> <power-source-name> <thermal-layer> <xmin ymin xmax ymax (in OA user-units)>
opamp M3__1 channel 12.080 23.480 16.080 38.480
opamp M3__2 channel 16.880 23.480 20.880 38.480
opamp M4__1 channel 2.480 3.750 6.480 18.750
opamp M4__2 channel 7.280 3.750 11.280 18.750
...
opamp M9__9 channel 125.600 3.750 128.500 18.750

138
 Complete Examples

opamp R0__1 poly 54.490 3.750 89.590 5.750

opamp R0__2 poly 54.490 12.750 89.590 14.750
opamp R0__3 poly 54.490 9.750 89.590 11.750
opamp R0__4 poly 54.490 6.750 89.590 8.750

One method for preparing this data is by using the HeatWave Virtuoso Interface, which is the method used
in this example.

10.2.3 Pval File

The <cellname>.pval file (opamp.pval in this example), has the syntax described in the Power Value file
section. It is optional, and need not be specified, particularly if power is obtained from circuit-simulation, e.g.
Spectre. All power-sources have a default power dissipation of 0 W. In this example, having initial power
values (from circuit-simulation at a constant temperature) speeds up convergence of the electro-thermal
loop.

# opamp.pval file (... indicates lines deleted for brevity)

# Power-source power values in .pval format:
#<power-source-name> <power (W)>
M3__1 0.0024627
M3__2 0.00245907
M4__1 6.58163e-05
M4__2 6.60254e-05
...
M9__9 0.00359547
R0__1 7.36104e-08
R0__2 7.36104e-08
R0__3 7.36104e-08
R0__4 7.36104e-08

10.2.4 ESolve Control File

Circuit-simulator invocation within the electro-thermal loop is managed by HeatWave as described in the
section on the Electrical Solver Initialization file. An example for the Spectre circuit simulator follows. Heat-
Wave’s Spectre interface supports invocation of APS , as shown below. The default value of most variables
is usually correct, and they need not be specified. However, for clarity, the default values are shown com-
mented (# prefix) below:

# gda_sim.ini file
solver_type spectre
spectre_command "aps -f psfascii =l spectre.out -r ./psf "
spectre_psf psf/tran.tran
#spectre_netlist spectre/input.scs
#spectre_subckt opamp
#spectre_script hw_spectre
#spectre_log spectre_flow.out

This file may be prepared by the HeatWave interface to Virtuoso, if your CAD software department has
defined the appropriate SKILL callbacks.

10.2.5 Package Model file

Conditions at the die-boundaries may be defined as described in the Package Model section. An example
of this follows:

139
 Complete Examples

# Basic package model: pkg.ini file

# kamb = ambient conductivity W/(K*m)
# lamb = length of thermal resistor m
#
# name x- x+ y- y+ z- z+
#------------------------------------------------
kamb: 1 1 1 1 8 3
lamb: 1e-3 1e-3 1e-3 1e-3 1e-4 1e-4
tamb: 27 27 27 27 27 27

10.2.6 Spectre run directory

A Spectre run-directory, ready for use in HeatWave’s electro-thermal loop, is prepared in a directory named
spectre, as described in the section on the HeatWave interface to Spectre. One method for preparing this
data is by using the HeatWave Virtuoso Interface, which is the method used in this example.

10.3 Using Text Inputs

This section describes the invocation of HeatWave using plain-text input files, so no script inputs are used.
The previously described common inputs are used, as summarized below for the opamp example:

• OPAMP.ptab defines power-source extents

• opamp.pval defines the power dissipated by power-sources

• gda_sim.ini configures the electro-thermal loop
• pkg.ini is included in gdatech.ini, in this input model
• OPAMP/ contains the OpenAccess database of the opamp layout

• spectre/ run-directory ready for HeatWave electro-thermal simulation

140
 Complete Examples

Figure 39: Using Text Inputs

The file-names above are, wherever possible, the default values to HeatWave’s command-line switches, to
reduce the number of switches used on the heatwave command-line.
The additional file specific to this input model is described in the Text Techfile section.

• gdatech.ini defines a technology in plain-text (i.e. not a Tcl script) If needed, meshing controls are
specifiable in an optional text mesh control file gdamesh.ini.

Given the preceding input files, you may run HeatWave as follows, as described in the section on HeatWave
Usage:

• heatwave -L OPAMP -C opamp

10.3.1 Text Techfile

The section on the text Technology File explains its syntax, and the section on Text Technology Definition
provides a representative example. The text techfile for the opamp example follows:

# gdatech.ini file for OPAMP test-case

# thermal layer stack

# name height k kbar

0: bsubstrate 0.000440 100 100
1: tsubstrate 0.000005 120 100 NW
2: channel 0.00000030 100 100
3: poly 0.00000050 100 100 P01
4: contact 0.00000055 174.0 1.00 CO1
5: metal1 0.00000055 397.0 1.00 MT1
6: via1 0.00000060 174.0 1.00 V12

141
 Complete Examples

7: metal2 0.000000595 397.0 1.00 MT2

8: passivation 0.000001725 400.0 1.00

# optional mask layer declaration

mask_layers NW P01 CO1 MT1 V12 MT2

# as in "pkg.ini"-- see Package Model section

kamb: 1 1 1 1 8 3
lamb: 1e-3 1e-3 1e-3 1e-3 1e-4 1e-4
tamb: 27 27 27 27 27 27

10.4 Using Tcl Primitives

This section describes the invocation of HeatWave using the Tcl primitives. The benefits of this input model
are explained in the overview of scripting primitives. This simulation-flow is simpler than the context based
flow though it is less suited to integration and standardization in the CAD tool suite of a large chip-design
group.
The previously described common inputs are still used in this mode, and are summarized below for the
opamp example:

• OPAMP.ptab defines power-source extents

• opamp.pval defines the power dissipated by power-sources
• gda_sim.ini configures the electro-thermal loop
• pkg.ini defines a basic package model
• OPAMP/ contains the OpenAccess database of the opamp layout
• spectre/ run-directory ready for HeatWave electro-thermal simulation

Figure 40: Using Tcl Primitives

142
 Complete Examples

The Tcl file specific to this input model is described in the Complete Tcl Script section.

• basic.tcl defines a technology and a basic thermal simulation flow in Tcl.As with any Tcl script, it may
be split across multiple files.

Given the preceding input files, you may run a thermal simulation as follows, as explained in the section on
scripts in HeatWave:

• heatwave basic.tcl

Alternatively to save outputs printed to the console, that sometimes contain system warnings or errors not
written to logfiles, you may invoke HeatWave using the UNIX tee command, as follows:

• heatwave basic.tcl |& tee heatwave_console.log

10.4.1 Complete Tcl Script

This section shows a complete Tcl script to reload an existing transient thermal simulation, or run a steady-
state thermal simulation, using power computed within a Spectre transient circuit-simulation. The script
performs the following steps:

• defines a gda::Flow object

• defines a thermal technology using scripting primitives in Tcl, as exemplified by the section on Com-
pact Tcl Technology Definition.
• loads the OpenAccess database and package model.
• sets transient controls if in transient mode
• runs a steady-state or transient thermal simulation

A complete Tcl script using HeatWave’s scripting primitives follows.

# basic.tcl HeatWave script:

# This script is an example of the basic Tcl-based flow described in the
# HeatWave User Guide. This flow is simpler than the context based flow
# though it is less suited to integration and standardization in
# the CAD tool flow of a large chip-design group.
# This flow may be invoked from the commandline as follows:
# heatwave basic.tcl
# To save the console output (which sometimes contains more than logfiles)
# consider this invocation:
# heatwave basic.tcl |& tee heatwave_console.log
# which writes the output to the screen as well as to a logfile

# We can combine scripts for transient and steady state simulation

# in the same file by creating a control variable (e.g. IS_TRANSIENT)
# that sets up a transient run if 1, or a steady-state thermal simulation,
# if 0. Both cases use a transient electrical (Spectre) simulation to
# compute power. For the steady-state thermal simulation, the power
# is averaged over the simulation time.

set IS_TRANSIENT 0 ;# run steady state thermal simulation

gda::Flow flow

143
 Complete Examples

# THERMAL TECHNOLOGY DEFINITION

# invoke the following procedure to define a 2-metal CMOS thermal-technology
# for the OPAMP design. This procedure may be defined in a separate file
proc opampTech {flow} {
# Example of a complete thermal technology description in Tcl.
# Temperature dependent conductivity K(T): {T1 K1 T2 K2 ... TN KN}

# silicon’s thermal_conductivity as a function of temperature

set Si_K_T {
25 156.1425 40 146.2506 55 137.4056 70 129.4560
85 122.2778 100 115.7683 115 109.8419 130 104.4268
145 99.46221 160 94.89642 175 90.68520 190 86.79047
205 83.17932 220 79.82315
} ;# later automatically converted to a Function1d

#----------------------
# MATERIAL DEFINITIONS
#----------------------

# THERMAL CONDUCTIVITY
# { name thermal_conductivity W/(mK) [metal_electron_mean_free_path (m)] }
set K_list "
{Si {$Si_K_T} }
{PolySi 100 }
{SiO2 1 }
{Al 237 4e-8 }
{W 174 4e-8 }
{Polyimide 0.5 }
"
# K_list is enclosed in quotes, so $Si_K_T is evaluated

# VOLUMETRIC HEAT CAPACITY (use material names from K_list)

# {name heat_capacity_per_unit_volume J/(m^3 K)}
set Cv_list {
{Si 1.63e6}
} ;# no $variables used, so braces {} are ok

#----------------------------
# THERMAL LAYER DEFINITIONS
#----------------------------
# {name thickness(m) bkgnd-material {lyr1 mat1}...{lyrN matN}}
set layer_list {
{ bsubstrate 440e-6 Si }
{ oxide 5e-6 Si {OX1 Si}}
{ channel 0.1e-6 SiO2 {OX1 Si}}
{ thinox 0.05e-6 SiO2 {PO1 SiO2} {CO1 W}}
{ poly 0.18e-6 SiO2 {PO1 PolySi} {CO1 W}}
{ poly_ild 0.13e-6 SiO2 {PO2 SiO2} {CO1 W}}
{ poly2 0.18e-6 SiO2 {PO2 PolySi} {CO1 W}}
{ contact 0.45e-6 SiO2 {CO1 W} }
{ metal1 0.55e-6 SiO2 {MT1 Al}}
{ via1 0.60e-6 SiO2 {V12 W} }
{ metal2 0.595e-6 SiO2 {MT2 Al}}
{ passivation 1.725e-6 Polyimide {PAD Au}}
}
gdInfo "defined K and Cv of materials in OPAMP example stack" ;# context info

144
 Complete Examples

gdDefineTech flow $K_list $layer_list $Cv_list

}

opampTech flow ;# call the procedure above to define a thermal technology

# load design and package <library> <cell> <package>

flow loadDesign "OPAMP" "opamp" "pkg.ini"

# set moderate-resolution meshing parameters

# see gdSetModerateResolution definition in gdacontext.tcl
gdSetModerateResolution flow

if {$IS_TRANSIENT} { ;# setup for transient thermal, if needed

gdInfo "setting up TRANSIENT thermal simulation"

# Transient solver: moderate capacity solver (0) is default.
# Need license gda_transient_hc for high capacity solver (1)
[flow tsolveVars] configure -transient_solver 0 ;# 1 is high-capacity

# measurement:
# gdTranMeasureTemp flow <inst> -avg -min -max {<tstart> <tend>}
# report min/max/avg temp on <inst> from <tstart> to <tend>
# report min/max/avg temperature on instance M8__1 from 0ms to 1ms
gdTranMeasureTemp flow M8__1 -max [gdFloats {0 1.0e-3}] ;#-avg -min

# limits:
# gdTranDTemp flow <inst1> <inst2> -max <temp>
# report when the temp of <inst2> exceeds that of <inst1> by <temp> degC
# report when the temp of M9__10 exceeds that of M9__1 by 3 degC
gdTranDTemp flow M9__1 M9__10 -max 3.0

# similar commands to the above exist for power

# define smaller steps early on, or when power changes fast

set variableSteps [gdFunction1d {
0.0 1e-5 1e-5 1e-5
1e-5 5e-5 1e-4 5e-5
1e-4 1e-4 1e-2 1e-4 } ]

# Define parameters controlling the transient thermal solver

# Note we set the start/stop/step times here, but the
# more general settings are in cxtPreRun (in ../data/examples.tcl)
# The local settings are for the design specific details
[flow transientVars] configure
-start_time 0
-stop_time 1e-4
-time_step 1e-5
-time_steps $variableSteps
-snapshot_temperature_change 0.8
-snapshot_time_interval 1e-4
-verbosity 3

[flow getTransient] criticalTemperatureChange 5 ;# for all power-sources

} ;# end transient thermal definitions

145
 Complete Examples

flow continueOnError true

# run thermal simulation, using powers from transient Spectre simulation

if {$IS_TRANSIENT} { ;# in this script, we load previously-saved results

gdInfo "re-loading TRANSIENT thermal simulation ..."

[flow] configure -run_name "transient/testResults.au"
flow transientStatisticsReport

} else {
gdInfo "running STEADY STATE thermal simulation ..."
flow runSteadyState
}

# launch a Graphical User Interface window.

[flow getGUI] show

10.5 Using Tcl Utilities

This section describes the invocation of HeatWave to run utilities, that use the HeatWave Context object.
The benefits of this input model are explained in the overview of Context base Tcl utilities. This simulation-
flow is best suited to integration and standardization in the CAD tool suite of a large chip-design group.
The previously described common inputs are still used in this mode, and are summarized below for the
opamp example:

• OPAMP.ptab defines power-source extents

• opamp.pval defines the power dissipated by power-sources

• gda_sim.ini configures the electro-thermal loop

• pkg.ini defines a basic package model
• OPAMP/ contains the OpenAccess database of the opamp layout

• spectre/ run-directory ready for HeatWave electro-thermal simulation

146
 Complete Examples

Figure 41: Using Tcl Context and Utilities

To make this example resemble deployment in an enterprise production design environment, assume
that the opampTech procedure from basic.tcl above, is now in a Tcl file within some PDK hierarchy.
From some other directory, e.g.<some-path>/CENTRAL_CAD_TCL/, we may then run a Tcl auto_-
mkindex command that traverses the PDK hierarchy mentioned above. This produces a tclIndex file in
<some-path>/CENTRAL_CAD_TCL/, that has recorded (indexed) the location of the opampTech proce-
dure. Finally, prepend this path to your TCLLIBPATH shell environment variable, i.e.
set $TCLLIBPATH to "<some-path>/CENTRAL_CAD_TCL $TCLLIBPATH". This allows HeatWave, or
any Tcl shell, to automatically find procedure opampTech, when needed. Individual users would not need
to know where opampTech is defined, nor would they need to explicitly source a Tcl file.
Complete Tcl scripts are provided below for the setup and invocation of transient and steady-state thermal
simulation.

10.5.1 Transient Tcl

The Tcl files specific to this input model are described in the subsequent Complete Transient Script section.

• run_transient.tcl is typically created by HeatWave’s Virtuoso interface, thought you may also eas-
ily create it manually. run_transient.tcl defines a Context to customize the thermal simulation flow
launched by gdRun.
• run_transient.tcl loads a gda_local.tcl which is also shown, in full.

Given the preceding input files, you may run a thermal simulation as follows, as explained in the section on
scripts in HeatWave:

• heatwave run_transient.tcl

147
 Complete Examples

This is essentially the command issued by the Thermal Analysis Invocation Form in HeatWave’s Virtuoso
GUI.
Alternatively to save outputs printed to the console, that sometimes contain system warnings or errors not
written to logfiles, you may invoke HeatWave using the UNIX tee command, as follows:

• heatwave run_transient.tcl |& tee heatwave_console.log

10.5.2 Complete Transient Script

This section shows the complete Tcl scripts to reload an existing transient thermal simulation using power
computed within a Spectre transient circuit-simulation.
The main script, "run_transient.tcl" listed below, loads an optional local script "gda_local.tcl", that is used to
add a few commands, so we may match the settings in basic.tcl.
The gdRun command in "run_transient.tcl" launches a customizable thermal simulation flow, controlled by
the values in the Context named runVars. The section on the Customizable Thermal Simulation Flow
provides a detailed description of the flow.
"run_transient.tcl" loads the specified input-data, and restores the temperature-solution from the directory
specified by the trans variable’s value, i.e. "transient/testResults.au". The tech variable is set to
opampTech. Therefore, HeatWave will invoke opampTech to define a thermal technology. Since we defined
$TCLLIBPATH and tclIndex as previously described, HeatWave can automatically locate the procedure
opampTech.
You may easily modify this script’s functionality. For example, to (re)-run the simulation, you would set the
run variable to 1:

set runVars(run) 1 ;# run simulation

The complete Tcl transient simulation script from HeatWave’s Virtuoso GUI, that you can easily create
manually or procedurally, is shown below. It performs a super-set of the actions defined in basic.tcl.

# run_transient.tcl:
# HeatWave Thermal Analysis Tcl script
# ====================================

# Define a Context named runVars [see Tcl Utilities]

global runVars() ;# global array of run-control vars
gdNewVars runVars ;# runVars=Context with default settings
set runVars(batch) 0 ;# run in GUI
set runVars(summary) 0 ;# summarize layer temps in logfile
set runVars(run) 0 ;# don’t run sim -- load existing data
set runVars(restore) "" ;# archive name to read in
set runVars(archive) "" ;# archive name to write to
set runVars(tech) {opampTech} ;# Tcl technology definition proc
set runVars(package) {pkg.ini} ;# package-model file
set runVars(trans) "transient/testResults.au"
set runVars(libname) "OPAMP"
set runVars(cellname) "opamp"
set runVars(trtimes) "0 1e-4 1e-5" ;# [start [stop [step [min-step]]] times
set runVars(reloads) "" ;# times at which to reload/save
set runVars(trsteps) "0.0 1e-5 1e-5 1e-5 1e-5 5e-5 1e-4 5e-5 1e-4 1e-4 1e-2 1e-4";

# gda_local.tcl may contain Tcl commands, including user-defined callbacks

if {[file exists gda_local.tcl]} {source gda_local.tcl}

148
 Complete Examples

# Load results, or run a simulation, using runVars values

# gdRun is defined in $GDA_ROOT/tcl/gdacontext.tcl
gdRun runVars

The complete Tcl file local to the HeatWave simulation run-directory, gda_local.tcl, is shown below. This file
is loaded by the main script, run_transient.tcl, listed above.

#gda_local.tcl:
# define Context callback cxtLocalPreRun
# to issue design-specific commands before running thermal simulation
proc cxtLocalPreRun {flow} {

gdInfo "local customizations before simulation"

# report min/max/avg temperature on instance M8__1 from 0ms to 1ms

gdTranMeasureTemp flow M8__1 -max [gdFloats {0 1.0e-3}] ;#-avg -min
# report when the temp of M9__10 exceeds that of M9__1 by 3 degC
gdTranDTemp flow M9__1 M9__10 -max 3.0

# Define parameters controlling the transient thermal solver

[flow transientVars] configure
-snapshot_temperature_change 0.8
-snapshot_time_interval 1e-4
-verbosity 3
[flow getTransient] criticalTemperatureChange 5 ;# for all power-sources
}

10.5.3 Steady State Tcl

The Tcl files specific to this input model are described in the subsequent Complete Steady State Tcl Script
section.

• run.tcl is typically created by HeatWave’s Virtuoso interface, thought you may also easily create it
manually. run.tcl defines a Context to customize the thermal simulation flow launched by gdRun.
• run.tcl loads a gda_local.tcl which is also shown, in full.

Given the preceding input files, you may run a thermal simulation as follows, as explained in the section on
scripts in HeatWave:

• heatwave run.tcl

This is essentially the command issued by the Thermal Analysis Invocation Form in HeatWave’s Virtuoso
GUI.
Alternatively to save outputs printed to the console, that sometimes contain system warnings or errors not
written to logfiles, you may invoke HeatWave using the UNIX tee command, as follows:

• heatwave run.tcl |& tee heatwave_console.log

10.5.4 Complete Steady State Tcl Script

This section shows the complete Tcl scripts to run a steady-state thermal simulation using power computed
within a Spectre transient circuit-simulation.

149
 Complete Examples

The main script, "run.tcl" listed below, loads an optional local script "gda_local.tcl", to illustrate how few
commands may be added.
The gdRun command in "run.tcl" launches a customizable thermal simulation flow, controlled by the values
in the Context named runVars. The section on the Customizable Thermal Simulation Flow provides a
detailed description of the flow.
"run.tcl" loads the specified input-data, and launches a steady state thermal simulation, since the Context
variable trans is an empty string. The tech variable is set to opampTech. Therefore, HeatWave will invoke
opampTech to define a thermal technology. Since we defined $TCLLIBPATH and tclIndex as previously
described, HeatWave can automatically locate the procedure opampTech.
You may easily modify this script’s functionality. For example, to re-run the simulation in batch mode, you
would set the batch variable to 1:

set runVars(batch) 1 ;# batch simulation

The complete Tcl steady-state simulation script from HeatWave’s Virtuoso GUI, that you can easily create
manually or procedurally, is shown below. It performs a super-set of the actions defined in basic.tcl.

# run.tcl:
# HeatWave Thermal Analysis Tcl script
# ====================================

# Define a Context named runVars [see Tcl Utilities]

global runVars() ;# global array of run-control vars
gdNewVars runVars ;# runVars=Context with default settings
set runVars(batch) 0 ;# run in GUI
set runVars(summary) 0 ;# summarize layer temps in logfile
set runVars(run) 1 ;# run a simulation
set runVars(restore) "" ;# archive name to read in
set runVars(archive) "" ;# archive name to write to
set runVars(tech) {opampTech} ;# Tcl technology definition proc
set runVars(package) {pkg.ini} ;# package-model file
set runVars(trans) "" ;# empty, so run steady state
set runVars(libname) "OPAMP"
set runVars(cellname) "opamp"

# gda_local.tcl may contain Tcl commands, including user-defined callbacks

if {[file exists gda_local.tcl]} {source gda_local.tcl}

# Load results, or run a simulation, using runVars values

# gdRun is defined in $GDA_ROOT/tcl/gdacontext.tcl
gdRun runVars

The complete Tcl file local to the HeatWave simulation run-directory, gda_local.tcl, is shown below. This file
is loaded by the main script, run.tcl, listed above.

#gda_local.tcl:
# define Context callback cxtLocalPreRun
# to issue design-specific commands before running thermal simulation
proc cxtLocalPreRun {flow} {
gdInfo "local customizations before simulation"
[flow meshVars] configure
-refine_temp_value 0.5 # resolve to 0.5 degC
}

150
 Using HeatWave’s Virtuoso GUI

11 Using HeatWave’s Virtuoso GUI

This section describes how you may use the Virtuoso graphical interface to HeatWave, to set-up and run a
thermal simulation. The HeatWave User Guide , and the HeatWave Tutorial , or OPAMP example, further
illustrate the capabilities described in this section
This section is also included in the HeatWave User Guide, since it describes the use of the Virtuoso interface
to run HeatWave. In this manual, it is complementary to the section on Customizing HeatWave’s Interface
to Virtuoso, a reference that may be used by your CAD software support department to set up HeatWave
for use in your design environment.

11.1 HeatWave Menu

The HeatWave interface to Virtuoso is installed when you load the SKILL file $GDA_ROOT/il/gda_-
heatwave.ile, as described in $GDA_ROOT/README.INSTALL After installation of the HeatWave inter-
face to Virtuoso, a pulldown-menu titled "HeatWave" is added to the banner menus in your test-bench’s
schematic window. You should run HeatWave from the "HeatWave" pulldown menu in a valid test-bench,
and not from some lower-level cell in the test-bench hierarchy, so the test-bench is reliably identified.
The entries in the "HeatWave" pulldown menu of a Virtuoso window are shown in the following figure.

Figure 42: HeatWave Menu in Virtuoso

Any entry selected from the HeatWave Menu launches a form that prepares data for, or runs, a steady-state
or transient electro-thermal simulation.

• "Setup Thermal Analysis..." launches the Thermal Analysis Setup Form

• "Extract Power Sources..." launches the Power Source Extraction Form

• "Setup Simulator..." launches the Simulation Setup Form
• "Run Thermal Analysis..." launches the Thermal Analysis Invocation Form

Your CAD support department will automatically load appropriate initial values for the entries in the forms
(whose description follows), so you should not generally need to modify most entries. Your CAD support
department will also define actions specific to your design environment, as each form is created, or after
each form has completed its actions, to ensure that data is properly set up for your design environment.
The forms launched from the HeatWave Menu are described in the following sections.

151
 Using HeatWave’s Virtuoso GUI

11.2 Thermal Analysis Setup Form

The "Setup Thermal Analysis..." menu launches the form shown in the following figure.

Figure 43: Thermal Analysis Setup Form

You may specify a transient or steady_state simulation Thermal simulation mode, and "HeatWave
run-directory", in which thermal simulation is performed. The name of the "Testbench" schematic is deduced
from the Virtoso cell-view within the current window. The schematic contains an instance of the "Cell name"
whose extracted-view provides the physical netlist for circuit-simulation. These are also deduced, if the
testbench is correctly prepared. You may also modify any of the above settings, if needed.
If you launch HeatWave from "HeatWave" pulldown menus in a cell below the top-level of the test-bench, the
test-bench’s cell-view cannot be reliably deduced by HeatWave. In that case, you must enter the test-bench
library and cell names manually. Depending on how your environment is configured, your CAD department
may be able to to deduce the test-bench in the appropriate callback.
You may specify the name of HeatWave’s OpenAccess database. HeatWave inputs are built by traversing
your design data.

11.3 Power Source Extraction Form

The "Extract Power Sources..." menu launches the form shown in the following figure.

152
 Using HeatWave’s Virtuoso GUI

Figure 44: Power Source Extraction Form

This form obtains the extents of power sources from your design data, to build HeatWave’s
<lib-name>.ptab input-file definining power-sources. This is done by traversing the "Extracted view"
that you specify. For each instance in the extracted view,

• HeatWave obtains the point at which the instance is placed (its location)
• If "recognition-layer" is selected HeatWave reads the SKILL recognitionShape() property, that your
device-extraction flow can attach to the instance it generates in the extracted-view. The recognition-
Shape() property is a standard Virtuoso construct, that defines a shape indicating where the device
was recognized by your device-extractor. This shape is used as the physical (x,y) extent of the power
source. It defines where power will be dissipated, for the given instance. If this method fails and "Try
alternate methods?" is selected, the "power-layer" method described below will be applied.
• If "power-layer" is selected HeatWave probes the layout cell-view you provide, on the "Power layer
name" (e.g. y0) you provide, at the location point identified for each instance in the extracted view. If
a geometry on the "power-layer" exists at that point, it is used as the physical (x,y) extent of the power
source. It defines where power will be dissipated, for the given instance. If "User-units around device
center" is specified, the region searched for overlap with a shape on "Power layer name", is a square
box with width 2∗p user units (usually microns) centered on the point. If this method fails and "Try
alternate methods?" is selected, the "recognition-layer" method described above will be applied.

• If neither method above can identify the extent of the power-source (instance), the bounding box of
the instance is used. Since this is probably inaccurate the definition written to the <lib-name>.ptab file
is commented. You may review and un-comment it, if acceptable.
• The thermal layer of a power-source determines its vertical location in the thermal stack. The power-
source’s thermal layer should be set by the appropriate SKILL callback procedure, defined by your
CAD department, typically within a physical design kit (PDK).

153
 Using HeatWave’s Virtuoso GUI

• Another method for specifying the thermal layer of the power source is applicable if the "power-layer"
is used. In this case you may associate a thermal layer with any shape on the "power-layer". You do
this by adding an optional SKILL property, whose value is a list, to any shape on the "power-layer"
you are using. The name of the property is the value of the "Power prop name" field of this form,
which is "power" by default. The value of the property is list( <thermal-layer-number> )
where thermal-layer-number is the integer identifying the thermal-layer for the power-source.
• By default, all power sources are placed on the layer-number specified in the "Power thermal-layer
number" field.
• The"Valid prop name", "Valid prop value" and "Valid layer name" fields are not generally required,
though they may be useful. The work as follows. If an instance within the extracted view has a
property defined, whose name matches the "Valid prop name" and whose value matches the "Valid
prop value", that instance is forced to be marked as valid. So, even possibly inaccurate bounding
box information that would have been written commented in <lib-name>.ptab file (see above) will now
be written uncommented to the <lib-name>.ptab file. Also, if you specified a "Valid layer name" and
a valid instance as described above contains layout on the "Valid layer name" in the master of the
instance, then that layout is used as the extent of the power source (i.e. instance).

The result of this form’s actions is to create HeatWave’s <lib-name>.ptab input-file defining power-
source extents for your design.

11.4 Simulation Setup Form

The "Setup Simulator..." menu launches the form shown in the following figure.

Figure 45: Simulation Setup Form

This form allows you to specify a circuit-simulator and an existing post-layout circuit-simulation run directory

154
 Using HeatWave’s Virtuoso GUI

in Virtuoso. The interface will invokes the specified Script to run simulation... that is typically provided by
HeatWave (though you may write your own), to modify the simulation-netlist, by associating parametrized
temperature values with each instance found in the power source extraction step. HeatWave later invokes
the same script during the electro-thermal loop to run circuit-simulation that computes the power dissipated
by each power-source.
The result of this form’s actions is to prepare a HeatWave circuit-simulation run directory for the simulator
you specify in the form. In particular, the simulation netlist is modified, so temperature-parameters are
associated with each instance. HeatWave computes and sets these temperature parameters before circuit-
simulation, within the electro-thermal loop.

11.5 Thermal Analysis Invocation Form

The "Run Thermal Analysis..." menu launches the form shown in the following figure.

Figure 46: Thermal Analysis Invocation Form

This form allows you to run or load a steady-state or transient HeatWave electro-thermal simulation, in
batch or GUI mode. When preparing to run a simulation, you may specify transient times, namely start,

155
 Using HeatWave’s Virtuoso GUI

stop, time-step and minimum step values in the "Start Stop Step Min-Step" list, or you may specify varying
time-steps in a "Time-steps(time) table" that defines transient time-steps as a function of time.
You may load (restore) existing results from a previously saved archive, instead of running a simulation.
In this case, you may specify reload times at each of which a temperature profile will be read from your
transient archive ("Load temperature-waveform from" field), and saved as valid initial-values for later use.
You may specify the name of the Tcl procedure that defines your current current thermal technology, This
sets the value of the Context variable tech, that determines the name of the Tcl technology-definition pro-
cedure in HeatWave. Examples of such settings are seen here.
This form’s action is to run HeatWave as specified, using settings in this form and the preceding forms. The
Tcl Utilities input model is used. HeatWave’s Virtuoso interface writes the data in the form’s fields into scripts
named run_transient.tcl (see example transient script) or run.tcl (see example steady-state script)
depending on the thermal simulation mode.
Each of these scripts eventually invokes the gdRun procedure (as in these transient or steady-state ex-
amples). HeatWave uses the inputs described in the Tcl Utility Input Model section, within the thermal
simulation flow of gdRun. Further context is provided by the sections on how data from Virtuoso is used in
HeatWave and on the HeatWave program flow.
HeatWave’s log-file (also saved as .gda_log in the HeatWave run-directory) is presented in a Virtuoso text-
file window. If "Invoke in batch mode?" was not selected, the HeatWave GUI is started after simulation, or
after loading previous results. The HeatWave GUI is described in the HeatWave User Interface Guide.
Possible outputs include text files, binary archives or transient outputs depend on the thermal simulation
mode and other settings.

156
 Customizing HeatWave’s Virtuoso GUI

12 Customizing HeatWave’s Virtuoso GUI

The HeatWave User Guide , and the HeatWave Tutorial , or OPAMP example, describe how the Virtuoso
interface to HeatWave may be used. By contrast, this section describes how your CAD software department
may set up HeatWave’s interface to Virtuoso appropriately for your environment
This following sections describe the data-structure and callback procedures that your CAD software depart-
ment may use to set up HeatWave’s interface to Virtuoso appropriately for your environment

12.1 Overview

Your design data in Virtuoso is traversed by HeatWave’s SKILL scripts to assemble several of the inputs
required by HeatWave’s thermal solver. The initial data-flow to build these inputs, as well as the subse-
quent data-flow during electro-thermal simulation iterations, are shown in the following figure, that is also
described in the HeatWave User Guide.

157
 Customizing HeatWave’s Virtuoso GUI

Figure 47: HeatWave data-flow using Virtuoso

As the preceding figure shows, your design data in Virtuoso, when properly prepared for electro-thermal
simulation, includes a test-bench schematic that instantiates a physical (device-extracted) view of the part(s)
of your chip that will be electro-thermally simulated. Your CAD softare department will need to define a few
SKILL callback procedures to efficiently prepare some of HeatWave’s input data, given their knowledge of
the CAD data organization in your design environment. Why is it necessary to customize the HeatWave
interface to Virtuoso ? The following points should help you answer this question.

• HeatWave requires a diverse set of inputs to compute temperature, including power source definitions

158
 Customizing HeatWave’s Virtuoso GUI

with the extents and values of power-sources. Power values may be obtained from electrical solvers,
such as circuit simulators, as well as the layout database of the design. A thermal technology definition
is also required.
• HeatWave comprises a thermal extractor that builds a thermal model from your layout and technology
file, and a thermal solver that solves for temperature, given power within the thermal model.

• HeatWave does not contain an electrical extractor, so the results of your device level extraction are
used to identify the power-dissipating region for devices within your netlist.
• HeatWave does not contain a circuit-simulator, so the results of your circuit-simulation are traversed,
to obtain the average power, or the time-varying power dissipated by each instance in your circuit-
simulation netlist.
• The HeatWave inputs summarized above should be obtained from your design environment. Since
design environments vary between companies, and within them, the organization of your design data
, and how items within it should be presented to you, are best understood by your CAD department.
• Therefore, your CAD software support department should customize the automated generation of
some of the required information described above, This includes data related to device extraction and
circuit simulation, as well as the thermal technology-data in your physical design kit (PDK).

The SKILL data model as well as the SKILL structures and SKILL callbacks that may be used to customize
HeatWave’s Virtuoso interface are described in the following sections.

12.2 Configuring HeatWave using SKILL and Tcl

HeatWave’s interface to Virtuoso is configurable using SKILL structures and SKILL callback procedures.
HeatWave’s flow is configurable using Context variables and Tcl callback procedures, as previously de-
scribed in the sections on Scripting Primitives and Tcl Utilities. The SKILL and Tcl code you write may be
arbitrarily organized, both logically and physically, as long as the required variables and procedures are
defined.

159
 Customizing HeatWave’s Virtuoso GUI

Figure 48: SKILL and Tcl code organization

The preceding figure shows a typical organization of SKILL and Tcl code that is used to configure Heat-
Wave.

• while your environment may differ, this figure may still help you consider how to logically and physically
partition and set up your HeatWave configuration code.
• the "shared" SKILL or Tcl libraries represent one or more groups of utilities that may be shared by
different Physical Design Kits (PDKS), in their configuration of HeatWave. For example, a shared Tcl
library of materials may be defined, or a SKILL procedure to create a Electrical Solver Initialization
File may be defined, for use by multiple PDKs.
• each PDK will probably configure the default values and actions for most of the menu entries in the
HeatWave interface to Virtuoso to minimize the input required from the end-user of HeatWave
• each PDK will also need to configure procedures that define a thermal-technology or solver controls.
Each PDK may also need to set primitive variables controlling the meshing, solver and transient
simulation, or Context variables customizing the solver-flow.

12.3 Virtuoso Interface SKILL Data Model

The key concepts underlying HeatWave’s interface to Virtuoso are summarized below, and are further
described in the section on Using HeatWave’s Virtuoso GUI.

• HeatWave’s Virtuoso interface comprises a pulldown menu from which you may launch any of four
forms.

160
 Customizing HeatWave’s Virtuoso GUI

• each form has entries, whose current value you may set, by setting the fields of the main GUI structure,
named GdaHwGui, and the structures it contains. The initial values in the GUI structure determine the
values of each form entry, when the form is first presented to you.
• when setting up your thermal-simulation using the interface, you select a Thermal simulation mode ,
that is either steady-state or transient. A distinct Mode GUI structure, named GdaHwModeGui,
is created for each mode.
• when using the interface, you also select a circuit-simulator that computes the power dissipated
within an electro-thermal loop. For each supported circuit-simulator, in each mode, a distinct Simulator
GUI structure, named GdaHwSimGui, is created.

You may configure the user interface prevously described using simple SKILL data-structures that are shown
in the following schema or data-model figure.

161
 Customizing HeatWave’s Virtuoso GUI

Figure 49: SKILL Data Structures

For each variable shown in the preceding figure, the effects of the variable, and its corresponding form-field,
are described in the following sections. The reverse mapping, from a GUI form-field to a SKILL variable
name, is shown in figures in those sections, that label each form-field with its associated variable within a
GUI structure, a Mode GUI structure, or a Simulator GUI structure.
The SKILL structures shown in the preceding figure are organized as follows:

• GUI structure GdaHwGui is the main data-stucture that stores the data defining the current values of
all fields, as well as related controls, for all forms in HeatWave’s Virtuoso interface. The GUI structure

162
 Customizing HeatWave’s Virtuoso GUI

stores copies of the other data-structures, as shown in the figure.

• The GUI structure stores a copy (or instance) of the Mode GUI structure, for each possible value of hw-
CurrentMode. Each Mode GUI structure, in turn, stores a Simulator GUI structure for each simulator.
So, the form-settings for every simulator, in every mode, are stored as distinct variable-values.

The main pulldown-menu created by the HeatWave Virtuoso interface is accessible in your SKILL code as
described in the section on procedure gdaCreateGradientPullDownMenu, and summarized in the following
figure.

Figure 50: SKILL access to HeatWave pulldown

Most SKILL callback procedures should take one required argument (and may accept any number of op-
tional arguments). The exceptions are documented below. HeatWave’s SKILL interface will provide the
required argument when invoking the callback. This required argument is almost always a GdaHwGui GUI
structure.

12.4 Example of GUI Data Access

The GdaHwGui argument may be used to acquire the data-structures that contain the current values of all
entries in all forms, and values of some control-variables, as shown in following excerpt of SKILL code.

; example of a callback that performs actions after simulator setup

procedure( gdaPostGuiSim( hwGui ) ;hwGui is a GUI structure (GdaHwGui)
prog( ( modeGui simGui simSymbol spectreGui ...)

; get the Mode GUI structure (GdaHwModeGui) for the current mode
modeGui = gdaModeGui(hwGui) ; a Mode GUI structure (GdaHwModeGui)

; get the Simulator GUI structure (GdaHwSimGui) for the current simulator,
; in the current Thermal simulation mode
; hwSimTable[] contains a Simulator GUI structure for each simulator (symbol)
simSymbol = modeGui->hwCurrentSim ; current circuit simulator (symbol)
simGui = modeGui->hwSimTable[simSymbol] ; a Simulator GUI structure

; get the Simulator GUI structure for the Spectre simulator, which may not
; be the same as the current simulator, in the current mode
spectreGui= modeGui-> hwSimTable[’spectre] ; a Simulator GUI structure

163
 Customizing HeatWave’s Virtuoso GUI

; given the current hwGui, modeGui, and simGui structures, you may now read/use
; or set their fields’ values in your customizations below
info("Begin customizations after HeatWave has set up the %s simulator\n"
symbolToString(simSymbol))
...
)
)

12.5 GUI structure

This SKILL structure, named GdaHwGui, stores the "current" values of all entries, and related controls, for
all forms in HeatWave’s Virtuoso interface. It contains copies of a Mode GUI structure for each Thermal
simulation mode of HeatWave. The variables directly in this structure mainly control fields in the Thermal
Analysis Setup Form and the Power Source Extraction Form, as shown in the following figures.

Figure 51: Variables for Setup form

164
 Customizing HeatWave’s Virtuoso GUI

Figure 52: Variables for Power Source Extraction form

12.5.1 hwModeTable

This SKILL structure contains a Mode GUI structure for each possible value of the current mode variable,
as shown in the preceding figure. The section on Example of GUI Data Access shows how the current
Mode GUI structure may be obtained from this structure using the procedure gdaModeGui.

12.5.2 hwCurrentMode

This variable stores a SKILL symbol represents the type of thermal simulation being set up or launched
from HeatWave’s interface to Virtuoso. hwCurrentMode may take on one of two values: ’steady_state
or ’transient, This variable stores the "Thermal simulation mode" field of the Thermal Analysis Setup
Form within the HeatWave Menu. The default value is ’steady_state

12.5.3 hwCdsLib

This string variable stores the name of the Virtuoso library that contains the test-bench schematic of the
design. The schematic contains an instance of the cell being electro-thermally simulated. This variable
stores the "Library name" field of the Thermal Analysis Setup Form within the HeatWave Menu. The default
value is derived from the Virtuoso schematic-window, from which the HeatWave Menu was invoked.

165
 Customizing HeatWave’s Virtuoso GUI

12.5.4 hwCdsCell

This string variable stores the name of the Virtuoso cell within the Virtuoso library, whose extracted view
is instantiated within the test-bench schematic of the design being electro-thermally simulated. This variable
stores the "Cell name" field of the Thermal Analysis Setup Form within the HeatWave Menu. The default
value is derived by traversing the cell-view in the current window.

12.5.5 hwCdsSch

This two-element list contains two string values, that are respectively the library-name and the cell-
name of the schematic cell-view that defines your design’s test-bench in Virtuoso. To be valid, the test-bench
schematic must contain an instance of the extracted view of the cell (within the Virtuoso library) that will be
electro-thermally simulated within HeatWave. The default value is the library and cell-name of cell-view in
the current window, if the cell-view is a valid test-bench. If the cell-view in the current window is not a valid
test-bench, this field is not auto-set by HeatWave, so you will need to manually specify the library-name and
cell-name of a valid test-bench. If your CAD department has rules for deducing the test-bench, those rules
may be encoded in SKILL within the gdaPostInitGuiData() callback. An example value is list("opamp_-
test" "schematic").

12.5.6 hwCdsInstInSch

This string variable stores the instance-name of the cell that in instantiated within the test-bench
schematic. This value is computed and stored, but not displayed in any form.

12.5.7 hwOaLib

This string variable stores the name of the OpenAccess library, in which the layout-data for HeatWave is
stored. This variable stores the "OpenAccess library name" field of the Thermal Analysis Setup Form within
the HeatWave Menu. The default value is the value of the Virtuoso library name.

12.5.8 hwOaCell

This string variable stores the name of the OpenAccess cell, in which the layout-data for HeatWave is
stored. This value is not displayed in any form. The default value is the value of the cell name.

12.5.9 hwLockMode

This boolean variable (t or nil), if true, removes the "Thermal simulation mode" field from the Thermal
Analysis Setup Form, so the initial value that your CAD group sets (e.g. in gdaConfigureHwGui) for hw-
CurrentMode is the only one allowed. If false, the "Thermal simulation mode" field from the Thermal Analysis
Setup Form is displayed, and may be used. The default value is false (nil).

12.5.10 hwPtabLayer

This integer variable sets the default thermal layer number in which all power sources are defined. You
may control the thermal layer of a power-source by defining the callback procedure gdaPreWritePtabInst-
Layer. This variable stores the "Power thermal layer number" field of the Power Source Extraction Form
within the HeatWave Menu. The default value is 2.

166
 Customizing HeatWave’s Virtuoso GUI

12.5.11 hwExtView

This string variable sets the name of the extracted view of the Virtuoso cell. The section on the Power
Source Extraction Form explains how the extracted view is used, to obtain the extents of power sources
from your design data. This variable stores the "Extracted view" field of the Power Source Extraction Form
within the HeatWave Menu. The default value is "extracted".

12.5.12 hwExtViewList

This SKILL list variable define a list of string values, that specify valid extracted view-types. This variable
is used to find hwCdsSch, by visiting all instances within the hwCdsSch hwCdsSch "testbench schematic",
and finding any that have an extracted-view whose name matches one in the list. This value is not displayed
in any form. The default value is list("extracted" "av_extracted" "calibre")

12.5.13 hwLayoutView

This string variable sets the name of the layout view of the Virtuoso cell. This variable stores the "Layout
view" field of the Power Source Extraction Form within the HeatWave Menu. The default value is "layout".

12.5.14 hwPowerLayer

This string variable sets the name of the layer that defines the extents of power sources in the Virtuoso
layout of the cell. This use of this power layer is described in the section on Power Source Extraction Form.
This variable stores the "Power layer name" field of the Power Source Extraction Form within the HeatWave
Menu. The default value is an empty string.

12.5.15 hwPowerProp

This string variable stores the name of the "Power prop name" field in the Power Source Extraction Form,
which is used as described in that section. The default value is "power".

12.5.16 hwValidPropName

This string variable stores the name of the "Valid prop name" field in the Power Source Extraction Form,
which is used as described in that section. The default value is an empty string.

12.5.17 hwValidPropVal

This string variable stores the name of the "Valid prop value" field in the Power Source Extraction Form,
which is used as described in that section. The default value is an empty string.

12.5.18 hwValidLayer

This string variable stores the name of the "Valid layer name" field in the Power Source Extraction Form,
which is used as described in that section. The default value is an empty string.

167
 Customizing HeatWave’s Virtuoso GUI

12.5.19 hwExtractionMethod

This string variable stores the value of the "Extraction based on" field in the Power Source Extraction Form
(see that section) within the HeatWave Menu. The value must be either "power-layer" or "recognition-layer".
The default value is "power-layer" if hwExtView is "calibre" ; otherwise the default value is "recognition-layer".

12.5.20 hwTryAlternates

This boolean variable (t or nil), stores the value of the "Try alternate methods?" field in the Power Source
Extraction Form (see that section) within the HeatWave Menu. The default value is true (t)

12.5.21 hwGrowPowerBox

This float variable stores the value in Virtuoso user units (typically microns) of the "User-units around
device center" field in the Power Source Extraction Form (see that section) within the HeatWave Menu. The
default value is 0.

12.5.22 hwUserContext

This SKILL variable stores any extra data your CAD department may need to associate with HeatWave’s
SKILL GUI structure. This data may be arbitrarily complex. The default value is nil.

12.6 Mode GUI structure

This SKILL structure, named GdaHwModeGui, stores the values of form fields that depend on the Thermal
simulation mode of HeatWave. A distinct copy of this structure is stored in the GUI structure for each
possible mode. This structure stores copies of a Simulator GUI structure for each circuit simulator interface
provided by HeatWave.
The variables directly in this structure mainly control fields in the Thermal Analysis Invocation Form, as
shown in the following figure.

168
 Customizing HeatWave’s Virtuoso GUI

Figure 53: Variables for Invocation form

12.6.1 hwSimTable

This SKILL structure contains a Simulator GUI structure for each supported value of the current simulator-
variable, as shown in the figure in the section on Virtuoso Interface SKILL Data Model. Given a Mode GUI
structure such as modeGui in the Example of GUI Data Access, you may obtain the current Simulator GUI
structure (GdaHwSimGui) in SKILL as follows:

simGui = modeGui->hwSimTable[hwGui->hwCurrentMode] ; for the current simulator

169
 Customizing HeatWave’s Virtuoso GUI

12.6.2 hwCurrentSim

This variable stores a SKILL symbol representing the simulator-interface that is used to set up the electrical
solver used in HeatWave’s interface to Virtuoso. hwCurrentSim may be ’eldo, ’finesim, ’hspice,
’spectre or ’ultrasim, if mode is ’steady_state. If mode is ’transient, this variable may be
’eldo, ’finesim, ’hspice or ’spectre. This variable stores the value of the "Simulator and local
run-directory name" field of the Simulation Setup Form within the HeatWave Menu. The default value is
’spectre

12.6.3 hwExecName

This string variable stores the executable name that will be invoked to run thermal simulation. In
steady_state mode , the values may be "firebolt" or "heatwave", while in transient mode, the only
value allowed is "heatwave". This variable stores the "Thermal Analysis Executable Name" field of the
Thermal Analysis Invocation Form within the HeatWave Menu. The default value is "heatwave"

12.6.4 hwRunDir

This string variable stores the name of the run-directory in which hwExecName is invoked. This variable
stores the "HeatWave run-directory" field of the Thermal Analysis Setup Form within the HeatWave Menu.
The default value is "gda"

12.6.5 hwTranTimes

This string variable containing one or more numbers, stores the value of the "Start Stop Step Min-Step
(s)" field of the Thermal Analysis Invocation Form (see that section) within the HeatWave Menu. This string
will be used as the value of the Context variable trtimes, so it has an identical format. This variable only
applies in ’transient mode, when run is selected. In that case, at least the Start and Stop times must
be provided, or an error dialog-box is displayed. The default value is an empty string.

12.6.6 hwTranSteps

This string variable containing one or more numbers, stores the value of the "Time-steps(time) table (s)"
field of the Thermal Analysis Invocation Form (see that section) within the HeatWave Menu. This string will
be used as the value of the Context variable trsteps, so it has an identical format. This variable only applies
in ’transient mode, when run is selected. The default value is an empty string.

12.6.7 hwTranReloads

This string variable containing one or more numbers, stores the value of the "Reload times" field of the
Thermal Analysis Invocation Form (see that section) within the HeatWave Menu. This string will be used
as the value of the Context variable reloads, so it has an identical format. This variable only applies in
’transient mode, when run is unselected, so a previous solution is being reloaded. The default value is
an empty string.

170
 Customizing HeatWave’s Virtuoso GUI

12.6.8 hwRunResultDir

This string variable sets the name of the directory in which transient thermal-simulation results are stored.
This variable stores the value of the "Save temperature waveform results in" field of the Thermal Analysis
Invocation Form (see that section) within the HeatWave Menu. This variable only applies in ’transient
mode, when run is selected. The default value is "transient/testResults", within the run directory,

12.6.9 hwLoadResultDir

This string variable sets the name of the directory from which existing thermal simulation results are
loaded. This variable stores the value of the "Load temperature waveform results from" field of the Ther-
mal Analysis Invocation Form (see that section) within the HeatWave Menu. This variable only applies in
’transient mode, when run is un-selected. The default value is "transient/testResults.au", within the run
directory.

12.6.10 hwLockSim

This boolean variable (t or nil), if true, restricts the "Simulator and local run-directory name" (see hw-
CurrentSim) in the Simulation Setup Form in the HeatWave Menu. The form-field is restricted to the initial
value of hwCurrentSim, that your CAD group may set (e.g. in gdaConfigureHwGui). If this variable is false,
the "Simulator and local run-directory name" field from the Simulation Setup Form may be modified. The
default value is false (nil).

12.6.11 hwRun

This boolean variable (t or nil) if true, starts a thermal simulation run. If false, previously saved results
are loaded. This variable stores the value of the "Run simulation [or only read archive]?" field of the Thermal
Analysis Invocation Form (see that section) within the HeatWave Menu. The default value is true (t)

12.6.12 hwBatch

This boolean variable (t or nil) if true, starts a batch simulation run. If false, a GUI is launched when
the simulation finishes. This variable stores the value of the "Invoke in batch mode?" field of the Thermal
Analysis Invocation Form (see that section) within the HeatWave Menu. The default value is false (nil)

12.6.13 hwSaveShapes

This boolean variable (t or nil) if true, saves a text file listing temperatures on all geometries, after the
simulation finishes. If false, no such file is produced. This variable stores the value of the "Write shape-
temperature file?" field of the Thermal Analysis Invocation Form (see that section) within the HeatWave
Menu. The default value is false (nil).

12.6.14 hwRunLogFile

This string variable specifies the HeatWave’s output log file name. This variable stores the value of the
"Log file name" field of the Thermal Analysis Invocation Form (see that section) within the HeatWave Menu.
The default value is "gda_cds.log" in steady_state mode and "gda_transient_cds.log" in transient
mode.

171
 Customizing HeatWave’s Virtuoso GUI

12.6.15 hwTclTech

This string variable specifies the name of the Tcl procedure that defines your current thermal technology,
similarly to these examples. The value of this variable is used to set the Context variable tech, that deter-
mines the name of the Tcl technology-definition procedure in HeatWave. This variable stores the value of
the "Tcl proc defining technology" field of the Thermal Analysis Invocation Form (see that section) within
the HeatWave Menu. The default value is cxtTech.

12.6.16 hwTechIni

This string variable specifies the name of the technology and package file that is an input to Heat-
Wave. This variable stores the value of the "Technology or package file name" field of the Thermal Analysis
Invocation Form (see that section) within the HeatWave Menu. The default value is "gdatech.ini".

12.6.17 hwEsolveIni

This string variable specifies the name of the electrical solver control file that is an optional input to Heat-
Wave. This variable stores the value of the "HeatWave simulation-control-file name" field of the Thermal
Analysis Invocation Form (see that section) within the HeatWave Menu. The default value is "gda_sim.ini".

12.6.18 hwMeshIni

This string variable specifies the name of the mesh control file file that is an optional input to HeatWave.
This variable stores the value of the "HeatWave analysis control-file" field of the Thermal Analysis Invocation
Form (see that section) within the HeatWave Menu. The default value is "gdamesh.ini".

12.6.19 hwReadArchive

This string variable specifies the name of the archive that HeatWave should restore. This value is speci-
fied as the Context variable restore to configure the customizable flow that will be run. This variable stores
the value of the "HeatWave archive file to read" field of the Thermal Analysis Invocation Form (see that
section) within the HeatWave Menu. The default value is an empty string (see restore for more on this).

12.6.20 hwWriteArchive

This string variable specifies the name of the output-file that HeatWave should save as an archive. This
value is specified as the Context variable archive to configure the customizable flow that will be run. This
variable stores the value of the "HeatWave archive file to write" field of the Thermal Analysis Invocation
Form (see that section) within the HeatWave Menu. The default value is an empty string

12.6.21 hwTcl

This string variable specifies the name of the main Tcl script that HeatWave’s Virtuoso interface should
produce, and that HeatWave will run. This value is not displayed in any form. The default value is "run.tcl"
in steady_state mode and "run_transient.tcl" in transient mode.

172
 Customizing HeatWave’s Virtuoso GUI

12.6.22 hwSummarizeTemps

This boolean variable (t or nil) sets the value of the Context variable summary (see that section) variable.
This variable stores the value of the "Summarize layer temperatures in logfile?" field of the Thermal Analysis
Invocation Form (see that section) within the HeatWave Menu. The default value is false (nil)

12.7 Simulator GUI structure

This SKILL structure, named GdaHwSimGui stores the values of form fields that depend on the current
circuit simulator and the current mode of HeatWave. A distinct copy of this structure is stored in each Mode
GUI structure for each supported simulator.
The variables directly in this structure mainly control fields in the Simulation Setup Form, as shown in the
following figure.

Figure 54: Variables for Simulation Setup form

12.7.1 hwSimName

This string variable specifies the name of circuit simulator interface represented by this Simulator GUI
structure. This value is derived from that of the current simulator, and should not be explicitly set. It is not
displayed in any form. The default value is "spectre".

173
 Customizing HeatWave’s Virtuoso GUI

12.7.2 hwSimRunDir

This string variable specifies the name of a valid run-directory for this simulator. This directory is used
to build HeatWave’s local copy. This variable stores the "Reference simulator run directory" field of the
Simulation Setup Form within the HeatWave Menu. The default value is empty, as it cannot be deduced,
and must be specified.

12.7.3 hwSimNetlist

This string variable specifies the name of the netlist for the simulator. This variable stores the "Netlist in
reference run directory" field of the Simulation Setup Form within the HeatWave Menu. The default value is
"input.scs", the default Spectre netlist-name.

12.7.4 hwSimOutRelPath

This string variable specifies the output path for the simulator results. This variable stores the "Simulation
output-data directory" field of the Simulation Setup Form within the HeatWave Menu. The default value is
"psf", a Spectre output directory-name.

12.7.5 hwSimScript

This string variable specifies the simulation script provided by HeatWave, that runs circuit-simulation to
obtain the power dissipated by each instance. This variable stores the "Script to run simulation, extract
power" field of the Simulation Setup Form within the HeatWave Menu. The default value is "hw_spectre",
the Spectre interface-script.

12.7.6 hwSimMaxTemp

This float variable specifies the maximum temperature HeatWave may annotate into circuit-simulation
.This variable stores the "Max temperature to annotate on devices" field of the Simulation Setup Form
within the HeatWave Menu. The default value is 200.

12.7.7 hwSimTempStr

This string variable specifies the name of the parameter that HeatWave must specify, to set the temper-
ature on each simulation instance. This variable stores the "Temperature parameter-name in netlist" field
of the Simulation Setup Form within the HeatWave Menu. The default value is set appropriately for each
simulator.

12.7.8 hwSimSubckt

This string variable specifies the name of the sub-circuit containing the physical extracted view that
contains the power sources. This variable stores the "Subcircuit name" field of the Simulation Setup Form
within the HeatWave Menu. The default value is set appropriately for each simulator.

174
 Customizing HeatWave’s Virtuoso GUI

12.7.9 hwSimLocDir

This string variable specifies the name of the local simulation directory within the HeatWave run-directory
This value is typically that of the simulator name and should not be modified. This value is not displayed in
any form. The value is automatically set for each simulator.

12.7.10 hwSimOverwriteLocDir

This boolean variable (t or nil), if true, allows HeatWave’s Virtuoso interface to overwrite the local sim-
ulation run-directory, if one already exists. If the value is false, the previous simulation run-directory is
renamed. This variable stores the "Overwrite local run-dir ?" field of the Simulation Setup Form within the
HeatWave Menu. The default value is true (t).

12.7.11 hwSimCmdStr

This string variable is optional and specifies the circuit-simulation command for the simulator, omitting
the netlist name at the end , which will be appended by HeatWave. This string is not used by HeatWave’s
Virtuoso interface. If needed, it should be processed by a callback; as shown in the example for gda-
PostGuiSim. This variable stores the "Simulation command" field of the Simulation Setup Form within the
HeatWave Menu. The default value is an empty string.

12.8 SKILL Globals

This section describes SKILL global variables within HeatWave’s SKILL code, that may be of use in cus-
tomizing HeatWave’s Virtuoso interface.

12.8.1 gdaDefaultMenuTrigger

By default, the HeatWave pulldown-menu created by the HeatWave Virtuoso interface is installed in windows
that contain any of the following view-types: schematic, maskLayout, extracted, av_extracted, or
calibre However, you may need the HeatWave pulldown-menu to appear for a different set of view-types.
The gdaDefaultMenuTrigger variable allows you to specify the the list of Cadence view-types within which
the HeatWave pulldown-menu appears. The default value of this variable is

list("schematic" "maskLayout" "extracted" "av_extracted" "calibre")

An example of a gdaDefaultMenuTrigger setting to display the HeatWave pulldown-menu only in schematic

windows follows:

gdaDefaultMenuTrigger = list("schematic");

12.8.2 gdaSourceSelector

During the power source extraction process described in the Power Source Extraction Form section, when
the "power_layer" method is used, and when multiple shapes are found containing the location point of
the power-source, the last shape visited in SKILL is chosen as the extent of the power source. The gda-
SourceSelector variable allows you to select which shape is selected in the case described above. The
only recognized value is

gdaSourceSelector = ’minArea

175
 Customizing HeatWave’s Virtuoso GUI

which results in the shape with the smallest area being chosen as the power-source extent. The default
value of gdaSourceSelector is nil, resulting in the last-visited shape being selected.

12.9 SKILL Procedures

This section describes SKILL utilities that may be of use when writing SKILL Callback Procedures to con-
figure HeatWave’s Virtuoso interface These procedures are already invoked within the normal flow of the
HeatWave interface to Virtuoso. However, they may be useful to your CAD software group, in automating
steps within the flow when the locations of all the required data are known.

12.9.1 procedure gdaIsSteadyState

This SKILL procedure takes a mode as its single argument and returns a boolean (t or nil) indicating
whether that mode is ’steady_state. Given a GUI structure such as hwGui in the Example of GUI Data
Access, the following SKILL code would work:

if(gdaIsSteadyState(hwGui->hwCurrentMode) then
... ; steady-state actions
else
... ; transient actions
)

12.9.2 procedure gdaModeGui

This SKILL procedure takes a GUI structure as its single argument and returns the current Mode GUI (Gda-
HwModeGui) for the current thermal simulation mode. Given a GUI structure such as hwGui in the Example
of GUI Data Access, this procedure returns a value equivalent to the following SKILL code:

hwGui->hwModeTable[hwGui->hwCurrentMode] ; mode GUI structure for the current mode

An example of gdaModeGui invocation follows:

modeGui = gdaModeGui(hwGui) ;hwGui is a GUI structure (GdaHwGui)

12.9.3 procedure gdaSimGui

This SKILL procedure takes a GUI structure as its single argument and returns the current Sim GUI (Gda-
HwSimGui) for the current thermal simulation mode and the current circuit simulator . Given a GUI structure
such as hwGui in the Example of GUI Data Access, this procedure returns a value equivalent to the follow-
ing SKILL code:

modeGui = gdaModeGui(hwGui) ; mode exists, get it

sim = modeGui->hwCurrentSim ; current circuit simulator (symbol)
simStr = symbolToString(sim) ; current circuit simulator (string)

An example of gdaSimGui invocation follows:

simGui = gdaSimGui(hwGui) ;hwGui is a GUI structure (GdaHwGui)

176
 Customizing HeatWave’s Virtuoso GUI

12.9.4 procedure gdaCreateGradientPullDownMenu

This SKILL utility procedure takes no arguments and and returns an identifier for the pulldown-menu created
by the HeatWave Virtuoso interface. This object is as returned by Virtuoso’s hiCreatePulldownMenu
procedure. The gdaCreateGradientPullDownMenu procedure is called by HeatWave as the banner
menus for your Virtuoso window are built. So, your invocation of this procedure should not create a new
pulldown menu, but should return the existing HeatWave pulldown menu id. This pulldown-menu object is
also accessible as a SKILL global variable named GdaGuiMenu, as summarized in the final figure of the
Virtuoso Interface SKILL Data Model section.
Keysight recommends that you do not modify the individual forms within the top-level HeatWave pulldown
menu. However, we encourage the customization of the top-level HeatWave pulldown menu, including the
addition of your own forms, that may be used to set the values of HeatWave form-fields.
An example of gdaCreateGradientPullDownMenu invocation follows:

procedure(myCallback() println("this is my test callback procedure"));

myMenuItem = hiCreateMenuItem(?name ’myMenu ?itemText "MY MENU" ?callback "myCallback()")
gdaMenu = gdaCreateGradientPullDownMenu() ; or = GdaGuiMenu
if( gdaMenu && myMenuItem
hiInsertMenuItem(gdaMenu myMenuItem 0) ; see Cadence SKILL manuals
error("myMenuItem or gdaMenu are not valid menu objects")
)

12.9.5 procedure gdaGuiSetupPowerSources

This SKILL utility procedure takes a GUI structure as its single argument and returns a boolean (t if suc-
cessful or nil if errors occurred). This procedure is called by the Power Source Extraction Form after the
OK button is clicked and after the callback gdaPreGuiPsrc is invoked. This procedure performs the tasks
described in the Power Source Extraction Form section.
This procedure is already called by HeatWave’s SKILL interface, as described above. However, you may
wish to automate this task in your CAD environment. For example within a callback such as procedure gda-
PreGuiRun, if you find that the user has not created the power-source extent table file <lib-name>.ptab
using the Power Source Extraction Form, you may do that task by invoking gdaGuiSetupPowerSources.
An example of gdaGuiSetupPowerSources invocation follows:

status = gdaGuiSetupPowerSources(hwGui) ;hwGui is a GUI structure (GdaHwGui)

12.9.6 procedure gdaGuiSetupSim

This SKILL utility procedure takes a GUI structure as its single argument and returns a boolean (t if suc-
cessful or nil if errors occurred). This procedure is called by the Simulation Setup Form after the OK
button is clicked and after the callback gdaPreGuiSim is invoked. This procedure performs the following
tasks :

• verifies that the hwSimRunDir and hwSimNetlist exist

• verifies that the cross-reference file <cell-name>.gdai exists and that the power-source extent table
file <lib-name>.ptab exists in hwRunDir .
• builds hwSimLocDir, the local simulation directory, overwriting (or moving aside) one if it exists. The
instantiation of each power-source in <lib-name>.ptab is found in the netlist hwSimNetlist, and a
statement setting a temperature parameter hwSimTempStr is added to the instantiation statement in
a local copy of the netlist within hwSimLocDir hwSimLocDir.

177
 Customizing HeatWave’s Virtuoso GUI

This procedure is already called by HeatWave’s SKILL interface, as described above. However, you may
wish to automate this task in your CAD environment. For example within a callback such as procedure
gdaPreGuiRun, if you find that the user has not set up the simulation run directory using the Simulation
Setup Form, you may do that task by invoking procedure gdaGuiSetupSim
An example of gdaGuiSetupSim invocation follows:

status = gdaGuiSetupSim(hwGui) ;hwGui is a GUI structure (GdaHwGui)

12.10 SKILL Callback Procedures

This following sections describe the callback procedures that your CAD software department may use to
set up HeatWave’s interface to Virtuoso appropriately for your environment. As described in the section
on the Virtuoso Interface SKILL Data Model, nearly all SKILL callbacks in this interface must take one
required argument, and may accept any number of optional arguments. That required argument is a Gda-
HwGui GUI structure. The exceptions are gdaPreWritePtabInstLayer, gdaPreWritePtabGeometry and gda-
PreCommand, as described later in this section. HeatWave’s SKILL interface will provide the required
argument(s) when invoking the callback.
When you open a Virtuoso schematic window, HeatWave’s Virtuoso interface does the following:

• creates SKILL GUI structure, Mode GUI structure and Simulator GUI structure to store the contents
of form-fields

• creates menu-structures for a HeatWave pull-down menu in the banner of your window

Later, when you pull-down the HeatWave menu and select an entry:

• the data-structures for a form are created, and the form-fields are filled with the values in the GUI
structure.

The callbacks described below are invoked at various points in the flow, including:

• immediately after the SKILL GUI structure, Mode GUI structure and Simulator GUI structure objects
are created, but before menus or forms are defined. This allows you to specify default values for the
form fields.
• after the GUI pulldown menu is created

• just after the OK button is clicked for any form, but before the actions for that form are performed
• after the actions for a form are performed

Following are descriptions of each callback, indicating the point at which each one is invoked. Most call-
backs take a single required argument that is a GdaHwGui GUI structure. In the following examples this
argument has the arbitrary variable name hwGui

12.10.1 procedure gdaConfigureHwGui

This callback is invoked immediately after the SKILL GUI structure, Mode GUI structure and Simulator GUI
structure are created. These structures contain the values that will be seen in the fields of the Thermal
Analysis Setup Form, Power Source Extraction Form, Simulation Setup Form and Thermal Analysis Invo-
cation Form. In this callback, you may modify any of the values described in the preceding sections, with
settings appropriate to your CAD and design environment.

178
 Customizing HeatWave’s Virtuoso GUI

; example of a callback that acts just after the GUI structure is created,
; but before forms are created
procedure(gdaConfigureHwGui(hwGui) ;hwGui is a GUI structure (GdaHwGui) structure
prog( (ss tran ssSpectreGui tranSpectreGui)
info("(gda) begin configuring GUI settings\n")

hwGui->hwPowerLayer = "y0" ; power layer

;ss and tran are Mode GUI structure (GdaHwModeGui) structures

ss = hwGui->hwModeTable[’steady_state]
tran = hwGui->hwModeTable[’transient]
ss->hwTechIni = "pkg.ini"
ss->hwTclTech = "opampTech"
tran->hwRun = nil ; load archived results
tran->hwTechIni = "pkg.ini"
tran->hwTclTech = "opampTech"; Tcl opampTech

;ssSpectreGui and tranSpectreGui are Simulator GUI structure (GdaHwSimGui) structures

ssSpectreGui = ss->hwSimTable[’spectre]
ssSpectreGui->hwSimRunDir = "nl" ; ADE Spectre steady-state
ssSpectreGui->hwSimMaxTemp = 180.0 ; limit max delta-temp
tranSpectreGui = tran->hwSimTable[’spectre]
tranSpectreGui->hwSimRunDir = "nl_tran" ; ADE Spectre transient

info("(gda) configured GUI\n")

return t
)
)

12.10.2 procedure gdaPostInitGuiData

This callback is invoked after the initial SKILL data-structures are created and immediately before the Ther-
mal Analysis Setup Form is created. In this callback, you may modify any of the values described in the
preceding sections, with settings appropriate to your CAD and design environment.

12.10.3 procedure gdaPostGuiSetup

This callback is invoked after the Thermal Analysis Setup Form OK button is clicked and all that form’s
actions have been performed. In this callback, you may read any of the values described in the preceding
sections, but you should only modify values related to the Power Source Extraction Form, Simulation Setup
Form and Thermal Analysis Invocation Form, with settings appropriate to your CAD and design environ-
ment.

12.10.4 procedure gdaPreGuiPsrc

This callback is invoked after the Power Source Extraction Form OK button is clicked but before any of
that form’s actions have been performed. In this callback, you may read any of the values described in
the preceding sections, but you should only modify values related to the Power Source Extraction Form,
Simulation Setup Form and Thermal Analysis Invocation Form, with settings appropriate to your CAD and
design environment.

179
 Customizing HeatWave’s Virtuoso GUI

12.10.5 procedure gdaPreWritePtabInstLayer

This callback is invoked after the Power Source Extraction Form OK button is clicked. The callback is
invoked during the traversal of instances in the extracted view. The purpose of this callback is to assign a
thermal-layer, and therefore a vertical extent, to any power-source, as needed. HeatWave will invoked this
callback procedure with two arguments:

• first, a Virtuoso database object, that is the instance of a power-source

• second, an integer representing the current thermal-layer number of the instance, which is usually the
hwPtabLayer value.

The callback should return a single value that is one of the following:

• an integer representing the correct thermal-layer number (index) for the instance,
• a string value representing the thermal-layer name for the instance,

An example that assigns a thermal layer to each given instance follows:

; callback gdaPreWritePtabInstLayer:
; This example uses the instance’s master-name to determine the
; device-type ; and hence, its thermal-layer-number.
; You may choose any method to implement this mapping.
; This example uses a table (MyDeviceLayerTable) to map the instance’s
; master’s name to a layer number.
; MyDeviceLayerTable, in this case, is a SKILL assoc-list of the form
; ((g_key1 g_value1) (g_key2 g_value2) ... (g_keyN g_valueN))
; The key is the instance-master’s cellname, and the value is the
; HeatWave thermal layer name in which to place the device (instance).
MyDeviceLayerTable = list(
’("res" "poly") ’("pmos4" "channel") ’("nmos4" "channel"))

; gdaPreWritePtabInstLayer(...)
; sets thermal layer name or number of a power source
; This version is an example.
; You should write a version for your CAD/design environment.
; This procedure should be defined in each design kit (PDK).

procedure(gdaPreWritePtabInstLayer(
dbInstPowerSource ; power source instance db object
intCurrentPowerLayer ; current thermal-layer of
) ; power source
prog( (cv lib cell lyr val)
verbose = nil ; t --> messages even if no changes
lyr = intCurrentPowerLayer ; default return is same as input

; Here are the steps to writing this procedure

; 0. Check data
; Check that the device to layer mapping table is well-defined.
; Replace USER by your company-name, or other identifier
unless(dbInstPowerSource return(lyr))
unless((boundp(’MyDeviceLayerTable) && MyDeviceLayerTable != nil)
; build table using buildMyDeviceLayerTable()
; You may write buildMyDeviceLayerTable() to create the table

180
 Customizing HeatWave’s Virtuoso GUI

unless( fboundp(’buildMyDeviceLayerTable)
&& buildMyDeviceLayerTable()
error("(USER) can’t build device-to-layer-map\n")
return(lyr)
)
)

; 1. Get inst’s master (library and cellname)

cv = inst~>master ; cellview of master
if( verbose info("(USER) processing inst %s\n" inst~>name))
when( cv
lib = cv~>libName
cell = cv~>cellName
if( verbose info("(USER) inst %s -> lib %s cell %s\n"
inst~>name lib cell)
)
; 2. Lookup inst’s master (lib cell) in table
; If found, return the corresponding power-layer-number.
; If not found, return intCurrentPowerLayer
when( lib && cell ; lookup cellname in table
val = assoc( cell MyDeviceLayerTable)
if( val && listp(val) val = cadr(val))
when( fixp(val) || stringp(val)
when( verbose
info("(USER) re-set layer of inst ")
info("%s (cell %s) from %d to %s\n"
inst~>name cell lyr
if(fixp(val) sprintf(nil "%d" val) val))
)
lyr = val
)

)
)
; lyr = thermal layer name or number for dbInstPowerSource
return(lyr)
)
)

12.10.6 procedure gdaPreWritePtabGeometry

This callback is invoked after the Power Source Extraction Form OK button is clicked. The callback is
invoked during the traversal of instances in the extracted view. The purpose of this callback is to assign a
new horizontal (x,y) extent to any power-source, if needed. HeatWave will invoked this callback procedure
with two arguments:

• first, a Virtuoso database object, that is the instance of a power-source

• second, a list of four co-ordinates, in OA user units representing the current power source geometry.

The callback should return a single value, which may be the same as the second argument:

• a list of four co-ordinates, in OA user units, representing the new power source geometry.

An example that assigns a geometry to each given instance follows:

181
 Customizing HeatWave’s Virtuoso GUI

; callback gdaPreWritePtabGeometry:
; This example takes the original power source and its geometry,
; and calls user defined function modifyPowerSourceGeometry() to
; define a new geometry
; gdaPreWritePtabGeometry(...)
; defines the geometry, or (x,y) extent of a power source
; This version is only an example.
; You should write a version for your CAD/design environment.
; If needed, this procedure should be defined in the design kit (PDK).
procedure(gdaPreWritePtabGeometry(
dbInstPowerSource ; power source instance db object
geomList ; power source geometry: a list of points
)
prog( ( newGeom ... )
;Modify the power source geometry as needed.
...
newGeom = modifyPowerSourceGeometry(dbInstPowerSource geom)
return(newGeom) ; a list of 2 points is expected
)
)

12.10.7 procedure gdaPostGuiPsrc

This callback is invoked after the Power Source Extraction Form OK button is clicked and after that form’s
actions have been performed. In this callback, you may read any of the values described in the preceding
sections, but you should only modify values related to the Simulation Setup Form and Thermal Analysis
Invocation Form, with settings appropriate to your CAD and design environment.

12.10.8 procedure gdaPreGuiSim

This callback is invoked after the Simulation Setup Form OK button is clicked but before any of that form’s
actions have been performed. In this callback, you may read any of the values described in the preceding
sections, but you should only modify values related to the Simulation Setup Form and Thermal Analysis
Invocation Form, with settings appropriate to your CAD and design environment.

12.10.9 procedure gdaPostGuiSim

This callback is invoked after the Simulation Setup Form OK button is clicked and after that form’s actions
have been performed. In this callback, you may read any of the values described in the preceding sections,
but you should only modify values related to the Thermal Analysis Invocation Form, with settings appropriate
to your CAD and design environment.

; gdaPostGuiSim
; Sets up a gda_sim.ini file in the run directory
; This version is an example.
; You should write a version for your CAD/design environment.
procedure( gdaPostGuiSim(hwGui); hwGui is a GUI structure (GdaHwGui)
prog( (fname ofile modeGui simGui sim simStr)

; get Mode GUI structure (GdaHwModeGui) for current mode

modeGui = gdaModeGui(hwGui) ; mode exists, get it
sim = modeGui->hwCurrentSim ; current circuit simulator (symbol)
simStr = symbolToString(sim) ; current circuit simulator (string)
simGui = modeGui->hwSimTable[sim]; gui settings for current simulator

182
 Customizing HeatWave’s Virtuoso GUI

; circuit-simulator invocation-control file (default gda_sim.ini)

sprintf(fname "%s/%s" modeGui->hwRunDir modeGui->hwEsolveIni)
unless( eq(sim ’spectre) || eq(sim ’eldo)
warn("(gdaPostGuiSim) cannot create %s for simulator \"s$\$”\n" fname simStr)
return(nil)
)
when(isFile(fname) info("(gdaPostGuiSim) will overwrite existing %s\n" fname))

; create file to control HeatWave’s Spectre invocation

info("(gdaPostGuiSim) creating %s for simulator \"s$\$”\n" fname simStr)
ofile = outfile(fname "w") ; controls invocation of circuit simulator
fprintf(ofile strcat( "\n"
"solver_type %s\n"
"%s_netlist %s/%s\n"
"%s_subckt %s\n"
"%s_script %s\n")
simStr
simStr simGui->hwSimLocDir simGui->hwSimNetlist ; <sim>_netlist
simStr simGui->hwSimSubckt ; <sim>_subckt
simStr simGui->hwSimScript ; <sim>_script
)
if( !equal(simGui->hwSimCmdStr "")
fprintf(ofile "%s_command %s\n" simStr simGui->hwSimCmdStr)
)
caseq( sim
(’spectre
fprintf(ofile "spectre_psf %s/tran.tran\n" simGui->hwSimOutRelPath)
)
(’eldo
fprintf(ofile "eldo_pwr %s/eldo.out" simGui->hwSimOutRelPath)
)
(t ; this statement should not be reached
close(ofile)
warn("(gdaPostGuiSim) cannot create %s for unknown simulator \"s$\$”\n"
fname simStr)
return(nil)
)
)
close(ofile)
return(t)
)
)

12.10.10 procedure gdaPreGuiRun

This callback is invoked after the Thermal Analysis Invocation Form OK button is clicked but before any
of that form’s actions have been performed. In this callback, you may read any of the values described in
the preceding sections, but you should only modify values related to the Thermal Analysis Invocation Form,
with settings appropriate to your CAD and design environment.

12.10.11 procedure gdaPreCommand

This callback is invoked after the Thermal Analysis Invocation Form OK button is clicked, and after the Heat-
Wave command-string is built, but before that command-string is executed. The purpose of this callback is
to define a custom HeatWave invocation string, for example, the command to launch HeatWave in a Load

183
 Customizing HeatWave’s Virtuoso GUI

Sharing Facility (LSF). HeatWave will invoke this callback procedure with one string-valued argument, which
is the current value of the HeatWave invocation string. This callback should return a single string-value that
is the customized HeatWave invocation string you wish to use.

; This example reports the current HeatWave invocation command, and shows
; how you would return your customized HeatWave invocation command.
; This version is an example.
; If needed, write a version for your CAD/design environment.
procedure(gdaPreCommand(
currentCommand ; current HeatWave invocation string
)
prog( (myCommand)
println(sprintf(nil "Current command: %s\n" currentCommand))
myCommand = currentCommand
; customize myCommand below
...
return(myCommand)
)
)

12.10.12 procedure gdaPostGuiRun

This callback is invoked after the Thermal Analysis Invocation Form OK button is clicked and after that
form’s actions have been performed. In this callback, you may read any of the values described in the
preceding sections, but you should not modify any form values. You may perform any actions appropriate
to your CAD and design environment.

184