No! We have tried to make it a separate library. Using it with any particular power-performance simulator simply requires some simple "glue" functions to extract average power for the same units in your floorplan.
HotSpot should be extremely portable. It is written in C, and we are not aware of any specific operating system dependencies. Our testing has only been on SunOS, x86 RedHat and Fedora Linux systems, but we also know of users who have had no problems compiling it for Cygwin under Windows. For Mac OS, users had successful experience with both Snow Leopard and Lion without any extra adjustments. We certainly welcome reports of successful builds for other architectures and operating systems, and any patches that may be needed.
Yes. Simply specify your own floorplan file with any floorplan and granularity you want. A sample floorplan is provided that is loosely modeled after a 0.13 micron Alpha 21364. The format of the floorplan file simply requires, for each block in the floorplan, the width, height, and (x,y) coordinates of the lower-left corner. Alternatively, you could just specify the block areas, aspect ratios and connectivity in a file and use the HotFloorplan or ArchFP tool to generate a floorplan optimized for an objective function of your choice.
The block model in HotSpot models temperature at the functional block granularity. If you would like to use the block model, then the way to do this would be to specify a floorplan with a separate block for each sub-component. Note that the power simulator should then provide power numbers for these individual sub-blocks. However, if the sub-components are very small, the grid model might be a better solution in terms of accuracy. In that case, you can inspect the grid temperatures by using the '-grid_steady_file' option of the grid model.
When using the block model for such a purpose, it is to be noted that some inaccuracy could occur due to spatial discretization if the modeled floorplan has blocks with high aspect ratios. Hence, versions 4.x provide scripts to convert such floorplans into ones with nearly square-shaped blocks. 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 should be mentioned 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 grid layer file specification so that each volumetric cell is still nearly "cubical" and not "tall and skinny". See the aspect ratio subsection under the "More detailed guidelines" section of the HOTSPOT-HOWTO for more information.
Given identical grid structures (eg: a 3x5 grid shaped floorplan solved with a grid resolution of 3x5), both the block and grid models will give identical results. This is because they are solving the same set of equations through two different methods (matrix and iterative). However, for more general floorplans, the block and grid models are fundamentally different in their organization. The block model has a single temperature for the entire block while the grid model has one each per grid cell within a block. Differences are bound to arise when we try to substitute the multitude of temperatures with a single value. Depending on the application where HotSpot is used, this single value could be a simple average, weighted average, maximum, minimum or any other function of interest. In order to give flexibility to the user, HotSpot incorporates four choices - minimum, simple average, maximum and center. The 'center' function means that the temperature of a block reported by the grid model is that of the grid cell at its center. In the way the models are derived, this 'center' function should give the closest match between them and hence, it is also the default mapping mode for the grid model.
It represents average power dissipated in each block over each time step. If the average power dissipation of a particular event in a particular block is known (eg, power to read a value from the register file, power to add two ints in the IntALU, etc.), then average power is simply (#events*Eevent)/timestep. The power for each event type 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. Event counts are typically obtained using a simulator such as SimpleScalar, M5, etc., but could be obtained using a processor's event counters.
In most cases, HotSpot outputs temperature values in Kelvin. One exception is the .ttrace files produced during transient simulations. Those files use Celsius.
Here are the defaults used in the distribution, which are reasonable for a typical, high-performance microprocessor. They are defined in the 'hotspot.config' file. The bulk material properaties are defined in 'temperature.h'. The current values are:
Yes, you can use debug_print_* functions to output R and C matrices. These functions are:
We have found that a sampling rate of 100-300 KHz (i.e., a period of 3.3 - 10 microsec.) gives excellent precision with negligible slowdown.
We have done some preliminary simulations by adding metal layers on top of silicon bulk. Due to the tiny cross-sectional area of the metal layer, and therefore the large lateral thermal resistance, we found that metal interconnects play a negligible role in laterally spreading heat within silicon. However, this is only our preliminary results, and we haven't considered factors such as metal self- heating, busses, clock tree, etc. We are open to exchanging of ideas on this research problem, and would be glad to hear different voices.
Not at this time. The current version of HotSpot only supports power-of-two grid size (e.g. 32*32, 128*64). This simplifies the implementation of the multigrid algorithm we used for grid-mode computation. If you would like to see a non power-of-two grid size please let us know and we may consider including that in a future release.
We do not explicitly support dumping transient grid temperature results into a file (that usually ends up with huge files). If you prefer to do so, you can use existing dump data functions(can be found in temperature.c) as templates to create a separate dump transient grid data function.
Yes, you can do that by modifying the source code. dump_top_layer_temp_grid writes out the layer0 temperatures. (as shown in its code below:)
for(i=0; i < model->rows; i++)
for(j=0; j < model->cols; j++)
fprintf(fp, "%d\t%.2f\n", i*model->cols+j, temp->cuboid[0][i][j]);
For other layers, you would have to change temp->cuboid[0][i][j] to temp->cuboid[n][i][j] where n is the layer number. For example, the following code prints layer n of the most recently computed steady state temperatures onto stdout
for(i=0; i < model->rows; i++)
for(j=0; j < model->cols; j++)
printf("%d\t%.2f\n", i*model->cols+j, model->last_steady->cuboid[n][i][j]);
In the floorplans generated by HotFloorplan, the relative importance of the metrics such as area, temperature and wire length can be controlled through the weights lambdaA, lambdaT and lambdaW specified in the hotspot.config file respectively. Their default values were tuned for the ev6-like blocks released with HotSpot. You might want to tune them to suit your own application. In order to reduce the empty blocks of the form _(number), increasing lambdaA should help. Please see section C-5-d-iii of the HotSpot How-To for more information. Alternatively, you may want to consider using ArchFP.
The interfaces remain pretty much the same. So, just replacing the old files with the new ones in version 5.x and incorporating the changes in the Makefile for compiling them should suffice. However, if you are using the grid model, for better accuracy, it would be better to distinguish between the first call to compute_temp and subsequent calls. The first call should continue to pass the temperature vector argument as before while the subsequent calls should pass a NULL pointer instead. For more details about how to do this, please see the subsection on source-level integration of HotSpot with other power/performance simulators in the HOTSPOT-HOWTO.
We recommend that you switch to newest HotSpot version considering it as a new installation. This means that code that is already using versions 1.0 and 2.0 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. For more details about how to do this, please see the subsection on source-level integration of HotSpot with other power/performance simulators in the HOTSPOT-HOWTO.
Last updated: Jan. 23, 2019