构建更好的系统，ARM这些幕后系统级验证工作很关键！

来源：Wilson Research Group

虽然付出了如此大的努力，但对于首次设计，功能故障的风险仍然普遍存在。自从多处理器芯片（包括异构设计）问世以来，SoC 的复杂度显著增加。在下图中，您可以看到随着时间推移以及工艺的演进 SoC 中的 IP 组件的数量迅猛增加。

来源：ChipDesignMag

SoC 已经演变成为复杂的实体，集成了多种不同的 IP。当今的 SoC 可能包括多个组件，例如 CPU、GPU、互连、内存控制器、系统 MMU、中断控制器等。IP 本身也是复杂的设计单元，需要经过独立验证。即便经过了 IP 级别的严格验证，也不可能检测出全部bug——特别是有一些bug，只有在系统内部IP之间交互时才会发现。让我们深入了解ARM在幕后所作的一些系统级验证工作，正是这些验证工作帮助ARM的IP被广泛使用！

ARM 的验证流程与业界广泛采用的流程非常相似。

ARM 验证流程金字塔

设计的验证工作在早期以单元粒度开始进行，这些单元共同构成了独立的 IP。在整个验证周期中，只有在单元级别上，工程师才能够获得对设计的最高可见性。除非信号太底层，否则我们可在单元级别上对各个信号进行探测，或将其设置为需要的值以协助验证。当单元级别的验证达到一定的成熟度之后，这些单元可以组合在一起，形成完整的 IP（例如一个 CPU）。在此之后，才能开始 IP 的 IP 级别验证。对于 CPU 而言，这通常是能够进行汇编程序级别测试的开始时间。此前，大多数测试只能通过控制各个线路/信号来进行。在 IP 级别上，测试是使用汇编语言编写的。处理器从内存（模拟）获取指令，对其进行解码，然后执行。在IP级验证到达一定的稳定性之后，多个 IP 组合形成一个系统，系统验证工作开始。

在 IP 的设计、验证阶段，会经过多个里程碑，这些里程碑可以反映它们的功能完整性和正确性。其中，Alpha 和 Beta 是内部质量里程碑。LAC（限制访问）也是一个里程碑，在它之后，合作伙伴可以获取对 IP 的访问。随后是 EAC（早期访问）里程碑，在它之后，IP 可以用于制造，以便获取工程样本和测试。到达 REL（发布）里程碑之后，由于IP 已经过严格测试，能够投入量产。

在通过系统验证流程之前，IP 质量通常处于 Alpha 和 Beta 之间。截止到设计周期的这个阶段，IP 已经过了大量的测试，大部分的低级别错误已被发现，必须非常周密细致地构建激励，使得每个 IP的微架构的内部状态最大可能的被测试激励覆盖。激励既可由汇编代码提供，也可使用集成到系统中的专门设计的验证 IP 来提供，ARM 结合使用了这两种方法。

如果没有检测到，很多错误可能导致最终产品出现严重故障。基于以往的经验，ARM 估计需要 1 至 2 千万亿个周期的验证，另外还需要 4 至 7 个月的调试工作，才能发现这些类型的错误。很多情况下，严重的延迟会让芯片错失在关键时间内推向市场。在作为一个组成部分集成到 SoC 之前，应在设计周期内及早发现这些错误，这对确保 IP 的稳定基础至关重要。

ARM IP 的性质意味着它要在各种不同的 SoC 中使用，从物联网设备到高端智能手机，再到企业级产品。系统验证的关键目标是确保技术能够一致地、可重现地运行设计的功能，在对 IP 进行严格验证时，我们始终牢记这个目标。换而言之，验证的重点目标是 IP，但必须在实际的系统环境中进行验证。为此，ARM 会在多种不同的实际系统配置下对 IP 进行测试，这些系统配置被称为套件。

套件定义为通过子系统的形式集成在一起的“IP 组”，面向特定的目标应用市场（例如移动、物联网、网络等）。它通常包括 ARM 内部开发的一整套 IP – CPU、互连、内存控制器、系统控制器、中断控制器、调试逻辑、GPU 和媒体处理组件。

套件进一步细分为更小的组件，称为“元件”。元件可以视为套件的构建块。它包含至少一个主要 IP，周围有空白逻辑，有些元件也是由多个 IP 集成在一起的。

这些套件旨在代表面向不同应用的典型 SoC，让 ARM 能够更加全面地了解将各个 IP 组件集成在一起以实现目标系统性能的生态系统所面临的挑战。

系统验证团队结合使用激励和测试方法，对套件进行压力测试。激励主要是在系统中的 CPU 上运行的软件测试。这些测试可以使用汇编语言或更高级别的语言人工创建，或者使用随机指令序列(RIS) 工具生成。除了在 CPU 上运行的代码之外，我们还使用一组验证 IP (VIP)，为系统注入激励并观察运行情况。

在准备验证时，我们要为套件中的每个 IP 制定测试计划。测试计划包含不同的 IP 配置、要测试的功能、要涵盖的场景、激励、与 IP 的互操作、验证指标、跟踪机制、以及验证中的各种流程。对套件的测试从简单的激励开始，然后逐渐升级到更加复杂的场景和压力测试。

测试将执行各个子系统级别的评估，例如性能验证、功能验证和功率估测。通过报告记录选定套件的参考数据，包括性能、功率和功能质量，并在内部公布。

我们选择 IP 及其内部配置以及系统的拓扑结构的不同组合，以反映广泛的最终用途。这些套件在两个主要平台上进行测试 – Emulation和 FPGA。通常，测试首先在Emulator上开始，然后在 FPGA上完成Soak Testing（浸泡测试）。每个 IP 平均经过 5 至 6 万亿个Emulator周期和 2 至 3 千万亿个系统验证 FPGA 周期。为了运行这个级别的测试，ARM 开发了一些内部工具。

在系统验证中，主要使用了三种工具，分别侧重于不同方面，例如指令管线、IP 级别和系统级别的内存系统、系统一致性、接口级别的互操作性等。其中两种工具是随机指令序列 (RIS) 生成器。RIS工具可通过自动化方式，对架构和微架构设计空间进行探索，试图触发设计中的故障。与人工编写的定向测试相比，它们能够更加有效地覆盖测试空间。这些代码生成器可以生成测试，以便通过自动化方式，对架构和微架构的不同区域进行探索。这些测试是多线程的汇编代码，包括随机的 ARM 和 Thumb 指令，其目的是充分执行设计中不同部分的功能。

第三方工具是轻量级的内核，可用作开发定向测试的平台。我们的验证方法结合使用了定向测试和基于随机指令的自动化测试。它支持基本的内存管理和线程调度，以及一部分 Pthreads API，让用户能够开发参数化的定向测试。

为了在系统级别上对 IP 进行压力测试，我们采用了更加随机的方法，而不是定向方法。这使 ARM 能够覆盖广泛的场景、激励多种时序条件并创建复杂的事件。为此，套件可以支持多种有利于验证的功能，例如在不同接口上更改时钟比、实现错误注入以及禁用不需要做功能验证的组件等。系统中的不同接口（例如 CPU、互连和动态内存控制器）的总线时钟比可以更改，以激励实际的系统时钟条件。 

系统验证调用

上图显示了系统最初如何进行bring up，以及测试复杂性如何逐渐提升。

初始测试从一系列简单集成测试开始，运行这些测试的目的是确认套件的基本稳定性，并消除微小的集成问题。随后，我们使用一套名为套件验证套装 (KVS) 的测试，对套件的集成进行彻底测试。这些测试在验证周期的早期运行，用来确认套件是否足够强大，以运行更大压力的工作负载。KVS 可以配置为在多个套件上运行。它包括了多个子套装，分别用于测试集成、功耗、CoreSight 调试和跟踪、媒体 IP。KVS 还提供特定的测试，用于测试 GPU 和显示的集成，以及 GPU 一致性。初始启动通常需要先做仿真，然后逐渐转移至用于集成测试的Emulator（硬件加速器）。

随后，我们在套件上启动具有基本调用测试功能的所有 RIS 工具，以检测所有硬件/软件配置问题。

套件稳定之后，测试的复杂度将会随之增加，因而它们对系统的压力也会增加。与定向激励相比，随机激励可以更快地覆盖设计空间，在激励创建方面的工作量也比较小。因此，压力测试更加依赖于随机激励，而不是定向激励。首先运行 RIS 工具的默认配置，在经过适当数量的验证周期之后，工具将被重新配置，以便对套件中的特定 IP 进行压力测试。

在系统验证的最后一个阶段，套件在 FPGA 上进行浸泡测试。虽然硬件加速器更加有利于调试，但 FPGA 的速度更快，提供的验证周期也更多。因此，在 IP 稳定成熟之后，ARM 将在 FPGA 上进行浸泡测试，以寻找那些复杂的Corner Case。

为每个套件运行的验证周期数量是我们跟踪的主要指标之一，旨在确保达到目标验证周期数量，这对我们确保达到浸泡测试周期目标尤其有用，从而增强我们对 IP 在各种应用中的质量的信心。除此之外，我们使用统计覆盖方法，对覆盖进行量化和跟踪，以确保整个设计（包括潜在的Corner Case）都经过充分测试。

最新版本的 ARM Juno 芯片经过了总计 6,130 小时的验证运行时间，相当于 8.5 个月的测试。这为我们提供了独特的视角，可以看到系统内部的极端情况，让 ARM 能够更好地为尝试调试自身设计中的问题的合作伙伴提供支持。此外，在验证流程中发现的错误可以反馈给 IP 设计团队，他们将会利用这些信息，在每个发布里程碑改进 IP 质量，并为下一代产品提供指导。