FPGA网络通信实战：从RGMII时序到UDP协议栈实现

很多朋友把LED、按键、UART、SPI都跑通之后，看着开发板上那个千兆网口，心里都会痒：这东西到底能不能用FPGA做？我的答案是能，而且没那么玄乎。FPGA做网络通信，本质上就两件事：跟PHY芯片把RGMII时序谈拢，再用状态机把ARP、ICMP、UDP这几层协议串起来。这篇是《从近似0基础开始FPGA开发》系列的第7篇，默认你已经有Verilog基础、会看Vivado波形、知道FIFO怎么例化。我会围绕一块市面上最常见的Artix-7开发板讲，我手头是黑金AX7103，网口PHY是88E1512，工程基于Vivado 2020.2，从PHY初始化一路讲到上板后PC能ping通、能收发UDP数据。

1. 想玩网络通信，先看清FPGA站在整个链路哪一层

1.1 一条以太网帧从PC到FPGA要走多少步

很多初学者把“FPGA网络通信”想成一个黑盒子，觉得要么很底层、要么需要抄一堆IP核。其实以太网是一个分层协作的系统，每一层只处理自己该处理的事。PC端发出的数据经过应用层、TCP/UDP层、IP层、MAC层，最终在PHY（物理层收发器）里变成差分信号送到网线。FPGA这边正好反过来：PHY芯片先把差分信号还原成并行数据，FPGA内部再逐层剥掉以太网头、IP头、UDP头，最后拿到真正的有效载荷。

所以FPGA并不是直接去操作网线上的模拟信号，那些编码、时钟恢复、线路驱动工作全由PHY芯片完成。FPGA和PHY之间通过一个标准接口对接，最常见的就是RGMII（Reduced Gigabit Media Independent Interface），这也是本篇的重点。FPGA真正要做的是把MAC层的逻辑用状态机实现：组装以太网帧、解析以太网帧、处理ARP、响应ICMP、收发UDP包。明白了这个分工，你就能理解为什么FPGA做网络通信没有想象中难——因为协议逻辑都是数字电路，状态机写清楚就行。

1.2 平台选型：为什么我建议用GMII/RGMII硬干

做FPGA以太网通信，方案不止一种。用W5500这类集成MAC+PHY的芯片，通过SPI操作很方便，但它本质是把网络协议的脏活累活都封装好了，你学不到FPGA内部怎么处理时序，而且吞吐率上限就在那里，不适合高速场景。用Zynq的PS端GEM控制器也是一个选择，但那是ARM在干活，纯FPGA逻辑的戏份变少。用Xilinx官方的三速以太网MAC IP核当然最省事，但问题是对0基础起步的人来说，IP核配置界面里一堆概念本来就够劝退，调出问题还不好定位，它把该学的底层细节都藏起来了。

我建议在入门阶段用RGMII加自研协议栈的方案，不是因为它简单，而是因为它把以太网的关键知识全部暴露在你面前：PCS/PMA是PHY芯片的事，但你得理解RGMII的DDR采样；MAC封装是FPGA的事，你就得亲手拼CRC和前导码；ARP和UDP的状态机也得自己写。这套走通之后，再用任何现成IP核都是降维打击。硬件上就用常规开发板自带的千兆网口，PHY型号常见的是88E1512、RTL8211FD、YT8531，它们的RGMII接口逻辑大同小异，寄存器细节查数据手册即可。

2. PHY芯片与RGMII接口：先把第一层握手打通

2.1 RGMII的DDR时序到底怎么回事

RGMII在千兆模式下有8根数据线加上时钟和控制线：TXD[3:0]和RXD[3:0]各4位，但时钟是125MHz，数据在时钟上升沿和下降沿都有效，所以一个时钟周期能传8位，正好凑成千兆。TX_CTL和RX_CTL在上升沿表示TX_EN/RX_DV，下降沿表示TX_ER/RX_ER。我用一个比较土的类比来记：RGMII像一趟双向两车道的县道，数据不是一辆车占一整条路，而是同一时刻上下行各有一辆车，但每辆车都可以“侧挂”半个方向的信息。

这个DDR特性是RGMII真正麻烦的地方。FPGA内部逻辑一般是单沿时钟，想要处理RGMII，要么用IDDR原语把上下沿数据拆成两份，要么直接让RXC时钟通过BUFIO进IOB逻辑。发送方向也一样，ODDR原语把两个bit合并到一根线上，分别在时钟上下沿送出。很多朋友第一次写RGMII代码，以为像SPI那样在某个时钟沿采样就行，结果上板后要么一直收不到正确帧，要么CRC疯狂报错，根源往往就是DDR采样没做对。

2.2 MDIO配置与PHY上电复位流程

PHY芯片除了数据接口，还有一根管理接口叫MDIO，两根线：MDC时钟和MDIO数据。通过MDIO可以读PHY的状态寄存器，也能配置工作模式。初次上板，我建议先干一件事：把MDIO时序写对，然后反复读寄存器0x01（BMSR），确认bit2的Link Status为1，再读速度协商结果寄存器确认协商成千兆全双工。如果MDIO连不上，后面全是空中楼阁。

MDIO写起来有几点容易翻车。首先MDC频率不要太高，标准里允许最高25MHz，很多人图省事把系统时钟直接接上去，结果PHY不回应，我习惯用一个分频时钟把MDC降到2.5MHz左右，稳定第一。其次MDIO的读写操作需要严格按照帧格式来：32位前导码、起始码、操作码、PHY地址、寄存器地址等，一位都不能错。最后，大部分PHY的地址由硬件引脚决定，常见值是0x00或0x01，具体看开发板原理图，别想当然。

上电复位时序也值得一提。我用的88E1512要求复位引脚保持低电平至少10ms，释放后PHY还要几百毫秒到一两秒做自动协商。有些人复位信号只拉低几十微秒就释放，PHY根本没起来，MDIO当然读不到数据。建议在上电后用一个计数器延时至少50ms再释放RST_N，然后每隔一段时间轮询Link Status，确认link up后再跑后续协议逻辑。

2.3 不亮link、状态寄存器读不到，怎么排查

我遇到过好几次“MDIO读回来全是F”的情况，最后定位原因五花八门。最常见的是PHY的复位引脚没接对，默认被拉低导致PHY一直处于复位状态；其次是MDIO的上拉电阻缺失，数据线不能正确回读；还有电源时序问题，PHY核心电压起来太慢，MDIO能写但读不稳定。这类问题用波形分析仪或者ILA抓MDIO线上的波形可以很快定位，如果没有仪器，就在FPGA侧把MDIO读回来的原始bit流打出来，对照协议帧格式一个一个看，比瞎猜高效得多。

Link不亮也有几个高频原因：网线插错口或者对方设备没开，这类人为因素要排除；PHY的LED引脚配置不同，有些板子的LED不亮不代表没link，最好通过寄存器判断；交换机和PC网口只支持百兆，而你把RGMII强制配成千兆，自然协商失败。调试时给PC网卡设置固定千兆全双工是常见手段，但也别忽略检查网线是否是千兆八芯线，四芯百兆线在千兆模式下是肯定协商不起来的。

3. 最小协议栈怎么设计：ARP、ICMP、UDP一个都不能少

3.1 为什么先做UDP而不碰TCP

FPGA上实现TCP不是不行，但对入门阶段来说性价比太低。TCP为了保证可靠传输，要维护序列号、确认号、滑动窗口、超时重传、拥塞控制，这些逻辑在状态机里写起来又长又绕，而且很多行为要等到真实网络环境下才能验证，调试成本高。UDP就简单得多：无连接、无确认、没有重传，你只需要把数据塞进UDP头、外面套IP头、再套以太网头，发出去就完事。对数据采集、图像传输、工业控制这类“丢一帧重发一帧”或“丢包可容忍”的场景，UDP已经足够。

不要觉得用UDP就是“低端方案”，实际上很多高速数据采集设备在FPGA和上位机之间走的就是UDP，关键是设计好帧协议和丢包检测机制。入门阶段先跑通UDP，后面遇到更高要求再研究TCP或者用Zynq的PS端协议栈都可以。

3.2 帧结构、CRC32和帧间隙，这三个细节决定你能否被交换机认可

以太网帧发送顺序是：7字节前导码0x55、1字节帧起始定界符0xD5，然后才是目的MAC（6字节）、源MAC（6字节）、以太类型（2字节，ARP是0x0806，IPv4是0x0800），后面跟净荷，最后4字节CRC32校验。CRC计算范围是从目的MAC到净荷结束，不包含前导码、SFD，也不包含CRC本身，这是新手最容易算错的地方。以太网CRC32用的是反射多项式0x04C11DB7，初值为0xFFFFFFFF，结果还要取反。

帧间隙IFG也是很多人忽略的细节。以太网规定两个帧之间至少要有96bit时间的间隔，千兆下就是96ns。如果FPGA发帧时不管不顾地连续发，交换机可能直接丢弃。我自己的发送状态机里专门有一个IFG计数器，每帧发完后强制等待至少12字节时间，稳定得很。最小帧长64字节、最大帧长1518字节也是硬性规定，UDP净荷太短时要在后面填充到46字节以上，净荷超过1500字节必须分片或限制上层数据大小，否则网络设备直接不认。

3.3 接收解析和发送组装的状态机骨架

协议栈说穿了就是两个状态机：一个收，一个发。我习惯把接收解析分成IDLE、PARSE_MAC、PARSE_IP、PARSE_UDP、WRITE_DATA几个状态。在IDLE状态等RGMII的RX_DV拉高，开始收前导码；之后逐字段解析MAC头，如果以太类型是0x0806就转ARP处理，是0x0800就继续解析IP头；IP头里看协议字段，0x11就是UDP，0x01是ICMP；UDP头解析出端口后，把有效载荷写进FIFO。这里的关键是不要在一个状态里塞太多事，每收到一个字节就做一个判断，状态转移要清晰，否则定位问题的时候会疯掉。

发送状态机我分成IDLE、WAIT_DATA、SEND_PREAMBLE、SEND_MAC、SEND_IP、SEND_UDP、SEND_CRC、WAIT_IFG。从FIFO里拿到数据后开始组装帧，算IP头校验和、UDP长度、CRC32。这里建议先组帧缓存到一个RAM，再统一算CRC，而不是边发边算，因为CRC需要整帧数据才能算完，边发边算的话CRC字段根本来不及补进帧尾。发送状态机里还有一个细节：CRC算完后要补在帧尾，然后立刻进入WAIT_IFG状态，不能直接回IDLE去抢发下一帧。

3.4 FIFO深度与跨时钟域数据通路

网络PHY的RXC时钟是125MHz，而FPGA内部协议逻辑通常跑在系统时钟域，两个时钟不同源，直接拿系统时钟去采样RXC过来的数据，必然出问题。正确做法是RXC时钟域内先把RGMII数据还原成字节流，写入异步FIFO，系统时钟域再从FIFO读出做协议解析。这个设计和UART的跨时钟域处理是同一个思路，区别只是速率从几MHz变成了125MHz，对FIFO的读写时序要求更高。

FIFO深度怎么选？接收方向我建议至少2048字节起步，因为需要等一整帧校验通过后，上层才敢把数据拿走，也就是所谓的“帧缓冲”模式。如果后续要连续收多个大帧，比如图像传输场景，FIFO深度就得开到16KB甚至更大，或者外挂DDR。发送方向也类似，系统时钟域把数据写入发送FIFO，发送状态机从FIFO里按帧取数，FIFO深度至少能容纳一两个最大以太网帧，也就是1518字节乘2比较保险。如果FIFO深度小于一帧大小，但又把整帧数据都安排好了，很可能会出现FIFO溢出丢数据的情况，这类问题在Wireshark里表现为“PC发了很多包但FPGA只收到一部分”。

4. 时序约束：综合工具不知道你的RGMII该怎么采

4.1 千兆RGMII的相位关系，以及IDELAY的必要性

RGMII接口标准规定，发送方输出的数据和时钟是边沿对齐还是中心对齐，在千兆模式下有讲究。很多PHY在接收方向会输出一个内部移相后的时钟，让数据在时钟中心稳定，但不同的PHY实现不一样。88E1512这类芯片可以通过寄存器配置是否启用内部的RX delay、TX delay，如果硬件设计时把对应的strap引脚设置错了，就会出现“数据刚好在时钟边沿上翻转”的尴尬状态，采样结果不稳定，表现为时好时坏、CRC偶发错误。

遇到数据与时钟边沿对齐的情况，FPGA侧可以通过IDELAY原语把RXD路径上的数据向后延迟1~2ns，让数据对齐到时钟中心。7系列FPGA的IDELAYE2每个tap大约78ps，具体延迟值可以在调试时通过ILA观察数据是否稳定来确定。我自己的经历是：某块板子同样的RGMII逻辑，换个PHY型号就要重新调整延迟参数，这也是为什么我不建议把RGMII代码写得“自适应”，而是在工程里保留可配置的IDELAY参数。

4.2 输入延迟和输出延迟约束怎么填

综合工具不知道RGMII接口外面的芯片时序，需要你用约束告诉它。Vivado里最核心的就是set_input_delay和set_output_delay。RXC时钟周期是8ns（125MHz），RXD相对RXC的有效数据窗口由PHY芯片数据手册给出，比如某PHY手册上写着RXD相对RXC的skew范围是-0.4ns到+2.4ns，那么输入延迟约束就类似这样：

set_input_delay -clock [get_clocks rgmii_rxc] -max 2.400 [get_ports {rgmii_rxd[*]}] set_input_delay -clock [get_clocks rgmii_rxc] -min -0.400 [get_ports {rgmii_rxd[*]}]

这里max和min不是随便写的，它们决定了工具能否让内部采样逻辑避开建立时间和保持时间违规。输出方向同理，要约束TXD和GTXCLK的延迟关系，保证对端PHY能稳定采到数据。我见过很多人写完RGMII逻辑后完全不写时序约束，综合运行时序的人一脸茫然，上板后偶尔能通偶尔不能通，最后发现是工具布局布线的结果不在期望相位上。

4.3 异步复位、时钟域划分与后端工具才是稳不稳的关键

除了IO延迟约束，还有几个影响上板稳定性的因素。RXC时钟域里的复位一定不能直接用全局异步复位，否则FIFO内部可能出现复位释放时序不一致的问题，最好做异步复位同步释放。系统时钟域的复位也同样处理。另一个点是RGMII数据线最好没经过普通LUT逻辑，直接进IOB里的IDDR原语，否则路径延迟难控制，工具也很难满足时序约束。

时钟域划分也建议提前规划清楚：RXC时钟域只管RGMII接收和异步FIFO写入，系统时钟域管协议解析、ARP、发送状态机、发送FIFO读取。每个时钟域内部逻辑尽量保持简单，跨时钟域的地方全部用FIFO或两级同步器，不要图方便在RXC时钟域里直接去读FIFO的空满信号。这样划分后，后端实现工具能更容易地把关键路径收敛好，上板稳定性会高很多。

5. 上板联调实录：从PC ping不通到连续发几千帧不丢

5.1 调测过程的分层定位法

上板联调我强烈建议按层来，不要一上来就发UDP。第一步，用ILA抓MDIO和PHY状态寄存器，确认PHY已经link up、协商成千兆全双工。第二步，只实现ARP应答逻辑，在PC上ping FPGA的IP，观察PC端能否学到FPGA的MAC地址。第三步，实现ICMP Echo应答，让PC能ping通FPGA。第四步，做UDP回环，PC发什么FPGA就原样发回来，Wireshark里确认包内容和校验都正常。每一步都有明确的“成功标志”，出了问题时也能快速定位是PHY的问题、MAC层问题还是协议层问题。

调试时Wireshark是神器，但要用对。建议把PC网卡IP固定成192.168.1.10，FPGA的IP设成192.168.1.88，避免动态IP干扰。在Wireshark里配合过滤语法eth.type==0x0806看ARP、icmp看ping、udp.port==你定义的端口看UDP。如果RX方向能看到PC发来的包，但FPGA没有回应，基本可以断定是FPGA接收解析逻辑的问题；如果FPGA侧ILA里收到了完整数据但发不出去，那就查发送状态机和CRC。

5.2 一个真实案例：ARP能回，ping却不通，最后卡在ICMP type判断

这个故事很有代表性。我的ARP应答逻辑已经通了，PC能正确学到FPGA的MAC地址，但ping的时候一片超时。我用ILA抓接收侧信号，发现ICMP请求已经进到了协议栈内部，ICMP type也确实是8（Echo请求），但回包一直没出来。查了大半天，最后发现是发送回包时把ICMP头里的Type字段从8改成0后，忘了重算ICMP的校验和。PC端收到Type=8的“Echo Reply”，直接判定包无效就丢了，表现就是ping不通。

这类问题很隐蔽，因为不重算校验和的代码在语法上没问题，查CRC也不一定能立刻发现，毕竟以太网层的CRC是好的，ICMP报文内部校验才是坏的。后来我在设计里定了一条规矩：凡是修改IP头或ICMP/UDP头中的任意字段，必须重新计算对应校验和。IP头校验和的计算方法是把20字节的IP头按16bit一组求和，进位回卷，最后取反，写成一个子模块复用，省得每次手工算。

5.3 高频问题排查表与Wireshark使用要点

我把网络联调阶段遇到过的典型问题整理成一张表，方便卡住时快速对号入座。

Wireshark里还有一个容易误判的点：PC网卡开启了checksum offload后，Wireshark抓到的PC发出包可能显示校验和错误，其实那些包是好的，只是抓包点在校验和填充之前。这时候不要急着怀疑FPGA，先对比发送端和接收端的完整链路，再决定往哪边查。

5.4 调通之后能做哪些事：从回环测试到图像数据以太网传输

能ping通、能UDP回环之后，恭喜你，FPGA网络通信这个方向你已经入门了。我通常会建议下一步做一个简单的串口转以太网或ADC数据以太网传输，把UART或SPI采集到的数据按自定协议打包成UDP帧发给上位机。这个过程中你会遇到新的带宽计算问题：比如用UART 115200bps收20字节一帧，以太网每帧至少64字节，算下来以太网带宽利用率低得可怜，需要做多包合并缓冲。又比如SPI ADC 10Msps 16bit，数据率是20MB/s，千兆以太网线速是125MB/s，理论带宽够，但中间有协议开销，还得算帧头、填充、CRC，这些实战换算比单纯跑demo有价值得多。

再往后可以做图像传输项目，FPGA把摄像头采集的图像经过缓存、打包成UDP帧发给PC，这又引入了一个新的设计问题：图像数据按行/按帧拆包，上位机怎么通过IP头里的ID字段和UDP payload序号重组。这类方向和图像处理、DDR3/4缓存也经常组合在一起。真到了需要更高吞吐量或更可靠传输的阶段，再回头用Xilinx三速以太网MAC IP核或者Zynq PS端的GEM，你会明显感觉到自己对底层原理的理解完全不同了。

最后分享一个调网络时让我很受益的小习惯：每个模块都留一个独立的调试寄存器，比如PHY状态、收到帧计数、CRC错误计数、FIFO溢出标志，通过串口或简单的AXI-Lite接口读出来。这样在PC端ping半天不通的时候，你能直接通过读寄存器快速判断是PHY没link还是接收错误太多，不用一次次接ILA重新综合。调网络通信这种事，定位问题的速度往往比写代码的速度更能决定项目能走多远。