向SoC硬件“敞开”Windows

最新推荐文章于 2023-12-29 11:29:52 发布

FPGAerClub

最新推荐文章于 2023-12-29 11:29:52 发布

阅读量908

点赞数

更多精彩内容，请微信搜索“FPGAer俱乐部”关注我们

长期以来，系统设计的一个惯例是通过嵌入专用硬件观察和控制系统状态。自数字计算诞生之始，中央处理器就使用硬件支持寄存器和内存的单步指令实施、加载与检查及断点设置，以支持软件调试。在多年之后（仍属于发展初期），集成电路开始包含用于制造测试的扫描硬件。FPGA 同样沿袭了这一发展思路，配备了内置逻辑分析功能，以帮助设计师对其电路进行细致入微的检查。

随着系统芯片 (SoC) 采用更多功能且变得日益复杂，仅通过观察外部确定系统内部的运行情况变得不切实际和不可能（图 1）。为此，设计师尝试在其芯片设计中内置刺激发射器和检查器，即芯片认定 (assertion) 功能。这一做法在高速串行收发器等一些电路中已必不可少，且在 SoC 用于 FPGA 的实践中得到了更广泛的应用，因为这类专用硬件可在不需要时从设计中移除。

图 1.随着系统日趋复杂，从外部评估内部功能已变得不可能。

如今，对内部功能的评估正呈现出新的发展方向。系统设计师面临着与模块级芯片设计或嵌入式软件开发截然不同的挑战。四个方面尤其需要引起重视：系统集成、运行时性能优化、系统安全性与功能安全性。所有这些方面日益要求设计师从 SoC 芯片内部观察和控制系统。设计师的做法是，通过嵌入更多专用硬件支持从芯片内部观察 Windows。

集成挑战

过去，多数 SoC 验证工作都在模块层面进行。系统架构往往非常简单并以 CPU 为中心（图 2），模块集成至行业标准总线上的特定插座中。只要模块能正常运行，多数工作都能顺利开展。)

.图 2.在以 CPU 为中心的传统 SoC 中，一个调试内核几乎可看见一切。

但今天的 SoC 已彻底改变了这一状况。如今，SoC 具有多个或许多 CPU 内核（无明确的主内核），不再以 CPU 为中心。芯片上的其他模块可以处理数据和共享内存，因此即便掌握芯片上的每个 CPU 内核也无法保证成功。（图 3）。高速缓存可能具有许多级别，部分或所有级别支持一致性协议，让用户无法清晰了解芯片的实际情况和最新数据。外设可能具有直接内存访问 (DMA) 能力。过去由 CPU 控制的同步总线已被交换总线层或复杂的全局异步片上网络 (NoC) 所取代。此外，芯片上的许多模块将成为所谓的预验证知识产权 (IP) —— 通常来自于谨慎公布设计细节的第三方。

图 3.在复杂的 SoC 中，隔离的调试内核对芯片的可视性较为有限

Ultra SoC 首席执行官 Rupert Baines 表示：“现在，情况发生了扭转。IP 级设计工具和验证流程非常高效。您使用的 IP 模块将来很可能达到设计师对其功能的设想。但是，鉴于系统复杂性有所增加，模块之间的交互已成为目前的挑战”。

即使所有模块都在正常运行，这些交互也会导致严重的系统错误。而且交互是非常微妙的。不同 CPU 上任务之间的交互会致使高速缓存发生故障。SoC 不同部分中事件顺序的微小差异都会造成任务延迟的巨大波动，例如，当两个处理器进入死锁状态时，一个 CPU 上的高优先级中断服务例程会调用另一个 CPU 上的低优先级子例程。此外，看似微小的固件变化会改变命令到达共享 DRAM 控制器的顺序，从而引发一系列页面丢失问题和大幅降低有效的内存带宽。

面对这类时刻变化的交互，即使最出色的隔离 CPU 调试工具和总线监控器也无法发挥作用，甚至无法隔离故障，更别说发现问题根源了。为此，您需要捕捉系统的完整状态，即设定某状态（更可能是一系列状态）的触发条件（定义故障症状），然后查看追踪缓冲区，了解包含触发事件的状态历史记录。在这一过程中，您通常需要让系统保持全速运行。换言之，您需要利用最佳的 CPU 硬件调试内核，但对于整个 SoC，一次不仅使用一个内核。

实际上也就是说，在 SoC 中内置自定义逻辑分析器，并在芯片的每个功能模块中采用状态监控或评估硬件。另外，我们需要部署一个芯片级互连网络，汇集这些状态检测器中的数据，按时间对这些数据排序，并对最后的系统状态图片设定复杂的触发条件。最后，我们还希望用户界面能够便于用户理解所有相关信息。

Baines 表示，然而，多数系统设计师通常仅有并不完整的孤岛式工具，这些工具基于不同模块，而且质量上参差不齐。CPU IP 厂商一般为软件开发人员提供调试模块，支持通过 JTAG 或专用调试端口实施单步指令、断点、跟踪和转储。这类模块在质量上不尽相同，有些具备实时和全面特性，有些仅供临时使用或并不可用。如果没有软件的充分干预，它们几乎无法看见 CPU 内核之外的状态。

感测 CPU 内核之外的状态更为困难。在密码、视频编解码器、视觉处理或神经网络推理等方面，DSP 内核或专用加速器厂商可能认为他们的调试设施或引擎状态信息过于敏感，不适合与最重要客户之外的人分享。这些模块可能成为黑匣子。除技能娴熟的 GPU 程序员外，一般用户或可了解 GPU 状态，但将其变为黑匣子则非常困难，对于代码的依赖度较高。

内部 IP、尤其是前一项目使用过的内部 IP 会造成更大困难。例如，如果一个自定义数据流机器具有一个实时调试模块，而且具有详细的记录，它可能仍然不适合新应用。复用指南对于可复用调试设施的规定并非总是非常明确。

此外，SoC 的实用程序模块 —— NoC 交换机和垫圈、DRAM 控制器和网络接口、DMA 和中断控制器 —— 并不总能为系统开发人员提供充足的可视性。不过，状态信息对于系统集成商可能非常重要。总之，即便在技术上可行，捕捉整个 SoC 的状态也并非易事，这种设计问题的重要性相比初始设计可能并不低多少。

现场优化

系统开始工作后，我们希望系统集成的深度可视性需求能告一段落。但新的需求可能出现，即系统优化，而非调试访问。

当然，在工作负载以毫秒级速度变化的数据中心内，SoC 无疑可受益于持续调整。有些因素需进行大幅度调整，如分配至某个任务的内核数量、哪个任务共享哪个内核、硬件加速器的分配方式等；有些因素只需较小幅度的调整，如 DRAM 分配；还有些因素可微调，如中断优先级、多客户端 DRAM 控制器中的客户端优先级和 NoC 交换机中可调整的大量因素。

随着嵌入式系统从专用的单 CPU 架构转向动态分配的多核设计，其中许多注意事项开始显示出重要性。有人可能会说，嵌入式系统的工作负载信息在设计时就已非常详尽，芯片优化应在这一阶段实施。这种说法仍然有其合理性。但嵌入式工作负载的信息在系统集成之前越来越难以掌握，尤其是对于高度依赖数据的任务，如神经网络推理。因此，数据中心服务器等嵌入式设计可能需要在集成后进行调整。

而且这种调整也需要深入了解 SoC，但这种可视性不同于调试或集成。当集成需要识别和记录一系列系统级状态，调整更加依赖汇总数据或统计数据，如数据率、设备利用率、闲置时配置文件等。为有效进行调整，您需要查找过度利用和未充分利用的资源。

对于一个典型的例外情况，这类统计信息可能难以获取。CPU 调试硬件通常用于收集突然产生的跟踪数据，而非利用率、吞吐量统计数据或高速缓存配置文件。统计数据可能来自于跟踪数据的随机样本或外部监控器。NoC 影响着 SoC 中各模块之间的几乎所有流量，适用于收集流量和一些活动统计数据。需要指出的是，许多数据都可直接或间接收集到，但数据收集和汇编的工作可能要设计团队完成。

系统安全性

随着网络安全意识的日益增强，嵌入式系统设计师面临着一些新出现的运行时需求。在保护一个任务的内存不被另一个任务检查到或损坏方面，多任务处理系统的设计师长期依赖处理器内核附带的内存保护单元 (MPU)。这种方法非常有效，前提是系统中的所有内存访问都经过 CPU，且所有 MPU 寄存器都设置正确。但在多个模块实施 DMA 且面临网络攻击的多核系统中，这些条件均得不到保障。

一项有效的防护措施是确保 MPU 设置访问只可在安全运行模式下进行，如 ARM 的 TrustZone。理论上，一项任务只可通过展示有效证书进入这种特权模式。但对于 Meltdown 和 Spectre 漏洞的广泛报道，以及之前基于管理程序的攻击事件的有限报道均表明，即便是安全的执行模式也会受到攻击。

这些风险促使一些开发人员将思路转向在 SoC 中部署嵌入式监控硬件。高速缓存和系统总线、DRAM 控制器和 NoC 上的监控器可以构成另一道防线，持续确保任务或外设不会超出所分配的内存。

功能安全性

通过将这种监控和防止系统出现异常情况的思路进行归纳整理，我们会豁然开朗。如果能够了解整个 SoC 的状态，嵌入式监控可发现系统准备实施危险的物理操作 —— 如将工具移动至不安全区域或在未查看相位匹配的情况下关闭 AC 电网中的开关，并可迫使系统进入安全状态。这种预测和避免不良后果的能力是功能安全性的要义。

这又回到了前面的话题，即使用嵌入式监控器从 SoC 的所有重要模块中收集状态信息，并将这些信息关联至芯片总体状态的一致性视图。我们发现，部分（远非所有）关键模块具有可收集这些数据的电路。该电路负责汇集数据，这一任务通常不能交由软件处理，以免产生不可预测的延迟和系统资源争用，以及更严重的安全问题。

我们的可选方案是捕捉每个重要模块中的状态，在源端为其添加时间戳，并使用专用的路由资源将这一信息发送至中央收集点。可喜的是，许多厂商正向这一目标迈进。

举例来说，ARM 的 CoreSight* 开发人员在预料到多核调试的挑战之后，将其基于硬件的工具的应用范围扩展至 ARM* IP 内核与总线的多个实例。Arteris、Netspeed 和 Sonics 等 NoC 厂商也在开展相关工作，他们顺理成章地将端点和交换机中的分析设施扩展至芯片级状态监控和报告网络。

此外，致力于解决相关问题的 IP 厂商 Ultra SoC 也在努力实现该目标。该公司开发了路由和收集站来汇集 SoC 中带有时间戳的状态信息。他们开发了垫圈来提取 CoreSight 和一些其他内核厂商的调试模块中的信息。该公司正在与至少一家 NoC 提供商开展合作。Ultra SoC 还开发了可视化与分析软件，用于帮助用户有效利用从 SoC 上载的状态信息。

这似乎是商用工具当前的价值所在。在提升各种处理器的可视性方面，我们仍然任重而道远。目前，Ultra SoC 正在使用 RISC-V 架构，而且已开始大规模应用 FPGA 加速器。

对于其他的一些系统模块，我们甚至无法就应该关注其内部状态的哪一部分达成一致。还有许多问题等待我们来解答。通过若干要点（而非直接测量），我们能在多大程度上推断出 SoC 的内部状态？行业能就处理要素和监控网络之间的标准接口达成一致吗？某种形式的深度学习网络能通过学习海量状态数据‍‍推断出故障根源，或预测功能安全故障吗？我们任重而道远。