复杂 SoC 的准确高效功率估算流程

文摘   2024-11-09 06:00   上海  
摘要:
下一代 SoC 设计有望同时提供最高性能和最低功耗。必须满足设备不同操作模式下的严格功率目标,因此需要设计非常准确的功率估算技术。本文讨论了针对不断缩小的设计技术的下一代数百万门设计的早期和准确功率估算技术。本文还讨论了从硅片前阶段(理论功率估算、基于 VCD 的估算)到硅片后平台(模拟验证、测试仪)关联功率数字的挑战。

简介:
在当今世界,随着对低功耗可重构 SoC 设计的需求不断增加,能耗最近已成为系统性能的重要因素。我们估计 SoC 平台的整体功耗,包括处理器、片上总线和外设。
SoC 功率估算通过静态/平均功率和动态 IR 压降功率分析完成。初始功耗估算是使用基于核心、外设和内存组件活动因子的理论分析完成的。验证团队运行用例以同时刺激最大可能的设计组件,并以值变化转储 (VCD) 或切换计数格式 (TCF) 的形式向功率估算团队提供最大活动窗口以确定功率数字。功率分析工具无法处理较大的转储/VCD 大小(例如超过 100GB)。我们越来越需要使用仿真平台进行功率分析,以模拟无法在软件模拟中运行的长期运行用例。
SoC 技术的特点是使用的“特征尺寸”。特征尺寸如 90nm、55nm 或 28nm。特征尺寸决定了导线或晶体管的最小尺寸。因此,对于给定尺寸的芯片,晶体管的密度可以大幅增加。然而,随着特征尺寸的减小,使用的电压也必须降低。这似乎可以降低功耗,但晶体管的数量呈指数级增长,时钟频率也在增加,必须更频繁地切换更多晶体管,从而导致功耗净增加。在设计过程中,必须在每个设计步骤中估算功率,以满足设计的每个部分以及整个设计的约束。

为什么 SoC 中需要功率估算:
需要功率估算来确定设备是否符合目标功率数规范。在当今世界,电子设备具有高晶体管密度。因此,这些元件之间需要更多的互连。这些互连的功耗保持在一定水平,因为它们不能做得更小,而且需要彼此靠近。与总能量耗散相比,互连中消耗的功率份额增加了。
这一趋势的主要后果是增加了冷却电路,缩短了系统的电池寿命。也就是说,功率估算也有助于避免与冷却和可靠性有关的问题。市场力量要求低功耗,不仅是为了延长使用寿命,也是为了可靠性、便携性、性能、成本和上市时间。

SoC 中准确高效功率估算的挑战:
在当今十亿门 SoC 芯片设计中,运行时和生成的波形数据库大小是准确功率估算的挑战性问题
  • 为了生成适合 SoC 的输入序列以同时触发硬件和软件,我们需要抽象架构设计的系统表示。对于功率估算,可以使用一个输入序列来激活设计的所有功能,以最大化其消耗的功率。
  • 需要模拟来分析功率。然而,对于十亿门 SoC,模拟运行时间对于合理的设计周期来说太长了。
  • 模拟生成的模拟波形可能占用数百 GB 以上,这给功率分析工具带来了巨大的负担。如此大的模拟转储会导致功率分析工具的性能和内存严重下降,使用如此大的转储文件执行功率分析是不切实际的。
  • 通常,VCD(值更改转储)文件在总模拟持续时间方面可能非常大。虽然静态功率计算可以处理这种完整的 VCD 文件并得出平均活动以计算静态功率,但由于性能和资源限制,在完整的 VCD 上运行动态模拟是不现实的。因此,建议您预先确定耗电周期或具有高开关活动的周期,以执行动态功率计算。

通常,验证和设计团队之间会进行 VCD 生成和该 VCD 上的功率分析迭代。

为什么 SoC 的 RTL 和 GATE(GLS) 级需要功率估算:
功率分析在 RTL 和门级进行。这是优化设计和功率分析所必需的。
在 RTL 级,当为用例场景转储模拟数据时,模拟器或仿真器的运行时间和内存使用量会减少。它还显著减少了模拟转储的大小。
此流程还有助于减少功率分析中的运行时间和内存使用量。如果 RTL 模拟转储中任何信号/模块的功率出现意外(不符合规格),则在此阶段很容易改进设计和功率。
RTL 功率估算的缺点是,与实际硅片功率有 15-20% 的偏差,因此我们需要门级功率分析,其中与实际硅片功率的偏差为 10%。
GLS 功率分析的缺点是,GLS 的模拟运行时间很长,转储大小和内存大小也会增加。大型转储大小 (VCD) 很难通过电源工具处理。此外,如果 GLS 模拟转储中的任何信号/模块出现意外功率(不符合规格),那么与 RTL 级别相比,在此阶段很难改进设计和功率。

功率分析:
SoC 设计的功耗可以用以下公式描述:
Pavg =P 动态 + P 短路 + P 漏电 + P 静态
图 1:晶体管级的不同功率。
Pavg 是平均功耗。
P dynamic 是由于晶体管切换而产生的动态功耗,动态功耗是由充电引起的。
P short-circuit 是从电源到地存在直流电流路径时的短路电流功耗。
P leak 是由于漏电流引起的功耗。
P static 是静态功耗。静态功率是栅极未切换时(即处于非活动或静态状态时)的功耗。
在 SoC 中,我们专注于估算数字电路的动态和静态功耗,因为这与芯片发热和电池寿命直接相关。

功率分析过程:
图 2:RTL 和门级功率估算流程
SoC 功率估算的一般趋势是验证团队运行用例场景以生成转储/VCD,功率分析团队使用此转储/VCD 进行功率分析。在此过程中,团队(验证团队和功率分析团队)之间会进行迭代以获得最大切换转储/VCD。
SoC 功率估算是通过静态/平均功率和动态 IR 降功率分析完成的。
  • 平均功率:平均功率是根据其工作模式(例如运行模式、停止模式)等在一段时间内消耗的功率。
  • 动态 IR 降:这是实际的瞬时峰值功率,而不是平均功率。

平均功率分析:
对于十亿门 SoC,由于 VCD 尺寸较大,因此会为整个模拟运行生成切换计数格式 (TCF),而不是为平均功率分析生成 VCD。TCF 是从获取第一个复位向量到模拟结束之间生成的,然后针对该 TCF 进行功率计算。
使用上述 (TCF) 平均功率分析过程,我们可以非常高效地获得平均功率数据,并且比传统功率分析过程更快。

动态 IR 降分析:
动态功率是由于晶体管切换而产生的动态功率耗散,动态功率耗散是由瞬间充电引起的。
对于动态 IR 降,上述流程不起作用,因为切换信息不足,而是需要实际切换(读为 1 或 0)才能获得该时刻的实际功率。
对于动态 IR 降,整个模拟都会生成不同的 TCF(大约每 2000 个周期)。然后电动工具处理这些数量的 TCF。所有这些 TCF 仅在一次模拟运行中生成,占用的时间和内存更少。
因此,在处理这些 TCF 之后,就可以找到发生最大活动的确切时间。对于此最大活动窗口(由 TCF 处理发现),将生成 VCD /FSDB,从而提供准确的 IR 压降。
应首先运行静态功率分析,并在运行动态分析之前解决所有静态问题。

应对 SoC 功率分析期间挑战的战略方法:
在 RTL/Gate 级别:在为功率分析生成 vcd 期间,转储大小变得非常大(超过 ~100GB),导致工具频繁崩溃(由于内存使用量大)。大多数行业标准功率分析工具支持高达 100GB 的转储大小。它使功率分析过程更加耗时,并且需要多次迭代。
解决方案:
  • 我们可以将 VCD 分解为小的 vcd 切片(VCD 分段)并提供给电源团队。电源团队可以有效地使用这些 VCD 切片,而工具崩溃的情况非常罕见。
  • 为了计算平均功率,选择如上所述的 TCF 方法。
  • 为了最小化门模拟中的转储大小,我们可以生成 FSDB 转储。
  • 如果您的 SOC 验证环境具有模拟行为模型,那么在 VCD 转换期间,vcd 可能包含实际值 ($VAR_REAL、$READY、$DRIVE、-b、-、r# 等),这也可能导致功率分析工具崩溃,那么我们需要在将 VCD 交付给功率团队之前对 VCD 进行后处理。

总结:
SoC 的精确功率分析具有以下流程:
  • 从 RTL/GLS 仿真生成 VCD。
  • 功率分析工具将处理提供的 VCD/FSDB/TCF。
  • 处理 VCD/FSDB/TCF 后,我们从功率分析工具中获得功率数字。
  • 后来,我们也分享了来自测试团队 (硅片) 的功率数字。
  • 比较两个功率数字 (来自 GLS 流程和测试仪的功率)
  • 现在根据规范比较来自预期/应用功率的功率。

因此,在 SoC 系统中,功率是从门和测试团队 (硅片) 计算出来的,然后进行比较以获得优化的功率分析。

结论和未来工作:
使用不同的功率估算工具对从 RTL 级到门级的不同电路进行了功率估算。
但是,这些结果在降低功率模型复杂性和广泛输入信号分布的可行性方面仍然非常令人印象深刻。较低的复杂性还可以充分减少特性时间和估算时间。从这些不同抽象级别的功率估算中可以得出结论,RTL 上的不准确值与晶体管级别的不准确值相比如何。
如果在 RTL 级别有更多准确和有效的功率估算方法,那将是最大的成就,因为从这个阶段改进设计更加可行。这将避免在获得硅片后突然对功率数字感到吃惊的功率估算挑战。

References:

V. Tiwari, S. Malik and A. Wolfe, “Instruction Level Power Analysis and Optimization of

C. Talarico, J.W. Rozenblit, V. Malhotra, A. Stritter, “A new framework for power estimation of embedded systems”

R.A. Bergamaschi, Y.W. Jiang, “State–Based Power Analysis for Systems–on–Chip”, DAC2003, June 2–6, 2003, Anaheim, California, USA, pp 638–641

软硬件协同设计 HW-SW Co-Design
欢迎后台留言,AI 客服全天在线。脱离物理硬件,开发测试和调试软件。基于虚拟原型的软硬件协同设计,提前一年实现产品上市创收,降低一半开发时间。
 最新文章