Installation
------------
1. Download the HotSpot tar ball (HotSpot-4.1.tar.gz) following the
instructions at http://lava.cs.virginia.edu/HotSpot
2. Unzip and untar the file using the following commands
a) gunzip HotSpot-4.1.tar.gz
b) tar -xvf HotSpot-4.1.tar
3. Go to the HotSpot installation directory
a) cd HotSpot-4.1/
4. Uncomment the lines corresponding to your installation of the BLAS/LAPACK
vendor libraries (see http://www.netlib.org/blas/faq.html#5) and set the path
and compiler options corresponding to your library. This version of HotSpot has
code integrated for Intel Math Kernel Library, AMD Core Math Library, Apple
Velocity Engine and Sun Performance Library. Extending it to other vendors
should be straightforward. For such an extension, apart from the user guide
from those vendors, http://www.netlib.org/blas/blast-forum/cinterface.pdf might
also be useful as it provides useful description of the C interface to BLAS.
5. Build HotSpot
a) make
7. To remove all the outputs of compilation, type 'make clean'. To remove the
object files alone, type 'make cleano'. To view the list of files HotSpot needs
for proper working, type 'make filelist'. To compile for debugging, use 'make
DEBUG=1'. To compile for using with a profiler (e.g. gprof), use 'make DEBUG=2'.
8. Known compatibility issues:
a) For old AMD machines without SSE2 instructions, the most recent version
of ACML available is 3.1.0. On such machines, the ACML library works with
GCC 4.0 but not with GCC 4.1.
b) Linking with Sun Performance Library on old Solaris machines fails as
'libmtsk' was not found.
(e.g. see http://supportforum.sun.com/jive/thread.jspa?threadID=72529)
Installing patch 117560 from Sun's patch finder
(http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access)
solves the problem.
HotSpot 4.1 Changes
-------------------
This release of HotSpot incorporates the following improvements:
1) The steady-state solver of the grid model has been upgraded from
a Gauss-Seidel solver to a multigrid solver. This results in typical
steady-state computation speedups > 20x. In order to facilitate the
multigrid implementation, now the grid dimensions are required to be
a power of two. Hence, the default grid size has been modified from
50x50 to 64x64.
2) The simulator template (sim-template.c) that illustrates the use
of HotSpot in a typical cycle-accurate simulator has been upgraded
to include grid model usage. Earlier it only demonstrated the use of
the block model (sim-template_block.c)
3) The 'Makefile' has been upgraded to wrap HotSpot into a library
(libhotspot.a) for easier integration with existing simulators.
4) Bugfixes etc.:
a) A bug in 'hotspot.c' lead to erroneous power averaging in
modeling 3-D chips while using the grid model. This has been
fixed in this release.
b) A bug in the floorplan plotting script 'tofig.pl' caused
temporary files not to be deleted. It has been fixed now.
c) Other minor changes like fixing typos etc.
HotSpot 4.0 Changes
-------------------
This version of HotSpot incorporates several accuracy enhancements described
in the following paper:
W. Huang, K. Sankaranarayanan, R. J. Ribando, M. R. Stan and K. Skadron.
"An Improved Block-Based Thermal Model in HotSpot 4.0 with Granularity
Considerations." In Proceedings of the Workshop on Duplicating,
Deconstructing, and Debunking, in conjunction with the 34th International
Symposium on Computer Architecture (ISCA), June 2007 (pdf).
Extended discussion and results can be found in this technical report.
While the paper itself focuses on the block model, some of the changes also
improve the accuracy of the grid model. Specifically, following is a list of
the modifications:
a) Accuracy Enhancements:
1) Enhanced package modeling: removal of the forced isotherm
2) Modeling of lateral heat flow in the TIM layer
3) Block model: a wrapper script to sub-divide floorplan blocks
with high aspect ratio to improve accuracy
4) Grid model: upgradation of the first order transient sover to
a fourth order adaptive step-size Runge-Kutta solver
5) Grid model: an option to maintain grid thermal state across
calls to the transient solver
b) Updated defaults:
The default package parameters have been updated to reflect
contemporary packages. The most significant of the changes are:
1) Die thickness has been updated to 0.15 mm down from 0.5 mm.
(See: B. Majeed, I. Paul, K. M. Razeeb, J. Barton and S. C. O'Mathuna.
"Microstructural, Mechanical, Fractural and Electrical Characterization
of Thinned and Singulated Silicon Test Die". Journal of Micromechanics
and Microengineering, 16:1519-1529, Aug. 2006.)
2) Tim thickness and resistivity have been updated respectively to 20u
down from 75u and 0.25 mK/W down from 0.75 mK/W. (See: E.C. Samson,
S.V. Machiroutu, J.-Y. Chang, I. Santos, J. Hermerding, A. Dani,
R. Prasher, and D.W.Song. "Interface Material Selection and a Thermal
Management Technique in Second-Generation Platforms Built on Intel
Centrino Mobile Technology." Intel Technology Journal, 9(1), Feb. 2005.)
c) Others:
1) Complete re-write of the grid model for easy readability and extensibility.
2) Minor bugfixes etc.
Notes on the Modifications:
---------------------------
1) As the WDDD paper above mentions, the block model suffers from spatial
discretization errors when the modeled blocks have very high aspect ratios.
In such cases, the user should either use the grid model or the floorplan
should be modified in such a manner that the blocks are sub-divided into
square-shaped sub-blocks. To aid in this aspect ratio sub-division, this
version provides two wrapper scripts: hsconvert-flp.pl and hsconvert-data.pl.
The former can be used to convert floorplans with high-aspect-ratio blocks
while the latter can be used to migrate power/temperature trace data corresponding
to the old floorplan into the new floorplan. Here is a sample use where ev6.flp.orig
is the old floorplan and the power trace corresponding to it is gcc.ptrace.orig.
The following sequence of commands produce a floorplan file (ev6.flp) with
nearly square-shaped blocks and a compatible power trace file (gcc.ptrace):
hsconvert-flp.pl ev6.flp.orig > ev6.flp
hsconvert-data.pl -o ev6.flp.orig -c ev6.flp -p gcc.ptrace.orig > gcc.ptrace
It is to be noted that being a finite-element solver, HotSpot cannot avoid
discretization errors altogether. However, they can be dealt with effectively
as a speed vs. accuracy trade-off. For instance, in cases where higher accuracy
is desired, the grid model could be used. It is to be noted that even with the
grid model, high aspect ratios can be a problem. A common pitfall is using an
extremely fine mesh in the x-y direction without correspondingly increasing
the resolution in the z direction. For instance, if one must use a 1000 x 1000
grid, then the no. of z-layers should also be increased using the grid layer
file specification so that each volumetric cell is still nearly "cubical" and
not "tall and skinny".
2) The interfaces to HotSpot remain almost identical to previous versions. The
minor differences include:
a) The grid layer file specification has been made optional with the default
being one silicon layer and one TIM layer (similar to the block model). This
change also means that the grid model is now compatible with HotFloorplan.
However, this compatibility is only theoretical because, for practical grid
sizes, the grid model would be too slow to be used with HotFloorplan.
b) Before solving for transient temperature, the grid model maps the functional
block power and temperature numbers onto each grid cell. After the solution is
done, the temperature numbers are mapped back onto each functional block.
This reverse mapping involves averaging. When the transient solver is called
repeatedly (as is usually the case), and if the internal state of the solver
is not maintained across calls, this averaging can result in some loss of
accuracy. To avoid that, this version of HotSpot provides an option to
maintain state across calls to the transient solver of the grid model. When
the solver is called for the first time, the functional block temperature
vector is passed as an argument to compute_temp. During subsequent calls
however, a NULL pointer is passed signalling the solver to maintain its
internal state from the last call and continue passing on its output to the
same temperature vector provided earlier. Here is the relevant code snippet
from hotspot.c that does this:
/* first time */
if (model->type == BLOCK_MODEL || lines == 0)
compute_temp(model, power, temp, model->config->sampling_intvl);
/* subsequent calls - 'temp' still gets updated every time with the
* transient solution
*/
else
compute_temp(model, power, NULL, model->config->sampling_intvl);
HotSpot 3.1 Changes
-------------------
This version of HotSpot incorporates significant performance enhancements
to the block model with the most important of them being a contribution
from Greg Link (http://www.drgreglink.com/), who recently obtained his PhD
from Penn State University, and is now with the York College of Pennyslvania.
This contribution comes from his HotSpot-based thermal modeling tool
HS3d (http://www.cse.psu.edu/~link/hs3d.html). Where available, it replaces
HotSpot's matrix and vector function calls with calls to vendor-provided
fast math libraries conforming to the Basic Linear Algebra Subprograms
(BLAS: http://www.netlib.org/blas/) and Linear Algebra Package (LAPACK:
http://www.netlib.org/lapack/) standards. This provides significant increase
in performance for large floorplans (with say, greater than 100 units) where
the resultant matrices are huge.
Other improvements include an algorithmic speedup of the block model's
steady-state solver and conversion of the transient Runge-Kutta (RK4) solver
from a fixed step-size method to an adaptive one. The adaptive RK4 solver,
which is based upon the discussion in the "Numerical Recipes in C" book,
(http://www.library.cornell.edu/nr/bookcpdf.html) adjusts its step size
to the need of the problem. When the temperature changes rapidly (i.e., the
slope is steep), it uses small steps and when the temperature curve is flat
(the slope is shallow), it rushes through the solution with large steps. In
each step, it ascertains its own accuracy by computing the temperature twice
- once with the desired step size and another time with two half-steps. When
the difference between these two computations is greater than an allowable
limit, the step-size is decreased and vice-versa.
Guidelines for Adaptive RK4
---------------------------
Adaptive RK4 adapts its step size by performing at each step size, almost
twice the computation of non-adaptive RK4. For small sampling intervals, there
is very little opportunity for gains due to adaptivity as there are only a few
steps to take even with a fixed step-size. Hence, adaptive RK4 might be slower
than the non-adaptive counterpart at small sampling intervals. However, at
larger intervals, even gains of multiple orders of magnitude are possible due
to adaptivity. Hence, it is important to choose the correct sampling interval
corresponding to your specific application.
A typical use of HotSpot in a processor simulator involves two runs - once with
default initial temperatures and a second time with initial temperatures set to
the steady-state temperatures computed in the previous run. During the second
run, since the transient temperatures are close to the steady-state, the slopes
are shallow and adaptive RK4 runs faster as it adapts itself into larger
step-sizes. If the average power values are available, the first run can be
entirely avoided as its purpose is only to compute the steady-state
temperatures. To facilitate this in the trace-driven 'hotspot' binary, its
command line options have been modified in this version. The "-o <file>" option
that outputs transient temperatures to the temperature trace file, has been
changed from being mandatory to optional. When the option is not provided,
transient simulation is avoided and only the steady-state temperatures are
computed based upon the average power values computed from the instantaneous
values in the power trace file.
HotSpot-3.0.2 Changes
---------------------
Release 3.0.2 fixes a bug in the grid model of HotSpot 3.0
that lead to erroneous discrepancies between the block
and grid models. The lateral resistances and hence the
temperatures of the block and grid models match more
closely now.
HotSpot-3.0.1 Changes
---------------------
1. Release 3.0.1 fixes a few bugs in release 3.0. The most
important of them being the way the dead space around the
edge of the chip is modeled. In the previous release, the
dead space was modeled as four thin strips around the chip
with aspect ratios that were vastly different from the
other blocks. This resulted in parasitic shorting of the
lateral resistances of the blocks near the corner of the
chip. This has been fixed now by splitting the rim strips
into multiple blocks corresponding to the corner functional
blocks. In cases when the floorplan consists of significantly
different aspect ratios and granularity, the block model
could result in some inaccuracy. An example for such a floorplan
would be a fine-grained variation of the standard floorplan
that comes with HotSpot, where the register file alone is
sub-divided into a large number of (say 128) entries. In order
to avoid such inaccuracies while using such a floorplan, use
the 'flp_create_grid' function provided in 'flp.c' to create
an equivalent floorplan that can be modeled accurately in
HotSpot. The 'flp_create_grid' function creates a non-uniform,
grid-like floorplan equivalent to the given floorplan, where
there is no partial sharing of edges between blocks. This
eliminates the inaccuracy that can arise due to the block
model's way of computing the lateral resistances.
2. This release provides a choice to the user for the
mapping between the grid and block temperatures of the
grid model. Previously, the temperature of a block reported
by the grid model was only the average of all the grid
cells in it. Now, there are four options available. The
'min', 'max' and 'avg' options mean that the block's
temperature is computed as the minimum, maximum, or average
temperature of the grid cells in it. The 'center' option
means that the block's temperature is given by the
temperature of the grid cell at its center.
3. It is to be noted that for the same power density,
the temperatures reported by the block and grid models
could differ from each other. This is because both these
models are fundamentally different in their organization.
Closer match can be observed when the grid model's mapping
mode is set to 'max' - i.e., the single temperature reported
by the block model is closer to the maximum temperature
within a block as computed by the grid model. We are
currently working on making the two models more accurately
consistent. Please look for updates soon at the HotSpot
web page.
HotSpot 3.0 Documentation
-------------------------
CONTACT:
----------------------------------------------------------------------------
Main: http://lava.cs.virginia.edu/HotSpot
E-mail list subscription: http://www.cs.virginia.edu/mailman/listinfo/hotspot
Send e-mail: hotspot at cs dot virginia dot edu
-----------------------------------------------------------------------------
This document assumes to a small extent that the reader is familiar
with the previous versions of HotSpot. If anything is unclear,
please read the old-HOWTO file for clarification.
CONTENTS
--------
A) Introduction
B) What's new since version 2.0?
C) Quick usage guide for the tools
1) Base case - the block level thermal model
2) The grid model
3) The HotFloorplan floorplanner
D) More detailed guidelines
1) The block model
2) The grid model
3) HotFloorplan
INTRODUCTION
------------
HotSpot is a computationally efficient, architecture level thermal modeling
infrastructure developed at the University of Virginia. It makes use of the
duality that exists between the electrical and thermal properties of materials
to model processor temperature. It is written in 'C/C++' and can be easily
interfaced with typical power/performance simulators available in the
community. It can be downloaded from http://lava.cs.virginia.edu/HotSpot
WHAT'S NEW SINCE VERSION 2.0?
-----------------------------
1. A new grid-based thermal model that is better suited for transient
thermal simulation of a large numbers of blocks, blocks of radically
different sizes, and study of temperature gradients within blocks.
2. 3-D modeling. The grid model allows modeling for individual layers
within a die (device, metal, etc.) or stacked 3-D chips.
3. HotFloorplan, an architecture-level floorplanning tool for pre-RTL
design studies. It uses the classic simulated annealing algorithm and
a thermal-aware objective function.
4. Floorplan and thermal modeling of the dead space around the edge
of the die due to scribe lines.
5. Implementation of previously proposed, first-order wire-delay
model for interconnects in the global and intermediate metal layers.
6. A thermal visualization tool for the grid model that outputs the
processor's thermal map as a color image in the SVG format.
7. Improved and hence significantly different interfaces including:
a) Better command line support
b) Better specification of parameters through a configuration file
c) More modular code organization
d) Switch to C++ compiler as parts of the grid model are in C++
e) Improved documentation
QUICK USAGE GUIDE FOR THE TOOLS
-------------------------------
1. Base case - the block level thermal model:
Similar to version 2.0, the thermal model is bundled as a trace-level
simulator that takes a power trace file and a floorplan file as inputs
and outputs the corresponding transient temperatures onto a
temperature trace file. There is also an option to output the final
steady state temperatures onto a file. With 'ev6.flp' as the given
floorplan, 'gcc.ptrace' as the given power trace file (whose formats
are same as version 2.0), the set of commands to generate the
temperature trace file 'gcc.ttrace' are given below. First let us
run the simulations with a set of default model parameters listed
in the file 'hotspot.config' and gather the steady state
temperatures onto a file. This is done by:
a) hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace \
-o gcc.ttrace -steady_file gcc.steady
Now, 'gcc.ttrace' does contain a thermal trace but the initial
temperatures that it used to generate it were default constant
values, which might not be representative if the simulation is not
long enough to warm up the chip and package. However, the steady
state temperatures are a good estimate of what the correct set of
initial temperatures are. So, we now use the steady state
temperatures produced as the set of initial temperatures for the
next 'true' run:
b) cp gcc.steady gcc.init
hotspot -c hotspot.config -init_file gcc.init -f ev6.flp \
-p gcc.ptrace -o gcc.ttrace
2. The grid model:
The above runs were just the basic functionality provided since
version 2.0. We will now try the added features of this release. The
thermal simulation above can be run using the grid model instead
of the block-level model. There are only two differences: 1) The
grid model can model 3-D chips and because of this capability,
it uses an additional input file 'layer.lcf'. This is the layer
configuration file that describes each layer of the stacked 3-D
chip and 2) The block model is the default setting for HotSpot
and hence we did not have to set any switch to choose it. For
the grid model, a model selection switch "-model_type grid" has
to be used for selection. Hence, the set of commands to redo
the 2-pass thermal simulations above using the grid model is:
a) hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace \
-o gcc.ttrace -steady_file gcc.steady \
-model_type grid -grid_layer_file layer.lcf
b) cp gcc.steady gcc.init
hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace \
-o gcc.ttrace -init_file gcc.init \
-model_type grid -grid_layer_file layer.lcf
Having mentioned the grid model's 3-D capability, we will
now show an example of its use. Let us use a simple, 3-block
floorplan file 'example.flp' in addition to 'ev6.flp'. In
the chip we will model, layer 0 is silicon with a floorplan
of 'example.flp', followed by a layer of thermal interface
material. This is then followed by another layer of silicon
with a floorplan of 'ev6.flp' and another layer of thermal
interface material. Such a layer configuration is described
in 'example.lcf'. Also, we will just do a single-pass
simulation with the default constant initial temperature
values. So, we will ignore the '-steady_file' option. The
command to do this is:
a) hotspot -c hotspot.config -f example.flp -p example.ptrace \
-o example.ttrace -model_type grid \
-grid_layer_file example.lcf
In addition to the '-steady_file' option that can be used with
the both the block and grid models, the grid model provides an
additional way to output the steady state temperatures. With
the '-steady_file' option, it outputs the temperatures in a
format similar to the block model (i.e., single temperature
corresponding to a single floorplan block). In this alternate
method, chosen by the command line switch '-grid_steady_file',
the internal grid temperatures are output directly (without
converting them into block temperatures). This can help in
learning how temperatures vary 'within' a block. Also, a
perl script 'grid_thermal_map.pl' can produce an SVG format
color image of these temperatures with a superposed drawing
of the floorplan 'example.flp' for viewing. If native viewer
programs (e.g.: Adobe SVG viewer) are not available for viewing
an SVG file, conversion tools like 'ImageMagick convert' can be
used to generate alternate formats. Below is the set of commands
to output grid temperatures onto a file called 'example.t' and
to output the thermal map as a PDF image:
b) hotspot -c hotspot.config -f example.flp -p example.ptrace \
-o example.ttrace -model_type grid \
-grid_layer_file example.lcf \
-grid_steady_file example.t
grid_thermal_map.pl example.flp example.t > example.svg
convert -font Helvetica svg:example.svg example.pdf
3. The HotFloorplan Floorplanner:
HotSpot comes with a thermal-aware floorplanning tool that
can be easily configured to optimize for an arbitrary objective
function. It takes a listing of the functional block names,
areas, allowable aspect ratios and the connectivity between
the blocks as its input from a file. 'ev6.desc' is such a
'floorplan description' file (as opposed to the 'floorplan
file' ev6.flp). In order to evaluate the floorplans it
generates for thermal merit, HotFloorplan also needs a set
of average power values for each of the functional blocks.
This is also specified in a file (e.g.: 'avg.p'). With these
files as inputs, the command to run HotFloorplan to produce
an output file 'output.flp' containing the floorplan
generated is given by:
a) hotfloorplan -c hotspot.config -f ev6.desc -p avg.p \
-o output.flp
If you run this command, please note that this typically
takes about 45 minutes to complete on a 2 GHz Athlon. It is
also to be noted that HotFloorplan uses only the block model
and not the grid model (the reasons are described below). The
floorplan generated can be viewed (as in previous versions
of HotSpot) using a FIG file viewer like 'XFig' and the perl
script 'tofig.pl' which converts it into a FIG format.
Alternatively, the command to convert this 'output.flp' into
PDF using fig2dev and ps2pdf is:
b) tofig.pl output.flp | fig2dev -L ps | ps2pdf - output.pdf
MORE DETAILED GUIDELINES
------------------------
While this section will try to provide more detailed explanation
about the toolset's capabilities and guidelines for its use,
the maximum amount of information can be obtained only from the
source code itself. Looking at the 'Makefile' for this release,
one can see whether a source file corresponds to the block model,
the grid model, the floorplanner or the miscellaneous category.
Also, the input files that come with this release are well commented
too. The formats of the floorplan, power trace, initial temperatures
etc. remain the same as the previous versions of HotSpot. For the
new files (e.g.: ev6.desc), the file format is explained in the
comments found in them. Moreover, just running the tools without any
command line options gives a detailed listing of the available
options. Hence, we encourage the reader to try running the tools
and also to take a look at the respective source files, Makefile
or the input files for more information about the tool that is not
covered here.
1. The block model:
a) The interfaces of hotspot have significantly changed. While this
means that code that is already using previous versions of HotSpot
has to be rewritten, we hope it would not be too difficult. The
model is now more encapsulated and easier to integrate with an
existing tool. The two main interface functions 'compute_temp'
and 'steady_state_temp' retain their names from the previous
releases of HotSpot but their parameters have changed slightly
according to the encapsulation of the thermal model. The function
'create_RC_matrices' has been split up into two functions -
'populate_R_model' and 'populate_C_model'. This is done since
'steady_state_temp' requires only the network of thermal
resistances for its computation. In applications where
'steady_state_temp' is called millions of times (e.g.: the
floorplanner), this reduction in computation of the thermal
capacitances results in a huge performance improvement. The
'sim-template_block.c' file provides a sample simulator use
of the block model (just like 'sim-template.c' of the older
HotSpot versions). A shorter code snippet that demonstrates the
use of HotSpot in the user's code is shown below:
#include "flp.h"
#include "temperature.h"
int main()
{
char *flp_file, *power_file;
char *init_temp_file, *steady_temp_file;
flp_t *flp;
RC_model_t *model;
thermal_config_t config;
double *power, *temp;
double delta_t;
flp = read_flp(flp_file, FALSE);
config = default_thermal_config();
model = alloc_RC_model(&config, flp);
temp = hotspot_vector(model);
power = hotspot_vector(model);
read_power(model, power, power_file);
read_temp(model, temp, init_temp_file, FALSE);
populate_R_model(model, flp);
populate_C_model(model, flp);
compute_temp(model, power, temp, delta_t);
steady_state_temp(model, power, temp);
dump_temp(model, temp, steady_temp_file);
delete_RC_model(model);
free_flp(flp, FALSE);
free_dvector(temp);
free_dvector(power);
return 0;
}
b) Another difference in the basic HotSpot model between the current
version and previous versions is the modeling of the dead space
around the edge of the die due to scribe lines. In the 'ev6.flp'
floorplan, four blocks named 'RIM_*' have been added that surround
the die. These dissipate zero power and are true dead spaces.
2. The grid model:
a) The grid model is faster than the block model for computing
the transient temperatures when there are a large number of
functional blocks in a floorplan. It is to be noted however that
it is much slower than the block model for computing the steady
state temperatures. Hence, the grid model should be used only
when there is a need for more accuracy (e.g.: when temperatures
within a block are desired or when there is a large number of
tiny blocks in the floorplan). More guidelines about the use
of grid vs. block models can be found in the 'hotspot.c' file.
b) Of the inputs to the grid model, the floorplan file and the
layer configuration file have to be consistent with each other.
The floorplan file should be the same as the floorplan specified
in layer 0 of the '.lcf' file. Also, it is to be noted that all
layers in the '.lcf' file must have the same width and height.
Further, the settings in the '.lcf' file (material properties,
thickness etc.) override the other global settings. Hence, care
should be taken in ensuring that these settings are consistent
with the values desired by the user. It is also to be noted
that the non-power-dissipating layers of the '.lcf' file
(like the interface material layer) should have the same
floorplan as the power-dissipating silicon layer above it.
The 'layer.lcf' and 'example.lcf' files provided are a good
example for the correct settings.
c) The modeling of a 3-D chip's thermal vias is not explicitly
supported in this release. But the users can get around it by
manually changing the thermal conductivity for the grid cells
at which the thermal vias are supposed to be located to the
desired values.
3. HotFloorplan:
a) As mentioned above, one of the inputs to HotFloorplan is a
floorplan description file that has information about the
blocks to be floorplanned. In the file provided with this
release ('ev6.desc'), the functional unit areas are same
as 'ev6.flp'. The maximum aspect ratio constraint is set
to 1:3 except when a block has a bigger aspect ratio in the
base floorplan 'ev6.flp'. In that case, the block's aspect
ratio from 'ev6.flp' itself forms the upper limit. Also,
the connectivity section of 'ev6.desc' currently lists 13
major interconnects that we thought were important at the
architecture level. They are assumed to be of equal wire
density. Also, the wire_density field of the floorplan
description can be used to assign weights for the different
wires according to their contribution to performance. In
'ev6.desc', the assignment of these weights is uniform
across all wires.
b) HotFloorplan includes a first-order wire-delay model for
wires in the global and intermediate metal layers. It is
a simple stand-alone model that converts wire length to
wire delay and can be used in any tool, whether the thermal
model, floorplan model, or any other simulator. It is
adapted from Otten and Brayton, DAC'98, and related work.
The interfaces for the model are provided 'wire.[ch]'. An
appropriate process technology node can be chosen by using
the TECHNODE #define in 'wire.h'. After that, the model is
a simple call to the function 'wirelength2delay'.
c) HotFloorplan can be configured through many command line options.
The 'hotspot.config' file clearly lists them and what they do.
Among the options, following merit further discussion:
i) Annealing parameters:
The meaning of each these can be easily obtained from any
standard text on VLSI CAD that deals with simulated
annealing (e.g.: Sarrafzadeh and Wong, "An Introduction to
VLSI Physical Design", McGraw-Hill 1996). The original
DAC '86 paper by Wong and Liu on floorplanning is a very good
starting point.
ii) Compaction ratio:
During floorplanning, empty spaces can arise in a floorplan.
Sometimes, these spaces are just an artifact of the discrete
nature of the aspect ratio function of the individual
blocks. Typically, about 50% of the maximum possible number
of dead spaces is due to this artifact. Such dead spaces
are very tiny and hence can be safely ignored without any
impact on the thermal model. In fact, ignoring such blocks
reduces the size of the problem input to the thermal solver.
Since the thermal model's solver algorithm is a higher order
polynomial function in the number of functional blocks,
ignoring the tiny blocks improves the performance of the
floorplanner significantly. The 'compact_ratio' option
sets a threshold on the area of such tiny blocks. The
default is 0.5% of the area of the encompassing 'parent
rectangle'. So, dead spaces that are smaller than 0.5% of
the parent rectangle are ignored during floorplanning. This
results in a maximum error in core area of about 0.46% for
our experiments. This setting, combined with the 'n_orients'
setting that determines the magnitude of discreteness of
the blocks' aspect ratio function, can be tuned to manage
the trade-off between the speed and accuracy of the
floorplanner. It is to be noted that in HotFloorplan, the
empty spaces that are not compacted are named in the form
_0, _1 and so on. It can be seen that the 'output.flp'
generated from the steps discussed above has blocks named
in that form.
iii) Weights for the metric (objective function):
HotFloorplan uses an objective function that is of the form
lambdaA * A + lambdaT * T + lambdaW * W where A, T and W are
the area, temperature and wire length respectively. The
weights lambdaA lambdaT and lambdaW can be set through
configuration parameters. Please note that for HotFloorplan,
A is in the order or hundreds of mm, T is in the order of
hundreds of Kelvin and W is in the order of tens of mm. In
combining them to a single metric, the weights have to be
assigned in a manner that not only takes into account the
desired importance of the variables A, T and W but also
compensates for the mismatch in their units of measurement.
The default weights in HotFloorplan are chosen based on this
principle. If one is interested in objective functions that
are not in the above-mentioned form, it is quite easy to
make the change in HotFloorplan. The design of the simulated
annealing algorithm is such that any arbitrary metric (objective
function) can be incorporated. In HotFloorplan, this is done just
by changing the return statement of the 'flp_evaluate_metric'
function at the beginning of 'flp.c' into an appropriate objective
function of A, T and W.
d) For further information about HotFloorplan and the impact of floorplanning
on temperature, please see the following paper:
K. Sankaranarayanan, S. Velusamy, K. Skadron and M. R. Stan, "A Case
for Thermal-Aware Floorplanning at the Microarchitectural Level." To
appear in the Journal of Instruction-Level Parallelism, June 2005.
Last updated: 11 Apr. 2008