企业官网建设流程全解析

算是赶上了好时候，以前要在FPGA上跑高速以太网，要么用板厂提供的闭源MAC核，要么自己硬啃MAC层状态机，还得处理SGMII、8B/10B编码、时钟恢复这些烧脑的东西。现在Xilinx把1G/2.5G Ethernet PCS/PMA IP核做成了可直接调用的模块，配合自己用Verilog写的UDP协议栈，就能用2.5G线速率做数据传输。这套方案的成本和复杂度比万兆低一个量级，带宽又比千兆翻了一倍多，非常适合中高速数据采集、图像传输、上位机高速交互这一类场景。

这篇文章我会从项目整体架构讲起，把UDP协议栈的Verilog实现、PCS/PMA IP核的配置、时钟拓扑和带宽计算、仿真验证、上板调试这几个环节全部过一遍。不管你是刚接触FPGA以太网的新手，还是已经在用千兆但想往2.5G升级的老手，按着这篇文章的思路走，都能少踩不少坑。

1. 2.5G UDP的项目定位与整体架构

1.1 为什么是2.5G而不是万兆

先聊一个最实际的问题，既然要搞高速以太网，为什么不直接上万兆。万兆以太网（10GBASE-R）确实猛，线速率10Gbps，用户侧数据率能到9.x Gbps，但对板卡的要求也上来了：需要GTY或更高端的SerDes，PCIE/DMA接口要做成64位或128位宽，逻辑时序收敛难度明显增大，而且很多中低端FPGA根本集不成万兆MAC核的license也不便宜。

而千兆以太网就太“憋屈”了，线速率1Gbps，扣掉8B/10B编码和MAC层开销，应用层实际能用的也就100MB/s左右。做图像采集、高速ADC采集、固态存储回放这类应用时，这个带宽往往是瓶颈。

2.5G正好卡在两个档位中间。SGMII标准本身就支持2.5G速率，很多PHY芯片和交换芯片都带2.5G SGMII口，甚至能直接用SFP+光模块配合部分交换机跑2.5G。FPGA侧用7系列或Ultrascale的GTX/GTH，十几Gbps的SerDes能力跑2.5G绰绰有余，约束非常好收敛。用户侧数据率大概在2Gbps，配合64位或32位用户接口，能比较轻松地做到连续数据流传输。

这就决定了2.5G是一个“性价比很高”的带宽档位：实现难度和千兆差不多，带宽翻倍，硬件成本增加很少，非常适合个人项目和中小团队产品。

1.2 硬件链路与数据流全景

整个系统的链路是这样的（从FPGA内部往外讲）：

首先FPGA内部有一个数据源，比如ADC采集模块、DDR3读出的图像数据，或者上位机通过PCIe/串口写进来的待发送数据。这些数据先进入一个发送FIFO做跨时钟域缓冲，然后被用户逻辑封装成UDP包，通过AXI-Stream接口送给1G/2.5G Ethernet PCS/PMA IP核。

PCS/PMA IP核负责把并行数据编码成串行比特流。在2.5G SGMII模式下，内部会做8B/10B编码、串行器、时钟生成等工作，然后把差分信号通过FPGA的GTP/GTX收发器引脚送到板外的SFP+座子或PHY芯片。接收方向则完全反过来：串行差分信号进来后，PMA做时钟恢复和串并转换，PCS做8B/10B解码，恢复出并行数据和时钟，再以AXI-Stream形式交还给用户逻辑。

为了便于调试，整个链路建议预留至少三个回环点：

• 用户侧环回：从发送逻辑直接连回接收逻辑，不经过PCS/PMA，用于验证UDP协议栈本身有没有写错。
• PCS/PMA回环：IP核内部配置成环回模式，从用户接口发出去的数据经过内部编码解码后回到用户接口，用来判断IP核是否工作正常。
• 外部物理环回：用一个SFP+光模块加一根短跳线，或者用网线直接插到板卡自带的PHY芯片上回环，用来验证物理层整个链路。

调试的时候从用户侧环回开始，一步步往外扩，问题就能定位得非常精准。

1.3 IP核选型：为什么是PCS/PMA而不是完整MAC

很多人会问，Xilinx明明有Tri-Mode Ethernet MAC（TEMAC）IP核，带完整MAC功能，为什么还要自己写MAC层，只挂一个PCS/PMA？

这个问题其实取决于项目需求。TEMAC确实是“开箱即用”的完整MAC：自带FIFO、接口转换、统计寄存器、MDIO配置，还支持RGMII、SGMII多种接口。但对2.5G UDP这种定制化场景来说，TEMAC的问题恰恰是“太完整了”：它把MAC层的处理逻辑都封装死在IP核里，你想深度定制CRC、帧格式、VLAN标签、时间戳，要么看IP核的内部寄存器手册，要么绕来绕去很别扭。

而PCS/PMA IP核只管物理层编码和SerDes，MAC层的“活儿”全部交给用户自己写。这个分工非常适合做UDP协议栈的玩家，因为以太网MAC层核心就是：组帧、解帧、CRC校验，逻辑数量并不大，而且完全可以用Verilog掌控。相比之下，PCS/PMA内部的高速串行逻辑、8B/10B编码、时钟恢复这些才是真正难写的部分，直接用IP核能帮我们省掉最大的一块工作。

换句话说，PCS/PMA IP扛下了复杂且不易验证的物理层，我们集中精力在相对可控的数据链路层，这是这个项目思路的核心。

2. 用Verilog搭建UDP协议栈

2.1 UDP帧结构：字段拆解与总线对齐

要把UDP协议栈写对，先得把帧结构弄清楚。一个完整的UDP/IPv4以太网帧从线缆上看是这样的：

• 前导码（7字节0x55） + 帧起始符（1字节0xD5）：这部分由PCS/IP核或MAC层生成，有些软MAC会一并处理。
• 目的MAC地址（6字节）
• 源MAC地址（6字节）
• EtherType（2字节）：IPv4是0x0800
• IP头（20字节）：版本/首部长度、服务类型、总长度、标识、片偏移、TTL、协议号、头部校验和、源IP、目的IP
• UDP头（8字节）：源端口、目的端口、UDP长度、UDP校验和
• UDP数据（0~1472字节）
• 帧填充（如果数据不足46字节，自动补到46字节）
• FCS（4字节CRC32）：由MAC层计算并填充

用户侧总线如果做成64位宽（AXI-Stream接口），那么一帧数据就是若干个64bit周期。需要注意的关键点是：IP头的“总长度”字段和UDP头的“长度”字段必须对应上，这两个字段如果写错，Wireshark抓包会直接标红报错。很多新手在这儿栽跟头，明明数据发出来了，上位机收到的全是乱包。

我习惯把协议字段定义成一个位宽可调的包结构体来维护，发端组包时用一个通用函数填充，收端解包时用同一个结构体解析，这样不容易出现字段错位。

2.2 发送引擎：状态机与AXI-Stream时序

发送引擎的本质是一个状态机：空闲（IDLE）、组MAC头（MAC_HEAD）、组IP头（IP_HEAD）、组UDP头（UDP_HEAD）、发送数据（PAYLOAD）、计算CRC（CRC）和帧间隙（IFG）。

每一拍往AXI-Stream总线上放64位数据，同时用TKEEP信号表示当前拍的哪些字节有效。比如发一个256字节的UDP包，MAC头+IP头+UDP头总共14+20+8=42字节，加上数据256字节，总长度298字节。第一拍放MAC头14字节+IP头前2字节？不对，实际分配是：第一拍放14字节MAC头加上IP头前6字节；后续每一拍按顺序填充，最后一拍用TKEEP标记有效字节。

发送接口的关键信号是TDATA、TKEEP、TVALID、TREADY、TLAST。TVALID和TREADY同时拉高的周期数据才算真正传输成功。TLAST在帧的最后一个有效数据周期拉高，告诉下游这一帧结束了。代码实现时要注意：TLAST必须和最后一个有效数据在同一个周期，否则下游解帧会错位。

发送侧还要考虑帧间隙（Inter-Frame Gap，IFG）。以太网标准要求两帧之间至少有12字节的空闲时间，如果连续发帧不休息，PHY层或接收端容易丢包。这个时间由状态机在发送完一帧后自动插入，简单做法是计数器数至少12拍（按8bit接口节奏）或3拍（按64位接口节奏）。

帧间隙处理完成后，发送引擎继续检查FIFO有没有下一包数据，有则继续组帧发送，没有就回到IDLE状态。这样主机端只要往FIFO里写数据，发送引擎就会自动一包接一包地发出去，效率很高。

2.3 接收引擎：解帧、长度裁剪与FIFO写入

接收方向逻辑相对麻烦一些，因为上游发来的帧长度是未知的，而且可能夹杂各种非我们协议里定义的广播帧、ARP帧、巨型帧。接收引擎的状态机至少要有：判定MAC头（CHECK_MAC）、解析EtherType（PARSE_ETYPE）、解析IP头（PARSE_IP）、解析UDP头（PARSE_UDP）、写入数据（WRITE_DATA）和丢弃（DROP）。

收到一帧后，先看目的MAC是不是本机MAC或广播地址（FF:FF:FF:FF:FF:FF），不是就整帧丢弃。然后看EtherType，0x0800才继续，遇到ARP（0x0806）可以直接丢弃或简单回一个ARP应答，取决于你的需求。IP头里要看协议号是不是UDP（17），源IP/目的IP对不对。UDP头里看目的端口是不是我们监听的端口，不是就丢。

整个解析过程都在数据流中进行，每收到一拍数据就处理对应的字段，不用等整帧收完再判断，这样延迟低、FIFO占用小。当所有条件都匹配后，接下来的数据就是真正的UDP负载，直接写入接收FIFO。UDP长度字段告诉我们要收多少字节，如果实际收的长度不够（坏帧），要把FIFO里已经写入的部分整个清掉，避免半包被上层取走。

接收侧一个容易忽略的问题是“帧尾处理”。AXI-Stream接口上每帧结束时TLAST拉高，最后一拍的TKEEP可能只有部分字节有效。写FIFO时最好把字节有效数也一并存进去，或者干脆写满固定位宽（比如不关心有效字节，上位机按长度字段截取），这样最简单。

2.4 跨时钟域与数据缓冲设计

UDP协议栈里至少存在三个时钟域：用户逻辑时钟（比如采集模块的100MHz）、用户接口时钟（2.5G SGMII下可能是62.5MHz）、GT收发器的并行时钟（由PMA恢复）。跨时钟域处理最常用的就是异步FIFO。

发送方向：用户逻辑产生的数据先写入发送FIFO，发送引擎在用户接口时钟域读FIFO，组帧后发往IP核。接收方向：接收引擎在用户接口时钟域解析数据并写入接收FIFO，用户逻辑用自己的时钟读出来。FIFO深度根据突发数据量决定，这个我们在第3节详细算。

一个有实际价值的细节是：发送FIFO要有一定的“预取”机制，因为UDP包头的长度字段要等到整包数据都进来才能确定（至少要知道数据长度），所以发送引擎不能像流水线那样边收边发。常见做法是数据源先写FIFO，写完一帧后再给发送引擎一个“包有效”信号，发送引擎从FIFO里把数据读出来组帧发送。这个“先存后发”的流程，天然要求FIFO深度至少要容纳最大一帧数据。

实际项目中我通常用4096×64bit的发送FIFO，既能容纳几帧1500字节的大包，又不会占用太多BRAM资源。

3. 时钟拓扑与关键参数计算

3.1 2.5G SGMII时钟体系

高速以太网调试，最怕的就是时钟不够清晰。2.5G SGMII的时钟体系大致是：FPGA外部晶振提供GT参考时钟（比如125MHz），GT内部的PLL把参考时钟倍频到线速率对应的串行时钟2.5GHz，PMA内部再分频产生并行时钟，PCS部分在并行时钟域做8B/10B解码。

在IP核的用户侧，通常会输出一个user_clk_out信号，这个时钟是用户逻辑与IP核交互的同步时钟。对于2.5G速率，如果用户接口是32位，那么user_clk大约是62.5MHz；如果接口是64位，则大约是31.25MHz（具体以IP核生成工程的示例代码为准）。我这次用的是32位接口，整个UDP协议栈全部工作在62.5MHz时钟域，逻辑时序压力非常小。

为什么会有32位接口和62.5MHz这个组合，可以用带宽公式来理解：线速率2.5Gbps，8B/10B编码带来的有效数据率是2Gbps（因为每10个bit中只有8个bit是有效数据）。要让用户侧接口匹配上这个速率，就需要“位宽乘频率”等于2Gbps。32bit × 62.5MHz = 2Gbps，刚刚好。

这也是为什么2.5G比千兆好调的一个重要原因：62.5MHz的时钟信号路时序非常舒服，配合两级寄存器和set_input_delay/set_output_delay约束，基本不会出现时序收敛不了的状况。

3.2 GT参考时钟与PCS/PMA IP核配置细节

在Vivado里配置1G/2.5G Ethernet PCS/PMA IP核时，有几步非常关键：

首先，Line Rate一定要选2.5G，Protocol选SGMII，而不是1000BASE-X。这里容易搞混：1000BASE-X是千兆光口标准，2.5G SGMII是2.5G电口/光口可用的SGMII扩展速率，二者编码方式都是8B/10B，但对速率、自协商处理完全不同。2.5G SGMII支持2.5G、1G等速率，而1000BASE-X固定1G。

其次，GT参考时钟（GT Reference Clock）的选择要和板卡实际晶振频率对上。我用的板卡在GTREFCLK引脚上接了125MHz晶振，所以IP核配置里参考时钟填125MHz，GT的QPLL或CPLL负责把125MHz倍频到线速率。如果板卡是156.25MHz晶振，配置成156.25MHz也行，PLL会自动调整倍频系数。关键是别把参考频率填错，填错了GT很可能直接锁定不住。

第三，Shared Logic选项建议选“Include Shared Logic in Example Design”以外的独立模式，把共享逻辑（比如复位管理、时钟缓冲）放到IP核外面，这样方便我们在用户顶层统一控制复位时序。否则在IP核内部被封装掉，调试时看不到复位状态。

第四，User Interface的数据宽度根据时钟可行性来选。2.5G速率下我推荐32位接口（62.5MHz），这个时钟在7系列FPGA上属于非常低的频率，布线随便跑。选64位接口虽然每拍数据量翻倍，但时钟降到31.25MHz，对于用户逻辑反而可能带来跨时钟域处理的额外麻烦，没有特别大的优势。

3.3 FIFO深度与连续传输带宽估算

FIFO深度设计是整个数据通路“会不会丢包”的关键。很多项目在仿真时一切正常，一上板UDP就丢包，很大概率就是FIFO深度不够或者读速率匹配不上写速率。

我们做一下定量估算。假设上位机一次性下发一个64KB的突发数据块，FPGA这边用户逻辑写发送FIFO的速率恰好是100MHz×64bit=6.4Gbps，而发送引擎的读速率只有2Gbps（2.5G线速率的用户侧有效速率）。发送FIFO用4096×64bit，深度4096拍，能缓冲32KB数据，当突发超过32KB时，FIFO就会写满，再写入就会溢出，这至少需要能力更强的缓冲。

如果手头有比较大的突发传输需求，建议把发送FIFO深度做到16384×64bit（128KB），并且加上ANTI_OVERFLOW逻辑：当FIFO快要满时，给上游一个backpressure信号，让DMA或采集模块暂停写入。没有背压机制的FIFO，无论深度做多大，在极端突发下都可能丢数据。

接收方向同理。如果上层应用读完一包数据需要比较长时间（比如做图像后处理），接收FIFO深度至少要能容纳2~3个最大UDP帧（2~3×1500字节），我一般直接配成4096×64bit，大多数场景都够用。

3.4 净荷带宽到底能跑到多少

很多人以为2.5G以太网能跑满2.5Gbps应用数据，实际上不可能也不现实。线速率2.5Gbps，经过8B/10B编码后数据率是2Gbps，这已经是天花板。然后还要扣除以太网帧本身的固定开销。

一个标准1518字节的以太网帧，实际组成是：14字节MAC头 + 20字节IP头 + 8字节UDP头 + 1472字节UDP数据 + 4字节CRC。此外每帧还要有8字节前导码和12字节帧间隙。所以线缆上传输一个1518字节的帧，实际占用1538字节的传输时间。

按2Gbps的数据率计算，每秒钟能发送的帧数量是：2Gbps / (1538×8) ≈ 162.6k帧/秒。对应UDP净荷速率就是162.6k × 1472 × 8 ≈ 1.915Gbps，约239MB/s。

这个239MB/s就是我们能用2.5G UDP做数据通信的实际上限。如果你的应用传输的是小包（比如64字节优质小帧），那净荷利用率会急剧下降，可能连1Gbps都不到。因此做高速传输时一定要尽量拼大包，最好把UDP负载做到1400字节以上，才能吃满2.5G的带宽。

这个239MB/s和千兆的120MB/s左右相比，优势就很明显了，基本一套2.5G UDP方案能给老千兆项目带来翻倍以上的吞吐能力提升，而且改动量不大。

4. 仿真验证：上板前先把2.5G数据通道跑通

4.1 仿真环境搭建思路

高速串行链路刚上板就想要靠逻辑分析仪看信号，基本不现实：GTX串行信号频率2.5GHz，普通逻辑分析仪根本采不到，即便用ILA去抓用户侧总线，也只能看到并行时钟域的信号。所以“先把仿真跑透”几乎是这套方案唯一的快速验证途径。

我的仿真环境分三层。第一层是纯用户逻辑仿真：只包含自己的UDP发送引擎、接收引擎，不实例化GT，用自己写的简单信号源驱动发送引擎，接收引擎收到的数据直接拉回发送引擎形成回环。这一层跑通说明UDP协议栈逻辑没问题。

第二层是挂上PCS/PMA IP核的仿真模型，把IP核配置成回环模式——用户在仿真中其实不需要配置回环，因为可以把IP核的串行输出直接环回串行输入，模拟物理层环回。这层跑通说明IP核的初始化时序、客户侧接口连接都没问题。

第三层才是在真实板卡上，通过SFP+光模块和短跳线做物理回环，并用ILA采集用户侧信号抓实际帧。

仿真工具我用Vivado自带的XSim，因为IP核的仿真模型通常已经集成在工程中，不需要额外编译库。如果你习惯用ModelSim或Questa，需要单独编译Xilinx仿真库，稍微麻烦一点，但也不是不行。

4.2 时钟、复位与Sequence任务设计

仿真的第一步是产生正确的复位时序。PCS/PMA IP核对上电复位顺序有要求：先等GT参考时钟稳定，再给IP核的复位信号，复位释放后还要等IP核的reset_done信号拉高，才能开始收发数据。

在Testbench里，我习惯写一个简单的寄存器来控制复位：初始拉低复位N个周期，拉高之后等待reset_done有效，再过100个周期才开始发包。这个“等待reset_done”非常关键，如果复位释放后不管IP核是否就绪就直接发数据，用户侧可能永远等不到回环数据。

Sequence任务建议用Verilog的task封装。我写了三个基础任务：send_single_packet（发单个UDP包，可指定负载长度）、send_burst_packets（连续发N个UDP包）、send_arp_request（可选，测试ARP处理）。任务内部通过写发送FIFO并触发发送引擎来完成。每个包发送完成后，Testbench检查接收侧是否收到相同长度、相同数据的包，并维护一个计数器统计总帧数和错误帧数。

一个需要注意的仿真细节：IP核内部对所有跨时钟域信号做了同步处理，仿真理想要等几个user_clk周期才能看到数据回环，所以Testbench在发完一包后不要立刻检查接收侧，最好等待例如100个时钟周期后再查询接收计数器，否则容易误判为“接收失败”。

4.3 回环测试与错误统计

我在Testbench里加入了自动回环比对逻辑：发送引擎发送的数据同时缓存在一个二维数组里，接收侧每收到一帧数据就与数组对应位置的数据做逐字节比较，不一致就报错。数据源可以用简单的递增序列或伪随机序列，我一般用递增序列比较多，因为排查问题时更容易定位是第几个字节出错。

除了数据内容校验，还要统计几个关键计数器：发包总帧数、收包总帧数、已接收字节数、CRC错误帧数（由IP核报出的FCS错误）、超长/超短帧数。帧数对不上就说明有丢包，字节数不对可能说明长度字段写错。

仿真中另一个实用技巧是刻意制造异常帧：比如发送一帧在UDP长度字段里写“300”，但实际数据只发了100字节，验证接收引擎能否正确处理（拒绝接收或按长度截断）。这种异常测试往往能提前发现协议栈的健壮性问题。

仿真跑顺之后，ILA在真机上的调试工作就能轻松很多，因为你已经知道协议栈逻辑本身是对的，剩下的问题大概率出在IP核配置或硬件连接上。

5. 上板调试与实战问题排查

5.1 串口打印一直卡在链路初始化

上板第一个常见问题，FPGA加载完程序后，串口打印一直停在“Initializing PCS/PMA…”不动。这时候别急着查代码，先检查GT参考时钟有没有起来。

用ILA抓一下IP核的gt_refclk_status和reset_done信号。如果gt_refclk_status一直为0，说明参考时钟没有稳定，检查板卡晶振是否供电、IP核里参考时钟频率和实际晶振频率是否匹配、对应的GTREFCLK引脚是否绑定正确。

还有一个很容易犯的低级错误：IP核的复位信号没有正确释放。PCS/PMA IP核的复位通常是低有效，很多人习惯性写高有效，导致IP核永远在复位态。这个用ILA抓reset_done信号一看便知，如果reset_done始终拉不高，就在复位逻辑里排查。

另外注意：如果Board里没有真正的PHY芯片，而是SFP+光模块，那么IP核的SGMII自协商信号可能永远不会link up，因为光模块本身不自协商。这在调试时要先确认：IP核是配置成自协商模式还是强制模式，如果是自协商而对面不参与，链路永远起不来。测试时可以直接把IP核配置成强制2.5G模式，或者用回环模式先验证数据通路。

5.2 TX能发出去，但RX侧收不到任何数据

这个现象通常意味着发送方向没问题，接收方向有信号没接对或者解帧逻辑有bug。先用ILA抓IP核的用户侧接收接口，看看有没有数据在活动——如果IP核接收接口上根本没有AXI-Stream数据活动，那么问题在物理层或IP核配置；如果IP核接收接口有数据，但我们的接收引擎一直丢弃，那问题在解帧逻辑。

物理层的问题最常见的是：SFP+回环线接触不良、光模块没插到位、差分引脚方向反了（TX/RX交换）、共模电压不对。这时候不要用逻辑分析仪硬看串行信号，直接换一根短跳线、重新插拔光模块，通常能解决。

解帧逻辑的问题常见于：目的MAC判断条件写死或写错、EtherType解析位宽错位、UDP端口不匹配。我在调试时习惯临时增加一个“旁路模式”——接收引擎把所有收到的帧不管MAC地址、端口、类型，全部直接写入FIFO，同时通过ILA抓原始数据。用这个旁路模式能快速判断是“物理层没数据”还是“我们的过滤逻辑把数据丢了”。

还有一个容易忽略的点：IP核用户接口的TVALID信号可能不是持续拉高的，中间可能有空周期。很多接收引擎在写FIFO时没有判断TVALID，导致把空周期的垃圾数据也写了进去。检查一下接收引擎的写使能是否严格等于TVALID && TREADY。

5.3 用户接口时序收敛失败

2.5G模式虽然时钟频率不高，但用户接口数据位宽32位时，路径上包含多个逻辑层的状态机判断和数据拼接，如果不留意，综合后的WNS容易为负。

我采用的方案是“数据流水化”：发送引擎不直接在同一个周期内完成所有字段拼接，而是把组帧过程拆成寄存器级流水，每个周期只做简单的字节选择和拼接。具体做法是维护一个帧头寄存器组和一个“发射反弹”寄存器，把TDATA、TKEEP、TVALID全部打一拍再输出。

接收路径也类似：解帧状态机不要在同一拍内同时解析IP头、UDP头和判断长度，把解析结果寄存起来，下一个周期再执行写入FIFO。多一级流水带来的额外延迟只有几个时钟周期，完全不影响UDP通信，但能让时序收敛轻松很多。

如果综合后还是有负数的setup slack，优先检查跨时钟域的异步FIFO读写地址线是否做好了同步处理，以及user_clk是否直接用了IP核输出的时钟而没有经过BUFG。

5.4 用Wireshark和iperf做实际带宽验证

板卡通了以后，还要验证真实带宽和UDP包格式对不对。我用上位机自带的网卡连接FPGA板卡，FPGA侧通过一个计数器循环发包，然后在上位机上用Wireshark抓包。

Wireshark打开后，筛选表达式可以用：udp.port == 目标端口或ip.addr == FPGA的IP地址。抓包后重点检查：目的MAC是不是上位机的MAC、源IP/目的IP是不是正确、UDP长度字段和实际数据长度是否一致、Wireshark有没有标注CRC错误或IP校验和错误。

带宽测试可以用iperf3的上位机版本来发包，让FPGA侧作为接收端并统计收到的包数和字节数，算出来实际吞吐率。我第一次跑到约230MB/s，离理论上限239MB/s差了不到4%，说明协议栈开销和回环效率已经接近极限了。如果想测FPGA发、上位机收的方向，可以反过来用iperf3的udp接收模式，FPGA侧持续发数据包，上位机统计吞吐率和丢包率。

抓包时如果发现Wireshark对UDP校验和报错，不要慌，很多网卡会在硬件计算校验和并把结果直接修改后再交给Wireshark，这是正常的零拷贝现象。真正要关心的是IP头校验和，如果IP头校验和都错了，帧基本废了。UDP校验和可以在FPGA侧填0，Wireshark会提示“校验和为0”，但很多应用不校验也能正常工作。如果要求严格，就在发送侧用逐字节累加的方式实现UDP校验和算法，也不复杂。

调试2.5G以太网，印象最深的一次问题是：Wireshark里能看到上位机发出的UDP包，但FPGA侧怎么都收不到，排查了两天，最后发现是接收引擎里把IP头长度字段当成了“总长度”，导致数据指针偏移错位，多出来的字段被当成UDP头的一部分解析，端口号完全对不上。后来我把解析逻辑改成“先校验字段是否符合预期（IP头长度固定20、UDP头固定8），不符合就丢帧”，问题立刻解决。

这类问题的排查思路其实很朴素：不要假设收到的帧是标准的，先把每一个字段打印或dump出来核对一遍，再谈后续处理。FPGA调试没有捷径，日志和计数器就是最好的朋友。建议在工程里多留几个32位计数器：发送帧数、发送字节数、接收帧数、接收字节数、CRC错误数、丢弃帧数，通过串口或ILA随时查看，定位问题会快很多。

最后再分享一个切身体会：这套2.5G UDP方案的价值，不仅在于把带宽翻倍，更重要的是它把以太网链路彻底“打开”了。千兆时代很多人不敢碰MAC层，全靠IP核黑盒；而一旦自己写过一遍UDP协议栈，后续不管是做TCP裁剪、加VLAN标签、还是对接自定义数据帧格式，都只是状态机里加几个字段的事。项目的扩展空间，一下子就从“我会用IP核”变成了“我能定义链路协议”。如果你也准备在FPGA上做高速通信，花点时间把这条2.5G UDP链路打通，回报绝对超值。