RDMA Scheduler + TX + Completion RTL 开发经验分享

RDMA Scheduler + TX + Completion RTL 开发经验分享

1. 背景

在芯片验证和 RTL 开发过程中，很多同学可能遇到这样的问题：

明明文档写好了模块接口，但实际开发时不知道从哪里开始，或者模块之间的交互链路不清晰。

今晚我在 RDMA 子系统（RoCEv2 子集）上实践了Scheduler → TX → Completion的最小闭环，收获了一些可复用的经验。

---

2. 经验总结

2.1 从最小闭环出发

• 原则：先做一个"可运行的最小闭环"，保证从请求提交到 Completion 上报完整路径走通。

• 做法：

  1. Scheduler 增加简单状态机（IDLE → FORWARD → DONE）。
  2. TX 仅透传请求，并在最后一拍生成 tx_done。
  3. Completion 模块监听 tx_done，输出 comp_valid。

• 收获：即便 QP、Memory Interface、RX Path 尚未完善，也能验证 Scheduler 和 TX/Completion 的交互逻辑。

---

2.2 状态机设计要明确责任

• Scheduler 的状态机不仅仅是"有数据就发"，而是要区分：

  • IDLE：接受新请求
  • FORWARD：处理中间拍数据
  • DONE：请求结束，准备返回 IDLE

• 经验：明确每个状态的边界条件，可以避免多拍请求丢失或重复转发。

---

2.3 Completion 信号设计

• 很多初学者容易忽略 Completion 的产生逻辑。

• 实践经验：

  • TX 在最后一拍请求时生成一拍 tx_done。
  • Completion 模块只对 tx_done产生一个单拍 comp_valid。

• 好处：保证了最小闭环可观测、可验证。

---

2.4 模块化复用

• RX、QP、Scheduler、TX、Completion 都是独立模块。

• 技巧：

  • 初期用透传逻辑快速集成。
  • 后续再逐步替换为真实功能。

• 经验：这种策略可以减少前期调试压力，同时验证接口契约是否合理。

---

2.5 验证策略

• 不用一开始就做完整 UVM 测试。

• 快速验证方法：

  1. 从 Scheduler 侧驱动请求。
  2. TX 模块生成 tx_done。
  3. Completion 输出 comp_valid。
  4. Monitor 打印 comp_valid，确认闭环。

• 经验：先验证闭环，再增加复杂功能，能显著降低调试难度。

---

3. 遇到的问题与教训

1. 接口不稳定导致 RTL 改动大

   • 经验：接口冻结之前，可以先用透传占位模块。

2. Completion 缺失导致闭环不可观测

   • 教训：即便是最简单的闭环，也必须有 Completion 或状态反馈。

3. 状态机边界条件处理不当

   • 教训：多拍请求容易出错，必须在设计初期明确 IDLE/FORWARD/DONE 条件。

---

4. 小结与利他建议

• 最小闭环优先：先走通数据路径，再逐步增加复杂逻辑。
• 状态机清晰：责任边界明确，后期扩展不踩坑。
• Completion 可观测：闭环可验证，调试更快。
• 模块独立、透传占位：接口先确定，实现后替换，降低前期开发成本。
• 快速验证：不用一次写完所有 test，先驱动核心模块，确认信号流。

对于刚入门 RTL 或芯片验证的同学，这套方法可以在保证功能正确的前提下，高效推进开发，同时方便验证环境逐步完善。

---