[ Home | Documentation | Version History | FAQ | How-To | License | People | Download | Links]

    A) Installation
    B) Quick usage guide for the tools
        1) Base case - the block level thermal model
        2) The grid model
        3) The MS Excel interface
        4) The HotFloorplan floorplanner
    C) More detailed guidelines
        1) The block model - aspect ratio
        2) The grid model - 3-D stacking capability
        3) Source-level integration with a power/performance simulator
        4) Tips for modeling your own chip
        5) HotFloorplan
    D) Conclusion    

1. Download the HotSpot tar ball (HotSpot-5.01.tar.gz) following the
instructions here

2. Unzip and untar the file using the following commands
    a) gunzip HotSpot-5.01.tar.gz
    b) tar -xvf HotSpot-5.01.tar

3. Go to the HotSpot installation directory
    a) cd HotSpot-5.01/
4. For Linux/UNIX systems with BLAS/LAPACK libraries installed, 
uncomment the lines corresponding to your installation of the
BLAS/LAPACK vendor libraries (see 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, might also be
useful as it provides useful description of the C interface to BLAS.

5. Build HotSpot
	a) Under Linux/UNIX systems with GNU Make and GCC, type the 
	following for compilation:
		1) make
	b) Under Windows system with VC++ compiler, do the following:
		1) Set up the VC++ paths. Under the command prompt, run 
		the "vcvars32.bat" file under the VC++ bin folder (e.g., 
		"C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat")
		2) Type "nmake /F Makefile.VC" to compile HotSpot
	c) Another way to build HotSpot under Windows, if b) has
	compatibility issues, is to use MinGW:
		1)	Download MinGW, which is a collection of freely available and
		freely distributable Windows specific header files and import
		libraries combined with GNU toolsets. To download, go to http:// and click the download link to install
		"Automated MinGW Installer", remember to check the box for
		"MinGW Make" during installation.
		2)	Start Visual C++ (I am using VC++ 9.0 Express Edition).
			a.	Create a new VC++ Makefile Project: File > new project >
			General > Makefile project > choose path and enter project name
			(mine is "hotspot") > "next".
			b.	Configure makefile command lines: enter "mingw32-make" in
			"Build command line"; "mingw32-make clean" in "Clean commands";
			"mingw32-make all" in "Rebuild command line"; "hotspot.exe" in
			"output". > "next" > "next" > "finish".
			c.	Set up default executable search path in VC++: Tools > Options
			> Projects and Soultions > VC++ directories. In the "Show
			directories for:" pull-down menu, choose "Executable files" and
			add the following path (assuming you installed MinGW in the root
			directory) "C:\WinGW\bin" > "OK".
			d.	Copy all files in the hotspot package to the VC++ Makefile
			project folder you created in Step 4(a-b), in my case, it is
			e.	Add files to the HotSpot VC++ project: In the Solution window,
			expand the "hotspot" project, right click "Header Files" and add
			all HotSpot header files, and right click "Source Files" and add
			all HotSpot c source files.
			f.	Remove all pre-compiled object files: Build > Clean solution.
			(When you compile it for the first time, there are no object files,
			so ignore the error message in that case.)
			g.	Create executable: Build > Build Solution (Ignore the error
			message about cannot find libhotspot.a, it is not related to this
			Windows compilation.)

6. To remove all the outputs of compilation, type 'make clean' or 
'nmake /F Makefile.VC clean' depending on whether it is a GCC/GNU Make 
system or a VC++/NMake system. Similarly, to remove the object files 
alone, type 'make cleano' or 'nmake /F Makefile.VC cleano'. To view 
the list of files HotSpot needs for proper working, type 
'make filelist' or 'nmake /F Makefile.VC filelist'. To compile for 
debugging, use 'make DEBUG=1' or 'nmake /F Makefile.VC DEBUG=1'. 
Under a Linux/UNIX system, to compile for using with a profiler 
(e.g. gprof), use 'make DEBUG=2'.

7. 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
    Installing patch 117560 from Sun's patch finder
    solves the problem.

1. Base case - the block level thermal model:

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. The formats of the input files can be gleaned from the
sample files included with this distribution. For instance, with
'ev6.flp' as the given floorplan, which represents a single core Alpha
21264 processor, 'gcc.ptrace' as the given power trace file, which
captures ev6's power consumption when running gcc, 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 were used to generate it were default constant
values. These 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

Note that the '-o <file>' command line flag is optional. Omitting it
makes HotSpot compute the steady state temperatures directly without
going through the transient simulation, thereby making the run faster.
So, in the above command a), since we are interested only in the
steady state temperatures, we could have actually omitted the '-o
gcc.ttrace' part. Also, in the command b) above, note that we have
omitted the '-steady_file <file>' option. This means that the steady
state temperatures are only output to the screen and not to a file.

2. The grid model:

The above runs used the default, fast but less accurate 'block'
thermal model. HotSpot offers the choice of another more accurate but
relatively slower model called the 'grid' model. The '-model_type
grid' command line option switches HotSpot to the grid mode. Hence,
the set of commands to  redo the two-pass thermal simulations above
using the grid model would be:
a) hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace \
           -steady_file gcc.steady -model_type grid 
b) cp gcc.steady gcc.init
   hotspot -c hotspot.config -init_file gcc.init -f ev6.flp \
           -p gcc.ptrace -o gcc.ttrace -model_type grid 

The trade-off between speed and accuracy of the grid model can be
controlled by specifying the grid model's resolution through the
command line options '-grid_rows <num>' and '-grid_cols <num>'. The
default grid size is 64x64 (as can be seen from the 'hotspot.config'
file). Grid dimensions are restricted to powers of two for algorithmic

In addition to the '-steady_file <file>' option that provides
temperatures at a per-block granularity, the grid model provides an
additional means to access the finer grid of steady state
temperatures. The command line option '-grid_steady_file <file>'
outputs the internal grid temperatures directly (without 
aggregating them into per-block temperatures). This can help in 
learning how temperatures vary 'within' a block. Also, the perl script
'' can produce an SVG format color image of these
temperatures with a superposed drawing of the floorplan for easy
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
'gcc.grid.steady' and then to output the thermal map as a PDF image
using 'convert':
c) hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace \
           -steady_file gcc.steady -model_type grid \
           -grid_steady_file gcc.grid.steady ev6.flp gcc.grid.steady > gcc.svg
   convert -font Helvetica svg:gcc.svg gcc.pdf

Since the grid model aggregates the finer grid temperatures into
per-block temperatures, HotSpot provides a choice to the user in the
mode of aggregation. The user can select the mapping between the grid
and block temperatures of the grid model through the command line
option '-grid_map_mode <mode>'. The four mapping modes supported are:
'min', 'max', 'avg' and 'center'. The first three options respectively
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. The MS Excel interface:

HotSpot provides an MS Excel 2003 interface to the block and grid 
thermal models through the "hotspotUI.xls" file. Its detailed usage 
instructions can be found in the "Usage" sheet of the Excel file.
The prerequisite to use the Excel file is to compile HotSpot under
the Windows/VC++ environment as mentioned above in the Installation
section. Once the floorplan information, input power trace numbers
and configuration parameters are provided in the Excel file through 
the "FLOORPLAN", "PTRACE" and "CONFIG" sheets respectively, the user
can use the buttons on the "FLOORPLAN" sheet to run HotSpot. The 
"FLOORPLAN" sheet also contains buttons for drawing the floorplan 
and plotting the block-level thermal map (a single temperature per 
block - as computed by the grid model or the block model). The 
Excel file would then prompt for the number of iterations to run.
A single iteration means that the transient temperatures are computed
using default constant initial temperature values. Two iterations 
mean that the steady-state temperatures are computed during the first
run and are used as the initial temperatures for the second iteration,
as mentioned in the previous section. Hence, the default number of 
iterations is two. A higher number of iterations does not currently 
have any impact and could in the future be used to model the 
leakage-thermal feedback loop.

4. 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 generated
floorplans 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

Please note that with default configuration, this typically takes
about 45 minutes to complete on a 2 GHz Athlon. The thermal model
defaults for HotFloorplan are the same as HotSpot. Also note that all
the thermal model command line options can be specified here too. Note
that if the grid model is chosen using the '-model_type grid' option,
it might be too slow for any useful progress. The floorplan generated
(or any other .flp file for that matter) can be viewed using a FIG
file viewer like 'XFig' and the perl script '' which converts
it into the FIG format. Alternatively, the command to convert this
'output.flp' into PDF using fig2dev and ps2pdf is:
b) output.flp  | fig2dev -L ps | ps2pdf - output.pdf

5. The package model:

HotSpot integrates a simple model for heatsink, air flow and fan. This
can assist cooling package design and exploration of the impact of cooling 
configurations on silicon temperatures. The package model also
supports natural convection (which results in a much higher thermal
resistance, and can cause thermal runaway for high-power chips). By 
default, HotSpot uses a single lumped thermal convection resistance 
(r_convec) at the air-sink interface. This should be adequate in most 
cases, unless factors such as the heatsink shape, air flow speed, fan 
diameter etc are the design variables. Detailed package configuration 
is provided in a file (e.g. 'package.config'). An example of using the 
package model is given by:
a) hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace \
		-package_model_used 1
6. The secondary heat transfer path:

HotSpot also models the secondary heat transfer path from the silicon 
to on-chip interconnect layers, C4 pads, packaging substrate, solder 
balls and printed-circuit board. In most cases when there is a heatsink 
with forced air-convection, the effect of secondary heat transfer path 
can be neglected. For special cases such as exposing silicon die to an 
oil flow for infrared thermal measurements, secondary heat transferpath
should not be omitted (see 'oil_bare_silicon.config'). This feature is 
only available with the grid model. Here is an example of how to enable
the secondary path:
a) hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace \
			-model_secondary 1 -model_type grid					 

7. The leakage mode:

HotSpot also provides a simple interface for leakage model. Modeling 
leakage is sometimes critical since it is exponentially dependent on 
temperature. The leakage model in implemented in 'calc_leakage()' in 
'temperature.c'. Users can replace it with their own model, as long as
the calling interface remains the same. This is only supported for 
steady-state simulations. Transient thermal-leakage loop is NOT 
supported, because the time scales of transient leakage power evolvement
are not clear, and it is potentially wrong to assume instantaneous 
leakage update with increased temperature in each transient step 
('sampling interval') in HotSpot. To enable the leakage calculations:
a) hotspot -c hotspot.config -f ev6.flp -p gcc.ptrace -leakage_used 1 

1. The block model - aspect ratio:

Since the block model approximates the temperature of an entire
functional block with a single node, it could potentially suffer 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, HotSpot provides two wrapper scripts:
'' and ''.  The former can be  used
to convert floorplans with high-aspect-ratio blocks while the latter
can be used to migrate the corresponding power/temperature trace data
from the old floorplan to 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 produces a floorplan file ('ev6.flp') with nearly
square-shaped blocks and a compatible power trace file ('gcc.ptrace'):
a) ev6.flp.orig > ev6.flp -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 1024 x 1024 grid,
then the no. of z-layers should also be increased using the layer
configuration file specification (described below in the next section
on 3-D stacking) so that each volumetric cell is still nearly
'cubical' and not 'tall and skinny'. 

2. The grid model - 3-D stacking capability:

HotSpot's grid model is capable of modeling stacked 3-D chips. To be
able to do that, one has to specify what is called the 'Layer
Configuration File' (LCF). An LCF specifies the set of vertical layers
to be modeled including its physical properties (thickness,
conductivity etc.) and the floorplan of the die in that layer. For
instance, the sample file 'layer.lcf' shows an LCF corresponding
to the default HotSpot configuration with two layers: one layer of
silicon and one layer of Thermal Interface Material (TIM). An LCF is
input using the command line option "-grid_layer_file <file>".

Let us now look at an example of how to model stacked 3-D chips. Let
us use a simple, 3-block floorplan file 'example.flp' in addition to
the original 'ev6.flp.orig'. In the chip we will model, layer 0 is
power dissipating silicon with a floorplan of 'example.flp', followed
by a layer of non-dissipating (passive) TIM. This is then followed by
another layer of active silicon with a floorplan of 'ev6.flp.orig' and
another layer of passive TIM. Such a layer configuration is described
in 'example.lcf'. Also, we will just do a single-pass simulation
staring with the default constant initial temperature values. So, we
will ignore the '-steady_file <file>' option. The command to do this
a) hotspot -c hotspot.config -f <some_random_file> -p example.ptrace \
           -o example.ttrace -model_type grid \
           -grid_layer_file example.lcf

Note that the floorplan files of the layers are all specified only
through the LCF. The file specified through '-f <flp_file>' command
line option is overridden by the LCF, as indicated by the warning
message printed while running HotSpot. It is now worth taking a moment
to look at the power trace file 'example.ptrace' and comparing it with

The modeling of a 3-D chip's thermal vias is not explicitly supported
in HotSpot. But the users can get around it by manually changing (in
the source code) the thermal conductivity of the grid cells at which
the thermal vias are located to the desired values.

3. Source-level integration with a power/performance simulator:
To assist in the easier integration of HotSpot into the user's
existing codebase, HotSpot bundles its functions into a library -
'libhotspot.a'. A minimal 'no-frills' version of the most important
datatypes and function prototypes are separately declared in
'hotspot-iface.h'. A user should be able to integrate HotSpot very
quickly by just including this header file and linking the existing
codebase with 'libhotspot.a'. However, for a more complete utilization
of HotSpot's capabilities, one might want to integrate its source
files more tightly. In order to illustrate such an integration of
HotSpot with a power/performance simulator like Simplescalar/Wattch,
the HotSpot distribution comes with a simulator template file
'sim-template.c'. The file contains detailed description and comments
about the HotSpot datatypes and function calls. It contains three
functions: 'sim_init', 'sim_main' and 'sim_exit' that clearly
illustrate the initialization, usage and clean-up of state
respectively when using HotSpot with another simulator. A shorter code
snippet that demonstrates the high-level 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;
    /* transient simulation for 1 ms    */
    double delta_t = 0.001;

    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);

    /* transient solver    */
    compute_temp(model, power, temp, delta_t);
    /* steady state solver    */
    steady_state_temp(model, power, temp);

    dump_temp(model, temp, steady_temp_file);

    free_flp(flp, FALSE);

    return 0;

A note about the transient temperature calls to the grid model: 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, 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
    compute_temp(model, power, NULL, model->config->sampling_intvl);

4) Tips for modeling your own chip

To model your own chip, you need to develop a floorplan for each silicon 
layer (see ev6.flp for an example) and then provide a power trace for
each block at each timestep (see gcc.ptrace for an example). The power
is usually obtained with a power model such as Wattch or McPAT, but could 
be obtained in CAD simulations, via infrared analysis, direct measurement, etc.
You can use default cooling solution or specify your own cooling solution
by changing parameters in hotspot.config. Be sure that no power value is
provided to internal nodes.

5. 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
   distribution ('ev6.desc'), the functional unit areas are same
   as 'ev6.flp.orig'. 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.orig'. In that case, the block's aspect
   ratio from 'ev6.flp.orig' 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) Simulated Annealing (SA) is a randomized algorithm that searches
   the solution space for candidates that lower a specific cost function.
   In HotFloorplan, the cost function is a weighted sum of peak temperature,
   area and wire length. The search process involves evaluating candidate
   floorplans and "moving" from one floorplan to another, while keeping
   track of the best floorplan so far.  Early on during the search, SA
   accepts almost all moves, even if they don't lower the cost function.
   Towards the end of the search, it is the opposite: only moves that lower
   the cost function are accepted. The columns output by HotFloorplan
   indicate the progress of the SA search process with information such as:
   the index of the current step, number of total attempted moves, number
   of accepted/rejected moves among them, average cost function of the
   attempted moves and the cost of the best floorplan so far.
d) 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 of 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.

While this document has attempted to provide a detailed overview of
HotSpot's capabilities and guidelines for its use, the maximum amount
of information can be obtained only from the source code itself. The
source is well-commented with sufficient pointers to documentation.
Particularly, the 'Makefile/Makefile.VC', sample input data files 
(eg: 'ev6.flp', 'gcc.ptrace' etc.) and the template simulator 
'sim-template.c' are all quick sources of information. Moreover, just 
running the binaries/scripts without any command line switches gives a 
detailed listing of the available options. In case of further questions, 
please send e-mail to the HotSpot user group at the address "hotspot AT". To subscribe to the list, please visit
this link.

This material is based upon work supported by the National Science Foundation under grant nos. CCR-0133634, CCR-0105626, EIA-0224434, CCF-0429765, CNS-0509245, and CNS-0551630, the Army Research Office under grant no. W911NF-04-1-0288, and grants from IBM, Intel, and the Univ. of Virginia Fund for Excellence in Science and Engineering. Any opinions, findings, conclusions, or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the sponsoring agencies.

Last updated: June 11, 2014

[ CS @ UVa | LAVA | HPLP ]