原文地址：System Validation at ARM: Enabling our Partners to Build Better Systems
作者：eoin_mccann， 翻译： jay
（特别感谢班加罗尔的系统验证团队为我提供本文中的所有技术信息。非常感谢！）
功能验证被广泛认为是SoC设计的主要瓶颈之一。在 SoC 产品化的过程中，很大一部分工作都花费在验证上。根据 Wilson Research Group 的统计，在 2014 年，典型的 SoC 项目中 57% 以上时间消耗在验证上。
来源：Wilson Research Group
虽然付出了如此大的努力，但对于首次设计，功能故障的风险仍然是普遍存在。自从多处理器芯片（包括异构设计）问世以来，SoC 的复杂度显著增加。在下图中，您可以看到随着时间推移以及工艺的演进 SoC 中的 IP 组件的数量迅猛增加。
来源：ChipDesignMag
SoC 已经演变成为复杂的实体，集成了多种不同的 IP。当今的 SoC 可能包括多个组件，例如 CPU、GPU、互连、内存控制器、系统 MMU、中断控制器等。IP 本身也是复杂的设计单元，需要经过独立验证。即便经过了 IP 级别的严格验证，也不可能检测出全部bug –特别是有一些bug，只有在系统内部IP之间交互时才会发现。本文旨在让您深入了解ARM在幕后所作的一些系统级验证工作，这些验证工作帮助ARM的IP被广泛使用。
很多 SoC 设计团队结合使用自研和商用的工具及方法，分别解决各种验证问题。ARM 所作的系统级验证的目标是为合作伙伴提供经过验证的能够正确互操作的高质量 IP。这样可以奠定标准基础，让合作伙伴能够在这个基础上构建自己的系统验证 SOC 解决方案。依托这个坚实基础，他们的设计和验证工作能够更多侧重于 SoC 的设计差异化，以及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 的互操作、验证指标、跟踪机制、以及验证中的各种流程。对套件的测试从简单的激励开始，然后逐渐升级到更加复杂的场景和压力测试。
测试将执行各个子系统级别的评估，例如性能验证、功能验证和功率估测。通过报告记录选定套件的参考数据，包括性能、功率和功能质量，并在内部公布。本文仅侧重于功能方面，有关性能和功率的主题将在今后的博客中进行更多论述。
ARM 的系统验证团队已经建立了可重复的自动化套件开发流程，让我们能够构建面向不同市场的多个套件。ARM 当前每年构建和验证大约 25 个套件。
我们选择 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) 的测试，对套件的集成进行彻底测试。这些测试在验证周期的早期运行，用来确认套件是否足够强大，以运行更大压力的工作负载。KVS 可以配置为在多个套件上运行。它包括了多个子套装，分别用于测试集成、功耗、CoreSight 调试和跟踪、媒体 IP。KVS 还提供特定的测试，用于测试 GPU 和显示的集成，以及 GPU 一致性。初始启动通常需要先做仿真，然后逐渐转移至用于集成测试的Emulator（硬件加速器）。
RIS Boot和BringUp
随后，我们在套件上启动具有基本调用测试功能的所有 RIS 工具，以检测所有硬件/软件配置问题。
RIS：默认和重点配置
套件稳定之后，测试的复杂度将会随之增加，因而它们对系统的压力也会增加。与定向激励相比，随机激励可以更快地覆盖设计空间，在激励创建方面的工作量也比较小。因此，压力测试更加依赖于随机激励，而不是定向激励。首先运行 RIS 工具的默认配置，在经过适当数量的验证周期之后，工具将被重新配置，以便对套件中的特定 IP 进行压力测试。
RIS 浸泡测试
在系统验证的最后一个阶段，套件在 FPGA 上进行浸泡测试。虽然硬件加速器更加有利于调试，但 FPGA 的速度更快，提供的验证周期也更多。因此，在 IP 稳定成熟之后，ARM 将在 FPGA 上进行浸泡测试，以寻找那些复杂的Corner Case。
指标、跟踪、覆盖和里程碑结束
为每个套件运行的验证周期数量是我们跟踪的主要指标之一，旨在确保达到目标验证周期数量。这对我们确保达到浸泡测试周期目标尤其有用，从而增强我们对 IP 在各种应用中的质量的信心。除此之外，我们使用统计覆盖方法，对覆盖进行量化和跟踪，以确保整个设计（包括潜在的Corner Case）都经过充分测试。
最新版本的 ARM Juno 芯片经过了总计 6,130 小时的验证运行时间，相当于 8.5 个月的测试。这为我们提供了独特的视角，可以看到系统内部的极端情况，让 ARM 能够更好地为尝试调试自身设计中的问题的合作伙伴提供支持。此外，在验证流程中发现的错误可以反馈给 IP 设计团队，他们将会利用这些信息，在每个发布里程碑改进 IP 质量，并为下一代产品提供指导。
小结
系统复杂度随着 SoC 性能一同增长，导致花费在验证上的时间和资金大幅增加。在向合作伙伴发布之前，ARM 需要验证 IP 的互操作性，以确保它适合各种应用。ARM 的 IP 团队的设计始终处于领先地位，在系统验证团队的帮助下，确保他们设计的 IP 能够在合作伙伴构建的系统中协同运行。
Cadence Design Systems 的 Frank Schirrmeister 将他们的工具互操作性验证视为一大优势。“软件驱动型验证方法的使用反映了整个行业向可移植激励发展的趋势，例如 ARM 内部使用的方法，它让我们能够在系统开发套件的所有引擎上验证 ARM 内核和子系统的集成和互操作性，这些引擎包括Simulation、Emulation和基于 FPGA 的原型验证引擎。”
由于 ARM 合作伙伴的设计面向非常广泛的应用场景，因此必须确保我们的 IP 能够在很多不同系统中正常运行。ARM 使用的多阶段系统验证方法让合作伙伴能够高枕无忧，确信我们的 IP 是值得依赖的。随着时间推移，验证方法已经演进为一种测试多个系统组件并对系统中的大多数 IP 进行压力测试的方法。今后，我们计划进一步扩展和改进我们的测试方法，以确保 ARM 的 IP 达到更高的水准。