前阵子拿到一块带 QSFP28 光口的 FPGA 板卡任务很直白把 100G UDP 数据通路跑起来。协议栈优先用开源方案能改的代码尽量自己改最后必须上板实测打流不能只停在仿真通过。我当时第一反应是这不就是找几个开源 IP 拼一拼的事真正动手才发现10G/25G 时代积累的经验在 100G 上有相当一部分要推倒重来。从选型、移植、上板调试到打流这个过程前前后后折腾了几周中间踩的坑比预想的多得多。这篇文章就当一次完整复盘把能公开的细节和踩过的坑全写出来。如果你也在做类似的高速网络 FPGA 项目希望这些记录能帮你省掉几周的试错时间。1. 立项评估100G UDP 为什么非要在 FPGA 上做1.1 CPU 方案在 100G 小包场景下的天花板先想清楚一个问题100G UDP 为什么要在 FPGA 上做而不是用服务器网卡加 DPDK一个 100G 网卡配合多核 CPU 和 DPDK在实验环境里确实能跑到很高吞吐但代价是包处理逻辑必须分摊到多个核上RSS 哈希、内存池、轮询线程这些工程细节一个都不能少。而且 CPU 方案的时延抖动是微秒级别的中断处理、调度器切换、缓存失效这些不确定性因素一直存在。对大多数业务来说没问题但对网络测量、高频交易或某些工业同步场景就是不可接受的。FPGA 这边是完全不同的思路所有包处理逻辑都是流水线数据一到就在硬件里完成解析、过滤、改写延迟是固定的几个时钟周期抖动基本可以忽略。而且 FPGA 方案上电即工作不依赖操作系统、驱动和协议栈这在很多嵌入式或专用设备场景里是决定性的优势。1.2 100G 线速的硬性指标148.8Mpps100G UDP 不是把 10G 的设计位宽乘 10 就行先看一组数字。100G 以太网线上最小的帧单元是 84 字节64 字节帧本身、8 字节前导码、12 字节帧间隙IFG。100Gbps 除以 672bit等于每秒 148.8 百万个帧Mpps。也就是说如果一个 FPGA 逻辑要线速处理最小帧平均每两个 322MHz 时钟周期左右就要处理完一个完整的数据包。这个账算明白了很多设计选择就清晰了。第一数据通路的带宽必须超出 100G否则峰值突发时必然丢包。第二帧处理状态机不能引入多拍等待否则 148.8Mpps 的小包会把队列打爆。第三用户逻辑不能有太深的优先级调度和仲裁每一拍都要有明确的处理路径。做移植的时候很多从低速率带过来的一拍做不完就延一拍的偷懒思路在这里都会变成吞吐瓶颈。1.3 哪些场景真的需要 FPGA 做 UDP我自己判断项目是否需要上 FPGA 的标准很简单要么需要线速小包处理要么需要自定义包头和确定性时延。前者的典型例子是 DDoS 过滤、流量采集、高速数据网关要求每条流都能以线速匹配和计数后者更常见传感器数据采集后需要在数据通路里加时间戳、做加解密、做格式变换然后再打包成 UDP 发出去。这些操作如果用服务器做绕不开 PCIe 传输和上下文切换延迟和抖动都会上来FPGA 里这些处理都在数据通道内部完成。所以 100G UDP 移植上板这类项目重点从来都不是 UDP 协议本身而是如何把协议栈嵌进一个以线速运转的数据通路里同时别把时序搞崩。下面这几章就按这个思路展开。2. 开源方案选型与裁剪哪些能直接用哪些必须重写2.1 两个主流开源方案的对比做高速以太网 FPGA 开发的人应该都对 Alex Forencich 那套 verilog-ethernet 项目有印象。它的核心价值不是给一个现成的千兆/万兆网卡而是把以太网 MAC、PHY、IPv4、ARP、UDP 这些层拆成了干净的模块。UDP/IP 那部分逻辑和具体速率关系不大主要是位宽和时钟不同。我评估之后认为在 100G 场景下这套代码里的 PHY 和 MAC 是注定用不上的但高层协议逻辑可以搬。另一个绕不开的项目是 Corundum。它是一整套开源网卡实现PCIe DMA、多队列、100G MAC 都有。功能很全架构也很现代但正因如此它的 UDP 收发逻辑和主机侧 DMA、描述符队列、上下文管理绑得很紧。如果我只想要一个 UDP 协议栈把 Corundum 拆出来等于同时引入一整套 PCIe DMA 子系统改动量和排错成本都太大。两个方案各看了几天代码后我的判断是不整体用 CorundumIP 核这里也不自己写 MAC。100G 以太网 MAC 的 PCS/FEC 部分在可编程逻辑里实现成本极高RS(528,514) 编解码、齿轮箱、PMD 这些做出来不仅逻辑量惊人时序也不一定收得紧。UltraScale 上的 CMAC 硬核免费PCS 和 MAC 都集成好了用户侧直接给 AXI4-Stream完全没必要重造轮子也没必要把开源里那块复杂但没有必要的软核 MAC 搬进来。2.2 保留和裁掉的逻辑模块实际移植时我把开源代码里这些模块留下了IPv4 头部解析和校验和检查UDP 头解析、长度检查、校验和计算ARP 请求解析和应答生成以太网类型字段过滤这些和速率关系不大头部格式是几十年来稳定的东西把接口位宽扩展好就能用。我的经验是越是接近协议栈顶层的逻辑跨速率复用的价值越高越靠近底层的逻辑越容易被硬件 IP 和速率变化重构。而拿掉的部分也明确开源的 10G/25G XGMII 接口适配层因为 CMAC 根本不长那样开源 MAC 和 PHY 相关逻辑CMAC 硬核接管了一些只为了仿真方便而加的总线结构。留哪些、砍哪些不能凭感觉。我当时的依据是以太网物理速率在变化但 IP/UDP/ARP 的头部格式从来没变属于稳定层MAC/PHY 每代速率都变属于易变层。协议处理逻辑应该尽量在稳定层里做让易变层通过标准接口替换。这个分层原则在整个移植过程中帮我避免了很多返工。2.3 为什么 CMAC 是绕不开的选择这里多说一句 CMAC 硬核。在 UltraScale 上一个 CMAC 实例基本就是 100G 以太网 MAC 加 PCS 加 PMA 的集合支持 100GBASE-R需要配置线速模式、FEC 模式、CRC 处理方式。它的用户侧接口是完整 AXI4-Stream典型配置下 tdata 512bit 或 1024bittkeep 对应 64bit 或 128bit时钟 322.265625MHz 或 161.1328125MHz。CMAC 本身不占太多逻辑资源但它的配置和复位时序有点讲究。刚上手时最容易出现的问题有两个一是 GTY 收发器的复位顺序不对导致 block_lock 起不来二是 FEC 协商不一致导致远端一直报 remote_fault。这两个问题都在上板测试阶段狠狠折磨过我后面调试章节会详细说。3. 移植中的核心改动数据位宽、时钟频率和背压3.1 接口适配从简化 AXI 到完整 AXI4-Streamverilog-ethernet 里 10G/25G 的场景用户接口通常是 xgmii 或者经过 mii_axis 转换成简化 AXI-Stream位宽 64bit 或 256bit。CMAC 这边给的是完整 AXI4-Stream多了 tkeep、tuser 和一组控制信号。第一版移植时我犯过懒想用一个小 wrapper 把 CMAC 的 tuser 丢掉只保留 tvalid/tdata/tlast/tready。这个想法在大多数情况下是能跑的但问题出在帧边界标志上。CMAC 接收方向用 tuser 的一个 bit 表示帧起始SOP如果对端在单拍内可以包含多个短帧虽然以太网最小帧 64 字节512bit 一帧正好 64 字节短帧不会多帧合一但 jumbo 帧会跨多拍没有 tuser 的辅助单纯靠 tlast 找帧尾在某些异常帧出现时会丢同步。所以最后还是老老实实把 tuser 接出来用它做 SOP 判断把 tlast/tkeep 做 EOP 和字节有效判断这是最稳的组合。UDP 解析逻辑里的所有状态机都围绕SOP 打点、EOP 收尾这个框架来改。3.2 时钟选择512bit322MHz 只是选项之一100G CMAC 用户接口时钟不是随便选的。典型配置下512bit 数据通路对应 322.265625MHz 时钟1024bit 数据通路对应 161.1328125MHz。初看 1024bit/161MHz 好像时序压力小很多但代价是单拍要处理 128 字节帧头拼接、mux 逻辑会很宽尤其是要同时处理 ARP 和 UDP 的时候那种一拍里做几十个字节的移位对齐的组合逻辑很容易让 Vivado 的综合结果变得很糟糕。我最后选了 512bit322MHz原因很简单这个位宽和原本 256bit 的实现差异相对小组合逻辑一条路径上处理的字节数翻倍比位宽再翻一倍的实现更容易收敛。另外一个技巧是如果用户逻辑不需要满速可以在 CMAC 用户侧后面放一个位宽转换 FIFO把 512bit/322MHz 降成 256bit/161MHz 甚至更低这样后面的用户逻辑时序压力就小很多。代价是额外消耗 BRAM/URAM 和几拍延迟但很多不在乎几个时钟延迟的应用很值得。3.3 背压处理别指望一个大 FIFO 解决所有问题刚开始设计时我下意识觉得接收侧放个大 FIFO 就能扛住一切。结果一算账就清醒了100G 线速突发 1 毫秒大约是 148.8K 个最小帧每个线上 84 字节累计约 12.5MB。片上 BRAM/URAM 根本扛不住。所以正确思路是片上 FIFO 只负责吸收短时抖动比如几个微秒的背压深度的量级在几百 Kbit 到几 Mbit 就行如果数据要写 DDR4 或发到其他低速接口必须在更高层做流控或者干脆接受 UDP 丢包。发送侧也一样。如果用户逻辑生成数据的速率波动很大发送 FIFO 要有 almost_full 信号提前反馈给用户逻辑不能等 full 了才停。等 full 再停流水线里已经积压的数据会溢出丢的就不是一两个包而是一整片。XPM 的 xpm_fifo_axis 原生支持 almost_full强烈建议直接用。还有一点FIFO 位宽变化时异步 FIFO 的读写时钟和位宽组合要提前规划不要搞到后期发现读侧位宽不够又回去改。3.4 校验和计算协议互通不了的头号嫌疑犯IP/UDP 校验和是移植里最容易出错但也是最不起眼的地方。IPv4 头校验和必须算对很多交换机和中转设备会直接丢弃校验错误的 IP 包。UDP 校验和在 IPv4 下虽然理论上可选但多数操作系统默认会做校验PC 收到校验错误的 UDP 包会直接丢掉抓包工具里会显示 checksum offload 相关的报错。开源代码里的校验和逻辑一般是针对 64bit 或 256bit 数据通路写的改成 512bit 后要注意一点输入数据跨拍时校验和累加的分片顺序必须保持正确。很多实现用两段式组合逻辑先把本拍内的字节按 16bit 对齐累加再把上一拍遗留的进位连进来。改成宽位宽时进位链变长了时序容易崩。我的做法是把累加拆成树形结构中间插两三级寄存器牺牲几个周期换取 322MHz 能收敛。这个改动对功能影响不大但对时序收敛非常关键别忽视。4. 上板调试全记录从 link down 到 100G 打流4.1 上电即踩坑光模块 TX_DISABLE 和 I2C第一次上电QSFP28 光模块完全没有光。刚开始怀疑是光模块坏了后来一查原理图TX_DISABLE 引脚上电默认是拉高的必须由 FPGA 侧拉低才能打开激光器发射。这是很多板卡的第一道坎不是代码问题但会浪费半天时间。建议上电后先写一个最简单的 I2C 读操作读取 QSFP28 模块的 ID 寄存器和状态寄存器确认模块在 I2C 总线上的地址通常是 0x50能正常应答再看模块中断引脚有没有拉低。这一步很快但能把硬件问题从逻辑问题里剥出来。我这次就是先确认了模块正常才放心去查 FPGA 配置和接线。4.2 IBERT 物理层自检不能省物理层自检是 100G 项目里绝对不能省的一步。用 Vivado 里的 IBERT IP把 4 个 GTY 通道都挂上跑 PRBS31最好连续跑几小时甚至过夜观察误码率。一些时有时无的链路误码跑几分钟根本看不出来等到系统联调时再暴露定位会非常痛苦。IBERT 配置时还要注意 refclk 频率和通道分配。100G 的 4×25.78125GT/s 需要 156.25MHz 参考时钟GTY Quad 的位置也必须和 CMAC 绑定的通道一致。我见过不止一次 refclk 分配错导致误码率居高不下的情况。另外如果对端是另一台设备发端和收端的链路训练参数要对齐否则可能出现单方向误码正常、反方向完全不通的现象。4.3 CMAC 环回和状态信号判读物理层确认无误后先做 CMAC 内部环回。Vivado IP 的 CMAC 自带 near-end loopback 功能不需要插光模块就能把 TX 数据环回给 RX用来验证 MAC 层逻辑和用户接口。这一步通过后再用 loopback 光纤做外部环回验证光模块和光路。CMAC 的状态信号里我最常看的是这几个tx/rx_block_lockPCS 层块同步是否建立phy_status物理层是否就绪local_fault / remote_fault本端/远端故障判断逻辑很简单local_fault 拉高优先怀疑 GTY 复位顺序、refclk 丢失remote_fault 拉高多半是对端的 PCS/FEC 配置不一致。尤其是 FECRS(528,514) 的协商和使能状态必须两端匹配一端开一端不开会导致 remote_fault 闪烁或者大量 CRC 错误看起来像光模块问题实际上是对端配置问题。我第一次遇到 remote_fault 反复横跳时先换了三根光纤最后才发现是对端测试仪 FEC 没开教训深刻。4.4 先 ping 再 UDP 的对通顺序PC 和 FPGA 对通时我的顺序永远是先 ping再 UDP。ping 通了至少说明 ARP 应答、IPv4 接收、ICMP 回包或者某个能回包的逻辑是通的链路基本没问题。如果 FPGA 里没写 ICMP 应答逻辑ping 会超时但不代表链路有问题。这种情况可以看 Wireshark 里有没有 ARP 请求和 FPGA 的 ARP 响应ARP 有响应就说明链路层和 IP 层是通的剩下只是应用层协议的问题。这里要专门说一下 ARP。如果只做了 UDP 没做 ARPPC 端在第一次通信前发出的 ARP 请求得不到响应PC 会认为对端不可达UDP 包根本发不出去。这个 ARP 应答必须是硬件实时响应的不能用软核 CPU 去轮询处理否则首次 ping 大概率会超时。ARP 逻辑还需要处理缓存老化的问题PC 会周期性重新发 ARP应答逻辑必须持续工作。UDP 对通测试有几个 PC 端的坑要注意。第一目标端口上必须有程序在监听否则 Linux 会回 ICMP Port UnreachableWireshark 里看起来是收到了包但应用层没收到。第二网卡的 rx checksum offload 可能把错误的 UDP 校验和隐藏掉抓包软件显示 checksum 错误时先对比一下是不是 FPGA 发出的校验和本来就有问题别被驱动层的自动补账弄糊涂。4.5 iperf3 打流和 PC 端那些坑对通后就开始打流。命令很常规服务器端iperf3 -s客户端iperf3 -c FPGA_IP -u -b 100G -l 1472。大多数人第一次跑都会发现丢失率惨不忍睹这不是 FPGA 的问题而是 PC 收包能力的问题。100G 的 UDP 大包大约是 8.5Mpps中小包直接奔 148.8Mpps普通服务器网卡没做多队列 RSS 配置的话单核根本扛不住。我的建议是先用 FPGA 对 FPGA 或者内部回环验证性能把 FPGA 侧计数器的发送/接收帧数对上再用 iperf3 看 PC 端能收多少两个数据合起来才能判断瓶颈在哪边。iPerf3 的 UDP 模式是单向测试PC 不回来的话接收端统计会出现大量丢包记录但这不影响判断发送方向的吞吐。如果任务反过来是 PC 往 FPGA 打流那就要看 FPGA 接收侧有没有丢包PC 发送侧能不能产生足够多的包。打流时还有一个常见统计Wireshark 的 UDP 统计里会显示 packets received 和 packets to unknown port received。如果后者数量巨大说明主机内核确实收到了 UDP 包但目的端口没有进程监听这类包都会被回 ICMP Port Unreachable 并丢弃。测试工具没启动、端口号写错、防火墙拦截都会触发这个现象。先在自己的电脑上排除这些再怀疑 FPGA 发出来的报文格式。5. 性能结果与下一步演进方向5.1 不同包长下的理论速率和实测方法把理论值先摆出来方便对照实测结果。下面这张表按线上帧格式64B 帧含前导和 IFG 共 84B计算帧长不含FCS线速帧率有效载荷吞吐64B148.8Mpps约 76.2Gbps1518B8.13Mpps约 98.8Gbps9000B巨型帧1.39Mpps约 99.8Gbps看这张表就明白UDP 传输如果想贴近 100G帧越长效率越高。如果项目允许尽量用 9000 字节巨型帧既减轻帧处理压力又能把有效带宽推到接近 100G。小包场景对应的高帧率对逻辑和处理流程要求最苛刻也是最容易出瓶颈的地方。实测时我建议至少测三档64B、1518B、9000B。64B 档几乎只有专业测试仪表或 FPGA 对 FPGA 能跑满PC 跑不满也别慌1518B 是通用以太网标准帧最能反映实际场景9000B 是巨型帧压测能看出数据通路在长突发下的稳定性。每档测完顺手记录 FPGA 侧 rx/tx byte 和 pkt 计数器跟对端统计做交叉验证。实测中如果 9000B 稳了但 1518B 丢包问题大概率出在帧处理流水线的某个 mask 逻辑上检查那些跟 tkeep 有关的代码。5.2 资源占用和时序收敛经验100G UDP 协议栈本身占用的资源其实不多大头在数据缓存和位宽转换 FIFO。UDP/IP/ARP 的解析生成逻辑扩充到 512bit 后我这里的整体资源占用在几万 LUT 量级相比 CMAC 硬核和 GTY 的固定资源可以忽略。真正吃资源的是你希望在数据通路上做的其他事情DDR4 缓存、PCIe DMA、加解密引擎这些才是架构设计的主战场。时序收敛是这次项目中最耗时的一部分。322MHz 时钟不算特别高但数据位宽大组合逻辑一宽路径就长。我的经验是任何跨 64 字节的操作比如移位、对齐、tkeep 变换都尽量用流水线拆到两级以上校验和累加用树形结构状态机里避免在同一个周期既更新大位宽寄存器又做比较。Vivado 报告里出现 setup violation 的时候先看是不是某个关键路径上堆了太多操作拆开比加时序约束更有效。还有一点复位信号在 322MHz 时钟域里的扇出可能很大建议用全局复位后再打两拍派生出局部复位别把所有模块都挂在原始复位上。5.3 后续可扩展的方向这次做完 100G UDP 之后很容易想到的几个扩展方向多端口一个 FPGA 里跑多个 100G数据通路逻辑复用关键变成 Crossbar 调度和输出仲裁时间戳在每个帧进出的瞬间打上 UTC 时间戳就可以做流量延迟测量这是网卡方案很难做到的TCP offloadUDP 好做TCP 的状态机、重传和流控就复杂多了需要评估开源的 TCP 卸载引擎RoCEv2要给 RDMA over Converged Ethernet 打基础需要处理 PFC、流控和协议头工作量大但确实是高端应用的主要方向这些方向最终都会回到同一个问题上数据通路能不能稳定地在 322MHz 下线速运转。架构设计时留好流水线余量和错误计数后面扩展就顺利很多。最后说点这次项目最深的体会。100G UDP 移植上板技术难点从来不在 UDP 协议本身——协议是死的难点在于和它共存的时钟、位宽、时序、流控这些工程细节。把开源代码读懂、改成自己的接口、再到板子上把每一个状态信号都盯着爬起来这个过程没有捷径。我建议所有做类似项目的朋友从一开始就把 ILA 触发条件和计数器埋好别等问题出现了再亡羊补牢。开源 IP 的价值是给你一个经过验证的起点但它不会替你把系统集成和上板调试的功课做完。希望这份记录能让你在这个起点上走得更快一点。