100G UDP在FPGA上跑通这件事我前前后后折腾了小两个月。从拿到开源代码到最终在板卡上用iperf3打满线速中间踩过的坑、推翻过的设计假设比想象中多得多。这篇文章把完整的移植过程和上板测试记录整理出来包括方案选型的理由、代码结构的拆解、工程搭建的细节、测试中遇到的各种诡异现象以及最终的排查思路。如果你正准备在FPGA上做高速网络处理或者手头有100G的项目要评估这篇应该能帮你省下不少走弯路的时间。1. 项目整体设计与方案选型思路1.1 为什么选择开源方案而不是自己造轮子100G UDP协议栈说简单也简单说复杂也复杂。简单在于UDP本身就是一个极简的无连接传输协议报文格式固定处理逻辑不复杂复杂在于100G的线速处理对数据通路的位宽、时钟频率、时序收敛都有极高要求加上MAC层、PCS层、XGMII接口这些底层细节一个细节处理不好整条链路就跑不满。我评估过三个方向一是完全自己写RTL从MAC到UDP全自研二是在Xilinx官方IP的基础上做二次开发三是选择成熟的开源方案直接移植。最终选了第三条路核心原因有两个。第一个是时间成本。100G以太网的数据通路涉及64B/66B编码、FEC、流控、CRC校验这些底层逻辑看起来简单但要做到线速且稳定运行没有几个月迭代很难成熟。第二个是验证成本。自研方案的验证工作量是移植方案的数倍光是搭建支持100G速率仿真的测试平台就要花不少时间更别说覆盖率收敛。开源方案里Alex Forencich维护的verilog-ethernet项目是绕不开的选择。这个项目包含从10G到100G的完整MAC、PCS、UDP、ARP、ICMP等模块代码风格统一接口使用AXI4-Stream非常干净且MIT协议商用友好。它的100G核心基于Xilinx 100G Ethernet MAC硬核自己实现的是用户侧逻辑可靠性有保障。选型之后我自己定了几条原则不魔改核心代码、不随意优化时序、优先保证功能正确、测试逐层推进。这四条被后续事实证明非常重要。1.2 100G UDP的架构分层与现实约束和10G/25G相比100G不是简单的速率翻倍它引入了一个在低速以太网中不存在的概念——多通道并行处理。100G以太网在PCS层会拆分成多个通道通常是20个lane每个5Gbps这要求用户侧逻辑必须适应多通道并行的数据模式。从整体架构上看100G UDP方案分为四层物理层光模块高速SerDes、数据链路层MACPCSFEC通常由硬核实现、网络层IP、ARP、ICMP、传输层UDP。开源方案在传输层和网络层做得比较完善MAC和PCS大多通过Xilinx官方IP例化两者之间的接口是核心集成点。物理层用QSFP28光模块这个没太多选择空间。FPGA侧需要4路或者8路GTY收发器具体取决于线速率和编码方式。如果算上RS-FECKR4还需要额外的逻辑资源消耗但只要MAC硬核支持这部分基本是配置问题。现实约束里最突出的有两个。一是时钟架构100G MAC通常工作在322MHz左右的用户时钟频率下数据位宽512bit即每时钟周期处理64字节这对逻辑的时序设计提出了要求。二是数据通路宽度AXI4-Stream接口在100G下是512bit宽这意味着所有用户逻辑都要适配这个位宽和10G时代的64bit位宽完全不是一个设计思路。还有个容易被忽略的点是MAC地址过滤的硬件卸载。100G MAC硬核内置了地址过滤表云环境下的报文过滤需求非常复杂如果完全靠软逻辑过滤用户时钟频率和逻辑资源都会吃紧。开源方案在这一点上没有做太深需要我们根据实际使用场景在用户逻辑里补充。2. 核心代码结构与移植适配要点2.1 开源代码的模块划分与数据流verilog-ethernet这个项目把100G UDP相关的代码分成几块rtl目录下是核心RTL代码lib目录下是AXI接口相关的基础组件example目录下有针对不同板卡的示例工程。整体风格非常适合移植每个模块的接口定义都很清晰注释也到位。数据流大概是这样的光模块接收到的光信号经过GTY收发器转为并行数据进入100G MAC硬核完成PCS解码、FEC纠错、MAC帧解析输出的数据以512bit的AXI4-Stream接口呈现。之后经过一个eth_mac_100g相关的模块做CRC校验和帧对齐再进入eth_udp_100g模块完成IP和UDP头解析。发送方向是接收方向的逆过程UDP模块组帧、MAC硬核添加CRC和前导码、GTY并串转换后发给光模块。2.2 AXI4-Stream接口的位宽适配逻辑这个项目的接口设计做得很好所有模块之间都通过AXI4-Stream接口交互。但要注意的是不同模块的位宽可能不同——MAC输出512bit而UDP解析模块内部的IP层和UDP层可能是256bit或128bit。模块内部用了一种叫“数据对齐桥接”的方式处理位宽不一致的问题。移植过程中我遇到的一个坑就在这里。之前只做过64bit或128bit位宽的数据通路512bit的接口下tkeep信号的逻辑判断方式和以前完全不同。比如在判断一个UDP包的边界时需要同时处理tkeep在多个周期内的组合情况而不仅仅是判断首尾两个周期。这个细节在仿真时不容易暴露但在实际抓包分析时如果处理不当会出现丢包或者错包。另一个需要特别注意的是axis_register类的模块。开源代码里大量使用了寄存器切片register slice来打断长组合逻辑路径这在100G频率下几乎是必须的。移植时最好不要砍掉这些寄存器级否则时序收敛会非常痛苦。我之前测试过从MAC出来的数据直接接UDP解析模块不插寄存器切片结果时序分析报告直接飘红很难收回来。2.3 用户逻辑侧如何与UDP模块对接对绝大多数使用场景来说我们是把UDP模块当作一个“透明通道”使用把要发送的数据包装成AXI4-Stream送入发送端从接收端取回解析好的数据。这个对接过程有几个关键信号需要理清楚。发送方向的axis_tx_tdata是512bittkeep表示有效字节tlast表示帧结束。需要注意的是tvalid和tready构成握手关系发送侧需要遵循“valid不能依赖ready”的原则否则容易产生死锁。另外还要注意包与包之间的间隔IPG虽然MAC硬核会自动处理最小帧间隔但如果用户逻辑发送时背靠背发送两个帧IPG太短会导致对端设备丢弃后续帧。这个问题在低速下不明显100G下对端网卡的容错能力反而不如想象中好。接收方向的数据处理相对简单但有一个容易忽视的点UDP模块输出的数据是剥离了MAC头和IP头之后的纯载荷如果需要知道源MAC、目的MAC、源IP等信息需要在模块内部把header信息以旁路信号的形式同步输出。开源代码里这部分功能是有的但默认没有完全打开需要根据具体场景修改配置参数。这里贴一段实际的对接代码示例展示用户侧发送数据的AXI4-Stream时序// 用户侧发送接口512bit位宽 // 以发送一个UDP包为例取前两个时钟周期 // cycle 0: tdata0x...前64字节tkeep64hFFFF_FFFF_FFFF_FFFFtvalid1 // cycle 1: tdata0x...剩余数据tkeep64h0000_0000_0000_00FFtvalid1tlast1 // 注意tlast必须与最后一拍数据同时有效 always (posedge clk) begin if (axis_tx_tready axis_tx_tvalid) begin // 数据已被接收准备下一帧 tx_state TX_IDLE; end end调试这个接口时建议先用ILA抓取一段真实的发送序列对照AXI4-Stream协议规范确认tvalid/tready/tlast/tkeep的时序是否正确。我在调试中发现的很多问题最终都归结为对这组握手信号的理解不到位而不是协议栈本身的问题。2.4 针对目标板卡的代码裁剪与参数配置开源代码基本是按“通用”设计的但不同板卡的PHY地址、差分时钟约束、复位逻辑、GTY参考时钟来源不同。移植时要改的地方主要集中在顶层文件里。首先是时钟。100G以太网的参考时钟通常是156.25MHz但这个频率可能来自板载晶振、外部时钟芯片或QSFP28模块的CDR恢复时钟具体取决于板卡设计。以我使用的板卡为例参考时钟需要通过IBUFDS_GTE4原语接入然后在时钟管理模块中分频倍频出MAC所需的时钟。其次是复位。MAC硬核的复位时序有明确要求——需要等GTY的PLL锁定之后才能释放否则会出现链路偶尔不通的“幽灵故障”。代码里默认的复位逻辑可能不完全匹配你的板卡建议根据板卡的电源上电时序和GTY复位要求做调整这个细节直接影响上板成功率。第三是MDIO接口。MAC硬核的配置是通过MDIO接口访问内部寄存器完成的开源代码在example工程里会有一个MDIO控制器但有些板卡的MDIO引脚约束可能需要调整。确保MDIO通信正常后再进行UDP功能测试否则后面的一切都无从谈起。参数配置方面有几个关键的宏定义需要关注MAC_PREAMBLE是否包含前导码、ENABLE_PADDING是否自动补零到最短帧长度、ENABLE_VLAN是否支持VLAN标签。默认配置适用于常规场景但如果你的应用里有特殊需求比如使用自定义以太网类型字段需要提前规划好参数调整方案。3. 移植过程与工程搭建实录3.1 目标板卡选择与硬件资源评估我用的是一块Xilinx UltraScale架构的板卡FPGA芯片是VU9P板载QSFP28光模块接口支持100G速率。选这块板卡的原因很简单它搭载的GTY收发器数量和速率等级足够而且VU9P的逻辑资源充裕跑一个100G UDP协议栈加上后续的用户逻辑不会太紧张。硬件评估时我列了一个资源清单GTY收发器需要至少8个或者4个取决于是否使用RS-FEC以及通道绑定方式Block RAM用于FIFO缓冲UltraScale的URAM在MAC硬核内部使用用户逻辑侧还需要额外的BRAM做数据缓存。以我的测试工程为例仅协议栈部分就消耗了约12%的LUT和16%的寄存器资源这对后续扩展功能是一个重要的参考数据。还有个值得关注的点是功耗。100G光模块加上高速SerDes的功耗不小尤其是上电初始化和链路训练阶段。我在调试过程中曾遇到板卡电源不稳定导致GTY频繁复位的问题后来确认是12V供电不足所致换了独立供电的电源适配器后问题消失。3.2 Vivado工程配置与IP例化步骤移植的第一步是创建一个标准的Vivado工程选择正确的FPGA型号然后例化100G Ethernet MAC IP。这里我选择的IP配置有几个关键点。在“Line Rate”选项中选择100G“Interface”选择“AXI4-Stream”“Data Bus Width”选择512bit。时钟方面选择“Shared Logic”模式让IP内部管理GTY的时钟和复位。有些设计会为了节省逻辑把时钟管理做成外部模式但我建议第一次移植时使用Shared Logic这样可以排除很多调试变量。IP例化完成之后需要把开源代码中的RTL文件添加到工程中。建议保持目录结构清晰至少分为rtl和sim两个目录方便后续仿真和综合管理。添加文件时注意Vivado会识别出核心代码和示例代码不要把所有文件都加进去只需要添加你真正用到的模块和库文件。约束文件的编写是整个工程搭建中最容易出问题的环节。100G以太网的约束不仅仅是引脚分配更重要的是时钟约束和例外约束。GTY的参考时钟需要设置create_clock约束MAC的用户时钟和系统时钟也需要明确约束。另外由于GTY的串行数据路径是异步的需要在约束文件中添加对应的set_false_path或set_max_delay约束。这里给出一个简化的约束示例展示了如何对GTY参考时钟设置约束# 156.25MHz GTY参考时钟约束 create_clock -name gt_ref_clk -period 6.400 [get_ports gt_ref_clk_p] # MAC用户时钟通常由IP内部的时钟管理器生成 # 需要在综合后通过 report_clock_networks 确认实际频率 # 然后在约束文件中补充对应的 create_clock 约束时序约束的基本原则是先让工具自动推断时钟关系再根据时序报告补充例外。如果一上来就写一大堆set_false_path反而会掩盖真正的问题。3.3 管脚分配与Vivado综合实现的调整过程管脚分配方面QSFP28模块的信号线相对固定4对高速差分收发信号如果使用4路GTY、一对差分参考时钟、一个模块管理接口I2C或MDIO。这些信号在XDC文件中的约束相对直观重点是确保GTY所在的BANK与参考时钟所在的BANK满足时钟布线要求。在实际实现过程中第一次综合通常不会直接收敛。我在调时序时遇到的主要瓶颈是发送方向数据通路的路径过长——从用户逻辑到MAC的寄存器切片之间经过了多级组合逻辑。为了解决这个问题我在用户逻辑和MAC之间额外插了一级AXI4-Stream寄存器把关键路径切断。代价是多了一个时钟周期的延迟但对于UDP这种无连接协议来说完全无所谓。还有一个容易被忽视的问题是复位信号的异步释放。如果复位释放时间和时钟建立时间不满足可能会出现寄存器进入亚稳态的偶发问题。我在代码里统一使用了异步复位同步释放的模板并且在约束文件中对复位信号设置了set_max_delay约束确保复位释放路径满足时序要求。综合完成后还要关注资源利用率。如果LUT或寄存器利用率超过70%布局布线难度会大幅上升时序收敛的难度也会增加。我的经验是将协议栈和测试逻辑分开布局通过Pblock约束将关键模块固定在特定区域这样既能缩短布线距离也便于后续做增量修改。3.4 上板前的仿真验证与常见陷阱在直接上板之前我花了不少时间做仿真验证。虽然开源代码自带的testbench覆盖了基本的功能场景但移植之后接口和参数有变化一些边界场景需要额外验证。仿真验证的重点有三个方面一是验证发送方向的数据通路从用户接口发出的数据能否正确组帧并送到MAC接口二是验证接收方向从MAC接口注入的报文能否正确解析出UDP载荷三是验证ARP请求和应答、ICMP回显这些控制平面功能是否正常。仿真中我踩过最典型的一个坑是tkeep信号的处理。在512bit位宽下一个UDP包的数据长度很可能不是64字节的整数倍最后一拍的tkeep是部分有效的。如果代码中把tkeep的判断逻辑写错会导致接收端解析出错误的载荷长度这在仿真中通常表现为数据错位但协议层面完全正常。另一个仿真陷阱是MAC硬核的行为模型与真实硬件的差异。Xilinx的100G MAC IP在仿真时会输出一些仿真特有的信号比如stat_*统计信号这些信号在真实硬件中也会出现但时序和数值可能有差异。建议在仿真时就把统计信号接出来上板后通过对比确认数据链路是否正常。4. 上板测试环境搭建与iperf3打流结果4.1 测试环境的完整拓扑与准备工作上板测试的环境搭建是整个项目中最耗时但也是最有价值的部分。一个规范的测试环境能让你快速定位问题而不是在“不知道是链路问题、协议栈问题还是测试工具问题”的迷雾中反复试错。我搭建的测试环境是这样的FPGA板卡通过QSFP28光模块连接一对光纤跳线另一端插到一台100G网卡的服务器上。服务器使用Ubuntu 22.04系统网卡型号是Mellanox ConnectX-5驱动mlx5_core支持100G速率。测试工具使用iperf3配合tcpdump或者wireshark辅助抓包分析。测试前需要做几件事。第一件事是确认光模块的兼容性。QSFP28光模块的型号选择很重要FPGA和网卡最好使用同一厂家的光模块或者至少确认双方的DDM数字诊断监控信息能被正确读取。第二件事是确认光纤链路质量最简单的方法是看网卡一侧的link状态是否变成UP如果link不UP检查光功率和信号完整性。第三件事是把FPGA的MAC地址设置为一个合法值IP地址设置为和服务器同网段的地址确保ARP能正常解析。我在第一次上板时服务器网卡显示link不UP排查了半天发现是光模块插反了方向——发送端和接收端接反了。听起来像个笑话但在100G级别的高速信号调试中这种低级错误反而最容易出现。4.2 Iperf3命令参数选择与双向吞吐测试完成基础环境搭建后我在FPGA板卡上配置了静态IP例如192.168.10.2/24对应MAC地址也做了软设置然后在服务器端启动iperf3服务端iperf3 -s -i 1服务器端启动监听后从同一服务器发起打流测试此时FPGA是接收端iperf3 -c 192.168.10.2 -u -b 100G -t 10 -i 1-u指定UDP模式-b指定目标带宽-t指定测试时间。初次测试时服务器端iperf3输出的接收带宽约为0bps说明FPGA端根本没有回包数据。问题定位到FPGA侧——检查ILA抓取的信号后发现ARP请求到达了FPGA但FPGA没有正确应答。排查发现是IP地址配置寄存器的位宽和字节序问题修复之后再次测试服务器端显示的接收速率稳定在98.4Gbps左右。这个结果基本达到了线速水平。UDP本身有20字节IP头和8字节UDP头加上前导码和帧间隔纯载荷速率不可能达到满100G98.4Gbps是一个比较健康的值。反向测试FPGA发送、服务器接收也是一样的命令不过要把FPGA端和服务器端互换角色。实际测试结果显示FPGA发送速率略微低于接收速率这主要是因为FPGA端发送数据时MAC层会自动计算并添加CRC增加了处理延迟。双向同时打满的情况下总吞吐量超过预期两台设备之间的流量达到了192Gbps级别这表明我用的FPGA资源足够处理双向全载荷数据而不丢包。4.3 丢包率与延迟数据的深入分析在iperf3的UDP测试输出中丢包率和延迟抖动是两个核心指标。我调整了发送端速率从1Gbps到100Gbps逐级提升统计对应的丢包率。当带宽低于60Gbps时丢包率为0当带宽达到100Gbps时丢包率约为万分之一。考虑到iperf3自身在打满线速时也会有调度损耗这个结果说明FPGA端的UDP协议栈本身没有构成瓶颈。为了进一步确认FPGA端的处理极限我修改了用户逻辑在接收后将每个包回环loopback到发送端测得的“反射”延迟发送到回收到约为1.5微秒这个延迟包括了FPGA内从MAC解析到UDP处理再回到MAC发送的全部时间。对比网卡到网卡之间的纯链路延迟约0.3微秒FPGA处理延迟增加了1.2微秒对于大多数数据中心场景来说完全可接受。丢包率测试中还有个小发现当发送速率超过90Gbps时FPGA端接收FIFO偶尔会出现溢出导致丢包。定位后发现是FIFO的深度配置不够——用户逻辑的消费速率跟不上突发流量。增大FIFO深度后丢包率从百万分之一量级降到了零。这个经验说明FIFO深度的配置需要根据实际应用场景合理设置不能简单拍脑袋用默认值。5. 常见问题与排查技巧实录5.1 链路层问题Link不UP与CRC错误上板测试中遇到最多的问题是Link不UP。从现象上看可能是FPGA侧看到的链路状态正常但服务器网卡侧Link Down或者反过来。排查链路问题有一个固定的顺序先检查光模块的光功率是否在合理范围内再检查GTY的PLL是否锁定接着检查MAC是否发出链路训练帧最后确认两端是否协商成功了FEC模式。调试过程中我习惯用ILA抓取MAC的tx_axis_*接口如果发送方向有数据输出说明MAC链路已经建起来。如果发送方向完全没有数据则问题大概率在GTY或时钟配置上。另外100G的链路训练需要一定时间不要一上电就急着看Link状态多等几秒钟再判断。CRC错误是另一个高频问题。现象是FPGA能收到包但服务器端显示大量CRC错误或FCS错误。这个问题的根源通常在PCS层——100G的64B/66B编码对误码很敏感哪怕是单个bit的误码也会导致整个帧被丢弃。检查光模块的DDM信息如果接收光功率接近灵敏度下限或者光模块温度过高都可能造成误码。我曾用过一条品质不佳的光纤跳线结果CRC错误率居高不下换了一条品牌跳线后问题消失。5.2 协议层问题ARP不通、UDP组播不达协议层排查需要抓包工具的帮助。在服务器端用wireshark抓包如果能看到ARP请求但没有ARP应答说明问题在FPGA端——ARP请求可能没有正确送达用户逻辑或者应答帧没有被正确发送。这时需要检查IP地址和MAC地址的配置是否与代码中的常量一致特别要注意地址的字节序问题。我之前遇到过IP地址配置为0xC0A80A02192.168.10.2但代码中解析时按大端序读取导致实际使用的IP变成了2.10.168.192ARP自然怎么都对不上。这个问题在仿真时不容易发现因为testbench用的是同一个字节序约定只有和真实网络环境对接时才会暴露。UDP组播测试不达的情况最先要确认的是组播MAC地址是否正确。UDP组播的MAC地址按照IETF规定是01:00:5E:xx:xx:xx其中后23位映射自IP地址。很多代码在ARP处理里只实现了单播应答对组播地址没有做过滤逻辑导致组播报文被MAC层过滤掉。解决方法是修改MAC地址过滤配置将组播地址加入白名单或者在用户逻辑中直接修改接收过滤规则。5.3 性能问题吞吐量打不满与系统卡死排查吞吐量打不满的情况可以从两个方向排查。第一个方向是确认瓶颈是否在FPGA内部——通过观察MAC的统计信号rx_good_packets、tx_good_packets等判断收发帧数是否相等。如果帧数相等但iperf3显示吞吐量有差异说明问题可能在服务器网卡侧——比如CPU中断处理能力不足、UDP接收队列溢出等。第二个方向是确认瓶颈是否在发送侧——如果FPGA发送时吞吐量达不到线速检查用户逻辑产生数据的速率是否足够以及发送FIFO是否频繁处于空状态。系统“卡死”的问题比较有意思。有一次测试中FPGA运行几个小时后突然不再响应ARP请求但Link状态正常。用ILA抓取后发现MAC的统计信号显示有持续的超大帧jumbo frame进入用户逻辑因无法处理超大帧而死锁。排查后确认是测试时iperf3发送了超过默认MTU大小的UDP包而FPGA端的缓存设计没有预留足够空间。这个问题用两个方法解决一个是在用户逻辑中增加对超大帧的丢弃逻辑另一个是和服务器端协商好MTU大小保持双方配置一致。5.4 移植项目常用调试方法论总结移植项目调试和全新设计调试有个很大的区别——你面对的是一个“大概率能跑通但偶尔有诡异问题”的代码库。因此调试方法要基于对开源代码行为的理解而不是简单地从头推演逻辑。我的调试习惯是“三层定位”先从现象判断问题在哪一层——物理层、数据链路层还是协议层然后在该层内的关键节点挂ILA或抓包工具最后用对比法缩小范围——把开源的example工程跑一遍如果example正常而你的工程不正常对比差异点即可快速找到问题。另一个好用的方法论是“灰度验证”。不要试图一次调到完美而是逐项验证先测MAC层的回环模式确保GTY和MAC硬核工作正常再测以太网帧收发确认CRC和帧格式正确再测ARP确认网络层互通最后测UDP数据通路确认载荷正确。每层验证通过后再进入下一层可以大幅降低调试难度。6. 实测心得与后续扩展建议6.1 实测中的几条核心经验整个移植和测试过程结束后有几条经验值得沉淀。第一开源协议栈的代码质量总体可靠但可靠的边界条件是你必须提供正确的环境。尤其要注意时钟约束、复位时序和FIFO深度这些基础配置任何一个失误都可能让你在调试中走很远弯路。第二100G调试中“眼见为实”的能力至关重要。ILA的采样深度一定要够至少能抓取完整的几个UDP帧。实际操作中我通常设置ILA的触发条件为报文的tlast信号然后查看前后多个周期的波形一次就能看到完整的帧结构比盲猜高效得多。第三100G项目一定要把链路层的稳定性放在首位。传输层跑得再快如果链路层偶发误码导致丢包整体性能还是不达标。建议在上板初期就持续跑一段长时间的稳定性测试至少12小时用统计信号记录误码和丢包情况确保链路质量稳定后再进入功能开发。6.2 后续可扩展的方向100G UDP跑通之后可扩展的方向非常多。如果项目需要GPU直接访问网络数据可以在UDP模块后面接XDMA或QDMA实现网络数据到主机内存的零拷贝传输。如果项目是做网络监控或流量分析可以在UDP模块后面接流表分类引擎做五元组匹配和流量统计。如果想支持RoCEv2需要保留MAC的流控能力和优先级处理逻辑这个方向的工作量和复杂度会明显上升但100G UDP跑通后整个基础设施是可复用的。如果把100G UDP当作一个基础组件来看从这次移植中获得的最有价值部分反而不是UDP协议本身而是对100G数据通路中AXI4-Stream时序、MAC硬核行为、GTY配置和时钟域交互的深入理解这些知识在未来面向200G、400G的项目中同样适用。