如何在系统层面优化功耗

文摘 2024-11-24 07:02 上海

作者：BRIAN BAILEY

翻译：Brian

校对：Mike

原文：https://semiengineering.com/optimizing-energy-at-the-system-level/

在实施过程中，人们投入了大量精力来优化硬件，但这只是整个机会的一小部分。

Power 是一个普遍关注的问题，如果不考虑整个系统，就不可能优化系统的能耗。在优化硬件实施方面已经取得了巨大进步，但这已经不够了。整个系统必须进行优化。

这具有深远的影响，其中一些正在推动特定领域计算的发展。左移发挥着作用，但更重要的是，它意味着在特定任务的总能耗中发挥作用的所有各方必须共同努力才能实现这一目标。

Power 正迅速成为首要考虑因素。“随着能源效率成为所有计算领域的关键问题，架构师经常被要求考虑硬件和软件设计算法的能源成本，”Arteris 产品管理和战略营销高级总监 Guillaume Boillet 说。 “重点从单纯优化计算效率（速度、吞吐量、延迟）转向优化能源效率（每操作焦耳）。这需要考虑诸多因素，例如内存访问次数、计算的可并行性以及专用硬件加速器的利用率，这些加速器可能为某些任务提供更节能的计算。”

这将重点从硬件实现转移到硬件和软件的架构分析。“在设计流程的后期阶段，优化的机会减少了，”Synopsys EDA 集团产品管理总监 William Ruby 说道。“您可能有更多的自动优化机会，但改进百分比会更小。当考虑潜在节省的曲线时（见图 1），从架构到签核并不是一条平滑的曲线。综合时有一个拐点。在将设计映射到实现之前，您拥有更多的自由度，但在此拐点之后，事情会急剧下降。”

图 1：设计阶段的节能机会。

最大的障碍是，在拐点之前，功率变得依赖于活动，这使得自动优化变得更加困难。“在 RTL 开发期间，可以使用动态矢量驱动检查来发现浪费并执行逻辑重构、时钟门控、运算符门控和其他技术来减少浪费，”西门子 EDA 首席产品经理 Qazi Ahmed 说。“同样重要的是要了解功率是用例敏感的，必须使用实际的软件驱动工作负载进行分析，以确保涵盖所有可能的场景。这在整个 SoC 的背景下尤其如此，其中功率范围可能与 IP 级别的合成矢量驱动分析所显示的完全不同。”

“将需要更多的前期规划、分析和优化，” MachineWare CTO Jan 说。

Jan 指出了需要解决的各个层面：

在宏观架构层面，进行大额权衡分析和专用处理元素的选择；
在微架构层面，针对目标应用优化指令集和执行单元；
在算法层面，选择和优化算法以提高计算效率和内存访问；
在软件层面，向开发人员提供反馈，帮助他们优化软件的功耗和能耗。

“这将需要用于虚拟原型设计和软件开发的功耗和能耗感知工具来生成数据，从而优化硬件和软件实现，”他指出。

软件映射

决定软件中应该包含哪些内容是一项早期任务。“我想用 DSP 内核来卸载 CPU 吗？”Synopsys 的 Ruby 问道。“这会对我的功耗产生什么影响？我想实现硬件加速器，还是想在软件中执行所有这些功能？在 CPU 上运行的软件的能耗成本不为零。”

随着系统越来越多地由软件定义，能源问题也必须从这里开始考虑。“软件是节能和提高性能的关键要素，”Arm 高级首席 CPU 架构师 Vincent Risson 表示。“计算密集型应用程序通常会从应用程序优化中受益匪浅。这既可以是高度调整的静态库，也可以是允许计算针对最佳处理引擎的动态框架。例如，移动设备已在 CPU 系统架构上进行了标准化，该架构为应用程序处理器提供了不同的计算性能，同时符合通用的 ISA 和配置。这允许应用程序动态迁移到效率最佳的处理器。软件和异构硬件的结合提供的自省和多功能性机制将为未来提高效率提供机会。”

软件可以运行的处理器通常不止一类。“我们可以根据看到的工作负载类型选择给定应用程序应该在哪里运行，”英特尔客户 SoC 架构研究员兼设计工程组首席技术官 Jeff Wilcox 表示。 “如果超出了较小核心的需求，则可以启动更大的核心。有遥测和工作负载特性来尝试找出应该在哪里运行才能最节能。我们现在看到的许多工作负载都是不同的。即使是处理相同工作负载的对称代理，它们之间也有依赖关系。越来越多的工作负载需要非对称代理，我们有 GPU、NPU、IPU 可用，这些类型的工作负载与 CPU 协作。这是一个更难优化的事情。我们已经到了能够理解性能和功耗挑战的地步，但我们仍在构建工具来真正了解如何完全消化和优化它。”

这里的困难在于工作负载的架构可能取决于硬件的架构。 Untether AI 硬件副总裁 Renxin Xia 表示：“AI 领域有许多发展，重要的不仅仅是模型的大小。同样重要的是模型的构建方式，以及它们是否以节能的方式构建。这个问题很难回答，因为它依赖于架构。在 GPU 上运行的算法的能源成本可能与在计算架构的内存上运行的算法的能源成本大不相同。”

专注于软件

普遍的共识是，如果没有更多的硬件和软件合作，这一切都不可能实现。英特尔数据中心部门高级研究员 Sailesh Kottapalli 表示：“需要硬件和软件共同开发才能获得这些阶跃函数改进。仅仅试图在硬件中透明地做到这一点已经达到了极限。看看 AI 领域正在发生的事情。如果硬件是唯一的元素，我们就不会看到我们现在看到的巨大进步。其中很多是算法改进。对于软件算法，如果缩短路径长度，就可以用更少的指令和更少的软件工作量实现相同的结果。有时，当你弄清楚这一点时，我们可以发现对于这些算法，有一个新的最佳指令集、一个新的微架构，然后你可以在硬件中进一步优化它。”

这需要对软件开发流程进行重大变革。“过去，架构和软件流程针对生产力进行了优化，这意味着通用处理器使用高级语言进行编程，使用最快、最便宜的软件工具，”MachineWare 的 Jan 说。“总体方向是提供尽可能多的灵活性和生产力，并只在绝对必要的情况下进行优化。这需要转变为只提供所需的灵活性，否则使用专用实现。”

对于许多软件功能而言，内存访问是最大的功耗。“软件功能可以以不同的方式实现，这会导致具有不同功率和能量分布的不同指令流，”Synopsys 的 Ruby 说。“您需要加权或为内存访问指令分配更高的成本。您需要小心建模。即使只是 CPU，您也需要在系统环境中模拟能量成本。”

将来，结果准确性也可能是有助于优化的一个因素。 “通过优化软件以更好地利用可用的硬件资源，可以实现大幅节能，”Arteris 的 Boillet 说道。“这包括编译器优化、代码重构以降低计算复杂度，以及专门设计用于节能的算法。对于可以容忍一定程度的不精确性的应用程序，如多媒体处理、机器学习和传感器数据分析，后者可以通过近似计算实现。”

分析

一切都从分析开始。“我们可以创建系统的虚拟模型，”Jan 说道。“然后我们可以定义用例，在这种情况下，用例实际上是设计的一系列操作模式。这还不是软件。您可以将系统描述为模型集合，包括性能模型和功率模型。它会根据这些模型和您定义的用例为您提供功率配置文件。下一个替代方案是类似类型的虚拟系统描述。现在，您可以针对此运行实际的软件工作负载。如果你进一步深入研究，如果你想要更多的可视性和更精细的细节，你可以采用设计的 RTL 描述，也许它还没有最终确定，也许还为时过早，但只要它大部分还在波动，你就可以把它放在模拟器上并运行实际工作。一旦你这样做了，模拟器就会生成一个活动数据库。面向仿真的功率分析功能可以获取大量数据、数亿个时钟周期的工作负载数据并生成功率配置文件。可以做的事情有很多。”

在某些情况下，这个时间跨度可能不够长。“我们的大多数热分析都是基于闭环分析，建立在硅片数据上，而不是基于硅片前模拟，因为需要走线长度和分析所需的时间，”英特尔的 Kottapalli 说。“我们不可能模拟那么长时间，从而建立一个真实的热配置文件。我们使用来自硅片的配置文件数据，使用不同类型的工作负载和轨迹，然后分析需要构建哪些解决方案。”

时间框架越短，事情就越容易。“需要考虑某种功率视图来制定基本架构决策，”Ruby 说。“您需要一个更高级别、更抽象的模型来描述系统的所有部分，包括所有处理核心和内存子系统，因为如何组织这些部分真的非常重要。真正需要多少内存？这些都是基本的架构决策。您需要掌握一些与这些组件相关的功率数据。在这种特定工作负载或那种特定工作负载下，CPU 消耗了多少功率？DSP 核心、硬件、内存、芯片上的网络呢？在执行每个操作时，它们各自消耗了多少功率？这些都是制定基本架构决策所必需的。”

需要许多新的与功率相关的工具。“虽然存在用于处理高速、高功率密度瞬变的 EDA 工具，但还存在许多其他挑战，”英特尔的 Wilcox 说。 “其他一些挑战包括研究更长时间的恒定动态，或者如何管理整个 SoC 中的事物。我还没有看到 EDA 领域对此有太多帮助。我们正在开发更多自主开发的工具，以尝试构建这些功能。”

虽然已经为这些架构权衡的硬件方面开发了工具，但目前很少有工具可以帮助软件方面。“我们需要软件工程师尽快编写正确的代码，”Ruby 说。“我认为真正需要的是软件开发人员的某种配套技术。就像我们有用于硬件的 RTL 功率分析工具一样，软件开发系统需要某种功率分析器来告诉他们这段代码消耗了多少功率和能量。由于我们现在生活在人工智能时代，让人工智能技术分析代码会很酷。你可以得到功耗的估计值，一些人工智能技术可能会说，如果你以这种方式重组代码，你可以节省大量电量。”

结论

硬件世界在功率和能源方面遇到了瓶颈。热限制和担忧在该社区中日益增加。如果不考虑它们，硬件功能就无法增长。但这些还没有达到系统级关注的水平。除非所有造成能源消耗的各方都坐在同一个房间里，设计出节能的系统，否则我们将看不到问题的真正解决方案。

这还有另一个方面。所有生产他们使用的工具的人也必须进入同一个房间，开发使每个人都能成功的流程。虽然 EDA 和系统世界在解决一些热挑战方面取得了一些进展，但在架构层面的进展较少，硬件和软件世界之间几乎没有进展。专注于功能的虚拟原型是不够的。它们需要扩展到系统功率和能量，而这离不开编译器开发人员的参与。领域特定计算中存在一个机会，因为这些人由于这些问题而采取了硬件方面的新方向，这对他们来说可能足够重要，可以在相邻领域取得进展。但这一切似乎还需要很长时间才能实现。

http://mp.weixin.qq.com/s?__biz=MzIxODAzMDA0Mg==&mid=2650946470&idx=1&sn=1a2f92a8749231a03825bc45d4456e55

软硬件协同设计 HW-SW Co-Design

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

最新文章

左移，只是冰山一角

为高性能计算构建芯片

如何在系统层面优化功耗

处理器的对比，为什么很困难？

IP-XACT 回归，理由充分

IEEE IP-XACT 标准概述

SoC 开发中的虚拟原型设计

汽车芯片开发中的虚拟原型

使用虚拟原型实现持续集成和部署流程

为什么 SOAFEE 项目对于联网汽车的设计至关重要

Debug 调试：SoC 计划表的杀手

调试嵌入式应用程序 Debugging

谁负责处理器验证？

如何优化处理器？

一种用于多级 IP/SOC 设计的快速 SystemC 仿真方法

使用 IP-XACT 元数据进行 TLM 建模流程

追踪并优化 SoC 性能

利用 NoC 创新加速 SoC 演进，使用 NoC 平铺实现 AI 和机器学习

BMW 和 Qualcomm 构建云端 ADAS 平台

汽车 ECU 的全面验证策略：MIL、SIL 和 HIL

调试复杂的 RISC-V 处理器

使用自定义 RISC-V ISA 指令创建领域特定处理器

开始使用 IP-XACT 进行 IP 设计

使用 IP-XACT 的 SoC 设计流程

IP-XACT 介绍

UVM 寄存器模型

成本节约和产品质量提升：软件测试的左移

左移？如何加速汽车芯片开发流程？

早期验证和软件启动的混合方法

汽车网络的艺术（系列 1）：VC3，新 E/E 架构评估系统

汽车网络的艺术（系列 2）：PCIe 走向汽车

汽车网络的艺术（系列 3）：虚拟化的力量

管理现代 SoC 设计中的性能

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

新硬件架构软件开发面临的五大挑战

计算机模拟：基础、术语、级别

在 Simulink 中生成 SystemC TLM 虚拟原型

MCU 故障模式：发生的原因以及如何预防

汽车行业对 Chiplet 和 UCIe 的需求

虚拟平台 Virtual Platform 技术

SystemC 中的系统级建模

优化 ISA 实现软硬件的和谐：自定义指令和 RISC-V 扩展

带有 RISC 主机和可配置微处理器的 SoC 的软硬件分区方法

SoC 设计中的系统架构是什么？

CPU 是最佳 AI 推理处理器的五大理由

通过改变抽象级别, 来加速 SoC 仿真

系统仿真、架构探索、电源管理、性能分析

汽车芯片团队研发岗位招聘

使用 TLM 虚拟系统原型, 进行汽车芯片的硬件和软件验证

芯片 Bring Up 正在发生变化

分类

时事

民生

政务

教育

文化

科技

财富

体娱

健康

情感

旅行

百科

职场

楼市

企业

乐活

学术

汽车

时尚

创业

美食

幽默

美体

文摘

原创标签

时事社会财经军事教育体育科技汽车科学房产搞笑综艺明星音乐动漫游戏时尚健康旅游美食生活摄影宠物职场育儿情感小说曲艺文化历史三农文学娱乐电影视频图片新闻宗教电视剧纪录片广告创意壁纸头像心灵鸡汤星座命理教育培训艺术文化金融财经健康医疗美妆时尚餐饮美食母婴育儿社会新闻工业农业时事政治星座占卜幽默笑话独立短篇连载作品文化历史科技互联网

发布位置

广东北京山东江苏河南浙江山西福建河北上海四川陕西湖南安徽湖北内蒙古江西云南广西甘肃辽宁黑龙江贵州新疆重庆吉林天津海南青海宁夏西藏香港澳门台湾美国加拿大澳大利亚日本新加坡英国西班牙新西兰韩国泰国法国德国意大利缅甸菲律宾马来西亚越南荷兰柬埔寨俄罗斯巴西智利卢森堡芬兰瑞典比利时瑞士土耳其斐济挪威朝鲜尼日利亚阿根廷匈牙利爱尔兰印度老挝葡萄牙乌克兰印度尼西亚哈萨克斯坦塔吉克斯坦希腊南非蒙古奥地利肯尼亚加纳丹麦津巴布韦埃及坦桑尼亚捷克阿联酋安哥拉