【IC】温度感知芯片微架构设计

摘要

随着功率密度和冷却成本呈指数级增长,处理器封装不能再为最坏的情况而设计,并且迫切需要运行时处理器级技术,以便在超过封装容量时调节工作温度。然而,评估这些技术需要一个可用于架构研究的热模型。

本文介绍了 HotSpot,这是一种准确而快速的模型,基于热阻和热容的等效电路,对应于微架构模块和热封装的基本方面。使用有限元仿真进行验证。本文还介绍了动态热管理 (DTM) 的几种有效方法:“温度跟踪”频率缩放、局部切换以及将计算迁移到备用硬件单元。在微架构级别对温度进行建模还表明,功耗指标是温度的不良预测指标,并且传感器的不精确性对 DTM 的性能有重大影响。

介绍

近年来,微处理器的功率密度每三年翻一番 [3, 17],随着特征尺寸和频率的扩展速度快于工作电压,预计这一速度将在一到两代内增加 [25]。由于微处理器消耗的能量转化为热量,因此热密度的相应指数级增长在可靠性和制造成本方面造成了巨大的困难。在任何功耗水平下,都必须从微处理器芯片表面去除产生的热量,对于当今除最低功率设计之外的所有设计,这些冷却解决方案都变得昂贵。对于高性能处理器,冷却解决方案的每瓦散热成本上涨 1-3 美元或更高 [3, 12],这意味着冷却成本呈指数级增长,并威胁到计算机行业部署新系统的能力。

仅靠功耗感知设计无法阻止这一趋势,它要求在所有系统级别(包括处理器架构)进行温度感知设计。温度感知设计将利用电源管理技术,但其方式可能与用于延长电池寿命或调制峰值电源功率的方式不同。局部加热比芯片范围的加热发生得快得多;由于整个芯片的功耗在空间上不均匀,这会导致“热点”和空间梯度,从而导致时序误差甚至物理损坏。这些效应在数百微秒或毫秒的时间尺度上演变。这意味着,为了用于热管理,电源管理技术必须直接针对工作温度的空间和时间行为。事实上,许多低功耗技术对工作温度的影响很小或没有影响,因为它们不会降低热点的功率密度,或者因为它们只回收松弛(reclaim slack),而不会在没有松弛时降低功率和温度。因此,温度感知设计是一个独特但相关的研究领域。

迄今为止,特定于温度的设计技术主要集中在热封装(散热器、风扇等)上。如果封装是为最坏情况下的功率耗散而设计的,那么它们必须针对可能出现的最严重的热点进行设计,而这非常昂贵。然而,这些最坏情况很少见:大多数应用程序,尤其是台式机,不会产生足够的功率耗散来产生最坏情况下的温度。为最坏情况设计的封装是多余的。

为了降低封装成本而不不必要地限制性能,建议 [4, 12, 13] 封装应针对最差的典型应用进行设计。任何耗散的热量超过这种更便宜的封装所能管理的应用都应该采用替代的运行时热管理技术(动态热管理或 DTM)。由于典型的高功率应用仍比最坏情况低 20% 或更多 [12],因此可以节省大量成本。这就是 Intel Pentium 4 [12] 散热设计背后的理念。它使用专为典型高功率应用设计的热封装,将封装的冷却要求降低了 20%,并相应地降低了成本。如果工作温度超过安全温度,则停止 clock (我们称之为 global clock gating),直到温度恢复到安全区域。这可以防止因持续高功率作、在高于预期环境温度下运行或封装中的某些故障而导致的时序错误和物理损坏。只要停止 clock 的 threshold temperature (trigger threshold) 基于系统中的最热温度,这种方法就可以成功地调节温度。

架构级热管理的需求

这些芯片级硬件技术说明了运行时热管理的优势和挑战:虽然它可以大大降低冷却成本并且能够允许典型应用运行在峰值性能,这些技术还会降低任何超过热设计点的应用程序的性能。对于全局时钟门控等芯片范围的技术,这种性能损失可能会很大,对于我们最热门的应用 art 来说,性能损失会减慢 27%。

我们认为,微架构没有使用芯片级热管理技术,而是发挥着至关重要的作用。微架构的独特之处在于它能够使用应用程序行为的运行时知识和芯片不同单元的当前热状态来调整执行和分配工作负载,以控制热行为。在本文中,我们展示了架构级热建模通过利用指令级并行性 (ILP) 以比芯片范围的技术更低的性能成本揭示了架构技术。例如,我们发现的最好的技术之一(仅减慢了 8%)是“本地切换”方案,该方案改变了只能访问热单元(通常是整数寄存器文件)的速率。ILP 有助于减轻该单元带宽减少的影响,而其他单元则继续全速运行。

架构解决方案当然并不排除软件或芯片级热管理技术。温度感知任务调度,如 Rohou 和 Smith [20] 提出的,当然可以减少使用任何类型的运行时硬件技术的需求,但总会存在工作温度无法通过软件成功管理的工作负载。当热应力变得极端时,芯片级失效保护技术可能仍然是管理温度的最佳方法,例如,当环境温度上升到规格以上或封装的某些部分出现故障时(例如,散热器脱落)。但所有这些技术都是协同的,只有架构技术才具有有关热点和温度梯度的详细温度信息,可用于精确调节温度,同时最大限度地减少性能损失。

架构级热建模的需求

一些架构技术已经被提出 [4, 13, 16, 22, 26],因此在架构领域内显然对这个主题感兴趣。为了准确描述当前和未来的热应力、时间和空间不均匀性以及应用依赖行为,更不用说评估管理热效应的建筑技术了,需要一个温度模型。然而,架构社区目前缺乏可靠且实用的热建模工具。正如我们在本文中所展示的,目前根据某种平均功率耗散来估计热行为的技术非常不可靠。

一个有效的架构级热模型必须足够简单,以允许建筑师考虑热效应和权衡;足够详细,可以模拟不同功能单元内的运行时间温度变化;同时具有计算效率和可移植性,可用于各种架构模拟器。即使是软件级的热管理技术也将从热模型中受益。最后,该模型应该足够灵活,以便轻松扩展到新型计算系统,如图形和网络处理器、MEMS 以及由纳米级材料制成的处理器。

贡献

本文说明了热建模的重要性;提出了一个紧凑、动态和可移植的热模型,以方便在架构级别使用;使用此模型来表明热点通常发生在架构级块的粒度上,并且基于功耗的指标与温度没有很好的相关性;并讨论了进一步提高社区评估温度感知技术的能力的一些剩余需求。我们的模型(我们称之为 HotSpot)在 http://lava.cs.virginia.edu/hotspot 上公开提供。使用这个模型,我们评估了各种 DTM 技术。最有效的技术是 “温度跟踪” 动态频率缩放:可以消除由热点引起的时序误差,平均减速 2%。对于还需要考虑防止物理损坏的温度阈值,最好使用备用寄存器文件并在寄存器文件之间迁移计算以响应加热,平均减慢 5-7%。本地切换的表现几乎相同,速度下降了 8%。我们所有的实验都包括传感器不精确性的影响,这大大阻碍了当前技术中的运行时热管理。

由于热约束变得如此严重,我们预计温度感知计算将成为一个丰富的研究领域。我们希望本文提供了一个基础,以激发和帮助架构师以他们应用于低功耗的相同力度来研究这个主题。

下一节将提供进一步的背景和相关工作。然后,第 3 节描述了我们提出的模型,并展示了对温度建模而不是功率的重要性。第 4 节介绍了几种新颖的热管理技术,并探讨了热传感器非理想性对热管理的影响,第 5 节描述了我们的实验装置。第 6 节比较了各种热管理技术调节温度的能力,第 7 节总结了本文。我们还发布了本文的扩展版本作为技术报告 [27],提供了额外的讨论和结果。

背景和相关工作

实际上,在未来的技术中,功率密度有望更快地上升,因为工作电压 (Vdd) 不能再像以前那样快速扩展:对于 130nm 及以后,2001 年国际半导体技术路线图 (ITRS) [25] 预计 Vdd 的变化很小。这些不断上升的功率密度产生的热量上升会产生许多问题,因为软误差和老化都会随着温度的升高而呈指数级增长。然而,为了保持通常与摩尔定律相关的传统性能改进速率,时钟速率必须继续每两年翻一番。由于载流子迁移率与温度成反比,因此高性能微处理器的工作温度不能升高,甚至可能需要在未来几代产品中降低。ITRS 实际上预测,最大结温从 180nm 的 95°C 降低到 130nm 及更高的 85°C。架构技术可以发挥重要作用,它允许将封装设计为典型应用的功耗,而不是最坏情况的应用,并利用指令级并行性,使极端应用即使超过封装的容量,也能实现合理的性能。

已经进行了大量工作来设计提供更大散热能力的新封装,布置电路板以改善气流,并在电路和电路板(但不是架构)级别对加热进行建模。紧凑模型是模拟这些效应的最常用方法,尽管在考虑空气或液体的流动时,通常会使用有限元建模来执行计算流体动力学。Sabry 在 [21] 中对这些建模技术进行了出色的调查。

尽管长期以来一直担心热效应,但建筑领域发表的研究很少。Gunther 等人 [12] 描述了 Pentium 4 的热设计方法,其中热管理是通过全局时钟门控完成的。Lim et al. [16] 提出了一种用于移动设备的异构双流水线处理器,其中标准执行核心由低功耗、单发、有序流水线增强,该流水线共享获取引擎、寄存器文件和执行单元,但停用了 renamer 和 issue 队列等乱序组件。低功耗管道主要用于可以容忍低性能的应用,因此在节能方面非常有效,但当主管道过热时,这种技术也可能有效。

Huang 等人 [13] 部署了一系列四种功耗降低技术——滤波器指令缓存、DVS、数据缓存的子银行,以及必要时的全局时钟门控——当温度接近最高允许温度时,会产生越来越强的响应。Brooks 和 Martonosi [4] 比较了几种独立的热管理技术:频率缩放、电压和频率缩放、fetch 切换(暂停 fetch 一段时间,类似于 Pentium 4 的全局时钟门控)、解码节流(改变每个周期可解码的指令数量 [22])和推测控制 [18])。Brooks 和 Martonosi 还指出了拥有直接微架构热触发器的价值,该触发器不需要对作系统及其相关延迟进行陷阱。他们发现只有 fetch 切换和激进的 DVS 才有效。在撰写这些论文时,没有任何类型的温度模型,因此两者都使用移动窗口上的平均芯片范围功率耗散作为温度的代理。正如我们在 Section 3.6 中所示,该值并不能可靠地跟踪温度。另一个问题是,由于当时没有可用的局部加热模型,因此其中一些技术不会降低实际热点的功率密度。

我们之前的工作 [26] 提出了一个简单的模型,用于跟踪每单位级别的温度,并提出了一个反馈控制来修改 Brooks 获取切换算法以逐渐响应,与全有或全无方法相比,性能损失降低了 65%。我们唯一知道的其他热模型是由 Dhodapkar 等人开发的 TEMPEST [9]。TEMPEST 还使用等效 RC 电路直接对温度进行建模,但整个芯片仅包含单个 RC 对,不提供局部信息。架构领域的先前工作没有考虑由于传感器噪声和放置而导致的不精确性。

本文展示了更详细的热模型的重要性,包括局部加热、热扩散和与热封装的耦合,并使用此模型来评估 DTM 的各种技术。

架构级别的热建模

使用等效的 RC 电路

传热和电现象之间存在着众所周知的二元性 [14]。热流可以被描述为“电流”通过热阻并导致类似于“电压”的温差。热电容对于模拟瞬态行为也是必需的,以捕获功率变化导致温度达到稳态之前的延迟。

热 Rs 和 Cs (热阻和热容)共同导致以热 RC 时间常数(类比电学RC常数)为特征的指数上升和下降时间。这种对偶性背后的基本原理是,电流和热流由完全相同的电位差微分方程描述。在热设计领域,这些等效电路称为紧凑模型,如果它们包含热电容器,则称为动态紧凑模型。这种对偶性为架构级热模型提供了便捷的基础。对于微架构单元,热传导到热封装和相邻单元是决定温度的主要机制。

对于我们建议的研究类型,紧缩模型必须具有以下属性。它必须跟踪单个微架构单元粒度的温度,因此等效的 RC 电路必须为每个单元至少有一个节点。它必须参数化,即为不同的微架构自动生成一个新的紧凑模型;和便携,使其易于与一系列功率/性能模拟器一起使用。最后,它必须是 BICI(boundary condition independent),即边界和初始条件无关:热模型组件值不应取决于初始温度或正在研究的特定配置。我们开发的 HotSpot 模型满足所有这些条件。它是一个简单的库,可以自动生成等效的 RC 电路,并提供任何选定时间步的功率耗散,计算每个感兴趣模块中心的温度。该模型在结构上是 BICI 的,因为组件值来自材料、物理和几何值。

今天的芯片通常采用封装方式,芯片靠在散热板(heat spreader)上,散热板通常由铝、铜或其他高导电材料制成,而散热板又靠着由风扇冷却的铝或铜散热器(heat sink)放置。这是 HotSpot 建模的配置。一个典型的示例如图 1 所示。低功耗/低成本芯片通常省略散热器,有时甚至省略散热器;移动设备通常使用热管和其他包装,以避免散热器的重量和尺寸。这些扩展仍然是未来工作的领域。
在这里插入图片描述

等效电路(示例见图 2)旨在与芯片的物理结构及其热封装具有直接和直观的对应关系。因此,RC 模型由三个垂直导电层组成,分别用于芯片、heat spreader和heat sink,以及第四个垂直对流层,用于散热器-空气接口。die layer 被划分为多个 blocks,这些 blocks 对应于感兴趣的 microarchitectural blocks 及其 floorplan。为简单起见,图 2 中的示例描述了一个只有 3 个块的芯片平面图,而实际模型将有 10-20 个甚至更多。spreader分为五个块:一个对应于模具正下方的区域 (Rsp),四个梯形对应于未被模具覆盖的外围。以类似的方式,sink分为五个块:一个对应于吊具正下方的区域 (Rhs);外围有四个梯形。最后,从封装到空气的对流热传递用一个单热阻 (Rconvection)表示。假设空气处于固定的环境温度,在热设计中通常假设为 45◦C [17](这不是室内环境温度,而是计算机“盒子”内的温度”)。请注意,我们目前忽略了流入芯片绝缘陶瓷帽和 I/O 引脚,然后从那里流入电路板等的少量热量。我们还忽略了芯片、撒布器和灌槽之间的接口材料。这些都是未来工作的进一步领域。

对于芯片层、spreader层和sink层,RC 模型由垂直模型和横向模型组成。垂直模型捕获从一层到下一层的热流,从芯片穿过封装,最终进入空气中。横向模型捕获了层内相邻块之间的热扩散,以及从一个层的边缘到下一个区域的外围的热扩散(例如,R1 考虑了从块 1 边缘到spreader的热量扩散,而 R2 考虑了从块 1 边缘到芯片其余部分的热量扩散)。在动态仿真的每个时间步长,die每个单元中的功耗被建模为该模块中心节点的电流源(未显示)。

派生模型

在本节中,我们将简要介绍如何计算 R 和 C 的值。更详细的讨论可以在本文的扩展版本中找到 [27]。

该推导主要基于热阻与材料厚度成正比,与热量传递的横截面积成反比的事实:
R = t k ⋅ A (1) R=\frac{t}{k \cdot A} \tag{1} R=kAt(1)

其中 k 是材料每单位体积的热导率,85℃时,硅的热导率100W/m ·K ,铜是400W/m ·K 。另一方面,热容与厚度和面积成正比:
C = c ⋅ t ⋅ A (2) C=c\cdot t\cdot A \tag{2} C=ctA(2)

其中 c 是每单位体积的热容,1.75 × 106J/m3 ·K 代表硅和 3.55 × 106J/m3 ·K 代表铜。典型的芯片厚度在 0.3-0.9 mm 范围内;本文研究了 0.5mm 厚的芯片。注意HotSpot需要一个应用于电容器的比例因子,以解释我们的集总模型中相对于全分布式 RC 模型的一些简化,这些如下所述。

除了上述基本推导外,横向电阻还必须考虑不同纵横比的块之间的扩展阻力,散热器的垂直阻力必须考虑从散热器底座到翅片的收缩阻力 [15]。扩散阻力解释了从小区域到大区域的热流增加,反之亦然。这些计算在 HotSpot 中完全自动化。为了空间的节约,可以在 [27] 中找到详细信息。

通常,封装对空气电阻 (Rconvection) 将根据特定的散热器配置计算得出。在本文中,我们改为手动选择一个价值阻力,它为我们提供了良好的基准行为分布;参见 Section 5.4 。

硅电容器必须乘以大约 2 的经验拟合常数。原因是芯片的底面实际上并不是等温的,而 HotSpot 通过将芯片的所有垂直 Rs 馈送到单个节点来处理底面。真正的等温表面位于散热器中的某个位置,这意味着决定片上加热速率的“等效热质量”大于芯片厚度,并使有效热容大于公式 2 得出的热量。对于 0.5mm 厚的芯片和芯片上功率耗散的合理分布,我们通过与参考有限元热传输模型进行比较,凭经验确定合理的平面图和功率耗散的缩放因子保持接近 2(参见第 3.3 节)。我们选择这种简化是因为它简化了 RC 网络的解决方案,而不会牺牲温度最热的芯片表面温度的准确性。然而,由于这个因素是经验性的,并且取决于芯片厚度,因此它违背了我们完全参数化模型的目标。改进模型或开发分析表达式是未来工作的另一个领域。

spreader和sink中的电容器必须乘以大约 0.4。与硅的缩放不同,这不是一个临时因素,而是每个模块使用简单的单块 C 而不是分布式模型的结果。我们根据经验确定的比例因子确实与 [19] 预测的值相匹配。

HotSpot 在使用由模块的布局及其区域组成的配置初始化时动态生成 RC 电路(参见 Section 3.4)。然后,通过向 HotSpot 提供每个模块的功率密度动态值(这些是电流源的值)和每个模块的当前温度,将该模型用于动态架构功耗/性能仿真。我们使用从 Wattch 获得的功率密度,这是过去 10K clock cycles 的平均值;有关采样率选择的更多信息,请参阅 Section 5.1 。在每个时间步长,描述RC电路的微分方程都使用四阶Runge-Kutta方法进行四次迭代求解,返回每个模块的新温度。在 1.6GHz Athlon 处理器上,每次调用求解器大约需要 50μs,因此对于合理的采样率,仿真时间的开销可以忽略不计,通常不到总仿真时间的 1%。

校准模型

动态紧缩模型在热工程界已经很成熟,尽管我们不知道已经开发出任何用于描述微建筑单元粒度的瞬态热流的模型。当然,精确的紧凑模型必须进行验证,以最大程度地减少使用集总单元对传热进行建模时可能出现的误差。这很困难,因为我们不知道任何可用于验证模型的物理温度的局部、时间依赖性测量来源。在热工程界,如何获得如此直接的测量结果仍然是一个悬而未决的问题。

我们目前最好的参考来源是 Floworks (http://www.floworks.com) 中的有限元模型,这是一个用于任意几何、材料和边界条件的 3D 流体和热流的商用有限元模拟器。我们对每个模块中具有不同布局图和不同功率密度的硅晶片进行建模;该芯片的一侧连接到铜散热器和铜散热器,另一侧由绝缘帽覆盖。假设空气保持在 45◦C;气流为 10 m/s。有关 Floworks 建模的更多详细信息,请参见 [27]。

Floworks 和 HotSpot 只是半独立的,因为硅中热电容的 HotSpot 拟合因子是使用 Floworks 凭经验确定的。尽管如此,我们可以验证两者是否获得了相似的稳态工作温度和瞬态响应。图 3a 显示了稳态验证,比较了 Floworks、HotSpot 和“简单”模型预测的温度,该模型消除了 RC 电路的侧面部分(但不包括封装,省略该部分会产生非常大的误差)。HotSpot 与 Floworks 显示出良好的一致性,误差(相对于环境温度,45°C 或 318°K)始终小于 5.8%,通常小于 3%。另一方面,简单模型的误差更大,高达 16%。最大的误差来自最热的模块,意味着产生了很多热触发(thermal trigger?没懂。可能是DTM时的触发动作)。图 3b 显示了 Floworks、HotSpot 和简单模型的瞬态验证,比较了芯片上一个模块中的温度随时间的变化。Floworks 和 HotSpot 之间的一致性非常好,但简单的模型显示温度上升得太快和太远。稳态和瞬态结果都显示了热扩散在确定片上温度方面的重要性。
在这里插入图片描述

布局规划:热邻接建模

模块的大小和邻接是推导 RC 模型的关键参数。在迄今为止的所有仿真中,我们都使用了与 Alpha 21364 相对应的平面图(以及近似的微架构和功耗模型)。该平面图如图 4 所示。与 21364 一样,它将 CPU 内核置于芯片一个边缘的中心,周围区域由 L2 缓存、多处理器接口逻辑等组成。由于我们没有对多处理器工作负载进行建模,因此我们省略了多处理器接口逻辑,并将芯片的整个外设视为二级 (L2) 缓存。与图 4a 中的 21364 晶粒照片相比,这个缓存的面积似乎不成比例地大,因为我们已经将 CPU 缩放到 130nm,同时保持整体晶粒尺寸不变。请注意,我们没有对 I/O 焊盘进行建模,因为我们还没有一个好的 dynamic 模型来模拟它们的功率密度。
在这里插入图片描述

局限

显然,仍有许多方法可以改进模型以进一步提高其准确性和灵活性。除了热建模之外,其中许多还需要架构功耗建模方面的进步,还有一些问题(例如对更广泛的热封装进行建模以及包括 I/O 焊盘的影响)如上所述。

也许未来工作最重要和最有趣的领域是包括由于时钟网格和其他互连而导致的加热。目前,可以通过将导线的功率耗散包含在驱动 HotSpot 的动态每块功率密度值中来近似计算导线的影响。更精确的方法是分别处理导线本身的自热和向周围硅的热传递,但模拟这些效应的最准确方法尚不清楚。另一个重要的考虑因素是,跨越一个块的全局连线中的活动可能与块内的活动无关。因此,连线效果可能很重要,例如,通过使架构上空闲的区域仍然加热。

另一个需要进一步研究的问题是推导出 RC 模型的适当粒度。HotSpot 非常灵活:可以以任何所需的粒度指定块,但随着粒度的增加,模型会变得更加复杂且更难推理。我们目前正在将 HotSpot 与对应于主要微架构单元的块一起使用,但对于功率密度不均匀的单元——例如缓存,这种近似可能会引入一些不精确性。

最后,尽管 HotSpot 基于众所周知的热力学原理,并且已经通过半独立的 FEM 进行了验证,但还需要进一步验证,最好使用来自运行实际工作负载的处理器的真实物理测量。

直接对温度进行建模的重要性

由于缺乏架构温度模型,之前的一些研究试图通过平均一段时间内的功率耗散来模拟温度。除非在片上 blocks 的粒度上完成,否则它不会捕获任何局部加热,但即使这样,它也无法考虑 blocks 之间的横向耦合、散热器的作用等。我们还遇到了温度对应于瞬时功率耗散的谬论,而实际上热容在将功率变化转换为温度变化时充当低通滤波器。

为了说明使用热模型而不是功率度量的重要性,我们计算了温度与功耗移动平均值之间的相关系数。表 1 中的数据来自具有代表性的基准 gcc。使用 HotSpot 收集温度,并使用500个million周期模拟的各种平均周期收集功率测量值。我们一直发现相关性非常差,尤其是在最热的块中。表 1 中报告了温度和平均功率的一些相关系数,功率平均间隔为 100 万次。
在这里插入图片描述

架构 DTM 技术

本节介绍了本文评估的动态热管理的各种架构机制,并讨论了传感器不精确性如何影响热管理。定义几个术语很方便:紧急阈值是芯片处于热违规温度之上的温度;对于 85◦,违规可能会导致时序误差,而对于具有较高紧急阈值的低性能芯片,违规会导致更高的错误率和更短的工作寿命。在任何一种情况下,我们都假设 chip 永远不会超过紧急阈值。这可能过于严格,因为错误率和老化是概率现象,足够短暂的违规可能是无害的,但目前还没有好的架构级模型来更细致地处理这些阈值。最后,触发阈值是运行时热管理开始运行的温度;显然,触发<紧急情况。

运行时机制

本文提出了 DTM 的三种新架构技术:“温度跟踪”频率缩放、本地切换和迁移计算。它们与之前提出的两种技术一起进行评估,即 DVS (但与之前的工作不同,我们增加了反馈控制)和全局时钟门控 (我们还增加了反馈控制)。

对于提供多种可能设置的技术,我们使用正式的 feedback control 来选择设置。反馈控制允许设计简单但坚固的控制器,使行为适应不断变化的条件。按照 [28] ,我们使用 PI(比例积分)控制器,将每个样品期间观察到的最热温度与设定值进行比较。差值 e 乘以增益 Kc 以确定控制器输出 u 应该变化多少,即:
u [ k ] = k [ k − 1 ] + K c ⋅ e [ k − 1 ] (3) u[k]=k[k-1]+K_c \cdot e[k-1] \tag{3} u[k]=k[k1]+Kce[k1](3)

然后,此输出按比例转换为所控制机构的设置。实现此控制器的硬件最少。需要一些 registers、一个 adder 和一个 multipliers,以及一个 state machine 来驱动它们。但是不需要单周期响应,因此控制器可以用最小尺寸的电路制成。该电路中的 datapath width 也可以相当窄,因为只需要有限的精度。

如前所述,Brooks 和 Martonosi [4] 指出,对于快速的 DTM 响应,中断的成本太高了。我们采用了他们提出的片上电路建议,直接将任何热应力信号转换为驱动热响应。我们假设它只由一个用于每个数字化传感器读数的比较器组成,如果比较器发现温度超过触发器,则断言一个信号。如果置位了任何触发信号,则使用适当的 DTM 技术。

接下来,我们介绍本文中介绍的新技术,然后是我们评估的其他技术。

温度跟踪频率调节

与动态频率缩放 (DFS) 相比,动态电压缩放 (DVS) 通常是节能的首选,因为 DVS 相对于频率可以节省三次方功率密度。然而,与频率和电压之间的关系无关,载流子迁移率的温度依赖性意味着频率也与工作温度呈线性关系。Garrett 和 Stan [11] 报告了 0-100% 范围内的 18% 变化◦。

这表明,为最大允许工作温度设计标称工作频率的标准做法过于保守。当应用超过温度规格时,它们可以简单地根据温度升高来降低频率。因为在感兴趣的工作区域内,这种温度依赖性是轻微的,所以这样做的性能损失也是轻微的,实际上是可以忽略不计的。

对于设置的每次更改,DVS 方案必须停顿 10-50 μs 以适应时钟锁相环 (PLL) 的重新同步,但如果转换足够平缓,处理器可以在不停顿的情况下执行更改,就像 Xscale 一样 [23]。

我们研究了工作频率每次变化时具有 10 MHz 步长和 10μs 失速时间的离散频率缩放;以及一个理想的版本,它不会引起这种停顿,但频率的变化要经过 10μs 后才会生效。我们称之为“TT-DFS”和“TT-DFS-i(deal)”。较大的步长不会提供足够的适应机会,而较小的步长会产生过多的适应并引发太多的停顿。

这种技术在我们的其他技术中是独一无二的,因为工作温度可以合法地超过其他技术必须保持的 85◦ 阈值。只要在温度上升到可能发生 timing errors 的水平之前调整 frequency ,就不会有违规。

TT-DFS 不需要反馈控制,因为频率只是当前工作温度的线性函数。请注意,与传统 DFS 不同,TT-DFS 不允许在不进一步降低频率的情况下降低电压。

本地反馈控制的 fetch 切换

[26] 中提出的反馈控制获取切换的自然扩展是在成功调节温度的最温和的占空比下切换处理器的各个域:“PILTOG”。仅切换热应力中的单位。通过在 x/y 的某个占空比下切换像整数执行引擎这样的单元,我们的意思是该单元以满负荷运行 x 个周期,然后停顿 y −x 个周期。占空比的选择是一个反馈控制问题,我们使用增益为 3 且设定值为 81.8◦ 的 PI 控制器。

在我们的方案中,我们将处理器分为以下域,每个域都可以独立切换:

  • 获取引擎:I-cache、I-TLB、分支预测和解码。
  • 整数引擎:问题队列、寄存器文件和执行单元。
  • FP 引擎:Issue queue、register file 和 execution units。
  • 加载存储引擎:加载存储排序队列、D-cache、DTLB 和 L2-cache。

请注意,即使关闭域,域之间的解耦缓冲区(如问题队列)仍会消耗一些功率,以允许相邻域继续运行;例如,允许 Data Cache 写回结果,即使 Integer 引擎在该周期中停滞。

迁移计算

两个本身运行很热的单元在相邻时往往会运行得更热。另一方面,将它们分开会引入额外的通信延迟,无论工作温度如何,都会产生这种延迟。这表明使用位于芯片寒冷区域的备用单元,只有当主单元过热时,计算才能迁移到这些区域。

在这里插入图片描述

我们开发了一个新的 floorplan,其中包括整数 register 文件的额外副本,如图 5 所示。当主寄存器文件达到 81.6◦ 时,问题停止,允许完成准备回写的指令,并复制寄存器文件,一次复制四个值。然后所有整数指令都使用 secondary register 文件,允许 primary register 文件冷却,同时计算不受阻碍地继续进行,除了更大的通信距离引起的额外计算延迟。额外的距离是通过为每个 register-file 访问收取两个额外的 cycle 来计算的。(为了在我们的模拟器中简单起见,我们通过简单地将每个功能单元的延迟增加两个周期来近似这一点,即使这会产生悲观的结果。当主寄存器文件返回到 81.5◦ 时,该过程将反转,并使用主寄存器文件恢复计算。我们称此方案为 “MC”。请注意,由于无法保证 MC 会防止热违规,因此需要一种故障安全机制,为此我们使用 PI-LTOG。

同样重要的是要注意,即使不使用任何 DTM 技术,不同的平面图也会对热行为产生一些直接影响。整个整数引擎运行得很热,即使从未使用过备用 register 文件,MC floorplan 也会分散热单元,特别是通过将 load-store queue(通常是第二个或第三个最热的 block)移得更远。

这里的设计空间非常丰富,但我们可以探索的平面图数量有限,因为在不添加空白的情况下开发适合矩形的新平面图是一个费力的过程。最终,我们设想了一种自动化的布局规划算法,它可以使用一些简单的规范格式自动导出布局图。

Lim et al. [16] 提出的双管道方案实际上可以被认为是迁移计算的另一个例子。因为次要的标量管道主要是为了提高能源效率而不是性能而设计的,所以双管道方案在我们研究的任何方案中遇到了最大的减速;结果显示在 [27] 中。MC 也可以被认为是多集群架构的一种有限形式 [7]。

动态电压调节

DVS 长期以来一直被认为是降低能耗的解决方案,最近被提议作为热管理的一种解决方案 [4, 13],并被用于 Transmeta 的 Crusoe 处理器中 [10]。频率必须与电压一起降低,因为当工作电压接近阈值电压时,电路开关会更慢。这种频率的降低会减慢执行时间,尤其是对于受 CPU 限制的应用程序,但 DVS 提供了相对于频率的功率密度的立方降低.

我们模拟了两种场景,我们认为它们代表了不久的将来可能可用的范围。在第一种 (“PIDVS”) 中,有 10 种可能的离散 DVS 设置,范围从标称电压的 100% 到 50% 不等。更改 DVS 设置的代价是 10μs,在此期间,管道会停滞。在第二个 (“PI-DVS-i(deal)”) 中,处理器可以继续执行更改,但更改要经过 10μs 后才会生效,就像 TT-DFS-i 一样。

为了设置电压,我们使用增益为 10 且设定点为 81.8◦ 的 PI 控制器。当控制器接近 DVS 设置之间的边界时,就会出现问题,因为温度的微小波动会导致设置发生太多变化,每次都会产生 10μs 的成本。为了防止这种情况,我们将低通滤波器应用于控制器输出。

全局时钟门控

最后,作为基准,我们认为全局时钟门控(“GCG”)类似于 Pentium 4 采用的 [12],其中当温度超过触发 81.8◦ 时,时钟被门控,当温度回落到该阈值以下时,时钟被非门控。我们还考虑了一个版本,其中时钟门控的占空比由增益为 1 的 PI 控制器 (“PI-GCG”) 确定,类似于 PI-LTOG 的控制方式。我们认识到,在精细占空比下门控整个芯片的 clock 可能会导致电压稳定性问题,但对于这个实验来说没有意义。我们只试图确定 PI-GCG 是否能胜过 PI-LTOG,并发现它不能,因为它在 PI-LTOG 利用 ILP 时减慢了整个芯片的速度。

我们还评估了 fetch 切换 [4],以及一个反馈控制版本,其中 fetch 而不是 clock 被门控,直到温度达到足够的水平。总的来说,fetch 切换和全局 clock gating 非常相似。我们对 global clock gating 进行建模,因为它也会削减 clock tree 中的功率并具有立竿见影的效果。我们只报告全局时钟门控的结果,因为 GCG 的性能略优于普通的 fetch 切换,而 PI-GCG 的性能略优于 PI 版本的 fetch 切换。参见 [27]。

传感器

运行时热管理需要实时温度感应。到目前为止,我们所知道的所有先前发表的工作都假设了全知传感器,我们在第 6 节中展示了这可能会产生过于乐观的结果。可用于我们考虑的局部热响应类型的芯片传感器通常基于使用电流参考的模拟 CMOS 电路。一个很好的参考是 [1]。输出电流使用环形振荡器或一些其他类型的延迟元件进行数字化,以产生可以馈送到计数器的方波。尽管这些电路在目标温度范围内产生良好的线性输出,并且对温度变化做出快速响应,但遗憾的是,它们对光刻变化和电源电流变化很敏感。通过扩大传感器电路,可以减少这些不精确性来源,但代价是增加面积和功率。另一个不容易通过扩大大小来解决的限制是传感器带宽,即传感器的最大采样率。

我们的行业联系人告诉我们,CMOS 传感器在中等数量(例如 10-20 个传感器的精度最多为 ±2◦C,采样率为 10 微秒)中使用是合理的。这与 [1] 中的结果相匹配。我们为每个架构块放置一个传感器。

我们通过在指定范围 ±2◦ 上随机化真实温度读数来模拟不精确性。我们假设硬件在运行时通过使用最近 10 次测量的移动平均值来降低传感器噪声,因为平均可以减少作为样本数平方根的误差。当然,这假设测量值是平稳的,这对于任何有意义的平均窗口来说都不是正确的。这意味着我们还必须考虑这种变化,如果温度每 30μs 可以上升 0.1◦,则可能高达 0.4◦。因此,对于 ±2◦,我们能够将不确定性降低到 S = 2 10 \frac{2}{\sqrt{10}} 10 2 + 0.4 = ±1◦。选择包含 10 个样本的平均窗口,因为较大窗口的改进误差减少被基础值的较大变化所抵消。

在对传感器进行建模时,还必须考虑一个额外的非理想性,并且不能通过平均来减少。如果传感器无法与每个可能的热点完全重合,则传感器观测到的温度可能比热点处的温度低一些空间梯度因子 G。如果除了上面讨论的随机误差外,传感器中还存在无法消除的系统误差或偏移误差,则会增加固定误差 G 的大小。根据有限元模型中的模拟以及传感器可以位于热点附近但不完全重合的假设,我们选择 G = 2◦。

因此可以看出,对于任何运行时热管理技术,使用传感器都会将紧急阈值降低 G + S(在本例中为 3◦)。与更激进和昂贵的包装选择相比,必须考虑这一点。这也是寻找避免这种开销的温度传感技术的巨大动力,也许是基于传感器之间巧妙的数据融合。性能计数器。

仿真设置

集成热模型

HotSpot 完全独立于电源/性能模拟器的选择。将 HotSpot 添加到功耗/性能模型仅包括两个步骤。首先,必须将初始化信息传递给 HotSpot。这包括一个描述平面图的邻接矩阵和一个给出每个架构模块的初始温度的数组。然后在运行时,每个模块中的功耗在用户指定的时间间隔内取平均值,并传递给 HotSpot 的 RC 求解器,后者返回新计算的温度。

尽管每个周期都重新计算温度是可行的,但这是浪费,因为即使在建筑单元的精细粒度下,温度也至少需要 100K 个周期才能上升 0.1◦C。我们选择了 10K cycles 的采样率作为精度和开销之间的最佳权衡。

Power-Performance 仿真器

我们使用基于 Alpha 21364 [2] 的功耗数据的功耗模型。21364 由一个与 21264 相同的处理器内核组成,具有较大的 L2 缓存和(未建模的)无胶多处理器逻辑。图 4 显示了芯片的图像,以及显示 HotSpot 建模的单元和邻接关系的平面图。因为我们研究微架构技术,所以我们使用 Wattch 版本 1.02 [5] 来提供一个框架,用于将我们的功耗数据与底层的 SimpleScalar [6] 架构模型集成。我们的功率数据是 1.6 V、1 GHz 和 0.18μ 工艺,因此我们使用 Wattch 的线性缩放来获得 0.13μ、Vdd=1.3V 和 3 GHz 时钟速度的功率。我们假设芯片厚度为 0.5mm。我们的吊具和水槽都是由铜制成的。吊具厚 1 毫米,× 3 厘米,水槽的底座厚 7 毫米,× 6 厘米。

使用 SimpleScalar 的最大困难是底层的 sim-outorder 微架构模型不再能很好地代表当代处理器,因此我们对其进行了增强,以尽可能接近地对 Alpha 21364 进行建模。我们扩展了微架构和相应的 Wattch 电源接口;扩展管道并将集中式 RUU 分解为四宽整数和双宽浮点问题队列、80 项整数和浮点合并物理/架构寄存器文件以及 80 项活动列表。一级缓存为 64 KB,2 路,回写,具有 64B 行和 2 周期延迟;二级为 4 MB,8 路,具有 128B 行和 12 周期延迟;主内存具有 225 个周期的延迟。分支预测因子类似于 21364 的混合预测因子。我们没有建模的 21364 的唯一功能是整数框的 register-cluster 方面、I-cache 中的路径预测以及重放陷阱的推测性负载使用问题(这可能会增加已经很热的 blocks 中的功率密度)。最后,我们增强了 SimpleScalar/Wattch 以考虑动态频率和电压缩放,并以秒为单位报告执行时间,而不是以周期为单位作为性能指标。

由于泄漏功率是温度的指数函数,因此这些功率贡献可能大到足以影响温度分布和不同 DTM 技术的有效性。此外,无论活性如何,都存在泄漏,并且在较高温度下的泄漏可能会影响仅降低活性速率的热管理技术的有效性。最终,我们计划将 HotSpot 与我们的温度/电压感知泄漏模型 [30] 相结合,以更精确地跟踪动态泄漏-温度相互作用,我们认为这是未来工作的一个有趣领域。目前,为了确保以合理的方式对泄漏效应进行建模,我们使用了一个更简单的模型:与 Wattch 一样,每个单元中的泄漏被简单地视为其激活时功率的百分比,但现在这个百分比是根据温度和技术节点使用 ITRS 数据中的数据确定的 [25]。

Benchmarks

我们使用 SPEC CPU2000 套件中的基准来评估我们的结果。基准测试使用具有 SPEC 峰值设置的 Compaq Alpha 编译器为 Alpha 指令集进行编译和静态链接,并包括所有链接的库。对于每个程序,我们快进到 5 亿条指令的单个代表性样本。该样本的位置是使用Sherwood等[24]提供的数据选择的。仿真使用 SimpleScalar 的 EIO 跟踪进行,以确保在多个模拟中每个基准测试的结果可重现。由于本研究需要大量的模拟,而且许多模拟的运行温度不够高,因此我们只使用了总共 26 个 SPEC2k 基准测试中的 11 个。选择了具有低、中等和极端热需求的整数和浮点程序的混合;我们省略的所有这些函数都远低于 81.8◦ 触发阈值。表 2 列出了我们研究的基准测试及其基本性能、功耗和热特性。可以看出,IPC 和峰值工作温度与平均功耗仅松散相关。对于大多数 SPEC 基准测试以及表 2 中的所有基准测试,最热门的单元是整数寄存器文件——有趣的是,对于大多数基准测试也是如此,包括浮点和内存绑定基准测试也是如此。目前尚不清楚这对其他基准测试集有多真实。
在这里插入图片描述

封装、预热和初始温度

在相对较短的时间尺度上,对流阻力和散热器启动温度的正确选择是热行为的两个最重要的决定因素,而使用 SimpleScalar 可以方便地进行仿真。

为了获得研究动态热管理的有用基准行为范围,我们手动设置了对流阻力。我们凭经验确定了 0.8 K/W 的值,它产生了最有趣的行为组合。这是一个中等成本的散热器,与没有 DTM 所需的 0.7 K/W 对流电阻相比,节省的费用可能不到 10 美元 [29]。更大的电阻,例如 0.85 K/W,可以节省更多的钱,但最高温度更高,热行为的种类更少,所有基准都是热的或冷的。较小的电阻节省的钱更少,并且使最高温度太接近 85◦,因此本研究没有兴趣。

在仿真开始时设置的初始温度在热行为中也起着重要作用。最重要的温度是散热器的温度。它的时间常数大约是几分钟,因此在我们的模拟中,它的温度几乎没有变化,当然也不会达到稳态。这意味着仿真必须从正确的散热器温度开始,否则会出现巨大的错误。对于使用 DTM 的实验(TTDFS 除外),散热器温度应设置为与最大容忍芯片温度相称的值(使用我们的传感器架构为 81.8◦):DTM 响应确保芯片温度永远不会超过此阈值,并且散热器温度相应地低于没有 DTM 的温度。如果错误地使用了更热的无 DTM 散热器温度,则在高达 10 亿次循环的模拟中,观察到高达 4.5 倍的急剧减速,而使用正确的 DTM 散热器温度时,最大减速约为 1.5 倍。表 2 中显示了两个散热器温度之间的差异。我们所有的模拟都使用此表中的相应值。

我们没有考虑的另一个因素是多编程行为。在散热器冷却时开始执行的 “热” 应用程序在其时间片到期之前可能不会产生热应力。Rohou 和 Smith [20] 用它来指导处理器调度并降低最高工作温度。

在合理长度的仿真中,其他结构将达到正确的工作温度,但所有结构的正确起始温度可确保仿真不受此类瞬态伪影的影响。这意味着,在加载 SimpleScalarEIO 检查点,则需要预热大型结构(如缓存和分支预测器)的状态,然后真正预热 HotSpot。当我们开始仿真时,我们首先以全细节周期精确模式(但没有统计数据收集)运行仿真 1 亿个周期,以训练缓存(包括 L2 缓存)和分支预测器。当微架构处于代表性状态时,我们处理温度。这两个问题必须按顺序处理,否则冷启动缓存效应会使处理器空闲并影响温度。为了预热温度,我们首先将 blocks 的初始温度设置为我们使用每个基准测试的每个 block 平均功耗计算的稳态温度。这加速了热预热,但仍然需要一个动态预热阶段,因为我们所在的样品可能不会在所有单位中表现出平均行为。因此,我们允许模拟在全细节周期精确模式下继续再进行 2 亿次循环,以使温度达到真正具有代表性的值。只有在这两个预热阶段完成后,我们才会开始跟踪任何实验统计数据。

DTM 的结果

在本节中,我们使用 HotSpot 热模型来评估第 4 节中描述的各种技术的性能。首先,我们假设真实的、嘈杂的传感器,然后考虑噪声对 DTM 性能的降低程度。

存在传感器噪声的结果

在这里插入图片描述

图 6 显示了每种热管理技术的“热”和“暖”基准的减速(热管理执行时间)/(原始执行时间)。条形图是主要焦点:它们为每种技术的更好版本提供结果:TT-DFS 和 PI-DVS 的“理想”版本、GCG 的 PI 控制器版本、PI 本地切换和 MC。这些线给出了某些技术的较弱版本的结果:TT-DFS 和 PIDVS,带有用于更改设置的失速,以及没有控制器的 GCG(即,全有或全无)。这些技术都不会引起热违规。仅显示热基准测试和暖基准测试;这两个 cold benchmark 不受 DTM 的影响,只是它们在使用 TT-DFS-i 时获得了 1% 的加速,在 TT-DFS 上获得了 1% 的减速。我们还尝试了一些其他的冷基准测试,但观察到 TT-DFS-i 的加速最小,而 TT-DFS 的加速经常变慢。

到目前为止,最好的热管理技术是 TT-DFS,TT-DFS-i 版本略好一些。即使是最热门的基准测试,性能损失也很小;最差的是 ART,TT-DFS-i 仅减慢了 2%,TT-DFS 放缓了 3%。如果 85◦ 的最高结温严格基于时序考虑,并且可以容忍略高的温度而不会过度缩短工作寿命,那么 TT-DFS 则非常出色,因为它的影响非常温和。

当低于触发阈值时,增加频率似乎应该对 TT-DFS 有一些好处,但我们没有观察到任何值得注意的加速。要使更高的频率提供显著的加速,应用程序必须受 CPU 限制,但那样它就会很热,并且频率不能提高。

如果 85◦ 的结温不仅由时序决定,还由物理可靠性决定,那么 TT-DFS 不是一种可行的方法。在其余技术中,MC 和 PI-LTOG 是最好的。除了 gcc、crafty 和 perlbmk 这三种应用程序外,MC 在所有应用程序中都优于 PI-LTOG,MC 的平均速度减慢为 7%,而 PI-LTOG 的平均速度减慢为 8%。当然,如果与备用寄存器文件的额外通信延迟较小,MC 的性能会更好:如果该损失是一个周期而不是两个周期,则 MC 的平均减速为 5%。需要注意的是,仅靠 MC 并不能防止所有热违规;我们的 MC 技术花费了 20-37% 的时间使用回退技术 PI-LTOG。这意味着回退技术的选择对性能很重要。例如,如果我们使用 DVS 或 GCG 作为后备,结果会差得多。

迁移计算和局部切换的性能优于全局切换和 DVS,即使 DVS 的功率密度相对于频率的降低而言减少了三次方。原因主要是 GCG 和 DVS 减慢了整个芯片的速度,尽管非理想的 DVS 也受到与更改设置相关的停顿的很大影响。相比之下,MC 和 PI-LTOG 能够利用 ILP。

一个非常有趣的观察结果是,使用 MC,两个基准测试 gzip 和 mesa,从不使用备用单元并且不会减速,而 vortex 很少使用它,几乎没有减速。新的平面图本身就足以减少整数引擎中各种热单元之间的热耦合,从而防止许多热违规。

尽管我们无法探索更多种类的平面图,但这些基于平面图的技术的成功表明了一种有吸引力的热量管理方法。一旦考虑了替代的平面图和额外的计算单元,微架构集群 [7] 的性能和温度的相互作用就成为一个值得进一步研究的有趣领域。这些结果还表明,未来工作的一个有利方向是在设计平面图时重新考虑延迟和热量之间的权衡,并且正如 Huang 等人 [13] 所建议的那样,从温和到严格的技术层次结构最有可能给出最佳结果。热管理方案可能基于 TT-DFS,直到温度达到危险阈值,然后进行某种形式的迁移,最后回退到 DVS。

传感器误差的影响

传感器噪声以两种方式造成伤害;当温度实际上没有接近违规时,它会生成 spurious trigger,并强制降低触发阈值。两者都会降低性能。图 7 显示了这两种影响对 PI-GCG 和 PI-DVS 技术的影响。每个条形的底部显示仅将触发器减少一度后的减速,顶部显示引入传感器噪声 ±1◦ 的后续减速。
在这里插入图片描述

对于暖基准和热基准,这两种影响的影响非常相似。将触发阈值从 82.8◦ 降低(如果不存在噪声则合适)可将 PI-GCG 和 PI-DVS 的性能降低 1-4%。杂散触发器进一步降低了 PI-GCG 的性能 3-6%,PI-DVS 的性能降低了 6-9%,PI-DVS 例外,为 13%。与 GCG 相比,噪声对 DVS 的影响更大,这是因为每次调用杂散触发器时都会出现高昂的停顿成本。

传感器误差显然对热管理的有效性有重大影响。这些结果仅考虑了传感器噪声的影响,即第 4.2 节中讨论的“S”因子;在没有传感器噪声和更高的触发因素的情况下,PI-GCG 在热门基准测试中的减速从 11.6% 降至 3.6%,PI-DVS 的减速从 17.4% 降至 5.2%。减少由于制造变化和传感器放置而导致的传感器偏移(“G”因子)将提供实质性的进一步改进。

总的来说,我们的结果不仅表明了在热研究中对温度建模的重要性,还表明了对真实传感器行为进行建模的重要性。

结论和未来工作

本文介绍了 HotSpot,这是一种实用且计算高效的方法,用于在架构级功耗/性能仿真器中对热行为进行建模。我们的技术基于一个简单的热阻和电容网络,这些网络被组合在一起,以考虑由于功率耗散、相邻模块之间的热流以及流入热封装的热流而导致的模块发热。该模型已使用 Floworks(一种用于热和流体流动的商用模拟器)进行了有限元仿真的验证。HotSpot 在 http://lava.cs.virginia.edu/hotspot 上公开提供。

使用 HotSpot,我们可以确定哪些是最热门的微架构单元;了解不同热封装对架构、性能和温度的作用;了解程序的热行为;并评估一些调节片上温度的技术。当最高工作温度由时序而不是物理可靠性问题决定时,“温度跟踪”频率缩放会在超过触发温度时降低频率,平均减速仅为 2%,如果处理器在频率变化期间不需要失速,则仅减慢 1%。当物理可靠性问题要求温度永远不超过规格时(在我们的研究中为 85◦),我们发现的最佳解决方案是反馈控制的局部切换方案(速度减慢 8%),或使用备用整数寄存器文件的计算迁移方案(速度减慢 5-7%,具体取决于对备用寄存器文件的访问时间)。

这些方案的性能甚至优于全局时钟门控或理想的反馈控制版本的 DVS,后者更改设置时不会发生停顿,因为本地化切换利用了指令级并行性,而 GCG 和 DVS 会减慢整个处理器的速度。

所有这些方案的性能损失很大一部分是由于传感器错误造成的,它不必要地调用了热管理。即使只有 ±1◦ 的余量,传感器误差也会导致 6-13% 的减速,几乎占我们观察到的总性能损失的 75%。

我们认为,这些结果有力地证明了运行时热量管理是管理处理器不断增长的散热的有效工具,并且微架构 DTM 技术必须成为任何温度感知系统的一部分。但为了获得可靠的结果,建筑热研究必须根据温度评估其技术,并且必须包括传感器噪声的影响。

我们希望本文能够传达对架构层面的热效应以及微架构、功耗、传感器精度、温度和性能之间相互作用的整体理解。本文仅触及了我们认为未来工作的丰富领域的表面。RC 模型可以通过多种方式进行改进;它还可以扩展到 Multiprocessor、ChipMultiprocessor 和同步多线程系统;许多新的工作负载和 DTM 技术仍有待探索;需要更好地了解程序的执行特性和微架构行为如何决定其热行为;需要用于传感器读数的智能数据融合技术,以实现更精确的温度测量并减少传感器引起的性能损失。另一个重要问题是了解有功功率、漏功率、电流变化和热效应的动态管理技术之间的相互作用,它们共同构成了一个丰富但知之甚少的设计空间,其中相同的技术可能用于多种用途,但设置不同。最后,热邻接被证明很重要,这使得温度感知型布局规划成为一个重要的研究领域。

致谢

这项工作部分由美国国家科学基金会 (National Science Foundation) 资助号支持。CCR-0133634 和 MIP-9703440,英特尔 MRL 的资助,以及弗吉尼亚大学卓越科学技术基金的卓越奖。我们还要感谢 Peter Bannon、Howard Davidson、Antonio Gonz ́alez、Jose Gonz ́alez Gonz ́alez、Margaret Martonosi 和匿名审阅者提供的有益评论。

原文:Temperature-Aware Microarchitecture

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值