基于SystemVerilog的RDMA验证平台架构：RoCE v2子系统设计与实现

本文探讨在开发一个RoCE v2高速数据传输系统的FPGA IP时，如何使用SystemVerilog（SV）构建功能验证平台。在云栈社区的技术实践中，基于SystemVerilog的仿真验证平台因其在验证效率、代码复用性以及团队协作方面的显著优势，已成为确保IP可靠性的重要手段。这里主要分享平台的核心设计思路，希望能为相关领域的开发者提供参考。

需要注意的是，一个商用IP的成功不仅依赖于其本身的设计，还涉及用户文档、示例工程以及对不同芯片平台（尤其是国产化芯片）的适配支持等诸多复杂因素。本文仅聚焦于开发流程中的验证环节进行探讨。

验证平台整体架构

我们的验证目标是一个RoCE v2高速数据传输系统。该系统对外的接口主要包括AXI4-Lite、AXI4等片内总线接口，以及QSFP光纤接口。对于片内总线接口，我们可以相对容易地将其信号抽象为事务级进行驱动和监测。而QSFP接口由CMAC集成模块驱动，其物理层仿真较为复杂，通常需要借助成熟但昂贵的验证IP（VIP）。

考虑到Xilinx的CMAC模块本身已经过充分验证，为了降低验证平台复杂度，我们在仿真验证时选择将CMAC模块从被测系统中剥离，仅对其暴露给用户逻辑的AXI-Stream及配置接口进行仿真。这样做的核心是验证RoCE v2协议处理逻辑的正确性。

基于以上思路，我们搭建的整体验证架构如下图所示：

图1：基于SystemVerilog的验证平台整体架构

如图所示，整个验证体系由以下几部分组成：

1. 验证环境：基于SV/UVM方法学构建，包含接口（Interface）、激励发生器（Sequencer/Driver）、监测器（Monitor）、测试用例以及结果比较（Scoreboard）等组件。
2. 被测设计（DUT）：即移除了CMAC模块的RoCE v2高速数据传输系统核心逻辑。
3. AXI BRAM IP：用于模拟系统外挂的存储，连接至DUT的AXI4数据总线。
4. RDMA子系统模型：这是一个自主设计的参考模型，用于模拟网络中另一端的RoCE v2远程主机行为，与DUT进行协议交互，是完成系统性功能验证的关键。

其中，验证环境和RDMA子系统模型是平台设计的核心。验证环境负责产生激励、收集响应并自动比对结果；而RDMA子系统模型则模拟了真实的网络对端，使得我们可以在无需实际物理网络和远程主机的情况下，闭环验证整个RDMA数据通路。这种方法是进行计算机系统设计前期功能验证的有效实践。

核心组件设计思路

1. 验证环境

验证环境采用分层结构，针对不同的总线协议（AXI4, AXI4-Lite, AXIS）构建了独立的验证组件复合体（Complex）。每个Complex内部包含：

• 接口（Interface）：封装了与DUT连接的实际物理信号，并定义了用于事务级通信的clocking block和modport。
• 驱动器（Driver）：从序列器（Sequencer）获取事务（Transaction），按照总线协议时序将其驱动到Interface上。
• 监视器（Monitor）：被动监测Interface上的信号，将符合协议的数据流还原成事务，并发送给后续的覆盖率收集器和计分板。
• 序列器（Sequencer）：负责生成和管理测试场景所需的事务序列。

顶层的测试用例（Test Case）通过配置和约束序列器来控制不同的测试场景。计分板（Scoreboard）接收来自DUT各接口监视器以及RDMA子系统模型的事务，进行比对，从而判断DUT功能是否正确。

2. RDMA子系统模型

这是验证平台中的“智能”对端。它不是一个简单的数据回环模型，而是一个能够理解RoCE v2协议栈（包括IB传输层、网络层、UDP等）的轻量化软件模型。其主要功能包括：

• 解析来自DUT的RoCE v2数据包。
• 根据协议规范生成正确的响应包（例如ACK）。
• 在需要时，模拟远程主机发起RDMA读写操作。
• 与验证环境的计分板通信，提供预期的数据内容用于比对。

通过这个模型，我们可以构建复杂的、接近真实应用的测试场景，例如多并发QP（Queue Pair）的操作、错误注入和恢复、以及不同数据长度的传输测试等，从而全方位地验证DUT的协议兼容性和健壮性。

总结

采用SystemVerilog搭建分层、模块化的验证平台，并结合自主设计的协议子系统模型，可以显著提升对复杂IP（如RoCE v2 RDMA子系统）的验证效率和验证完整性。这种方法将测试焦点集中在协议逻辑本身，避免了对复杂物理层或昂贵VIP的依赖，在项目早期即可开展系统级的功能验证，是硬件开发流程中控制风险、保证质量的关键一环。