管理NVMe验证复杂性

从一开始，NVMe 就旨在支持多个主机访问共享媒体。早期实施包括 PCIe 内置设备，如端点 （EP）、根复合体 （RC） 和根复合体集成端点 （RCiEP）;随着时间的推移，云和存储基础架构产生了对远程存储的需求。

NVMe 实现可以解决 SATA 点对点架构和 SAS 占用的空间问题。在这两个领域成功采用是由于低延迟和通用存储接口的承诺，无论位置如何。尽管这两个用例中的验证挑战相似，但它们仍然需要不同的思维过程。

点对点架构中使用的 NVMe 要求以控制器实现为中心进行验证。在这种情况下，控制器的数量< 10，逻辑内置于硬件、应用软件和固件中。带宽和吞吐量是点对点架构中的关键度量。NVMe控制器设计人员需要在实现中做出权衡，以实现成本/性能目标，尽管关键权衡是在各种功能的硬件和软件实现之间进行的。这些权衡的细节不会在这里讨论，但足以说明线路的位置对验证工程师很重要。

硬件/软件分区带来了验证的复杂性。传统上，硬件在仿真中得到验证，因为它需要更严格和彻底的测试。软件实现的功能在协同仿真和硬件加速验证环境中经过轻度测试，因为如果更新不影响硬件，则更新成本不高。我们在这里看到的验证挑战是验证用于加速各种软件功能的实现特定硬件。在这里，软件通常需要设置并卸载到硬件。根据软件实现的复杂程度，仿真可能需要数天时间才能达到验证目标点。协同仿真的仿真启动是一种直接的进度威胁。

为了解决仿真中的硬件和软件问题，许多验证团队利用ZeBu等硬件加速平台。硬件加速允许 NVMe 驱动程序在可以连接到仿真设备的 CPU 上启动。这里最大的挑战是可重用性。传统上，在仿真中编写的测试针对仿真测试平台进行了优化，并不完全适用于加速环境。Synopsys 的 ZeBu 平台已通过支持在加速中重用仿真验证 IP 并保留仿真和加速平台之间的相同用户界面，解决了这一问题。由于 ZeBu 加速平台的执行性能提高了 100 倍，现在可以启动软件。这种方法允许模拟更深入地进入测试，以发现可以审查管道、内存带宽、翻转条件或卡住或一次性故障的功能错误。加速还允许基于波形的调试，这是解决基于硬件的问题所必需的。

需要考虑其他仿真优化来缩短测试运行时间。对于以 PCIe 作为传输的 NVMe，可以删除整个 PCIe 堆栈，从而公开 NVMe 和 PCIe 堆栈之间的专有 TLP 接口。PCIe 堆栈往往很大，需要设置时间。删除堆栈也会删除此基于规范的设置时间。删除 PCIe 传输时，需要考虑其他事项，例如缓冲区管理、中断等。对于使用 AXI 接口（与专有 TLP 接口相比）的 PCIe 设计 IP，由于 AXI 是公共标准，因此更容易删除 PCIe 堆栈。这使得AXI接口的中断相对便携。

点对点调试相对简单，尽管通常很乏味。事务和模拟日志用于追踪与 NVMe 命令关联的内存事务。记分牌也可以在内联和边带记分牌中得到有效利用。调试的另一个关键方面是监视在内存中构造和操作的结构。跟踪从未进入完成队列的完成可能非常困难，因为控制器正在主机或验证 IP 的监视之外执行内存访问。拥有“监视”此内存的能力，无论该功能内置于验证IP还是验证组件中，都将节省无数小时的调试时间。要考虑的另一个验证工具是跟踪位于链路另一端的控制器、命名空间和其他资源的状态。通过跟踪验证环境中的状态，可以通过以下方式节省大量调试时间：

• 标记测试编写器格式不正确的命令 • 标记由于版本不足或功能
不支持而导致控制器不支持的命令
• 标记与尚未设置的先决条件设施相关的问题

一旦验证环境可以跟踪控制器和命名空间，相同的跟踪将自动扩展到具有多个控制器/命名空间的环境，从而为上述调试节省时间提供乘数效应。

设计最有效的核查环境以及选择最佳的核查组件对于实现核查时间表的“左移”至关重要。通过重用组件、序列等，可以花更多的时间来发现/修复真正的 DUT 错误。不要低估良好的调试工具所节省的时间 - 防止不良测试，指出DUT问题，标记DUT错误配置等。

审核编辑：郭婷