Corundum项目中的ZynqMP非物理层实现与随机丢包问题分析

问题背景

在基于Corundum框架的ZynqMP平台上实现网络功能时，开发人员尝试在FPGA逻辑内部连接两个AXI Stream接口（而非通过物理层）时遇到了随机丢包问题。具体表现为：当从一个网络命名空间（eth2）向另一个命名空间（eth1）发送ICMP ping请求时，部分响应包会丢失，且这种现象呈现随机性。

现象观察

通过ILA（集成逻辑分析仪）捕获的数据显示，在正常通信情况下，系统会完整执行以下AXI事务序列：

1. 从DMA读取请求包数据
2. 将请求包发送至目标接口
3. 写入响应包描述符
4. 读取CPU内存中的响应包存储位置
5. 写入响应包数据
6. 完成后续相关写入操作

而在丢包情况下，系统会缺失关键的AXI读取事务（步骤4），导致无法获取响应包在CPU内存中的存储位置，进而无法完成响应包的写入操作。

深入分析

通过tcpdump抓包分析发现：

• 请求包始终能正确到达目标接口
• 目标接口确实生成了响应包
• 响应包在某些情况下无法返回源接口

进一步测试发现一个有趣现象：当同时在两个方向上进行ping测试时，丢包现象消失；而单方向测试时则会出现随机丢包。这表明系统可能存在某种流量依赖性问题。

根本原因

经过深入调试，发现问题根源在于AXI Stream接口在FPGA逻辑中的连接方式存在错误。具体表现为：

1. DMA控制器未能正确发起对响应包内存位置的读取请求
2. 导致后续的响应包数据写入操作无法执行
3. 这种错误在特定流量模式下（如双向通信）可能被掩盖

解决方案

修正AXI Stream接口的连接方式后，系统恢复了正常的双向通信能力。具体改进包括：

1. 确保DMA控制器能正确识别和响应所有内存操作请求
2. 验证AXI Stream接口的握手信号完整性和时序
3. 检查并修正可能的死锁或资源竞争条件

经验总结

在FPGA逻辑中实现纯数字网络接口时，需要特别注意：

1. AXI接口协议的严格实现，特别是控制信号的时序
2. DMA控制器的完整功能验证
3. 不同流量模式下的系统行为测试
4. 使用ILA等工具进行实时信号捕获和分析的重要性

这个问题也提醒我们，在复杂系统中，某些错误可能只在特定条件下显现，全面的测试场景设计对于确保系统稳定性至关重要。