From hitoshi_mizunuma at tet.toshiba.co.jp Wed May 5 02:45:35 2004 From: hitoshi_mizunuma at tet.toshiba.co.jp (hitoshi_mizunuma@tet.toshiba.co.jp) Date: Wed Mar 22 16:04:10 2006 Subject: [Hotspot] Fw: HotSpot v2.0 Message-ID: Dear sir; I am a student who are using HotSpot v1.02. I tried to download the new version and found the link of following URL doesn't work. Could you please check for me, thanks! Mizunuma ----- Forwarded by hitoshi mizunuma/toshiba-tet on 2004/05/05 14:37 ----- skadron@cs.virgin ia.edu To: hitoshi_mizunuma@tet.toshiba.co.jp cc: 2004/05/05 13:20 Subject: HotSpot v2.0 Dear Hitoshi Mizunuma: Thanks for your interest in downloading HotSpot v2.0. It can be downloaded from this URL: http://lava.cs.virginia.edu/HotSpot/grab/hotspot-2.0.tar.gz If you have any questions please read our faq, or send email to hotspot@cs.virginia.edu. (You must subscribe to the mailing list first, at http://www.cs.virginia.edu/mailman/listinfo/hotspot) Please note that to receive updates about HotSpot, you will either need to subscribe to the mailing list or monitor the web site for announcements. Thanks, LAVA Lab From link at cse.psu.edu Thu May 13 14:22:08 2004 From: link at cse.psu.edu (Gregory M Link) Date: Wed Mar 22 16:04:10 2006 Subject: [Hotspot] rk4 returns array full of NaN's? Message-ID: <20040513182208.GA11403@orlith.cse.psu.edu> Hotspot Mailing List - I am compiling and running Hotspot on a Solaris workstation, and am attempting to do transient analysis through the compute_temp function. I have verified that the initial temperature arrays are being initialized with the initial temperature, and that the power and overall_power arrays also contain the proper values. Just before calling rk4 in compute_temp, temp[0] contains an appropriate value. After the call to rk4, the entry contains "NaN" (decimal 2147483647). What could be going wrong in the rk4 approximation? Here are some details on the specific test I'm trying to run: - A large number (~200) of sub-functional units - Each subfunctional unit consumes constant power throughout the test (so I have the power[] == overall_power[] ) - I'm trying to capture the temperature equalization across the chip as time progresses - Time step of 1us If you'd like any more information, I'll happily provide it. - Greg Link Penn State University From ks4kk at cs.virginia.edu Fri May 14 08:03:34 2004 From: ks4kk at cs.virginia.edu (Karthik Sankaranarayanan) Date: Wed Mar 22 16:04:10 2006 Subject: [Hotspot] rk4 returns array full of NaN's? In-Reply-To: <20040513182208.GA11403@orlith.cse.psu.edu> References: <20040513182208.GA11403@orlith.cse.psu.edu> Message-ID: Hello Greg, I might be wrong but this sounds like some array bounds problem because of the MAX_UNITS definition. In the release version of HotSpot, MAX_UNITS (maximum no. of units in a floorplan) has been defined to be 50. Have you changed it to incorporate the 200 sub-functional units? Please let me know if it still doesn't solve the problem. Thanks -karthik On Thu, 13 May 2004, Gregory M Link wrote: > Hotspot Mailing List - > I am compiling and running Hotspot on a Solaris workstation, and > am attempting to do transient analysis through the compute_temp function. > I have verified that the initial temperature arrays are being initialized > with the initial temperature, and that the power and overall_power arrays > also contain the proper values. Just before calling rk4 in compute_temp, > temp[0] contains an appropriate value. After the call to rk4, the entry > contains "NaN" (decimal 2147483647). > > What could be going wrong in the rk4 approximation? > > Here are some details on the specific test I'm trying to run: > - A large number (~200) of sub-functional units > - Each subfunctional unit consumes constant power throughout the test (so > I have the power[] == overall_power[] ) > - I'm trying to capture the temperature equalization across the chip as > time progresses > - Time step of 1us > > If you'd like any more information, I'll happily provide it. > > - Greg Link > Penn State University > > _______________________________________________ > HotSpot mailing list > HotSpot@cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/hotspot > From clucas42 at hotmail.com Sun May 23 15:24:10 2004 From: clucas42 at hotmail.com (Christopher Lucas) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] "HotSpot" mailing list Message-ID: An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/hotspot/attachments/20040523/fe505901/attachment.htm From link at cse.psu.edu Mon May 24 21:36:21 2004 From: link at cse.psu.edu (Greg Link) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] Out-Of-Memory Problems Message-ID: I've been running the tool on ever-larger floorplans and sets of data, and have hit some problems with memory space. In particular, I'm getting system fails with an assertion error pointing out that in fact, "m[i] != NULL" on line 236. I believe that this means that the calloc() function is failing to find enough space to allocate a new matrix. Strangely, my system has over 4GB of system memory, with a swap file over 8GB in size (of which 95%+ is free at the time of program start), yet it often fails just after the 4GB limit is reached. (This is being run on a 64-bit Solaris system, so the memory addressing problem shouldn't be an issue, I hope) Since I don't think I'll be rewriting the hotspot library with more advanced matrix handlers anytime soon, I can only hope that I can cut down on the number of matrices needed as much as possible. To that end, I'm thinking that the bare minimum required for a steady-state temperature distribution is as follows: Allocate space for floorplan array. Call 'create_RC_matrices'. Allocate space for 'overall_power' and 'steady_temp' arrays. Call 'steady_state_temp', then 'dump_temp'. Free up space. Is there any other arrays/matrices needed for that operation? Can I remove one of the above mentioned arrays earlier? Are there any other 'quick fix' places in the create_RC_matrices function where space might be saved? - Greg Link From grbriggs at ece.rochester.edu Wed May 26 10:34:28 2004 From: grbriggs at ece.rochester.edu (Greg Briggs) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] Impact of changing RHO_INT Message-ID: Hi all, I am doing some simulations in which one of the CPU functinal units is predicted to get very hot (> 800 C ...). To address this, one step I want to take is to use a better thermal compound on the CPU (like "Artic Silver" or what not), which means changing the value of RHO_INT from the default: RHO_INT 0.75 /* thermal resistivity of the interface material in (mK)/W */ The value for the better thermal interface material would be about 0.14. I observe that this constant is located in RC.h rather than the user-configurable sim-template.c, which suggests to me that changing it may break the FlowWorks calibrations or cause other unforseen complications. Should it be okay for me to change this value? Just making sure; thanks, Greg Briggs From wh6p at cms.mail.virginia.edu Wed May 26 11:30:19 2004 From: wh6p at cms.mail.virginia.edu (Wei Huang) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] Impact of changing RHO_INT In-Reply-To: References: Message-ID: <137768562.1085571019@hilopc3.ee.Virginia.EDU> There should be no problem, because all the factors are analytically derived (not calibrated from Floworks). Hope this helps, Wei Huang --On Wednesday, May 26, 2004 10:34 AM -0400 Greg Briggs wrote: > Hi all, > > I am doing some simulations in which one of the CPU > functinal units is predicted to get very hot (> 800 C > ...). To address this, one step I want to take is to use > a better thermal compound on the CPU (like "Artic Silver" > or what not), which means changing the value of RHO_INT > from the default: > > RHO_INT 0.75 /* thermal resistivity of the interface > material in (mK)/W */ > > The value for the better thermal interface material would > be about 0.14. > > I observe that this constant is located in RC.h rather > than the user-configurable sim-template.c, which > suggests to me that changing it may break the FlowWorks > calibrations or cause other unforseen complications. > > Should it be okay for me to change this value? > > Just making sure; thanks, > > Greg Briggs > > _______________________________________________ > HotSpot mailing list > HotSpot@cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/hotspot > From link at cse.psu.edu Wed May 26 19:48:08 2004 From: link at cse.psu.edu (Greg Link) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] Entries in the hotspot vector? Message-ID: When examining an object of type 'hotspot vector', it consists of a number of entries equal to Flp->n_units * NL + EXTRA This stores temperature information for all the nodes in the simulation, with each FUB having a total of NL-1 layers above it (since it is on layer 0, that of silicon). My question then, is: in the array, how are the FUBs and their nodes related? For example, if assuming 3 layers (silicon, interface, and heat spreader, as in the default configuration), and dealing with FUB0, what array element contains the interface above FUB0? What element contains the heat spreader over FUB0? I believe that if FUB0 is located at array location 0, then the interface above it is located at 0+flp->n_units, while the heat spreader is located at 0+2*flp->n_units. Am I correct in this belief? - Greg Link From wh6p at cms.mail.virginia.edu Wed May 26 21:39:20 2004 From: wh6p at cms.mail.virginia.edu (Wei Huang) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] Entries in the hotspot vector? In-Reply-To: References: Message-ID: <174309640.1085607560@hilopc3.ee.Virginia.EDU> Yes, you are right. In the future, we will add more layers, such as on-die interconnect layers, C4 pads, etc. Wei Huang --On Wednesday, May 26, 2004 7:48 PM -0400 Greg Link wrote: > When examining an object of type 'hotspot vector', it > consists of a number of entries equal to > > Flp->n_units * NL + EXTRA > > This stores temperature information for all the nodes in > the simulation, with each FUB having a total of NL-1 > layers above it (since it is on layer 0, that of silicon). > > My question then, is: in the array, how are the FUBs and > their nodes related? > > For example, if assuming 3 layers (silicon, interface, > and heat spreader, as in the default configuration), and > dealing with FUB0, what array element contains the > interface above FUB0? What element contains the heat > spreader over FUB0? > > I believe that if FUB0 is located at array location 0, > then the interface above it is located at 0+flp->n_units, > while the heat spreader is located at 0+2*flp->n_units. > > Am I correct in this belief? > - Greg Link > > _______________________________________________ > HotSpot mailing list > HotSpot@cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/hotspot > From ks4kk at cs.virginia.edu Thu May 27 08:30:45 2004 From: ks4kk at cs.virginia.edu (Karthik Sankaranarayanan) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] Out-Of-Memory Problems In-Reply-To: <40B52F99.4060904@cs.virginia.edu> References: <40B52F99.4060904@cs.virginia.edu> Message-ID: What you have mentioned looks fine. Additionally, since you need only steady state temperatures, all the capacitance related matrices allocated inside create_RC_matrices can be removed. Some of those matrices/vectors are internal to create_RC_matrices (vector c_ver) and some are global (matrices c and inva). Removing them all would not affect steady_state_temp. Thanks, -karthik > -------- Original Message -------- > Subject: [Hotspot] Out-Of-Memory Problems > Date: Mon, 24 May 2004 21:36:21 -0400 > From: Greg Link > To: > > I've been running the tool on ever-larger floorplans and sets of data, and > have hit some problems with memory space. In particular, I'm getting system > fails with an assertion error pointing out that in fact, "m[i] != NULL" on > line 236. I believe that this means that the calloc() function is failing to > find enough space to allocate a new matrix. > > Strangely, my system has over 4GB of system memory, with a swap file over > 8GB in size (of which 95%+ is free at the time of program start), yet it > often fails just after the 4GB limit is reached. (This is being run on a > 64-bit Solaris system, so the memory addressing problem shouldn't be an > issue, I hope) > > Since I don't think I'll be rewriting the hotspot library with more advanced > matrix handlers anytime soon, I can only hope that I can cut down on the > number of matrices needed as much as possible. To that end, I'm thinking > that the bare minimum required for a steady-state temperature distribution > is as follows: > > Allocate space for floorplan array. > Call 'create_RC_matrices'. > Allocate space for 'overall_power' and 'steady_temp' arrays. > Call 'steady_state_temp', then 'dump_temp'. > Free up space. > > Is there any other arrays/matrices needed for that operation? Can I remove > one of the above mentioned arrays earlier? Are there any other 'quick fix' > places in the create_RC_matrices function where space might be saved? > > - Greg Link > > _______________________________________________ > HotSpot mailing list > HotSpot@cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/hotspot From skadron at cs.virginia.edu Thu May 27 13:09:46 2004 From: skadron at cs.virginia.edu (Kevin Skadron) Date: Wed Mar 22 16:04:11 2006 Subject: [Hotspot] "HotSpot" mailing list In-Reply-To: References: Message-ID: <40B620DA.8090608@cs.virginia.edu> See my answers below. --Kevin Christopher Lucas wrote: > Hello , > > I have read your paper and I was wondering about two things. In the > program Hotspot you mentioned that u could break up blocks into smaller > blocks and feed them into hotspot. I am currently trying to use Hot SPot > for a class project ,where we are looking at data fusion techniques to > reduce sensor error and thus increase performance of the chip. > > > > 1) We are trying to use your ev6.flp as a sample floorplan we wanted to > know do you guys have a floorplan where each of these blocks are broken > into smaller blocks? Sorry, not at this time. > 2)How do you come up with power traces for the blocks in the ev6.flp > floor plan? We use Wattch and average it's cycle-by-cycle power estimations to get a sampling period of 10,000 cycles. You might want to refer to one of our papers for more detail.