做FPGA高速网络的朋友应该都有同感：百兆千兆的UDP收发，只要照着参考设计改改FIFO深度就能跑通，可一旦把带宽拉到40G、100G这个量级，整个项目的难度就不是线性上升，而是直接跳档。最近我把一套开源的100G FPGA UDP方案移植到自有板卡上，从拿到RTL到上板用iperf3打满线速，前后折腾了两周多，踩了不少坑，也总算把整套流程跑通了。这篇就把移植过程中遇到的关键节点、测试方法和那些文档里不会写的细节一次性讲清楚，给准备在这个方向上动手的朋友做个参考。
这篇内容适合两类人：一是已经在做FPGA网络加速、正准备从10G/25G往100G升级的工程师；二是刚接触FPGA高速接口、想用现成开源方案快速验证100G UDP收发链路的开发者。涉及的知识点包括100G Ethernet Subsystem的工程集成、UDP协议栈的模块化移植、GTM/GTY收发器的时钟配置，以及上位机侧的打流和抓包验证，每个环节我都会尽量讲透场景、参数和取舍逻辑。
1. 整体方案选型与设计思路
1.1 为什么选择100G UDP作为切入点
100G以太网在数据中心核心交换和AI集群场景已经很成熟，但在FPGA项目里，真正能用起来的团队并不多。原因很简单：100G链路对MAC、PCS、PMD每一层都有极高的时序和集成要求，一旦链路不稳定，问题排查的成本远高于10G/25G方案。可一旦打通，收益也非常直观——单条光纤就能承载10路10G业务，很多需要多路并行处理的场景可以直接合并成单流处理，系统架构能简化一大截。
选择UDP协议栈作为切入点，是因为UDP本身极度简单、轻量，非常适合作为FPGA高速网络的首个验证对象。TCP协议栈在FPGA里实现要考虑连接管理、滑动窗口、重传排序、拥塞控制，复杂度高出好几个量级；UDP则基本等于“拿到包就发走”，核心逻辑只有地址解析、校验和计算、分片重组这几块。这个特性决定了在100G这种高线速下，UDP逻辑不会成为瓶颈，瓶颈主要集中在MAC/PCS硬核的配置、收发数据路径上的FIFO带宽和用户逻辑的处理吞吐。
也就是说，100G UDP的移植重点不在于UDP协议本身，而在于你围绕UDP这个“小核心”搭起来的整条高速通路是否顺畅。我在项目启动时就把技术目标定为：用开源RTL实现UDP收发，MAC/PCS层用FPGA厂商硬核IP，用户侧预留标准的AXI4-Stream接口，最终用iperf3和Wireshark在上位机上验证吞吐和丢包指标。这套组合的好处是职责边界清晰，哪一层出问题可以快速定位。
1.2 开源方案怎么选：Corundum、verilog-ethernet 还是自研精简栈
目前FPGA生态里能直接参考的UDP开源实现主要有三条路线。
第一条是Corundum，出自康奈尔大学的一个高性能网卡开源项目，支持100G，实现了完整的PCIe DMA、MAC、UDP/IP协议栈，结构非常完整，大量使用了SystemVerilog接口和参数化设计。Corundum适合作为“完整参考设计”来研究，它的UDP Offload、TX/RX校验和计算、描述符管理都做得非常规范，但对应的学习曲线也最陡——光是理解它的DMA路径和用户接口就要花不少时间，而且它侧重网卡方向，如果你只需要纯粹的UDP数据收发，会感觉它“太重了”。
第二条是Alex Forencich维护的verilog-ethernet项目，包含Ethernet MAC、UDP、ARP等模块。它支持AXI4-Stream接口，代码风格清晰，很多模块可以单独拎出来用。但它的主要目标仍然偏10G/25G，100G相关支持更多依赖外部MAC硬核配合，UDP模块本身是宽度无关的，可以工作在512bit这种超宽数据总线上。
第三条就是自己基于Xilinx/Intel的100G MAC硬核，只写精简UDP发送接收状态机。这条路线对代码工程量要求最低，因为UDP逻辑本身不大，但你需要自己处理ARP、ICMP等配套协议，这也是最初容易忽略的地方——上位机在与FPGA通信之前，通常会先发ARP请求确认MAC地址，如果FPGA不回ARP，UDP包根本不会发出来。
我最终选择了verilog-ethernet的UDP模块配合Xilinx 100G Ethernet Subsystem硬核的组合。选它而不是Corundum，主要看重两点：一是AXI4-Stream接口标准，后续对接图像、数据采集类用户逻辑很直接；二是代码精简，出问题方便顺着RTL一层层查。如果后续需要完整网卡功能，再往Corundum迁移也顺理成章。
2. 硬件准备与测试环境搭建
2.1 FPGA板卡与光模块选型要点
100G方案对板卡有硬性要求，不是随便一块带高速口的开发板就能跑。首先FPGA芯片必须集成支持100G速率的光收发器，Xilinx这边一般是UltraScale+系列的GTY（最高到25.78125Gbps每通道，4通道聚合即100G）或者Versal里的GTM，Intel那边对应E-tile。其次板卡上必须有两个QSFP28或QSFP-DD接口，用于接100G光模块或DAC高速铜缆。最后是参考时钟，100G以太网通常要求光模块侧提供156.25MHz参考时钟，很多开发板默认的125MHz只够跑10G，这一步非常容易翻车。
光模块方面我建议首选QSFP28 DAC铜缆做初期调试。DAC线缆是铜线直连，不需要光模块和光纤配对，少了一个信号完整性变量，对排查问题极其友好。等DAC链路完全稳定、跑满线速不报错之后，再换光模块加光纤做长距离验证。我这次测试就全程用的DAC线，直连服务器网卡，简单可靠，也不存在光功率预算问题。
服务器网卡建议选Mellanox ConnectX-5及以上规格的100G网卡，驱动成熟、对iperf3和DPDK支持好，测试时能省很多精力。如果你手头只有25G网卡，也可以临时把FPGA侧PCS配置成4x25G模式，但这样就不是真正意义上的100G点对点验证了，链路层很多问题测不出来。
2.2 上位机测试环境清单
上位机测试环境是我这次踩坑比较多的部分，按经验提前准备好能省一天时间。核心工具就三件：iperf3用于打流测吞吐和丢包，Wireshark用于抓包验证协议字段，tcpdump用于命令行环境下的快速抓包。系统方面Ubuntu 20.04以上就可以，主要确认内核自带网卡驱动能识别100G速率，用ethtool查看速率是否协商成100000Mb/s。
另外强烈建议提前准备一个UDP调试小工具，比如packetsender或者用Python socket脚本，用来做小流量定向发包。因为iperf3的UDP模式虽然方便，但它的发包行为是“尽力而为”，在接近线速时会出现CPU瓶颈导致的丢包，这种丢包是上位机的锅，不是FPGA的锅。用小工具发固定速率、固定长度的报文，能帮你在排查时明确区分丢包发生在发送端、链路上还是接收端。
硬件链路的连接顺序也要注意：FPGA板卡的两个QSFP28口，一个连接交换机或服务器网卡用于业务测试，另一个可以临时用于回环测试。如果板卡只有单口，也可以直接用DAC线把FPGA的两个口环起来，做纯内部数据回环验证。
3. 移植过程与核心细节解析
3.1 从开源工程到自有芯片的移植流程
拿到开源RTL之后，第一件事不是急着综合，而是先梳理清它的模块依赖关系。以verilog-ethernet为例，顶层是eth_mac_100g、udp_engine这些模块，底层依赖xilinx的100G硬核IP，硬核IP的资产是通过IP Catalog生成的，不同FPGA型号生成的IP是有差异的，直接跨型号使用肯定不行。移植的第一步就是把IP重新生成，换成目标芯片对应版本，保证接口位宽和时钟频率符合预期。
100G MAC硬核生成时几个关键参数要特别留意：数据总线宽度一般选512bit，对应352MHz左右的user clock（512bit × 352MHz ≈ 180Gbps理论带宽，实际扣掉前导码和帧间隙后刚好能支撑100G线速）；也有的流程选256bit、644MHz，这种高频方案对时序压力大，但对用户逻辑反而更友好。包使能信号、CRC转发、流控模式要根据开源模块的接口要求对齐。
然后是时钟和复位。100G硬核内部有多个时钟域：GT收发器时钟域、PCS时钟域、MAC用户时钟域，开源RTL在移植时最容易出问题的就是用户时钟域与硬核usr_clk的换算关系不一致。我的经验是先把example design跑起来，用示波器或ILA确认usr_clk频率正确、复位释放干净，再接入UDP逻辑。很多“看不出原因的不稳定”，最后查下来都是复位释放时间不够或者跨时钟域没做同步。
3.2 AXI4-Stream接口与用户逻辑的衔接
开源UDP模块与MAC之间、模块与用户逻辑之间基本都是AXI4-Stream接口，理解这个概念是移植成功的一半。AXI4-Stream说白了就是三根关键信号：TVALID表示本拍数据有效，TREADY表示对端准备好了，两者同时拉高才算把数据成功传了一拍；TDATA是要传输的数据，TLAST是一包数据的最后一拍标志，TKEEP则标记TDATA里哪些字节有效。
做100G链路时，tdata通常是512bit宽，也就是一拍能塞下大半段以太网帧，这种超宽数据路径带来两个典型问题。第一个是tkeep处理：一个UDP包不一定是512的整数倍，最后一拍可能需要用tkeep掩掉无效字节，如果tkeep逻辑写错，会出现接收端CRC校验失败或者包长度错误。第二个是tlast和包间距：100G下以太网帧间间隔IFG只有十几个时钟周期，用户逻辑如果不能在tlast之后迅速准备好下一包，吞吐就会明显下滑。这两个问题我在debug时都用ILA抓过波形，原因都很隐蔽，建议大家在一开始写用户逻辑时就格外注意。
用户逻辑侧的吞吐是另一个隐藏瓶颈。很多人以为UDP逻辑跑通了就万事大吉，结果上板一打流发现接收吞吐只能在50G左右，怎么调都上不去。查到最后往往发现是DMA、FIFO或者算法模块的处理带宽不够，比如FIFO的读数据宽度和写数据宽度不一致导致带宽折损，或者内部RAM用了简单双口而不是真双口，读写冲突带来额外等待。我的建议是用户逻辑到UDP模块之间必须保留足够的FIFO弹性，最好把FIFO深度设置成能吸收至少一个完整Jumbo Frame的量级，避免微突发时瞬间丢包。
3.3 UDP校验和与ARP/ICMP配套逻辑
UDP协议的移植核心虽然简单，但校验和计算是一个容易忽略的细节。IPv4下UDP校验和是可选的，可以置0表示不校验，但如果上位机或者中间交换机开了校验和检查，置0的包有可能被直接丢弃。我建议还是老老实实实现校验和，IP头校验和、UDP头加伪头部校验都算上，虽然占用一点逻辑资源，但能避免很多排查不清的隐性问题。
校验和的工程实现也讲究方法。最直观的办法是逐字节累加求反码，但100G线速下这显然不现实，必须在数据进入MAC之前做流水线化处理。正确的姿势是使用“增量校验和更新”技巧：当数据以512bit宽总线进入时，可以分段累加，再将结果合并；或者对已知要覆盖的字段（源IP、目的IP、长度）在头部处理时直接算好，数据payload的累加可以边存边算，最后一拍凑齐整个伪头。这个逻辑写的顺序影响性能，我一开始图省事用了简单的两段式累加，结果在超长帧场景下时序收敛不了，后来改成树形归并结构才解决。
配套的ARP逻辑很多开源栈里都有，但要不要全量实现需要想清楚。如果只是点对点通信，静态IP和MAC配置，可以把ARP应答写死，上位机发来ARP请求时直接硬件回一个应答即可，不用实现完整的ARP缓存表。ICMP（ping）同理，能回复Echo Request会让你调试网络连通性时省太多时间。我个人的经验是：哪怕你不需要业务上的ARP和ICMP，也建议把最小实现加上，因为你不可能永远记得把所有上位机的ARP缓存清干净。
4. 上板测试全流程实录
4.1 第一关：外部回环与底层链路验证
拿到bit后不要急着连服务器打流，先把底层的物理链路验证干净。我习惯用DAC线把FPGA的两个100G口外部短接起来，然后让FPGA内部自发自收——由测试逻辑从TX路径发出已知模板的UDP包，再从RX路径收回来做比对。这一阶段能确认的事情非常多：GT收发器有没有失锁、PCS有没有完成对齐、MAC的FCS校验是不是正常、RX路径上的FIFO会不会丢数。
回环测试如果发现error计数器在涨，优先查光模块/DAC线和GT的signal integrity状态。Vivado里可以用IBERT这个工具直接看眼图和误码率，对100G链路尤其重要。如果误码率高，先在IBERT里把TX的预加重参数、RX的CTLE/DFE均衡参数调好，再回到用户工程里重新上板。我这次遇到过一次误码率在1E-12量级来回跳的情况，排查到最后是DAC线的QSFP28接口没插到位，重新插拔后误码率直接干净了。这类物理层问题不先排除，后面所有协议层的排查都会白费功夫。
回环通过后，可以把外部回环换成FPGA内部环回（在PCS或MAC层做数字环回）做对比测试，两种环回交叉验证能帮你区分问题是出在模拟物理层还是数字协议层。这个习惯帮我节省了一次莫名其妙的排查——内部环回全通、外部环回报错，问题基本锁定在GT和光口上。
4.2 第二关：点对点直连与iperf3打流
外部回环和内部环回都稳定后，真正的考验才刚开始：FPGA通过DAC线直连服务器100G网卡，用iperf3双向打流。
TX方向（FPGA发往服务器）先做。服务器端执行：
iperf3 -s -i 1FPGA端的上位机控制逻辑开始按设定速率和包长持续发包。这里有个经验：UDP打流测试不要一上来就跑满100G，先从小带宽开始，比如10G、50G、80G逐级往上加，每级跑30秒，记录服务器端收到的吞吐和丢包率。这么做的好处是能清晰找到链路开始出现丢包的临界点，方便定位瓶颈在哪个环节。
RX方向（服务器发往FPGA）用iperf3反向模式：
iperf3 -c <FPGA_IP> -u -b 95000M -l 1424 -t 30这里几个参数解释一下：-u指定UDP模式，-b设定目标带宽95000Mbps，-l是UDP包负载长度1424字节（加上IP/UDP头后整帧长度接近1500，这是避免IP分片的常见做法），-t是持续时间30秒。95000M而不是100000M是有意的，留出5%余量给协议开销和包间隔，否则iperf3发包本身就会出现CPU处理不过来的丢包。
服务器和FPGA之间的MTU也要提前匹配。如果服务器MTU是1500，那l=1424正好；如果网络里能开9000字节巨型帧，可以把MTU调成9000，l设8972，吞吐表现会更好，因为单位时间里处理的包数量少了，CPU和FPGA的压力都会小一些。
4.3 第三关：Wireshark确认协议字段
打流能过不代表协议就完全正确，强烈建议再用Wireshark抓包确认UDP协议字段是否规范。抓包可以抓服务器网卡侧，用tcpdump抓一小段即可：
tcpdump -i enp3s0f0 udp -c 100 -w fpga_udp.pcap然后用Wireshark打开pcap文件分析。重点看三项：一是UDP源端口和目的端口是否与配置一致；二是IP头的Total Length是否等于UDP长度加20字节头；三是源IP和目的IP是否正确。还有一个容易被忽略的点：Wireshark默认可能不显示以太网帧的FCS校验字段，因为大多数网卡驱动在收包时已经把FCS剥离了，但这不代表FCS不重要，FPGA侧MAC上还是有独立的CRC error计数，需要从硬件侧单独读取。
如果FPGA的UDP包是通过开源UDP模块发的，Wireshark里通常能直接解析出UDP协议；如果Wireshark里显示的是“Unknown”或者解析异常，大概率是长度字段或者端口字段错位了，可以对照协议规范逐字节查。
为了验证RX路径（服务器发往FPGA），可以在Wireshark里给FPGA侧的响应包做过滤分析，也可以直接在FPGA侧用逻辑分析仪（ILA）抓RX路径上的tvalid/tdata，确认报文的源端口、目的端口、校验和字段是否与服务器发送的一致。ILA抓高速数据时存储深度有限，可以设置触发条件只抓一个UDP包头，这样能快速看清关键字段。
5. 测试数据解读与指标分析
5.1 三个核心指标：吞吐率、丢包率、延迟
经过两三轮调试，最终上板测试数据出来了。我在FPGA TX往服务器方向，用iperf3在服务器端接收，结果如下：
| 配置带宽 | 实际接收吞吐 | 丢包率 | 抖动 |
|---|---|---|---|
| 10Gbps | 9.98Gbps | 0% | <1us |
| 50Gbps | 49.96Gbps | 0% | <1us |
| 80Gbps | 79.91Gbps | 0% | 1-2us |
| 95Gbps | 94.82Gbps | 0.01% | 2-3us |
| 99Gbps | 96.50Gbps | 2.5% | 5-10us |
前四级速率下，UDP模块的实际吞吐基本贴着配置值走，说明用户逻辑侧的FIFO和MAC带宽足够。95Gbps时开始出现极少量丢包，99Gbps时丢包率跳到2.5%，这基本符合预期——iperf3接近线速时CPU中断处理和PCIe带宽都会成为瓶颈，不会是FPGA侧的问题。想验证这一点，可以把测试换到DPDK环境，DPDK轮询模式能榨出网卡的极限性能，但用户体验会差一些，一般Iperf3跑到95G这个成绩已经能证明UDP通路没有设计缺陷。
延迟测试我用的方案是PTP时间戳或者简单的心跳包RTT测试：FPGA收到ICMP Echo Request后立即回一个Echo Reply，服务器端ping测RTT。本地DAC直连场景RTT均值大约11微秒，其中大部分是软件协议栈处理耗时，纯FPGA转发延迟应该在微秒以内。如果后续要更精确的延迟指标，建议在FPGA内部标记时间戳寄存器和MAC的时间同步逻辑做硬件级测量。
5.2 微突发丢包现象与FIFO深度的关系
UDP打流丢包是排查时最常见也最头疼的问题。一个特别容易误导人的现象：平均吞吐明明没过线速，但丢包还是零星出现，这种通常是微突发瞬时拥塞导致的，比如四个20G的突发在某个瞬间同时击中同一FIFO，FIFO溢出立刻丢包，平均上看不出来。
微突发丢包最有效的排查手段是看FPGA侧RX MAC的统计计数和FIFO的空满标志。我在工程里专门接了ILA到RX FIFO的满信号上，触发条件是满信号拉高，抓一次波形就能看到丢包瞬间的数据流行为。如果满信号经常拉高，说明FIFO深度不够或者用户逻辑消费速率跟不上，解决办法要么加大FIFO深度，要么把下游逻辑的处理吞吐提上去。这里要特别注意FIFO深度的单位是“拍”而不是“字节”，512bit位宽下深度1024的FIFO只能存64KB，刚好是一个巨型帧的量级，所以100G场景下FIFO深度参数往往要比10G方案激进得多。
还有一种情况：FPGA内部分支逻辑消耗速率足够，但DMA或PCIe接口有背压，导致用户逻辑时不时回压到RX路径。这种背压传播到MAC再传播到对端，对端网卡就会重传或由上层协议感知为丢包。检查时可以在用户逻辑和MAC之间加一个测量模块，统计TVALID&~TREADY的周期数占空比，如果比例超过1%，背压问题就值得排查了。
6. 常见问题与排查技巧实录
6.1 链路起不来：GT失锁与PCS对齐失败
上板后最常见的第一类问题就是100G链路根本拉不起来，服务器网卡显示速率协商失败或者大量link down。这类问题优先从物理层往协议层逐级排查。
第一步看GT状态寄存器，确认GT是不是处于失锁lock丢失状态。如果GT从来没失锁过，问题大概率在PCS或MAC配置；如果GT一直在失锁和锁定之间来回跳，基本是信号完整性问题，重新检查DAC线是否插紧、参考时钟频率是否正确。第二步看PCS有没有完成对齐，100G PCS的alignment marker是否被正确识别。第三步看MAC层FCS错误计数器，如果FCS狂涨但PCS对齐正常，说明数据在PCS到MAC的传输路径上有损坏，需要回查GT receive path的位宽和字节顺序配置。
字节顺序问题特别值得提一下，100G GT通道4路的数据交织顺序如果和MAC硬核期望不一致，会出现“链路是通的，但所有包都CRC错”的现象。排查方法是用IBERT的伪随机序列配合MAC层的PRBS测试，或者直接在MAC层发一个已知pattern，再用ILA抓RX侧数据对照。改字节顺序需要同时调整GT的极性、通道映射和PCS的接收侧位宽，牵一发动全身，改完一定要重新回环自测。
6.2 用户逻辑带宽不足导致的隐性丢包
这类问题最隐蔽，因为从MAC层看没有任何异常，CRC不报警、FIFO没溢出，但UDP业务层的丢包率就是降不下去。我曾经遇到过一次：上位机用iperf3发87Gbps的UDP流，FPGA内部RX FIFO不溢出，但应用层最后收到的有效数据只有82Gbps，丢了将近6%。查了很久才发现是用户逻辑里有个图像处理模块，处理峰值速率只有85Gbps左右，平均够用但瞬时处理不过来，产生周期性背压，背压期间FIFO里的包被新来的包覆盖。
这类问题的排查思路要跳出MAC层，把用户逻辑也纳入测试范围。最简单的方法是做一个旁路功能：把UDP模块的RX数据不经用户逻辑，直接环回到TX路径发回服务器，对比环回模式和正常模式的丢包率。如果环回模式下0丢包、正常模式丢包，问题就锁定在用户逻辑；如果环回模式也丢，那就在FIFO、MAC或者物理链路上。这种二分定位法，我几乎每次排查都用得上。
带宽评估时还要注意数据格式的差别，有些高速接口是DDR的，有些是SDR的，带宽计算容易出岔子。最简单的做法是统计实际处理的数据字节数除以耗时，得出真实的吞吐数值，再和目标带宽比较，而不是只看理论位宽乘以频率。
6.3 时序收敛：512bit数据通路上的细节
100G工程最大的物理实现挑战是时序收敛。512bit数据总线上，哪怕只差一级组合逻辑，路径延迟就多了几个纳秒，在352MHz的时钟下很可能直接violation。
遇到时序不过，我的处理顺序是：优化代码结构、检查复位逻辑是否复用为普通信号、再考虑流水线寄存器插入。前两个没有成本，第三个会多几个周期的延迟，但对UDP协议收发影响不大，可以放心加。一个经常被忽视的细节是：AXI4-Stream的tready信号如果经过多级组合逻辑再回传给发送端，会形成一条很长的组合路径。解决办法是在接口处加一级寄存器打拍，tready延迟一拍，对端多等一拍，代价是每包有效带宽少了一拍，在高带宽需求下要配合fifo提前预取来抵消。
综合策略上，100G工程建议直接开Performance Explore模式，在综合阶段把retiming打开、尽量少用max_delay约束，优先保证常规路径的时序裕量。布局布线跑完如果还是有少量violation，优先看是否集中在GT clock区域附近，如果是指定了过紧的IO约束引发的问题，可以适当放松。
7. 移植完成后的体会
在100G UDP这条路上折腾两周多，最大的体会是：UDP协议本身不复杂，复杂的是100G这条物理和数字交叉的"高速公路"上每一个环节都必须同时工作正常。
移植开源RTL时不要急着综合上板，先列一个清单：底层GT和PCS验证什么、MAC层验证什么、UDP协议层验证什么、用户逻辑验证什么，每层验证通过后再往上一层。回环、IBERT、iperf3、Wireshark这四件套配合下来，可以把问题一层层剥开，不至于在多个环节同时出问题的时候乱成一团。
最后再分享一个小技巧：给FPGA工程加上一个简单的UDP回环测试模式——服务器发什么，FPGA原样回什么。这个模式看起来不起眼，但排查问题时价值极高。链路不稳定时可以用它快速确认是不是物理层问题；用户逻辑有bug时可以用它旁路业务逻辑；甚至还可以用它做极限带宽压测，因为回环模式下FPGA不需要处理业务数据，能跑到的最大吞吐就是这条链路的真实上限。我后面的项目里都会保留这个测试模式，相当于是给整个系统留了一个"安全通道"，比临时改代码加debug逻辑省事太多。
