系统级验证目标提出了一个问题，即验证可能只有在设计和驱动程序大部分完全组装和调试后才可能进行，但在检查符合性之前等待设计完成也没有什么帮助。

Paul Cunningham（Cadence 系统验证小组高级副总裁/总经理）最近撰写了一篇文章，内容涉及先进的服务器设计如何为成功的系统启动带来新的挑战，以及 Cadence 如何与 Arm 合作加速这一进程，以符合 Arm SystemReady 程序。在这里，我想更详细地分享一下，对于我们自己的硬件开发，我们如何能够在半天内启动并运行系统级测试套件。

验证服务器平台的新挑战

新的系统级验证需求。（来源：Cadence 设计系统）

验证任何大型 SoC 都会遇到很多挑战，但其中有两个是该领域独有的。首先是确保 SystemReady 合规性。SystemReady 是 Arm 建立的一个程序，旨在确保对主流操作系统的开箱即用兼容性，并开始针对基于 Arm 的服务器（带有 ServerReady）并扩展到其他设备和市场，包括边缘服务器和嵌入式/物联网。. 实现这一目标是芯片设计人员的责任，因为重要的兼容性元素取决于 Arm 内核在 SoC 中的集成方式。为了简化和更好地确保集成商的系统兼容性，Arm 开发了 SystemReady 包，它定义了一组在 UEFI 层上运行的检查，集成商必须通过这些检查才能实现这一目标。

第二个挑战是证明集成的 PCI Express (PCIe) 兼容性。PCIe 在服务器中发挥着核心作用，用于与现在更智能的外围设备进行通信、小芯片间通信和远程启动。我们倾向于将围绕 I/O 块的测试视为以协议为中心，但有两个因素推动了对系统级测试的需求。首先，在基于 Arm 的设计中的松散排序内存模型下，可以在某些工作负载下提高性能。权衡是集成商可以在他们的设计中创建在高流量条件下 PCIe 数据包处理中出现死锁的可能性。其次，PCIe 从 3.0 开始有了长足的发展，以支持系统级优化，例如支持 TLP 处理提示 (TPH) 和地址转换服务 (ATS)。这些功能需要更广泛的系统级验证。

这样的系统级验证目标引起了人们的担忧，即只有在设计和驱动程序大部分完全组装和调试后才能进行验证。例如，如何执行在 UEFI 之上运行的 SystemReady 测试或依赖于流量的测试？但是在检查合规性之前等待设计完成也无济于事。

系统 VIP 方法

验证 IP (VIP) 通常用于生成外部流量或作为 IP 的快速替代品以加快验证周期。根据明确定义的标准进行了全面测试，VIP 在组件级角色中充当符合标准的元素。系统验证可以从类似的概念中受益，但具有不同的意义。例如，将一致性检查作为系统级验证目标。尽管与我们的 SystemReady 和 PCIe 死锁目标没有直接关系，但一致性检查是 SoC 测试计划的一个常见组件，并且是对 System VIP 概念的一个很好的介绍。

应用于一致性测试的系统 VIP。（来源：Cadence 设计系统）

另一个重要组件是系统性能分析，用于可视化和分析典型 SoC 关键点的性能。片上总线性能为 SoC 的运行提供了宝贵的洞察力。通常，高压力场景用于探索系统性能的极限，例如寻找不平衡的带宽共享或死锁。

系统 VIP 的一个关键组件必须是特定于应用程序的系统级检查和评分。我们提供了一个计分板，其中包含适用于各种场景的插件，涵盖片上总线和 DDR 内存模型，使其能够在事务遍历整个 SoC 时对其进行跟踪。

示例生成的测试平台架构。（来源：Cadence 设计系统）

最后，这些组件必须与被测设备 (DUT) 一起组装到测试台中。出于我们的目的，使用逗号分隔变量 (CSV) 或 IP-XACT 加上拓扑详细信息，生成器在 UVM 中创建用于仿真的 System Verilog 测试台或用于仿真的基于 C 的测试台。测试平台由基于目标执行引擎的各种接口的 VIP 或加速 VIP (AVIP) 组成。

应用于 SystemReady 和 PCIe 验证

如前所述，Arm SystemReady 测试套件运行在 UEFI 层之上。我们与 Arm 合作，将这些测试映射到裸机 (BM) 抽象层，然后将其捕获到 System VIP SystemReady 库中。使用这张地图，我们现在可以在几分钟内在我们的仿真平台上运行完整的 120 个自检测试套件。这条路径如此有效地加快了开发中的合规性测试和调试，以至于我们自己使用这些测试来验证我们的新一代仿真硬件。

BSA+SBSA 硅前认证。（来源：Cadence 设计系统）

对于 PCIe 测试，我们建议用户首先运行 SystemReady 测试库（包括基本的 PCIe 测试），以确保他们准备好运行更全面的测试。之后，测试的下一个方面是潜在的死锁。PCIe 是一种基于数据包的协议，其中一个数据包可以拆分为多个事务。其他一些要求对事务进行严格排序，以确保它们在请求者处正确重新组装。然而，支持松散排序的系统在某些情况下可以提供更高的性能，但在请求者可能正在等待数据包并发现自己被有效阻塞的高流量情况下也会面临死锁的风险。

当我们转向多芯片设计时，内存延迟会显着增加。在这里，不仅是从核心 MMU 通过一致互连到内存，而且现在从 MMU 到一致互连再到映射到另一个小芯片上的内存。延迟增加，死锁的可能性可能再次变得不可忽视。系统设计人员必须检测并防止这种可能性。

此外，从 PCIe 3.0 开始，该标准增加了对系统级服务的支持。一个例子是 TLP 处理提示 (TPH)，它添加了来自端点的提示，该端点采购事务，关于目标处理器应如何处理该事务以优化吞吐量。一个这样的提示可以通过建议直接将事务写入高速缓存行来加速处理器性能，以供预计很快需要该数据的处理器（高速缓存存储），而无需写入后备存储。

另一项优化支持地址转换服务 (ATS) 的远程分发。随着端点变得更加智能，可以将虚拟/物理地址转换卸载到这些端点，从而减少系统 MMU 中转换的处理负载。在这里，验证需要测试正确的地址转换，以及正确的失效和更新这些端点中的地址转换缓存。

在系统级别验证正确的 PCIe 行为——针对死锁、TPH、ATS 和其他系统级 PCIe 服务——显然需要的不仅仅是协议检查。在 System VIP 流量库中，我们有用于对端点建模的组件，我们可以从中拖放端点到内存的测试。这些将驱动芯片外部的流量，进入内存并再次返回。它们可用于性能测试，更一般地用于测试 PCIe 和相关路径的正确操作。同样，我们有如何构建 TPH 和 ATS 场景以及如何快速创建测试来验证这些使用模型的示例。这些功能共同利用流量库和生成、计分板和性能测试来快速构建系统级 PCI 测试。

概括

从历史上看，系统级验证一直被视为验证的终点，当然会利用库和一些可重用的组件，但其本身并不是可重用的。然而，我们现在发现，这些系统级方法对于保持验证和确认与服务器架构、无线基础设施、汽车和更多应用中出现的先进设计技术保持同步至关重要。我们发现系统 VIP 概念可以成为构建此类测试的重要加速器，通过可配置的生成器简化常见测试的构建。