1. 这块UDP模块到底要解决什么问题前七篇我们把FPGA开发环境、时序约束、LED闪烁、UART回环这些基础链路都过了一遍如果你一路跟下来手里应该有一套能跑通的上板流程也习惯了写代码—综合—上板—调波形的循环。这一篇进入一个很多人想碰又不太敢碰的领域——FPGA和外部设备之间的以太网通信具体实现是UDP模块的RTL代码。先说清楚一件事FPGA上的UDP通信不是像STM32那样调一个库函数就能发数据包。STM32的MAC和PHY都集成在芯片内部驱动帮你把ARP、IP、UDP头全封装好了。但在FPGA里除非你用的是ZYNQ这种带ARM硬核的芯片否则从以太网帧的最底层到UDP负载的最顶层每一个字节都得靠Verilog自己拼。对于纯FPGA的RTL工程师来说用RTL实现UDP协议栈是绕不过去的基本功。这篇博客要解决的核心问题非常聚焦一个几乎没有RTL网络基础的开发者如何从零开始设计一套能在FPGA上跑的UDP收发模块。我会按照协议拆解 — 发送通路设计 — 接收通路设计 — 跨时钟域处理 — 上板调试 — 系统验证的链路来讲代码会贴出可综合的关键片段不是伪代码是能在Vivado/Quartus里直接用的RTL。读完以后你应该能自己拼出带UDP通信的图像采集、数据采集或者控制回传系统。需要提前说明真正的完整UDP协议栈有很多边界情况比如分片重组、ICMP错误回报、多播组管理这些在这篇文章里不会全部涉及。咱们走的是一条能用、能上板、能实测跑通的务实路线。以最常用的1Gbps以太网、RGMII接口、88E1512 PHY芯片为硬件基线我默认你已经会看波形图会基本的Vivado操作懂Verilog的状态机写法。2. 硬啃协议栈还是直接调IP核先把这个老问题摊开讲说到FPGA做以太网很多人第一反应是用Vivado里的Tri Mode Ethernet MAC IP核不就行了吗。确实可以Xilinx和Altera都提供完整的MAC IP核内部封装好了GMII/RGMII接口、流控、CRC校验这些底层功能。但我不推荐新手一上来就切IP核理由有三个。第一个理由是IP核的接口复杂度远高于预期。以Xilinx的Tri Mode Ethernet MAC为例你要处理s_axis_tx_tdata、s_axis_tx_tkeep、s_axis_tx_tlast、s_axis_tx_tuser这种AXI-Stream侧的信号还要处理客户侧和MAC侧的时钟域转换再加上配置接口、状态接口、统计接口。一个没有任何MAC层背景的人面对这些信号很容易懵——你根本不知道tuser这个信号到底该什么时候拉高也不知道为什么发送偶尔卡死。第二个理由是IP核的仿真和上板调试链路更长。Vivado的MAC IP核有对应的example design但example design里带了一堆脚本、约束和测试代码新手想在里面做减法删掉不需要的部分难度反而比从零写一个简易MAC还大。我在帮别人排查问题时见过太多在IP核example design里迷路的案例。第三个理由也是最重要的UDP通信的本质不在MAC层而在MAC层之上的帧结构组织。MAC层只负责把一整帧数据从一个口搬到另一个口但谁来决定发出去的数据是什么内容目的MAC填什么IP头校验和怎么算UDP长度字段怎么填——这些逻辑IP核一概不管。你依然需要自己做ARP模块、IP校验和模块、UDP组帧模块。所以你迟早要把UDP层的逻辑亲手写一遍只是早晚问题。当然如果你做的是商用产品对稳定性要求极高要用VLAN、巨型帧、1588时间同步这些高级特性那直接上IP核和驱动是正路。但作为学习路径我强烈建议先用纯RTL把UDP收发链路跑通。这个过程能让你对以太网的每一层产生肌肉记忆后面再切IP核你会发现自己看接口文档的速度快了一个量级。为了照顾还没有以太网基础的读者我先把后面会反复出现的几个概念快速过一遍这些是UDP协议栈的地基必须烂熟于胸。MAC地址48比特烧录在网卡/PHY中决定数据帧在局域网里发给谁。FPGA板卡的MAC地址一般是厂商预设的也可以用软核寄存器把它配置成任意值。IP地址32比特决定设备在网络中的逻辑位置。FPGA作为设备端时需要给自己分配一个固定IP比如192.168.1.10。端口号16比特UDP层用来区分同一IP下不同的应用。发送数据时需要在UDP头里指定目的端口接收数据时可以自行约定端口号。ARP协议IP地址到MAC地址的映射。你想把UDP包发给192.168.1.2这台电脑但你不知道电脑网卡的MAC地址必须先发一个ARP请求问谁是192.168.1.2请把你的MAC告诉我。RGMII接口Reduced Gigabit Media Independent Interface用4根数据线控制线在时钟上升沿和下降沿各采一次达到1Gbps速率。这是FPGA和PHY芯片之间最常见的接口标准。这个地基图可能比文字描述更直观由于Markdown限制没法画图我直接用一个发送帧的字节序来呈现你看完就明白一个UDP包在线上长什么样了| 前导码(8B) | 目的MAC(6B) | 源MAC(6B) | EtherType(2B) | IP头(20B) | UDP头(8B) | 负载(NB) | FCS(4B) |前导码7字节0x55 1字节0xD5PHY芯片会自动处理FPGA侧一般不关心。EtherType0x0800表示IPv40x0806表示ARP。IP头版本0x45、总长度、标识、TTL、协议17表示UDP、源IP、目的IP、首部校验和。UDP头源端口、目的端口、UDP长度8负载字节数、校验和IPv4允许为0。FCSCRC32校验MAC层计算并填充接收方校验错误会直接丢帧。整条链路的逻辑关系是FPGA通过RGMII口和PHY芯片交换数据PHY把信号变成差分对跑到网线上。FPGA内部要完成的事就是从AXI-Stream或者自定义接口收到用户数据加上UDP头、IP头、MAC头一路送到RGMII发送引脚。接收方向则是反过来去掉每一层头把负载提取出来交给用户逻辑。了解了这些下面就可以进入正戏了——用Verilog把这条链路一条一条地搭出来。3. 发送通路的代码骨架从用户数据到RGMII引脚3.1 模块划分与信号约定我习惯把UDP发送通路拆成四级用户数据打包层 → UDP/IP组帧层 → MAC发送层 → RGMII输出层。每一层只干一件事信号清晰出问题也好定位。不会有那种一个always块里又拼MAC又拼IP头的混乱局面。为了让你更快理解我把最常用的发送接口定义出来这是我自己项目里的习惯写法// 用户接口握手协议valid拉高时data有效ready拉高时接收方可以接收 input user_tx_clk, // 用户时钟 input user_tx_valid, // 数据有效 input [7:0] user_tx_data, // 字节数据 output user_tx_ready, // 接收器可以接收 input user_tx_last, // 最后一字节这个接口和AXI-Stream几乎一样区别只是没有tkeep和tuser避免把新手绕晕。用户逻辑只要准备好数据在valid和ready同时拉高的周期把数据推给发送模块然后拉高last表示帧结束发送模块会自动完成全部打包工作。3.2 UDP帧构建一个状态机逐步切状态UDP发送的核心是一个状态机状态跳转的每一步对应一个头部字段的拼接我贴出核心代码框架localparam IDLE 3d0; localparam SEND_MAC 3d1; // 目的MAC 6B localparam SEND_IP 3d2; // 源MAC 6B EtherType 2B localparam SEND_IPHDR 3d3; // IP头 20B localparam SEND_UDPHDR3d4; // UDP头 8B localparam SEND_DATA 3d5; // 用户数据 localparam SEND_LAST 3d6; // 等待用户last信号 localparam DONE 3d7; // 帧结束CRC由MAC层处理 always (posedge clk or negedge rst_n) begin if (!rst_n) begin state IDLE; tx_byte 0; byte_cnt 0; end else begin case (state) IDLE: begin if (user_tx_valid user_tx_ready) state SEND_MAC; end SEND_MAC: begin if (tx_done) state SEND_IP; end // 每个头部字段以8比特为一拍发出计数到对应长度后跳转 ... endcase end end这里每个状态内部做的事情非常规整用byte_cnt记录当前状态已经发出了多少个字节计数到预设长度就跳转。比如SEND_MAC状态发出6个字节目的MAC、6个字节源MAC、2个字节EtherType一共14个字节然后跳转到SEND_IPHDR。3.3 首部校验和的计算一次到位不拖泥带水IP头校验和是所有新手最容易写错的地方也是最值得花时间说清楚的。IPv4首部校验和的算法是把IP头按16比特为单元分组全部相加如果相加过程中产生进位即和超过16比特把进位加到低位对最终结果取反填入校验和字段。在FPGA里我常用的做法是先临时把校验和字段置为0用组合逻辑算出校验和在发送到校验和字段这个字节的时候直接输出计算好的值。这样的好处是不需要单独的校验和计算周期状态机流程最简洁。function [15:0] ip_checksum; input [159:0] ip_header; // 20字节IP头校验和字段已置0 integer i; reg [31:0] sum; begin sum 0; for (i 0; i 10; i i 1) sum sum ip_header[i*16 : 16]; while (sum[31:16] ! 0) sum sum[15:0] sum[31:16]; ip_checksum ~sum[15:0]; end endfunction这个function在Vivado里可以综合仿真也没问题。实际运行证明用这种方式计算校验和上板抓包一秒通过。3.4 为什么UDP校验和可以填0很多人第一次看到UDP头的校验和字段容易卡住。UDP校验和的计算范围比IP校验和更广它覆盖整个UDP数据报UDP头数据而且还要加一个伪首部源IP、目的IP、协议号、UDP长度。新手在这里计算错的概率很高。好消息是IPv4下UDP校验和允许填0表示发送端没有计算校验和接收端可以不校验。这在FPGA与PC局域网通信场景里完全够用。我自己的实现里UDP校验和直接填0省掉一个复杂的伪首部求和模块。网上有些教程把UDP校验和算法写得很复杂但对于咱们这种板卡和PC之间调试的场景填0是务实且合法的做法。提示UDP校验和填0仍然符合RFC 768规范接收端不会因为这个字段为0而丢帧。如果你的应用场景经过三层交换机或者某些严格防火墙建议还是把校验和算对但纯实验室环境不需要担心。3.5 把帧头和数据拼到一起发送帧头和数据拼接的通用做法是在头部状态机每个状态里把待发送的字节送到一个字节宽度的发送通道同时往MAC层送valid信号。用户数据到达的时候直接从用户FIFO里读字节直到读到last。这段代码我会强调一个工程细节发送FIFO不能少。我见过有人在RTL发送路径上直接接用户逻辑产生的数据不做FIFO缓冲结果就是数据只要稍微来晚一拍MAC层发送就出现气泡帧与帧之间的间隔就会不对。用FIFO之后用户逻辑和UDP帧构建模块之间解耦用户侧可以突发传输发送侧可以等凑够一整帧再开始往MAC层发实际效果非常稳定。// 从用户FIFO读数据组装UDP帧 wire [7:0] fifo_dout; wire fifo_empty; wire fifo_rd_en; // 当状态在SEND_DATA并且MAC层请求数据时从FIFO读取 assign fifo_rd_en (state SEND_DATA) mac_tx_ready; assign user_tx_ready (state SEND_DATA) mac_tx_ready; // 数据通路头部状态下发head_data数据状态下发fifo_dout reg [7:0] tx_data_reg; always (posedge clk) begin case (state) SEND_MAC: tx_data_reg mac_header[47:40]; SEND_IP: tx_data_reg ip_header[159:152]; ... SEND_DATA: tx_data_reg fifo_dout; endcase end这个头部用寄存器拼接数据走FIFO的双通道模式是整个发送模块的核心思路。头部数据量小且固定用寄存器组存着慢慢发用户数据量大且随机必须用FIFO缓冲。两者在发送字节通道上二选一互不干扰。4. 接收通路的代码设计拆帧像削洋葱4.1 接收侧的层级解包接收方向就是发送的逆过程。RGMII接收引脚的数据进来后先经过一个输入寄存器和同步器把异步信号打稳然后经过MAC接收层做CRC校验和帧界定。校验通过的帧去掉FCS剩下的内容送进上一层的解析模块。这个解析模块做的事情很清晰用状态机逐字节判定当前处于什么解析状态localparam PARSE_MAC 3d0; localparam PARSE_ETH 3d1; localparam PARSE_IP 3d2; localparam PARSE_UDP 3d3; localparam PARSE_DATA 3d4; always (posedge clk) begin if (rx_valid) begin case (state) PARSE_MAC: begin // 解析6字节目的MAC 6字节源MAC后检查EtherType // 0x0800跳转到IP解析0x0806跳转到ARP处理 end PARSE_IP: begin // 解析20字节IP头取出源IP、总长度、协议号 // 检查协议是否为17(UDP)不是则丢弃整帧 end PARSE_UDP: begin // 解析8字节UDP头取出源端口、目的端口、UDP长度 // 如果目的端口不匹配帧可以直接丢弃 end PARSE_DATA: begin // 把负载数据写入用户FIFO end endcase end end接收的关键在于逐字段提取并核对。以太网帧没有长度指示它的长度是由帧间隔推断出来的所以你必须靠IP头里的Total Length字段来判断数据什么时候结束。比如IP头显示Total Length为50减去20字节IP头和8字节UDP头负载就是22字节持续接收22个字节就结束一帧。4.2 过滤策略谁的东西留下谁的东西扔掉接收方向最容易被忽视的是帧过滤。我见过大量FPGA网络代码的通病是接收模块把所有的包都解出来塞给用户FIFO包括广播包、组播包、别人的单播包、ARP应答、甚至其它协议类型的包结果用户逻辑每隔几毫秒就被无关数据打断一次。正确的做法是在解析阶段就做三层过滤MAC层过滤目的MAC和自己的MAC不一致且不是广播地址FF:FF:FF:FF:FF:FF直接丢弃。IP层过滤目的IP和自己的IP不一致直接丢弃。UDP层过滤目的端口不是自己约定的端口比如用户自定义端口直接丢弃。这三条过滤在代码里实现起来就是几个比较器每层解析出对应字段后立刻和预设寄存器比较不满足条件就拉一个drop_frame信号同时把状态机跳到丢弃状态一直等帧结束。4.3 接收FIFO的设计要点接收通路的FIFO比发送侧更要讲究。因为发送方向是你自己控制节奏数据全是自己产生的接收方向是外部网线随机到达的数据完全没有规律可言随时可能一帧接一帧地涌进来。如果用户逻辑来不及处理FIFO就会溢出溢出就会丢包。我的方案是解析完成的数据先写入一个ASYNC FIFO跨时钟域给用户逻辑。FIFO深度至少要能放下几帧完整的最大UDP数据包。比如你的最大帧负载是1400字节深度至少应该配2048字节。我实际项目里用4096字节深度应对突发完全没有问题。FIFO读出的接口同样用valid-ready握手和发送方向的接口保持一致。这样用户逻辑里收发两边的接口风格统一后续如果要把这个UDP模块封装成AXI-Stream外设改动也小。4.4 接收时最容易踩的坑总长度和实际接收不一致上板调试时经常出现一种诡异现象Wireshark抓到的包长度正常但FPGA接收到的数据总是少几个字节或者多几个字节。这通常是IP头里的Total Length字段和实际收到的字节数对不上。请注意IP Total Length是包括IP头和UDP头的总长度不是纯数据长度。很多人在这里少加了20或者8导致后面所有数据都错位。我排查过不少新手的代码最后发现就错在这一行// 错误写法只有负载长度 rx_len ip_total_length - 20 - 8; // 正确写法IP头总长度已经包含了IP头和UDP头 rx_len ip_total_length - 28;所以设计的时候我会把rx_frame_len直接存成ip_total_length - 28然后在数据接收状态用来计数一步到位。5. 跨时钟域和FIFO缓冲这里不过关上板必翻车5.1 为什么必须聊跨时钟域FPGA做以太网时钟问题绕不开。PHY芯片输出的RX时钟125MHz和FPGA内部用户逻辑时钟可能是100MHz、150MHz甚至200MHz经常不是一个频率。你不可能让所有逻辑都跑到125MHz也不应该把PHY的RX时钟当成唯一时钟——这会导致后续加逻辑时时序收敛非常痛苦。跨时钟域的处理标准做法就是FIFO。发送方向用户逻辑把数据写到发送FIFO写时钟是用户时钟UDP发送模块从FIFO读数据读时钟是125MHz读侧还需要变成RGMII发送时序。接收方向反过来PHY RX时钟域把数据写完接收FIFO用户逻辑用用户时钟读出来。Xilinx环境下直接用xpm_fifo_async原语Quartus环境下用dcfifoIP核。这两个都是跨时钟域FIFO的标准做法不要自己用双口RAM裸搭除非你想接受亚稳态的毒打。5.2 FIFO参数的具体配置FIFO配置看起来是件小事但参数配错会让整个系统偶尔好用偶尔抽风。我给出我实测稳定的一组参数参数发送FIFO接收FIFO说明数据位宽8 bit8 bit字节流接口深度20484096深度宁大勿小读模式First Word Fall ThroughFirst Word Fall Through减少握手气泡跨时钟域是是用户时钟 → 125MHzFWFT模式这里特别提一下普通Standard模式FIFO需要先拉读使能下一拍才出数据这在高速网络通路里会导致每一个字节的读取都延迟一拍状态机会变得不好写。FWFT模式下第一个数据就挂在输出端你只需要等valid信号少了一个拍频的延迟状态机写起来清爽很多。5.3 空满信号的处理宁可少收不可错位FIFO的空满信号处理是另一个经验集中的地方。很多人直接拿empty信号当接收完成标志在empty拉低时立刻开始读结果读到的数据是错的或者重复的。原因在于跨时钟域FIFO的empty信号有延迟可能在写侧已经写入数据但读侧还没有同步到。稳妥的做法是FIFO状态机里增加一个至少两拍的同步延迟在确认empty连续两拍为低后才开始读。这个白白增加的延迟不会影响性能因为UDP通信本身对延迟不敏感但能规避大量跨时钟域同步带来的毛刺问题。6. 上板调试实录三次翻车现场和最终的解决办法写代码从来不是最难的部分真正的分水岭是上板调不通的时候能不能沉住气排查。这段我分享三次让我印象深刻的翻车经验你在自己调试时很可能遇到一模一样的症状。6.1 第一个坑FPGA发不出任何数据Wireshark什么都看不到现象代码仿真全对时序约束全部满足但上板后Wireshark里一个包都抓不到。排查链路先用示波器量RGMII_TX_CLK和RGMII_TX_CTL看有没有信号活动再量TX_DATA[3:0]如果数据线上一直无翻转说明MAC层压根没有把数据推给PHY。逐级排查后发现问题出在MDIO配置没有完成88E1512需要复位后延时一段时间然后通过MDIO接口把寄存器配好比如把RGMII模式从SGMII切换到RGMII、使能内部延迟、关闭自动协商。很多板卡上电默认不是RGMII模式PHY等不到配置就躺平了。解决办法FPGA的MDIO管理模块在复位释放后先等待100ms用计数器计时然后依次写PHY寄存器0软复位、寄存器41000Mbps全双工、寄存器0x1cRGMII内部延迟使能。改完之后Wireshark立刻能看到包。注意MDIO配置不成功后续所有都白搭。很多人调UDP调两天没进展最后发现是PHY工作模式没配好这是最冤的排错经历。6.2 第二个坑PC能收到FPGA的包但FPGA收不到PC的包现象发送方向完全正常PC能看到UDP广播包或单播包但从PCping或发送UDP包给FPGAFPGA侧FIFO里始终是空的。排查链路先排除PHY方向的问题用示波器看RGMII_RX_CLK和RGMII_RX_CTL发现RX时钟是有的再用ILA抓接收状态机发现状态机一直停在PARSE_MAC的第一个字节判定帧没有真正开始。怀疑CRC校验不通过导致接收MAC层把帧整个丢弃。看一眼MAC接收模块的实现发现CRC校验逻辑写错了CRC计算输出没有对齐到帧末字节差了一个周期。这样每个帧的CRC都校验不过接收方向就直接把合法帧也丢了。芯片的数据手册写得很清楚FCS占用帧的最后一个4字节CRC引擎在收到最后一个有效数据字节后一个周期才能输出校验结果状态机必须等待这段时间不然截断位置就错了。解决办法在接收状态机里增加一个CRC_CHECK周期在完成负载接收后等待CRC计算输出并比对比对正确后才开始下一帧。修改后PC发送UDP包FPGA接收FIFO立刻有数据。6.3 第三个坑能通信但传输速度上不去每秒只能发几十kB现象PC和FPGA之间能互相收发但每秒钟最多只能传几十KB数据完全达不到千兆以太网的带宽。排查链路先用iperf3打流发现速度确实惨不忍睹。观察发送方向发现数据在发送FIFO经常为空用户逻辑产生的数据是一阵一阵的中间有大量空档。用ILA看用户时钟域的数据产生逻辑发现是中断驱动的数据采集方式每次中断之间gap太长。问题的根子是用户逻辑本身没有形成连续的数据流不是UDP模块的锅。UDP模块已经把帧间隔压到最小了但上游没数据只能空等。解决办法把用户数据产生逻辑改成双缓冲模式用户在采集缓冲区A的时候发送模块从缓冲区B取数据。这样数据流的连续性立竿见影实测速度提升了一个数量级以上。这个教训说明UDP模块代码再高效也救不了上游数据源的低效设计。这三个坑基本代表了以太网调试的三大类问题PHY配置、CRC边界、数据源吞吐。你如果遇到类似现象直接从这三个方向入手能省很多时间。7. 用专业工具做全链路验证7.1 用UDP测试工具做基本收发验证代码跑起来后第一步验证用最简单的工具。Windows平台我推荐用NetworkAssist网络调试助手Linux平台可以用nc -u命令。设置好目的IP和端口FPGA侧把收到的数据原样回传PC端连续发送一组数据如果回传内容和发送内容一致基本链路就通了。这里注意网络调试助手的发送间隔默认可能很大你需要手动把循环发送的时间间隔尽量调小才能模拟真实的高速UDP流。7.2 用Wireshark做协议级验证网络调试助手只能告诉你收到数据了但收没收到正确的数据帧还是要靠Wireshark。抓包后看三层关键信息Ethernet II层目的MAC是否指向PC网卡源MAC是否是FPGA板卡的MACEtherType是否为0x0800Internet Protocol层源IP是否为FPGA设置的IP目的IP是否为PC的IPIP首部校验和是否为correctUser Datagram Protocol层源端口、目的端口是否符合预期UDP长度字段是否等于负载长度加8。这三层检查都通过说明你的UDP模块协议正确性没有大问题。7.3 用iperf3做极限打流如果要做性能验证iperf3是绕不过去的标准工具。在PC端跑如下命令iperf3 -u -c 192.168.1.10 -p 5001 -b 800M -t 30 -l 1400这句话的意思是用UDP模式向FPGA的192.168.1.10:5001端口发送数据目标带宽800Mbps持续30秒每次负载1400字节。FPGA端需要先把收到的数据丢弃或者转发出来否则iperf3会因为没收到回包一直报错。如果FPGA收到的速率稳定在800Mbps而Wireshark抓包没有CRC错误和丢帧性能就算合格。要注意的细节是iperf3打流时FPGA的接收FIFO深度要足够大。1400字节的包800Mbps打进来每秒钟大约7万个包如果你的FIFO只有256字节深度不到一毫秒就溢出了。7.4 抓包数据与代码设计的对照检查我每次写完UDP模块上板后会拿Wireshark抓一包把抓到的原始十六进制字节一个一个和RTL代码里拼出来的值对一遍。这个过程看起来费时间但排查问题的效率高得惊人。比如有一次抓到的IP头里TTL字段和我代码里写的不一致一查发现是代码里字节序拼接反了高低字节颠倒Wireshark抓包一对照立刻定位。字节序是FPGA以太网开发里最容易犯的错。RGMII接口发送的数据是高位在前还是低位在前IP头里的16位字段是先发高字节还是先发低字节这些细节在代码里必须统一。我的经验是所有头部字段在RTL内部一律按网络字节序大端存储拼接时先发高字节。这样和Wireshark显示的字节序完全一致排查少走弯路。8. 把这段调试经验沉淀成一套可复用的工程方法UDP模块跑通以后我建议你把这些沉淀成自己的固定工程方法这样后续做图像传输、ADC数据采集、运动控制回传这些具体业务时不用每次从零开始。首先是模块的裁剪和封装。我现在的情况是UDP收发链路当成一个黑盒子外部只暴露出类似AXI-Stream的接口用户只需要关注数据本身。ARP模块、UDP组帧/拆帧、MAC层、RGMII接口全部内聚在一个目录下用参数配置板卡的IP、MAC、端口号。这样在不同项目里直接改参数就能复用不需要重新设计。其次是约束文件的做法。以太网的约束有两点特别重要RGMII接口的输入延迟约束必须准确约束错了时序收敛不了上板就随机出错时钟约束要把125MHz的TX时钟声明为生成时钟否则Vivado不认识后面综合可能把时钟树优化坏。最后是调试工具链的准备。ILA核对应的触发条件最好加上帧开始的tlast信号或者特定的包头数据这样一旦出错能精确定位到帧边界。我习惯在ILA里同时抓RGMII数据和UDP解析状态机两个窗口一对照问题原因往往一眼就看出来了。对我来说FPGA上的UDP模块是一个打通任督二脉性质的工程它把数字逻辑、通信协议、芯片接口、时序约束全串在一起了。写完这一个模块你对FPGA开发整个流程的理解会上一个档次。如果这篇文章帮你把这条链路跑通了后面做更高层的网络协议比如TCP、PCIe、DDR高速接口时你的信心和经验都会非常扎实。
FPGA纯RTL实现UDP通信：从零搭建可上板的收发模块
1. 这块UDP模块到底要解决什么问题前七篇我们把FPGA开发环境、时序约束、LED闪烁、UART回环这些基础链路都过了一遍如果你一路跟下来手里应该有一套能跑通的上板流程也习惯了写代码—综合—上板—调波形的循环。这一篇进入一个很多人想碰又不太敢碰的领域——FPGA和外部设备之间的以太网通信具体实现是UDP模块的RTL代码。先说清楚一件事FPGA上的UDP通信不是像STM32那样调一个库函数就能发数据包。STM32的MAC和PHY都集成在芯片内部驱动帮你把ARP、IP、UDP头全封装好了。但在FPGA里除非你用的是ZYNQ这种带ARM硬核的芯片否则从以太网帧的最底层到UDP负载的最顶层每一个字节都得靠Verilog自己拼。对于纯FPGA的RTL工程师来说用RTL实现UDP协议栈是绕不过去的基本功。这篇博客要解决的核心问题非常聚焦一个几乎没有RTL网络基础的开发者如何从零开始设计一套能在FPGA上跑的UDP收发模块。我会按照协议拆解 — 发送通路设计 — 接收通路设计 — 跨时钟域处理 — 上板调试 — 系统验证的链路来讲代码会贴出可综合的关键片段不是伪代码是能在Vivado/Quartus里直接用的RTL。读完以后你应该能自己拼出带UDP通信的图像采集、数据采集或者控制回传系统。需要提前说明真正的完整UDP协议栈有很多边界情况比如分片重组、ICMP错误回报、多播组管理这些在这篇文章里不会全部涉及。咱们走的是一条能用、能上板、能实测跑通的务实路线。以最常用的1Gbps以太网、RGMII接口、88E1512 PHY芯片为硬件基线我默认你已经会看波形图会基本的Vivado操作懂Verilog的状态机写法。2. 硬啃协议栈还是直接调IP核先把这个老问题摊开讲说到FPGA做以太网很多人第一反应是用Vivado里的Tri Mode Ethernet MAC IP核不就行了吗。确实可以Xilinx和Altera都提供完整的MAC IP核内部封装好了GMII/RGMII接口、流控、CRC校验这些底层功能。但我不推荐新手一上来就切IP核理由有三个。第一个理由是IP核的接口复杂度远高于预期。以Xilinx的Tri Mode Ethernet MAC为例你要处理s_axis_tx_tdata、s_axis_tx_tkeep、s_axis_tx_tlast、s_axis_tx_tuser这种AXI-Stream侧的信号还要处理客户侧和MAC侧的时钟域转换再加上配置接口、状态接口、统计接口。一个没有任何MAC层背景的人面对这些信号很容易懵——你根本不知道tuser这个信号到底该什么时候拉高也不知道为什么发送偶尔卡死。第二个理由是IP核的仿真和上板调试链路更长。Vivado的MAC IP核有对应的example design但example design里带了一堆脚本、约束和测试代码新手想在里面做减法删掉不需要的部分难度反而比从零写一个简易MAC还大。我在帮别人排查问题时见过太多在IP核example design里迷路的案例。第三个理由也是最重要的UDP通信的本质不在MAC层而在MAC层之上的帧结构组织。MAC层只负责把一整帧数据从一个口搬到另一个口但谁来决定发出去的数据是什么内容目的MAC填什么IP头校验和怎么算UDP长度字段怎么填——这些逻辑IP核一概不管。你依然需要自己做ARP模块、IP校验和模块、UDP组帧模块。所以你迟早要把UDP层的逻辑亲手写一遍只是早晚问题。当然如果你做的是商用产品对稳定性要求极高要用VLAN、巨型帧、1588时间同步这些高级特性那直接上IP核和驱动是正路。但作为学习路径我强烈建议先用纯RTL把UDP收发链路跑通。这个过程能让你对以太网的每一层产生肌肉记忆后面再切IP核你会发现自己看接口文档的速度快了一个量级。为了照顾还没有以太网基础的读者我先把后面会反复出现的几个概念快速过一遍这些是UDP协议栈的地基必须烂熟于胸。MAC地址48比特烧录在网卡/PHY中决定数据帧在局域网里发给谁。FPGA板卡的MAC地址一般是厂商预设的也可以用软核寄存器把它配置成任意值。IP地址32比特决定设备在网络中的逻辑位置。FPGA作为设备端时需要给自己分配一个固定IP比如192.168.1.10。端口号16比特UDP层用来区分同一IP下不同的应用。发送数据时需要在UDP头里指定目的端口接收数据时可以自行约定端口号。ARP协议IP地址到MAC地址的映射。你想把UDP包发给192.168.1.2这台电脑但你不知道电脑网卡的MAC地址必须先发一个ARP请求问谁是192.168.1.2请把你的MAC告诉我。RGMII接口Reduced Gigabit Media Independent Interface用4根数据线控制线在时钟上升沿和下降沿各采一次达到1Gbps速率。这是FPGA和PHY芯片之间最常见的接口标准。这个地基图可能比文字描述更直观由于Markdown限制没法画图我直接用一个发送帧的字节序来呈现你看完就明白一个UDP包在线上长什么样了| 前导码(8B) | 目的MAC(6B) | 源MAC(6B) | EtherType(2B) | IP头(20B) | UDP头(8B) | 负载(NB) | FCS(4B) |前导码7字节0x55 1字节0xD5PHY芯片会自动处理FPGA侧一般不关心。EtherType0x0800表示IPv40x0806表示ARP。IP头版本0x45、总长度、标识、TTL、协议17表示UDP、源IP、目的IP、首部校验和。UDP头源端口、目的端口、UDP长度8负载字节数、校验和IPv4允许为0。FCSCRC32校验MAC层计算并填充接收方校验错误会直接丢帧。整条链路的逻辑关系是FPGA通过RGMII口和PHY芯片交换数据PHY把信号变成差分对跑到网线上。FPGA内部要完成的事就是从AXI-Stream或者自定义接口收到用户数据加上UDP头、IP头、MAC头一路送到RGMII发送引脚。接收方向则是反过来去掉每一层头把负载提取出来交给用户逻辑。了解了这些下面就可以进入正戏了——用Verilog把这条链路一条一条地搭出来。3. 发送通路的代码骨架从用户数据到RGMII引脚3.1 模块划分与信号约定我习惯把UDP发送通路拆成四级用户数据打包层 → UDP/IP组帧层 → MAC发送层 → RGMII输出层。每一层只干一件事信号清晰出问题也好定位。不会有那种一个always块里又拼MAC又拼IP头的混乱局面。为了让你更快理解我把最常用的发送接口定义出来这是我自己项目里的习惯写法// 用户接口握手协议valid拉高时data有效ready拉高时接收方可以接收 input user_tx_clk, // 用户时钟 input user_tx_valid, // 数据有效 input [7:0] user_tx_data, // 字节数据 output user_tx_ready, // 接收器可以接收 input user_tx_last, // 最后一字节这个接口和AXI-Stream几乎一样区别只是没有tkeep和tuser避免把新手绕晕。用户逻辑只要准备好数据在valid和ready同时拉高的周期把数据推给发送模块然后拉高last表示帧结束发送模块会自动完成全部打包工作。3.2 UDP帧构建一个状态机逐步切状态UDP发送的核心是一个状态机状态跳转的每一步对应一个头部字段的拼接我贴出核心代码框架localparam IDLE 3d0; localparam SEND_MAC 3d1; // 目的MAC 6B localparam SEND_IP 3d2; // 源MAC 6B EtherType 2B localparam SEND_IPHDR 3d3; // IP头 20B localparam SEND_UDPHDR3d4; // UDP头 8B localparam SEND_DATA 3d5; // 用户数据 localparam SEND_LAST 3d6; // 等待用户last信号 localparam DONE 3d7; // 帧结束CRC由MAC层处理 always (posedge clk or negedge rst_n) begin if (!rst_n) begin state IDLE; tx_byte 0; byte_cnt 0; end else begin case (state) IDLE: begin if (user_tx_valid user_tx_ready) state SEND_MAC; end SEND_MAC: begin if (tx_done) state SEND_IP; end // 每个头部字段以8比特为一拍发出计数到对应长度后跳转 ... endcase end end这里每个状态内部做的事情非常规整用byte_cnt记录当前状态已经发出了多少个字节计数到预设长度就跳转。比如SEND_MAC状态发出6个字节目的MAC、6个字节源MAC、2个字节EtherType一共14个字节然后跳转到SEND_IPHDR。3.3 首部校验和的计算一次到位不拖泥带水IP头校验和是所有新手最容易写错的地方也是最值得花时间说清楚的。IPv4首部校验和的算法是把IP头按16比特为单元分组全部相加如果相加过程中产生进位即和超过16比特把进位加到低位对最终结果取反填入校验和字段。在FPGA里我常用的做法是先临时把校验和字段置为0用组合逻辑算出校验和在发送到校验和字段这个字节的时候直接输出计算好的值。这样的好处是不需要单独的校验和计算周期状态机流程最简洁。function [15:0] ip_checksum; input [159:0] ip_header; // 20字节IP头校验和字段已置0 integer i; reg [31:0] sum; begin sum 0; for (i 0; i 10; i i 1) sum sum ip_header[i*16 : 16]; while (sum[31:16] ! 0) sum sum[15:0] sum[31:16]; ip_checksum ~sum[15:0]; end endfunction这个function在Vivado里可以综合仿真也没问题。实际运行证明用这种方式计算校验和上板抓包一秒通过。3.4 为什么UDP校验和可以填0很多人第一次看到UDP头的校验和字段容易卡住。UDP校验和的计算范围比IP校验和更广它覆盖整个UDP数据报UDP头数据而且还要加一个伪首部源IP、目的IP、协议号、UDP长度。新手在这里计算错的概率很高。好消息是IPv4下UDP校验和允许填0表示发送端没有计算校验和接收端可以不校验。这在FPGA与PC局域网通信场景里完全够用。我自己的实现里UDP校验和直接填0省掉一个复杂的伪首部求和模块。网上有些教程把UDP校验和算法写得很复杂但对于咱们这种板卡和PC之间调试的场景填0是务实且合法的做法。提示UDP校验和填0仍然符合RFC 768规范接收端不会因为这个字段为0而丢帧。如果你的应用场景经过三层交换机或者某些严格防火墙建议还是把校验和算对但纯实验室环境不需要担心。3.5 把帧头和数据拼到一起发送帧头和数据拼接的通用做法是在头部状态机每个状态里把待发送的字节送到一个字节宽度的发送通道同时往MAC层送valid信号。用户数据到达的时候直接从用户FIFO里读字节直到读到last。这段代码我会强调一个工程细节发送FIFO不能少。我见过有人在RTL发送路径上直接接用户逻辑产生的数据不做FIFO缓冲结果就是数据只要稍微来晚一拍MAC层发送就出现气泡帧与帧之间的间隔就会不对。用FIFO之后用户逻辑和UDP帧构建模块之间解耦用户侧可以突发传输发送侧可以等凑够一整帧再开始往MAC层发实际效果非常稳定。// 从用户FIFO读数据组装UDP帧 wire [7:0] fifo_dout; wire fifo_empty; wire fifo_rd_en; // 当状态在SEND_DATA并且MAC层请求数据时从FIFO读取 assign fifo_rd_en (state SEND_DATA) mac_tx_ready; assign user_tx_ready (state SEND_DATA) mac_tx_ready; // 数据通路头部状态下发head_data数据状态下发fifo_dout reg [7:0] tx_data_reg; always (posedge clk) begin case (state) SEND_MAC: tx_data_reg mac_header[47:40]; SEND_IP: tx_data_reg ip_header[159:152]; ... SEND_DATA: tx_data_reg fifo_dout; endcase end这个头部用寄存器拼接数据走FIFO的双通道模式是整个发送模块的核心思路。头部数据量小且固定用寄存器组存着慢慢发用户数据量大且随机必须用FIFO缓冲。两者在发送字节通道上二选一互不干扰。4. 接收通路的代码设计拆帧像削洋葱4.1 接收侧的层级解包接收方向就是发送的逆过程。RGMII接收引脚的数据进来后先经过一个输入寄存器和同步器把异步信号打稳然后经过MAC接收层做CRC校验和帧界定。校验通过的帧去掉FCS剩下的内容送进上一层的解析模块。这个解析模块做的事情很清晰用状态机逐字节判定当前处于什么解析状态localparam PARSE_MAC 3d0; localparam PARSE_ETH 3d1; localparam PARSE_IP 3d2; localparam PARSE_UDP 3d3; localparam PARSE_DATA 3d4; always (posedge clk) begin if (rx_valid) begin case (state) PARSE_MAC: begin // 解析6字节目的MAC 6字节源MAC后检查EtherType // 0x0800跳转到IP解析0x0806跳转到ARP处理 end PARSE_IP: begin // 解析20字节IP头取出源IP、总长度、协议号 // 检查协议是否为17(UDP)不是则丢弃整帧 end PARSE_UDP: begin // 解析8字节UDP头取出源端口、目的端口、UDP长度 // 如果目的端口不匹配帧可以直接丢弃 end PARSE_DATA: begin // 把负载数据写入用户FIFO end endcase end end接收的关键在于逐字段提取并核对。以太网帧没有长度指示它的长度是由帧间隔推断出来的所以你必须靠IP头里的Total Length字段来判断数据什么时候结束。比如IP头显示Total Length为50减去20字节IP头和8字节UDP头负载就是22字节持续接收22个字节就结束一帧。4.2 过滤策略谁的东西留下谁的东西扔掉接收方向最容易被忽视的是帧过滤。我见过大量FPGA网络代码的通病是接收模块把所有的包都解出来塞给用户FIFO包括广播包、组播包、别人的单播包、ARP应答、甚至其它协议类型的包结果用户逻辑每隔几毫秒就被无关数据打断一次。正确的做法是在解析阶段就做三层过滤MAC层过滤目的MAC和自己的MAC不一致且不是广播地址FF:FF:FF:FF:FF:FF直接丢弃。IP层过滤目的IP和自己的IP不一致直接丢弃。UDP层过滤目的端口不是自己约定的端口比如用户自定义端口直接丢弃。这三条过滤在代码里实现起来就是几个比较器每层解析出对应字段后立刻和预设寄存器比较不满足条件就拉一个drop_frame信号同时把状态机跳到丢弃状态一直等帧结束。4.3 接收FIFO的设计要点接收通路的FIFO比发送侧更要讲究。因为发送方向是你自己控制节奏数据全是自己产生的接收方向是外部网线随机到达的数据完全没有规律可言随时可能一帧接一帧地涌进来。如果用户逻辑来不及处理FIFO就会溢出溢出就会丢包。我的方案是解析完成的数据先写入一个ASYNC FIFO跨时钟域给用户逻辑。FIFO深度至少要能放下几帧完整的最大UDP数据包。比如你的最大帧负载是1400字节深度至少应该配2048字节。我实际项目里用4096字节深度应对突发完全没有问题。FIFO读出的接口同样用valid-ready握手和发送方向的接口保持一致。这样用户逻辑里收发两边的接口风格统一后续如果要把这个UDP模块封装成AXI-Stream外设改动也小。4.4 接收时最容易踩的坑总长度和实际接收不一致上板调试时经常出现一种诡异现象Wireshark抓到的包长度正常但FPGA接收到的数据总是少几个字节或者多几个字节。这通常是IP头里的Total Length字段和实际收到的字节数对不上。请注意IP Total Length是包括IP头和UDP头的总长度不是纯数据长度。很多人在这里少加了20或者8导致后面所有数据都错位。我排查过不少新手的代码最后发现就错在这一行// 错误写法只有负载长度 rx_len ip_total_length - 20 - 8; // 正确写法IP头总长度已经包含了IP头和UDP头 rx_len ip_total_length - 28;所以设计的时候我会把rx_frame_len直接存成ip_total_length - 28然后在数据接收状态用来计数一步到位。5. 跨时钟域和FIFO缓冲这里不过关上板必翻车5.1 为什么必须聊跨时钟域FPGA做以太网时钟问题绕不开。PHY芯片输出的RX时钟125MHz和FPGA内部用户逻辑时钟可能是100MHz、150MHz甚至200MHz经常不是一个频率。你不可能让所有逻辑都跑到125MHz也不应该把PHY的RX时钟当成唯一时钟——这会导致后续加逻辑时时序收敛非常痛苦。跨时钟域的处理标准做法就是FIFO。发送方向用户逻辑把数据写到发送FIFO写时钟是用户时钟UDP发送模块从FIFO读数据读时钟是125MHz读侧还需要变成RGMII发送时序。接收方向反过来PHY RX时钟域把数据写完接收FIFO用户逻辑用用户时钟读出来。Xilinx环境下直接用xpm_fifo_async原语Quartus环境下用dcfifoIP核。这两个都是跨时钟域FIFO的标准做法不要自己用双口RAM裸搭除非你想接受亚稳态的毒打。5.2 FIFO参数的具体配置FIFO配置看起来是件小事但参数配错会让整个系统偶尔好用偶尔抽风。我给出我实测稳定的一组参数参数发送FIFO接收FIFO说明数据位宽8 bit8 bit字节流接口深度20484096深度宁大勿小读模式First Word Fall ThroughFirst Word Fall Through减少握手气泡跨时钟域是是用户时钟 → 125MHzFWFT模式这里特别提一下普通Standard模式FIFO需要先拉读使能下一拍才出数据这在高速网络通路里会导致每一个字节的读取都延迟一拍状态机会变得不好写。FWFT模式下第一个数据就挂在输出端你只需要等valid信号少了一个拍频的延迟状态机写起来清爽很多。5.3 空满信号的处理宁可少收不可错位FIFO的空满信号处理是另一个经验集中的地方。很多人直接拿empty信号当接收完成标志在empty拉低时立刻开始读结果读到的数据是错的或者重复的。原因在于跨时钟域FIFO的empty信号有延迟可能在写侧已经写入数据但读侧还没有同步到。稳妥的做法是FIFO状态机里增加一个至少两拍的同步延迟在确认empty连续两拍为低后才开始读。这个白白增加的延迟不会影响性能因为UDP通信本身对延迟不敏感但能规避大量跨时钟域同步带来的毛刺问题。6. 上板调试实录三次翻车现场和最终的解决办法写代码从来不是最难的部分真正的分水岭是上板调不通的时候能不能沉住气排查。这段我分享三次让我印象深刻的翻车经验你在自己调试时很可能遇到一模一样的症状。6.1 第一个坑FPGA发不出任何数据Wireshark什么都看不到现象代码仿真全对时序约束全部满足但上板后Wireshark里一个包都抓不到。排查链路先用示波器量RGMII_TX_CLK和RGMII_TX_CTL看有没有信号活动再量TX_DATA[3:0]如果数据线上一直无翻转说明MAC层压根没有把数据推给PHY。逐级排查后发现问题出在MDIO配置没有完成88E1512需要复位后延时一段时间然后通过MDIO接口把寄存器配好比如把RGMII模式从SGMII切换到RGMII、使能内部延迟、关闭自动协商。很多板卡上电默认不是RGMII模式PHY等不到配置就躺平了。解决办法FPGA的MDIO管理模块在复位释放后先等待100ms用计数器计时然后依次写PHY寄存器0软复位、寄存器41000Mbps全双工、寄存器0x1cRGMII内部延迟使能。改完之后Wireshark立刻能看到包。注意MDIO配置不成功后续所有都白搭。很多人调UDP调两天没进展最后发现是PHY工作模式没配好这是最冤的排错经历。6.2 第二个坑PC能收到FPGA的包但FPGA收不到PC的包现象发送方向完全正常PC能看到UDP广播包或单播包但从PCping或发送UDP包给FPGAFPGA侧FIFO里始终是空的。排查链路先排除PHY方向的问题用示波器看RGMII_RX_CLK和RGMII_RX_CTL发现RX时钟是有的再用ILA抓接收状态机发现状态机一直停在PARSE_MAC的第一个字节判定帧没有真正开始。怀疑CRC校验不通过导致接收MAC层把帧整个丢弃。看一眼MAC接收模块的实现发现CRC校验逻辑写错了CRC计算输出没有对齐到帧末字节差了一个周期。这样每个帧的CRC都校验不过接收方向就直接把合法帧也丢了。芯片的数据手册写得很清楚FCS占用帧的最后一个4字节CRC引擎在收到最后一个有效数据字节后一个周期才能输出校验结果状态机必须等待这段时间不然截断位置就错了。解决办法在接收状态机里增加一个CRC_CHECK周期在完成负载接收后等待CRC计算输出并比对比对正确后才开始下一帧。修改后PC发送UDP包FPGA接收FIFO立刻有数据。6.3 第三个坑能通信但传输速度上不去每秒只能发几十kB现象PC和FPGA之间能互相收发但每秒钟最多只能传几十KB数据完全达不到千兆以太网的带宽。排查链路先用iperf3打流发现速度确实惨不忍睹。观察发送方向发现数据在发送FIFO经常为空用户逻辑产生的数据是一阵一阵的中间有大量空档。用ILA看用户时钟域的数据产生逻辑发现是中断驱动的数据采集方式每次中断之间gap太长。问题的根子是用户逻辑本身没有形成连续的数据流不是UDP模块的锅。UDP模块已经把帧间隔压到最小了但上游没数据只能空等。解决办法把用户数据产生逻辑改成双缓冲模式用户在采集缓冲区A的时候发送模块从缓冲区B取数据。这样数据流的连续性立竿见影实测速度提升了一个数量级以上。这个教训说明UDP模块代码再高效也救不了上游数据源的低效设计。这三个坑基本代表了以太网调试的三大类问题PHY配置、CRC边界、数据源吞吐。你如果遇到类似现象直接从这三个方向入手能省很多时间。7. 用专业工具做全链路验证7.1 用UDP测试工具做基本收发验证代码跑起来后第一步验证用最简单的工具。Windows平台我推荐用NetworkAssist网络调试助手Linux平台可以用nc -u命令。设置好目的IP和端口FPGA侧把收到的数据原样回传PC端连续发送一组数据如果回传内容和发送内容一致基本链路就通了。这里注意网络调试助手的发送间隔默认可能很大你需要手动把循环发送的时间间隔尽量调小才能模拟真实的高速UDP流。7.2 用Wireshark做协议级验证网络调试助手只能告诉你收到数据了但收没收到正确的数据帧还是要靠Wireshark。抓包后看三层关键信息Ethernet II层目的MAC是否指向PC网卡源MAC是否是FPGA板卡的MACEtherType是否为0x0800Internet Protocol层源IP是否为FPGA设置的IP目的IP是否为PC的IPIP首部校验和是否为correctUser Datagram Protocol层源端口、目的端口是否符合预期UDP长度字段是否等于负载长度加8。这三层检查都通过说明你的UDP模块协议正确性没有大问题。7.3 用iperf3做极限打流如果要做性能验证iperf3是绕不过去的标准工具。在PC端跑如下命令iperf3 -u -c 192.168.1.10 -p 5001 -b 800M -t 30 -l 1400这句话的意思是用UDP模式向FPGA的192.168.1.10:5001端口发送数据目标带宽800Mbps持续30秒每次负载1400字节。FPGA端需要先把收到的数据丢弃或者转发出来否则iperf3会因为没收到回包一直报错。如果FPGA收到的速率稳定在800Mbps而Wireshark抓包没有CRC错误和丢帧性能就算合格。要注意的细节是iperf3打流时FPGA的接收FIFO深度要足够大。1400字节的包800Mbps打进来每秒钟大约7万个包如果你的FIFO只有256字节深度不到一毫秒就溢出了。7.4 抓包数据与代码设计的对照检查我每次写完UDP模块上板后会拿Wireshark抓一包把抓到的原始十六进制字节一个一个和RTL代码里拼出来的值对一遍。这个过程看起来费时间但排查问题的效率高得惊人。比如有一次抓到的IP头里TTL字段和我代码里写的不一致一查发现是代码里字节序拼接反了高低字节颠倒Wireshark抓包一对照立刻定位。字节序是FPGA以太网开发里最容易犯的错。RGMII接口发送的数据是高位在前还是低位在前IP头里的16位字段是先发高字节还是先发低字节这些细节在代码里必须统一。我的经验是所有头部字段在RTL内部一律按网络字节序大端存储拼接时先发高字节。这样和Wireshark显示的字节序完全一致排查少走弯路。8. 把这段调试经验沉淀成一套可复用的工程方法UDP模块跑通以后我建议你把这些沉淀成自己的固定工程方法这样后续做图像传输、ADC数据采集、运动控制回传这些具体业务时不用每次从零开始。首先是模块的裁剪和封装。我现在的情况是UDP收发链路当成一个黑盒子外部只暴露出类似AXI-Stream的接口用户只需要关注数据本身。ARP模块、UDP组帧/拆帧、MAC层、RGMII接口全部内聚在一个目录下用参数配置板卡的IP、MAC、端口号。这样在不同项目里直接改参数就能复用不需要重新设计。其次是约束文件的做法。以太网的约束有两点特别重要RGMII接口的输入延迟约束必须准确约束错了时序收敛不了上板就随机出错时钟约束要把125MHz的TX时钟声明为生成时钟否则Vivado不认识后面综合可能把时钟树优化坏。最后是调试工具链的准备。ILA核对应的触发条件最好加上帧开始的tlast信号或者特定的包头数据这样一旦出错能精确定位到帧边界。我习惯在ILA里同时抓RGMII数据和UDP解析状态机两个窗口一对照问题原因往往一眼就看出来了。对我来说FPGA上的UDP模块是一个打通任督二脉性质的工程它把数字逻辑、通信协议、芯片接口、时序约束全串在一起了。写完这一个模块你对FPGA开发整个流程的理解会上一个档次。如果这篇文章帮你把这条链路跑通了后面做更高层的网络协议比如TCP、PCIe、DDR高速接口时你的信心和经验都会非常扎实。
