做 FPGA 高速接口的同行应该都有体会10G 是以太网基本功25G 开始要认真看时序到 100G 就是另一套玩法了。前段时间我接了一个需求要把一套开源 100G FPGA UDP 协议栈移植到自研板卡上完成上板验证目标是用 iperf3 跑出接近线速的 UDP 吞吐同时把丢包率压到可控范围。整套流程走下来从开源仓库到 bitstream从 GTY 参考时钟配置到 512bit 数据总线上的时序收敛从实验室光纤连线到抓包比对每一环都有代表性的大坑。我把这次“开源 100G FPGA UDP 移植上板测试”的完整过程整理出来方案选型思路、关键模块原理、移植步骤、排错记录一次说清楚。适合三类人读准备从 10G/25G 往 100G 迁移的 FPGA 工程师想评估开源 UDP 卸载方案是否靠谱的系统架构师以及正在为 100G 上板疑难杂症失眠的同行。即便你手头的板卡还是 25G 甚至 10G这篇文章里关于时钟、异步 FIFO、校验和、抓包排错的思路也完全通用。1. 项目定位与方案选型100G UDP 的开源路线1.1 需求拆解我们要的其实不只是 UDP拿到需求先做拆解。高速数据采集、网络加速、存储网关这类场景里100G 接口的意义不是“带宽数字好看”而是把 CPU 从逐包处理里解放出来。FPGA 上实现 UDP 卸载之后主机或者前端逻辑只需要提供目的 IP、目的端口和 payload剩下的 MAC 帧封装、IP 头、UDP 头、校验和全部在硬件里完成单包处理延迟可以做到微秒级以下。这种确定性的低延迟是纯软件协议栈给不了的也是我们要在 FPGA 上做 UDP 移植的根本原因。为什么选 UDP 而不是 TCP答案很直接TCP 是有状态协议有连接管理、拥塞控制、重传机制在 FPGA 里完整实现代价极高吞吐还容易被状态机瓶颈拖累。UDP 无连接、无状态硬件只需要做“封装校验转发”逻辑简单吞吐容易做高。数据中心里不少专用加速链路本来就不需要 TCP 的语义视频流、数据复制、部分 RDMA 场景都用 UDP。对 FPGA 来说UDP 是性价比最高的网络协议入口。1.2 开源方案对比Corundum 与 verilog-ethernet动工之前我认真盘了一遍市面上的开源方案。这里给一个基于我个人使用经验的对比表方便后面参考方案带宽支持核心定位License移植工作量Corundum10G/25G/100G完整网卡平台PCIe DMAUDP/RDMA 卸载BSD高依赖 Xilinx 100G IPverilog-ethernet10G/25G轻量以太网组件库MAC、LFSR、UDP/IP 卸载BSD中商业 Xilinx IP自研 UDP100GMAC/PCS 用商业 IPUDP 逻辑自研商业中高学术项目不等特定协议栈各异参考价值为主Corundum 是 Alex Forencich 那套 verilog-ethernet 的“全家桶”升级版把 PCIe 根端口、DMA 引擎、UDP 卸载、100G MAC 全链路打通社区活跃度很高issue 响应也快。verilog-ethernet 更轻量适合不需要 PCIe、只想把 UDP 收发逻辑嵌进自研数据通路的场景。我这边需要做一块独立的 100G 数据加速板卡既要从光口收 UDP 包也要从光口发 UDP 包和主机 PCIe 的耦合其实是次要的但 Corundum 的模块化程度和板卡参考设计完整度最好所以选了它。1.3 移植前明确边界哪些能复用哪些要重写选型定了不等于万事大吉。开源代码是通用设计落到自研板卡上一定会遇到“参考设计假设了特定时钟、特定引脚、特定 IP 版本”的问题。我在移植前先划了一条边界物理层完全复用 Xilinx CMAC 加 GTY 的配置思路MAC 层到 UDP 卸载层尽量不做大改动只调整包尺寸参数和查表表项去适配场景PCIe 相关模块当前用不到就先挂空或者走最小配置等链路跑通再回来补。这个边界的意义在于控制变量。100G 上板调试横跨物理层、协议层、主机软件三层如果一次改动太多出了问题根本定位不到根因。先把“收发 UDP 包”这条主链路跑通再谈性能优化和功能扩展这是我做高速接口项目一直坚持的顺序。2. 100G 链路核心原理移植前必须搞懂的三个层面2.1 物理层GTY 收发器与四通道聚合100G 以太网物理层听起来吓人拆开看就是一个“四通道聚合”结构。100GBASE-R 由 4 条 25.78125Gbps 串行通道组成每条通道跑 64b/66b 编码净数据等效 25Gbps四条合计约 100Gbps。所以 FPGA 侧第一步是把 GTY 收发器配置到 25.78125Gbps参考时钟几乎都用 156.25MHz。新接触 100G 的工程师容易在一个地方卡住10G 时代逻辑侧用 64bit 总线、156.25MHz直接跟线路速率对应很好理解100G 的逻辑侧总线就变成了工程权衡的焦点。Xilinx 100G CMAC 通常给出 512bit 的 AXI4-Stream 接口逻辑时钟需要跑到 322.265625MHz 附近也可以选更宽的位宽来降时钟但布线资源和寄存器扇出会迅速吃掉 FPGA 的余量。这里的第一条纪律是逻辑侧时钟不是你想跑多少就多少物理层 IP 已经把选择范围定死移植时不要为了“看起来稳”去随意改动 IP 内部时钟配置。2.2 MAC/PCS 层64b/66b、RS-FEC 与 CMAC 状态100G MAC 和 PCS 层的核心是 64b/66b 编码每 64bit 数据加 2bit 同步头变成 66bit 在串行链路上传输接收端靠同步头做字对齐和通道绑定。CMAC 里还会做通道重排序因为 4 条通道在接收端不一定按原始顺序到达。对调试者来说CMAC 的 status 信号是关键中的关键PCS 对齐、AM 锁存、通道绑定、FEC 误码计数都是判断链路是否健康的直接证据。RS-FEC 单独说几句。100G 短距光模块SR4/LR4一般可以不开 FEC但走 DAC 铜缆或者背板 KR 模式时RS(544,514) FEC 基本是强制要求否则误码率高到没法稳定传包。FEC 必须在收发两端配置一致这是上板联调最容易翻车的点之一FPGA 侧开了 FEC对端设备没开结果就是链路不稳定、误码重传满天飞。在实验室里我先统一用不开 FEC 的 SR4 光模块把功能调通再切换到最终场景验证 FEC 配置这样变量少、定位快。2.3 UDP 卸载引擎从 MAC 帧到载荷的流水线细节UDP 卸载引擎在 100G 上的逻辑复杂度并不比 10G 高多少难点全在“带宽×位宽×时钟”的组合上。一条典型的 TX 流水线是这样的应用逻辑通过 AXI4-Stream 把 payload 打进 TX 队列引擎查询 ARP 缓存拿到目的 MAC 地址生成以太网头插入 IP 头填版本、总长度、TTL、协议号 17计算 IP 校验和插入 UDP 头填源端口、目的端口、长度计算 UDP 校验和整帧送到 100G MAC 计算 FCSCRC32再进 PCS 编码。RX 方向就是反向操作MAC 层校验 FCS 并剥离以太网头再校验 IP/UDP 头最后按四元组源 IP、目的 IP、源端口、目的端口查表分发到不同接收队列。这里面有一个非常隐蔽的边界UDP 校验和算法是“逐 16bit 累加再取反”硬件引擎如果做增量更新比如只改端口号就快速重算校验必须小心 16bit 进位回卷的边界。很多自研引擎在这个位置有隐蔽 bug表现就是大多数包正常特定长度或特定载荷下偶发校验错包特别难查。开源实现一般是完整重算校验和逻辑简单正确性优先这个取舍在 100G 高带宽下反而更稳。另外 ARP 表必须有老化机制否则对端换 IP 之后你还往旧 MAC 地址上发表现就是“链路明明是通的UDP 就是没有回包”。3. 移植实操把开源代码落到自研板卡3.1 读懂参考设计三个文件决定成败Corundum 仓库里每个参考板卡一个目录典型如 Alveo U250、VCU118。拿到仓库第一件事不是改代码而是读参考设计里的三个关键文件顶层 RTL、约束文件、时钟 IP 配置。顶层 RTL 告诉你 100G MAC 怎么例化、用户时钟怎么产生、复位逻辑怎么设计XDC 约束告诉你哪些引脚绑定到哪个 GTY Quad时钟 IP 配置告诉你 REFCLK 频率、GTY 通道速率和逻辑时钟频率从哪来。我这次是把自研板卡原理图跟 U250 参考设计逐引脚比对列了一张映射表GTY 位置、REFCLK 引脚、QSFP28 的管理引脚I2C、中断、LP 模式、状态指示灯、拨码开关全部对应清楚才动代码。这个过程枯燥但是值得100G 板子改错一个引脚约束轻则综合报错重则上板后链路完全起不来而你很可能还在错误方向排查几个小时。3.2 板级适配引脚、时钟、约束逐项核对100G 的约束文件里有几项必须逐条确认不能照抄参考设计GTY 引脚QSFP28 的 TX/RX 差分对必须落在所选器件可用的高速 Quad 上且跟 REFCLK 在同一个 Quad或者属于允许跨 Quad 的拓扑关系参考时钟156.25MHz 差分时钟必须进 GTY 专用参考时钟引脚不能随便用一个普通时钟引脚替代逻辑时钟CMAC 用户时钟、AXI 总线的 create_clock 约束要跟着 IP 配置走不能自己拍脑袋定频率时序例外跨时钟域 FIFO 两侧的 set_false_path 或 set_max_delay 要成套维护漏一条就可能在布局布线时浪费大量时间。还有一类常被忽略的约束是电源和模块管理相关引脚。100G 光模块功耗不低QSFP28 的插拔检测、模块功耗协商信号都要正确接上并约束到位否则模块可能因为“没被主机正确识别”而拒绝上电发射激光链路自然起不来。这些细节全藏在原理图里移植时不花时间核对上板后必然还账。3.3 工程搭建与 IP 配置小步快跑Corundum 的 fpga 目录里有 Tcl 脚本可以生成 Vivado 工程。我的做法是把参考板卡的 Tcl 复制一份改成新板卡的器件型号、约束路径和 IP 参数。这里特别强调版本一致开源代码通常是在某个 Vivado 版本下验证过的如果新工程用了更高版本100G Ethernet Subsystem 和 Transceiver IP 的界面参数可能会有变化导致“明明照着脚本来的生成的 IP 却跟参考设计对不上”。遇到这种情况先回到仓库 README 里确认它推荐的 Vivado 版本别一上来就追新。IP 集成之后先做一次空跑确认所有 IP 的时钟、复位能正常产生再往上挂 UDP 引擎和测试逻辑。我习惯在顶层保留一个 AXI-Lite 寄存器组把关键状态寄存器拉出来方便硬件调试。开源代码的调试接口一般都很完善把该接的寄存器接全后面上板能省一半时间。3.4 时序收敛322MHz 逻辑域的调优手段综合实现跑完第一轮 timing 大概率不过这是 100G 项目的常态。512bit 总线在 322MHz 下的扇出压力比 10G/25G 高一个量级我总结出几个有效手段高扇出复位信号做同步复位树避免异步复位直接扇出到几百个寄存器上AXI4-Stream 长路径上插入 skid buffer这种带流控的流水寄存器会增加几拍延迟但能换来时序收敛UDP 校验和的加法树用 DSP 或逐级打拍不要在组合逻辑里一次算完 32bit 累加对无需关心的跨时钟域路径明确设置 set_max_delay 或 set_false_path避免工具白费布线资源关键路径上把单周期全处理改成多拍流水配合寄存器重组拆长路径。最终这张板卡的 100G 逻辑域我要求时序收敛后必须保留正余量才生成 bitstream。有人喜欢压线过觉得省资源但 100G 上板之后温度、电压稍有波动临界路径会先挂掉表现就是跑着跑着开始随机丢包。这种 bug 后期排查成本远高于当时多花两三版实现的成本。4. 上板测试从链路自检到 iperf3 满带宽打流4.1 测试环境与物理链路检查测试环境搭建本身不复杂FPGA 板卡插 QSFP28 模块用一根 100G DAC 线直连对端设备。对端可以是另一块 FPGA 板卡也可以是带 100G 网口的服务器。上电后第一件事不是跑业务是先查链路物理状态GTY 的 QPLL/CPLL 是否锁定、CMAC 的 PCS 对齐和 AM 锁定状态、FEC 误码计数是否正常。如果对端是大网卡或交换机还要看对端链路是否 up。我这次用 Vivado Hardware Manager 直接在 Hardware Session 里挂 ILA把 CMAC 状态信号和 GTY 锁存信号一起拉出来比反复读寄存器直观得多。这一步能确认 80% 的物理层问题时钟有没有进、收发器有没有锁、PCS 有没有对齐。链路状态确认正常之后再加载业务 bitstream千万不要在物理层没确认的情况下浪费几个小时去查 UDP 逻辑。4.2 回环自检顺序先内部数字回环再物理回环板卡刚点亮时直接拿主机打流是灾难因为你分不清丢包是 FPGA 的问题还是主机网卡的问题。正确顺序是先在 FPGA 内部做数字回环把 TX 数据直接送回 RX验证 MAC/UDP 逻辑本身再开 GTY 的 near-end PMA loopback验证收发器的串行通路然后用 DAC 线缆做物理回环验证外部光模块和连接器最后才跟对端设备联调。开源仓库一般会带 LFSR 伪随机序列发送器verilog-ethernet 里那个 lfsr_udp 就是干这个的可以持续发送指定长度的 UDP 包对端收到后比对序列号和数据丢包、错包一目了然。我习惯先用 64 字节小包把链路打死再用 1472 字节大包覆盖长度边界最后做随机长度混合测试。小包考验单包处理速率和 MAC 层效率大包考验 FIFO 深度和校验逻辑两者关注点不同必须分开测。4.3 iperf3 UDP 打流与主机侧缓冲调优链路自检通过后进入吞吐测试iperf3 是最常用的工具。UDP 打流命令大概是# 接收端 iperf3 -s -u -i 1 # 发送端往接收端 IP 打 50G UDP 流 iperf3 -c 192.168.30.2 -u -b 50G -l 1472 -t 60 --get-server-output这里有几个实测教训。第一iperf3 的 -b 只是目标带宽不会自动增大系统 UDP 缓冲区Linux 上要提前把接收缓冲区调大否则稍有拥塞就是千分之几的丢包表面看是 FPGA 的问题其实是主机 recvfrom 处理不过来sysctl -w net.core.rmem_max134217728 sysctl -w net.core.rmem_default67108864第二Windows 上跑 iperf3 UDP 更要注意系统默认的 UDP 缓存区非常小100G 打流下瞬时丢包极其夸张。可以在注册表 HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters 下把 DefaultReceiveWindow 和 DefaultSendWindow 调整到 512MB 量级再重启跟“100G 网卡一打满带宽就疯狂丢包”这类问题高度相关本质是协议栈缓冲不够不是网卡或 FPGA 的问题。第三吞吐和丢包要分开看。实测 FPGA 到服务器方向用 -b 50G 打上去接收端显示的吞吐能到 49.5G 以上、丢包率低于 0.001%在 100G 链路上已经算很好了。追求 100G 满线速纯 UDP 打流不现实接收端 Linux 协议栈单核单队列处理能力有限瓶颈在服务器软件侧不在 FPGA。提示打流前先确认对端网卡的 RSS 多队列和流控开关。100G 场景下单个接收队列很容易成为瓶颈RSS 把流量散到多核多队列接收端丢包会显著下降。4.4 数据正确性验证与抓包避坑吞吐达标不等于数据对。我验证正确性用“双层核对”FPGA 端每个 UDP 包带递增计数器固定魔数对端校验计数连续性和魔数这是离线比对同时服务器侧开 tcpdump 抓包把 pcap 导出来用脚本解析 UDP 载荷逐字节比对这是在线核对。两套结果一致才算通过。抓包这里有个很常见的坑在 Wireshark 的过滤器栏里写udp却发现依然能抓到 ICMP 或者其他非 UDP 报文。原因在于 Wireshark 有两种过滤捕获过滤器和显示过滤器。捕获过滤器是 BPF 语法在抓包时生效写错位置等于没过滤抓下来的是混杂模式全量报文显示过滤器只是不显示某些包报文已经存在 pcap 里。核对数据正确性时反而建议故意不开任何过滤器全量抓下来再按五元组分类信息最全过滤问题留给后续脚本处理。5. 常见问题速查与排错实录5.1 链路起不来按物理层→PCS→FEC 分层定位100G 链路起不来的故障90% 集中在物理层、PCS 层、FEC 配置这三层。我把这次和以往项目里的典型问题整理成速查表方便排查时对照现象可能原因排查手段GTY QPLL 锁定失败REFCLK 频率或引脚配置错误ILA 抓 qpll_lock检查时钟树PCS 对齐不上、AM 锁不住对端速率不匹配、线缆/光模块问题换线、换模块、核对对端配置FEC 误码率飙升两端 RS-FEC 配置不一致统一 FEC 开关观察 corrected/uncorrected 计数link 起来又立刻掉DAC 线太长或质量差换短 DAC 线或换光模块只有 TX 没有 RXRX 差分对约束错误或对端未发数查引脚约束、对端发包状态100G 调试最忌讳“流水式试错”每改一个参数就重新综合、重新加载时间全浪费在等待里。GTY 和 CMAC 的很多状态是运行时可读的先用 ILA 把锁存状态、错误计数看清楚判断出方向再决定要不要改代码重综合。一次只改一个变量这条纪律在高速接口调试里永远适用。5.2 丢包与吞吐上不去从接收侧反推丢包不能只盯着 FPGA。我遇到过一个典型案例FPGA 到服务器方向 100G 长时间打流服务器 tcpdump 显示完全没丢包iperf3 却报告 0.5% 丢包率。排查到最后发现iperf3 接收线程和服务器网卡 RX 中断绑在了同一个 CPU 核上中断处理把应用线程抢占了。用 taskset 或 iperf3 的 -A 参数把收发两端绑定到不同核上丢包直接清零。反过来如果 FPGA 作为接收方丢包重点查这几处发送端计数器是否真的发满了带宽接收 FIFO 深度是否足够100G 下链路另一端的一个短暂突发就能灌满小 FIFOUDP 查表分发引擎有没有对某些包头走了较长路径造成流水线气泡。查这类问题最好的工具就是计数器把发送包数、接收包数、FIFO 上下溢、ARP 命中失败全部做成寄存器触发一次就知道丢包发生在哪一级。5.3 抓包与计数器不一致先怀疑自己再怀疑链路最后记一个调试时的经典错觉Wireshark 或 tcpdump 看到的包数比 FPGA 发送计数器少就断言 FPGA 丢包了。先别急着怀疑 FPGA先检查抓包点。tcpdump 抓包结束时打印的统计里有关键三行captured、received by filter、dropped by kernel。received 是内核里收到的报文数dropped 是内核因为缓冲不足丢弃的报文数只有 captured 才是真正写进 pcap 的。如果 dropped 不为 0说明抓包工具自己在丢包跟链路和 FPGA 都没有关系。这次项目里有一版测试结果显示 FPGA 发送了 1000 万个 UDP 包服务器 tcpdump 只抓到 998 万个吓出一身冷汗最后发现是 tcpdump 缓冲区被瞬时大流量冲掉了几百个包。把 tcpdump 的 -B 参数调大、加上 -n 禁用反向解析之后两边计数就吻合了。调试高速链路任何“不一致”都要先把测量工具本身的可信度验证一遍再下结论说设备有问题。这次 100G 移植上板我最大的体会是开源代码把 100G UDP 的入门门槛从“抄代码”降到了“配约束”但门槛并没有消失只是转移到了配置、约束、调试这些看不见的地方。时序余量、PHY 配置、主机协议栈缓冲任何一环都能让一个看似简单的 UDP 收发问题变得极其隐蔽。最后分享一个实用习惯100G 项目里把 FPGA 内部所有关键计数器包括发送包数、接收包数、FEC 错误数、FIFO 上下溢、ARP 命中失败数全部引到可读寄存器配合串口或者 ILA 随时打印。这个习惯帮我省下的排错时间比写这些逻辑多花的几小时多得多。希望这次实战记录能让你在踩同样的坑时少消耗一个通宵。 
长河君 · 2026/9/5 4:24:13 · 阅读 1.2k 开源100G FPGA UDP协议栈移植上板实战与排错记录
做 FPGA 高速接口的同行应该都有体会10G 是以太网基本功25G 开始要认真看时序到 100G 就是另一套玩法了。前段时间我接了一个需求要把一套开源 100G FPGA UDP 协议栈移植到自研板卡上完成上板验证目标是用 iperf3 跑出接近线速的 UDP 吞吐同时把丢包率压到可控范围。整套流程走下来从开源仓库到 bitstream从 GTY 参考时钟配置到 512bit 数据总线上的时序收敛从实验室光纤连线到抓包比对每一环都有代表性的大坑。我把这次“开源 100G FPGA UDP 移植上板测试”的完整过程整理出来方案选型思路、关键模块原理、移植步骤、排错记录一次说清楚。适合三类人读准备从 10G/25G 往 100G 迁移的 FPGA 工程师想评估开源 UDP 卸载方案是否靠谱的系统架构师以及正在为 100G 上板疑难杂症失眠的同行。即便你手头的板卡还是 25G 甚至 10G这篇文章里关于时钟、异步 FIFO、校验和、抓包排错的思路也完全通用。1. 项目定位与方案选型100G UDP 的开源路线1.1 需求拆解我们要的其实不只是 UDP拿到需求先做拆解。高速数据采集、网络加速、存储网关这类场景里100G 接口的意义不是“带宽数字好看”而是把 CPU 从逐包处理里解放出来。FPGA 上实现 UDP 卸载之后主机或者前端逻辑只需要提供目的 IP、目的端口和 payload剩下的 MAC 帧封装、IP 头、UDP 头、校验和全部在硬件里完成单包处理延迟可以做到微秒级以下。这种确定性的低延迟是纯软件协议栈给不了的也是我们要在 FPGA 上做 UDP 移植的根本原因。为什么选 UDP 而不是 TCP答案很直接TCP 是有状态协议有连接管理、拥塞控制、重传机制在 FPGA 里完整实现代价极高吞吐还容易被状态机瓶颈拖累。UDP 无连接、无状态硬件只需要做“封装校验转发”逻辑简单吞吐容易做高。数据中心里不少专用加速链路本来就不需要 TCP 的语义视频流、数据复制、部分 RDMA 场景都用 UDP。对 FPGA 来说UDP 是性价比最高的网络协议入口。1.2 开源方案对比Corundum 与 verilog-ethernet动工之前我认真盘了一遍市面上的开源方案。这里给一个基于我个人使用经验的对比表方便后面参考方案带宽支持核心定位License移植工作量Corundum10G/25G/100G完整网卡平台PCIe DMAUDP/RDMA 卸载BSD高依赖 Xilinx 100G IPverilog-ethernet10G/25G轻量以太网组件库MAC、LFSR、UDP/IP 卸载BSD中商业 Xilinx IP自研 UDP100GMAC/PCS 用商业 IPUDP 逻辑自研商业中高学术项目不等特定协议栈各异参考价值为主Corundum 是 Alex Forencich 那套 verilog-ethernet 的“全家桶”升级版把 PCIe 根端口、DMA 引擎、UDP 卸载、100G MAC 全链路打通社区活跃度很高issue 响应也快。verilog-ethernet 更轻量适合不需要 PCIe、只想把 UDP 收发逻辑嵌进自研数据通路的场景。我这边需要做一块独立的 100G 数据加速板卡既要从光口收 UDP 包也要从光口发 UDP 包和主机 PCIe 的耦合其实是次要的但 Corundum 的模块化程度和板卡参考设计完整度最好所以选了它。1.3 移植前明确边界哪些能复用哪些要重写选型定了不等于万事大吉。开源代码是通用设计落到自研板卡上一定会遇到“参考设计假设了特定时钟、特定引脚、特定 IP 版本”的问题。我在移植前先划了一条边界物理层完全复用 Xilinx CMAC 加 GTY 的配置思路MAC 层到 UDP 卸载层尽量不做大改动只调整包尺寸参数和查表表项去适配场景PCIe 相关模块当前用不到就先挂空或者走最小配置等链路跑通再回来补。这个边界的意义在于控制变量。100G 上板调试横跨物理层、协议层、主机软件三层如果一次改动太多出了问题根本定位不到根因。先把“收发 UDP 包”这条主链路跑通再谈性能优化和功能扩展这是我做高速接口项目一直坚持的顺序。2. 100G 链路核心原理移植前必须搞懂的三个层面2.1 物理层GTY 收发器与四通道聚合100G 以太网物理层听起来吓人拆开看就是一个“四通道聚合”结构。100GBASE-R 由 4 条 25.78125Gbps 串行通道组成每条通道跑 64b/66b 编码净数据等效 25Gbps四条合计约 100Gbps。所以 FPGA 侧第一步是把 GTY 收发器配置到 25.78125Gbps参考时钟几乎都用 156.25MHz。新接触 100G 的工程师容易在一个地方卡住10G 时代逻辑侧用 64bit 总线、156.25MHz直接跟线路速率对应很好理解100G 的逻辑侧总线就变成了工程权衡的焦点。Xilinx 100G CMAC 通常给出 512bit 的 AXI4-Stream 接口逻辑时钟需要跑到 322.265625MHz 附近也可以选更宽的位宽来降时钟但布线资源和寄存器扇出会迅速吃掉 FPGA 的余量。这里的第一条纪律是逻辑侧时钟不是你想跑多少就多少物理层 IP 已经把选择范围定死移植时不要为了“看起来稳”去随意改动 IP 内部时钟配置。2.2 MAC/PCS 层64b/66b、RS-FEC 与 CMAC 状态100G MAC 和 PCS 层的核心是 64b/66b 编码每 64bit 数据加 2bit 同步头变成 66bit 在串行链路上传输接收端靠同步头做字对齐和通道绑定。CMAC 里还会做通道重排序因为 4 条通道在接收端不一定按原始顺序到达。对调试者来说CMAC 的 status 信号是关键中的关键PCS 对齐、AM 锁存、通道绑定、FEC 误码计数都是判断链路是否健康的直接证据。RS-FEC 单独说几句。100G 短距光模块SR4/LR4一般可以不开 FEC但走 DAC 铜缆或者背板 KR 模式时RS(544,514) FEC 基本是强制要求否则误码率高到没法稳定传包。FEC 必须在收发两端配置一致这是上板联调最容易翻车的点之一FPGA 侧开了 FEC对端设备没开结果就是链路不稳定、误码重传满天飞。在实验室里我先统一用不开 FEC 的 SR4 光模块把功能调通再切换到最终场景验证 FEC 配置这样变量少、定位快。2.3 UDP 卸载引擎从 MAC 帧到载荷的流水线细节UDP 卸载引擎在 100G 上的逻辑复杂度并不比 10G 高多少难点全在“带宽×位宽×时钟”的组合上。一条典型的 TX 流水线是这样的应用逻辑通过 AXI4-Stream 把 payload 打进 TX 队列引擎查询 ARP 缓存拿到目的 MAC 地址生成以太网头插入 IP 头填版本、总长度、TTL、协议号 17计算 IP 校验和插入 UDP 头填源端口、目的端口、长度计算 UDP 校验和整帧送到 100G MAC 计算 FCSCRC32再进 PCS 编码。RX 方向就是反向操作MAC 层校验 FCS 并剥离以太网头再校验 IP/UDP 头最后按四元组源 IP、目的 IP、源端口、目的端口查表分发到不同接收队列。这里面有一个非常隐蔽的边界UDP 校验和算法是“逐 16bit 累加再取反”硬件引擎如果做增量更新比如只改端口号就快速重算校验必须小心 16bit 进位回卷的边界。很多自研引擎在这个位置有隐蔽 bug表现就是大多数包正常特定长度或特定载荷下偶发校验错包特别难查。开源实现一般是完整重算校验和逻辑简单正确性优先这个取舍在 100G 高带宽下反而更稳。另外 ARP 表必须有老化机制否则对端换 IP 之后你还往旧 MAC 地址上发表现就是“链路明明是通的UDP 就是没有回包”。3. 移植实操把开源代码落到自研板卡3.1 读懂参考设计三个文件决定成败Corundum 仓库里每个参考板卡一个目录典型如 Alveo U250、VCU118。拿到仓库第一件事不是改代码而是读参考设计里的三个关键文件顶层 RTL、约束文件、时钟 IP 配置。顶层 RTL 告诉你 100G MAC 怎么例化、用户时钟怎么产生、复位逻辑怎么设计XDC 约束告诉你哪些引脚绑定到哪个 GTY Quad时钟 IP 配置告诉你 REFCLK 频率、GTY 通道速率和逻辑时钟频率从哪来。我这次是把自研板卡原理图跟 U250 参考设计逐引脚比对列了一张映射表GTY 位置、REFCLK 引脚、QSFP28 的管理引脚I2C、中断、LP 模式、状态指示灯、拨码开关全部对应清楚才动代码。这个过程枯燥但是值得100G 板子改错一个引脚约束轻则综合报错重则上板后链路完全起不来而你很可能还在错误方向排查几个小时。3.2 板级适配引脚、时钟、约束逐项核对100G 的约束文件里有几项必须逐条确认不能照抄参考设计GTY 引脚QSFP28 的 TX/RX 差分对必须落在所选器件可用的高速 Quad 上且跟 REFCLK 在同一个 Quad或者属于允许跨 Quad 的拓扑关系参考时钟156.25MHz 差分时钟必须进 GTY 专用参考时钟引脚不能随便用一个普通时钟引脚替代逻辑时钟CMAC 用户时钟、AXI 总线的 create_clock 约束要跟着 IP 配置走不能自己拍脑袋定频率时序例外跨时钟域 FIFO 两侧的 set_false_path 或 set_max_delay 要成套维护漏一条就可能在布局布线时浪费大量时间。还有一类常被忽略的约束是电源和模块管理相关引脚。100G 光模块功耗不低QSFP28 的插拔检测、模块功耗协商信号都要正确接上并约束到位否则模块可能因为“没被主机正确识别”而拒绝上电发射激光链路自然起不来。这些细节全藏在原理图里移植时不花时间核对上板后必然还账。3.3 工程搭建与 IP 配置小步快跑Corundum 的 fpga 目录里有 Tcl 脚本可以生成 Vivado 工程。我的做法是把参考板卡的 Tcl 复制一份改成新板卡的器件型号、约束路径和 IP 参数。这里特别强调版本一致开源代码通常是在某个 Vivado 版本下验证过的如果新工程用了更高版本100G Ethernet Subsystem 和 Transceiver IP 的界面参数可能会有变化导致“明明照着脚本来的生成的 IP 却跟参考设计对不上”。遇到这种情况先回到仓库 README 里确认它推荐的 Vivado 版本别一上来就追新。IP 集成之后先做一次空跑确认所有 IP 的时钟、复位能正常产生再往上挂 UDP 引擎和测试逻辑。我习惯在顶层保留一个 AXI-Lite 寄存器组把关键状态寄存器拉出来方便硬件调试。开源代码的调试接口一般都很完善把该接的寄存器接全后面上板能省一半时间。3.4 时序收敛322MHz 逻辑域的调优手段综合实现跑完第一轮 timing 大概率不过这是 100G 项目的常态。512bit 总线在 322MHz 下的扇出压力比 10G/25G 高一个量级我总结出几个有效手段高扇出复位信号做同步复位树避免异步复位直接扇出到几百个寄存器上AXI4-Stream 长路径上插入 skid buffer这种带流控的流水寄存器会增加几拍延迟但能换来时序收敛UDP 校验和的加法树用 DSP 或逐级打拍不要在组合逻辑里一次算完 32bit 累加对无需关心的跨时钟域路径明确设置 set_max_delay 或 set_false_path避免工具白费布线资源关键路径上把单周期全处理改成多拍流水配合寄存器重组拆长路径。最终这张板卡的 100G 逻辑域我要求时序收敛后必须保留正余量才生成 bitstream。有人喜欢压线过觉得省资源但 100G 上板之后温度、电压稍有波动临界路径会先挂掉表现就是跑着跑着开始随机丢包。这种 bug 后期排查成本远高于当时多花两三版实现的成本。4. 上板测试从链路自检到 iperf3 满带宽打流4.1 测试环境与物理链路检查测试环境搭建本身不复杂FPGA 板卡插 QSFP28 模块用一根 100G DAC 线直连对端设备。对端可以是另一块 FPGA 板卡也可以是带 100G 网口的服务器。上电后第一件事不是跑业务是先查链路物理状态GTY 的 QPLL/CPLL 是否锁定、CMAC 的 PCS 对齐和 AM 锁定状态、FEC 误码计数是否正常。如果对端是大网卡或交换机还要看对端链路是否 up。我这次用 Vivado Hardware Manager 直接在 Hardware Session 里挂 ILA把 CMAC 状态信号和 GTY 锁存信号一起拉出来比反复读寄存器直观得多。这一步能确认 80% 的物理层问题时钟有没有进、收发器有没有锁、PCS 有没有对齐。链路状态确认正常之后再加载业务 bitstream千万不要在物理层没确认的情况下浪费几个小时去查 UDP 逻辑。4.2 回环自检顺序先内部数字回环再物理回环板卡刚点亮时直接拿主机打流是灾难因为你分不清丢包是 FPGA 的问题还是主机网卡的问题。正确顺序是先在 FPGA 内部做数字回环把 TX 数据直接送回 RX验证 MAC/UDP 逻辑本身再开 GTY 的 near-end PMA loopback验证收发器的串行通路然后用 DAC 线缆做物理回环验证外部光模块和连接器最后才跟对端设备联调。开源仓库一般会带 LFSR 伪随机序列发送器verilog-ethernet 里那个 lfsr_udp 就是干这个的可以持续发送指定长度的 UDP 包对端收到后比对序列号和数据丢包、错包一目了然。我习惯先用 64 字节小包把链路打死再用 1472 字节大包覆盖长度边界最后做随机长度混合测试。小包考验单包处理速率和 MAC 层效率大包考验 FIFO 深度和校验逻辑两者关注点不同必须分开测。4.3 iperf3 UDP 打流与主机侧缓冲调优链路自检通过后进入吞吐测试iperf3 是最常用的工具。UDP 打流命令大概是# 接收端 iperf3 -s -u -i 1 # 发送端往接收端 IP 打 50G UDP 流 iperf3 -c 192.168.30.2 -u -b 50G -l 1472 -t 60 --get-server-output这里有几个实测教训。第一iperf3 的 -b 只是目标带宽不会自动增大系统 UDP 缓冲区Linux 上要提前把接收缓冲区调大否则稍有拥塞就是千分之几的丢包表面看是 FPGA 的问题其实是主机 recvfrom 处理不过来sysctl -w net.core.rmem_max134217728 sysctl -w net.core.rmem_default67108864第二Windows 上跑 iperf3 UDP 更要注意系统默认的 UDP 缓存区非常小100G 打流下瞬时丢包极其夸张。可以在注册表 HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters 下把 DefaultReceiveWindow 和 DefaultSendWindow 调整到 512MB 量级再重启跟“100G 网卡一打满带宽就疯狂丢包”这类问题高度相关本质是协议栈缓冲不够不是网卡或 FPGA 的问题。第三吞吐和丢包要分开看。实测 FPGA 到服务器方向用 -b 50G 打上去接收端显示的吞吐能到 49.5G 以上、丢包率低于 0.001%在 100G 链路上已经算很好了。追求 100G 满线速纯 UDP 打流不现实接收端 Linux 协议栈单核单队列处理能力有限瓶颈在服务器软件侧不在 FPGA。提示打流前先确认对端网卡的 RSS 多队列和流控开关。100G 场景下单个接收队列很容易成为瓶颈RSS 把流量散到多核多队列接收端丢包会显著下降。4.4 数据正确性验证与抓包避坑吞吐达标不等于数据对。我验证正确性用“双层核对”FPGA 端每个 UDP 包带递增计数器固定魔数对端校验计数连续性和魔数这是离线比对同时服务器侧开 tcpdump 抓包把 pcap 导出来用脚本解析 UDP 载荷逐字节比对这是在线核对。两套结果一致才算通过。抓包这里有个很常见的坑在 Wireshark 的过滤器栏里写udp却发现依然能抓到 ICMP 或者其他非 UDP 报文。原因在于 Wireshark 有两种过滤捕获过滤器和显示过滤器。捕获过滤器是 BPF 语法在抓包时生效写错位置等于没过滤抓下来的是混杂模式全量报文显示过滤器只是不显示某些包报文已经存在 pcap 里。核对数据正确性时反而建议故意不开任何过滤器全量抓下来再按五元组分类信息最全过滤问题留给后续脚本处理。5. 常见问题速查与排错实录5.1 链路起不来按物理层→PCS→FEC 分层定位100G 链路起不来的故障90% 集中在物理层、PCS 层、FEC 配置这三层。我把这次和以往项目里的典型问题整理成速查表方便排查时对照现象可能原因排查手段GTY QPLL 锁定失败REFCLK 频率或引脚配置错误ILA 抓 qpll_lock检查时钟树PCS 对齐不上、AM 锁不住对端速率不匹配、线缆/光模块问题换线、换模块、核对对端配置FEC 误码率飙升两端 RS-FEC 配置不一致统一 FEC 开关观察 corrected/uncorrected 计数link 起来又立刻掉DAC 线太长或质量差换短 DAC 线或换光模块只有 TX 没有 RXRX 差分对约束错误或对端未发数查引脚约束、对端发包状态100G 调试最忌讳“流水式试错”每改一个参数就重新综合、重新加载时间全浪费在等待里。GTY 和 CMAC 的很多状态是运行时可读的先用 ILA 把锁存状态、错误计数看清楚判断出方向再决定要不要改代码重综合。一次只改一个变量这条纪律在高速接口调试里永远适用。5.2 丢包与吞吐上不去从接收侧反推丢包不能只盯着 FPGA。我遇到过一个典型案例FPGA 到服务器方向 100G 长时间打流服务器 tcpdump 显示完全没丢包iperf3 却报告 0.5% 丢包率。排查到最后发现iperf3 接收线程和服务器网卡 RX 中断绑在了同一个 CPU 核上中断处理把应用线程抢占了。用 taskset 或 iperf3 的 -A 参数把收发两端绑定到不同核上丢包直接清零。反过来如果 FPGA 作为接收方丢包重点查这几处发送端计数器是否真的发满了带宽接收 FIFO 深度是否足够100G 下链路另一端的一个短暂突发就能灌满小 FIFOUDP 查表分发引擎有没有对某些包头走了较长路径造成流水线气泡。查这类问题最好的工具就是计数器把发送包数、接收包数、FIFO 上下溢、ARP 命中失败全部做成寄存器触发一次就知道丢包发生在哪一级。5.3 抓包与计数器不一致先怀疑自己再怀疑链路最后记一个调试时的经典错觉Wireshark 或 tcpdump 看到的包数比 FPGA 发送计数器少就断言 FPGA 丢包了。先别急着怀疑 FPGA先检查抓包点。tcpdump 抓包结束时打印的统计里有关键三行captured、received by filter、dropped by kernel。received 是内核里收到的报文数dropped 是内核因为缓冲不足丢弃的报文数只有 captured 才是真正写进 pcap 的。如果 dropped 不为 0说明抓包工具自己在丢包跟链路和 FPGA 都没有关系。这次项目里有一版测试结果显示 FPGA 发送了 1000 万个 UDP 包服务器 tcpdump 只抓到 998 万个吓出一身冷汗最后发现是 tcpdump 缓冲区被瞬时大流量冲掉了几百个包。把 tcpdump 的 -B 参数调大、加上 -n 禁用反向解析之后两边计数就吻合了。调试高速链路任何“不一致”都要先把测量工具本身的可信度验证一遍再下结论说设备有问题。这次 100G 移植上板我最大的体会是开源代码把 100G UDP 的入门门槛从“抄代码”降到了“配约束”但门槛并没有消失只是转移到了配置、约束、调试这些看不见的地方。时序余量、PHY 配置、主机协议栈缓冲任何一环都能让一个看似简单的 UDP 收发问题变得极其隐蔽。最后分享一个实用习惯100G 项目里把 FPGA 内部所有关键计数器包括发送包数、接收包数、FEC 错误数、FIFO 上下溢、ARP 命中失败数全部引到可读寄存器配合串口或者 ILA 随时打印。这个习惯帮我省下的排错时间比写这些逻辑多花的几小时多得多。希望这次实战记录能让你在踩同样的坑时少消耗一个通宵。