verilog-ethernet项目中FPGA ARP响应问题的分析与解决

问题背景

在基于Nexys4（Artix 7）开发板的以太网通信项目中，开发者遇到了一个ARP协议相关的通信问题。项目使用了Xilinx的MII到RMII核心IP，并成功实现了基本的环回测试，验证了PHY接口的正常工作。然而，在尝试发送非请求UDP数据包到PC时，系统出现了ARP响应失效的问题。

问题现象

开发者设计了一个UDP数据包发送逻辑，在仿真环境下（包括RMII PHY接口信号的模拟）工作正常。仿真测试平台能够正确生成ARP响应，使得UDP核心在收到ARP响应后能够成功发送预期的UDP数据包。

但在实际FPGA硬件实现中，行为出现了差异：

1. 当FPGA逻辑生成UDP数据包后，核心会发送ARP请求
2. PC确实返回了ARP响应（通过Wireshark捕获确认）
3. FPGA似乎忽略了这些ARP响应，继续发送多个ARP请求
4. 最终未能发送预期的UDP数据包

问题分析

开发者最初注意到仿真结果与硬件实现之间的差异，特别是发现仿真在详细设计阶段工作正常，但在综合设计阶段出现问题。这提示可能存在时序或资源利用方面的问题。

经过深入排查，发现问题根源在于接收路径的"堵塞"现象。由于开发者最初只关注数据包的发送功能，没有正确处理接收路径的ready信号：

1. 没有设置rx_udp_hdr_ready和rx_udp_payload_axis_tready信号
2. 实际网络中不断有各种以太网数据包流动
3. 由于接收路径没有正确丢弃不需要的数据包，MAC层逐渐被接收到的无用数据堵塞
4. 导致ARP层无法看到ARP响应

解决方案

解决这一问题的关键在于正确处理接收路径的ready信号：

1. 将rx_udp_hdr_ready信号置为1
2. 将rx_udp_payload_axis_tready信号置为1

这样做的效果是：

• 允许UDP头部信息通过接收路径
• 允许UDP有效载荷数据通过接收路径
• 防止MAC层被无用数据堵塞
• 确保ARP层能够及时看到ARP响应

经验总结

这个案例提供了几个重要的经验教训：

1. 全双工通信考虑：即使项目主要关注发送功能，也必须正确处理接收路径，因为以太网本质上是全双工通信。

2. 仿真验证的局限性：RTL仿真（特别是行为级仿真）可能无法完全反映实际硬件中的行为差异，综合后仿真和硬件测试同样重要。

3. 协议栈完整性：在实现网络协议栈时，需要考虑所有相关信号和状态，即使某些功能看似暂时不需要。

4. 调试技巧：使用Wireshark等工具捕获实际网络流量是验证通信问题的重要手段。

后续工作

解决ARP响应问题后，开发者可以继续完善项目：

1. 实现专门的接收逻辑（而非简单的环回）
2. 优化UDP数据包处理流程
3. 考虑添加错误处理和超时机制

这个案例展示了在FPGA上实现以太网通信时可能遇到的典型问题，以及如何通过系统性的分析和调试来解决这些问题。