一直在做高速数据采集和网络加速相关的项目，之前最多也就用到10G光口，数据通路稍微一复杂就得上多路绑定的方案，麻烦不说，时延和同步问题也够头疼。最近接了个活，要在单端口上跑满100G的UDP吞吐，还得是用FPGA实现，评估了一圈现成方案之后，决定把开源的UDP协议栈移植到FPGA上做上板实测。这篇就把整个移植和验证过程完整记录下来，包括方案选型的理由、移植时踩过的坑、上板打流的数据，以及几个典型的排查思路，给后面要搞100G UDP的同行们做个参考。
1. 项目背景与整体方案选型
1.1 为什么选100G UDP而不是TCP或者私有协议
先说项目背景：需要把前端采集到的高速数据流打包后通过网络传输出去，带宽要求是单口100Gbps，数据包以小包和突发流量为主，对时延极其敏感。这种场景下，TCP的可靠传输和拥塞控制在FPGA里实现成本太高，尤其在链路层要做到线速转发，光TCP的窗口管理和重传缓存就能把BRAM吃掉一大半，完全不现实。私有协议当然可以，但后端的服务器和测试软件都得配套开发，项目周期撑不住。
UDP恰好是平衡点。协议简单，开销极小，头解析和校验和计算在FPGA里只是一小段组合逻辑加一个流水线。而且开源生态里有不少现成的UDP/IP核可以做100G，这就能把精力集中在数据通路优化和应用层逻辑上，不需要从零写MAC层和PCS层。说白了，UDP是把"能跑"和"跑得快"同时兼顾的选择，剩下可靠性问题交给应用层或者链路冗余来解决。
1.2 开源协议栈怎么选：对比几个常见方案
开源FPGA以太网协议栈目前主要的选项有Alex Forencich维护的verilog-ethernet、OpenCores上的10G/25G MAC项目，以及一些商业IP的评估版本。verilog-ethernet是我个人比较推荐的，原因有三：一是它提供的软件栈粒度很细，MAC、PCS、UDP、ARP、Checksum都是独立模块，可以按需裁剪；二是它对Xilinx UltraScale+系列有成熟的示例工程，特别是CMAC硬核的集成方式写得清楚；三是代码风格统一，接口都是AXI4-Stream，移植到不同FPGA平台时改动成本低。
OpenCores上的一些项目其实也不差，但问题在于维护时间普遍偏早，很多还停在Xilinx 7系列时代的代码风格，做100G时需要大改跨时钟域逻辑和位宽转换。商业IP虽然稳定性和支持都很好，但授权费高，而且锁定厂商，不适合做开源方案验证和后续的产品化预研。综合考虑之后，选了verilog-ethernet作为核心协议栈，自己写应用层数据通路和寄存器配置管理。
1.3 硬件平台与整体架构规划
实测平台用的是Xilinx UltraScale+ VU3P系列板卡，板载100G QSFP28光口，FPGA内部集成了100G CMAC硬核。一开始想过用软核逻辑直接做PCS/PMA，但100G的PCS层开销和时序收敛难度很大，LUT利用率会变得非常紧张。后来确认UltraScale+支持CMAC原生协议栈，就把PCS/PMA和MAC层全部交硬核，开源协议栈只负责MAC上层的UDP/IP处理，这样既保证了线速性能，又大幅简化了逻辑设计。
系统架构大概是这样的：光模块进来的数据先进入CMAC硬核完成64B/66B编解码和FEC，之后以AXI4-Stream接口输出512位数据总线，由开源的UDP/IP RX通路完成以太网帧解析、IP校验、UDP校验和分离；用户逻辑从UDP payload里直接读取数据，处理后按TX通路封装成UDP包，再送回CMAC发送。整个环路分成RX和TX两条独立流水线，中间用异步FIFO隔离时钟域。
2. 开源UDP协议栈的移植细节
2.1 模块裁剪与接口适配：不是拿来主义，动手改了不少
开源代码拿到手并不能直接跑，首先是需要裁剪掉不必要的模块。verilog-ethernet里包含ARP、ICMP、Checksum、Priority等一堆可选IP，我们实际只需要UDP/IPv4收发和基础的ARP响应能力，外加一个用于调试的ICMP回显。因此把多余的模块从工程中排除掉了，只保留了eth_mac_rx、eth_mac_tx、udp_ip_rx、udp_ip_tx、arp_cache和checksum这几个核心模块。
接口适配上最大的工作量是位宽转换。CMAC硬核的AXI4-Stream接口固定为512位，而开源协议栈内部默认支持8位、64位和256位三种位宽。100G下每个时钟周期要处理512位数据，用户逻辑和数据接口必须统一到512位对齐。我改写了udp_ip_rx和udp_ip_tx的内部数据总线，把非对齐处理逻辑放到帧头解析阶段，payload部分全部按512位对齐快速穿过。这样改完之后，逻辑时钟频率可以稳定的跑到322MHz，刚好满足100G吞吐需求。
2.2 时钟域处理与复位同步要点
100G系统最容易被忽视的就是跨时钟域和复位设计。CMAC恢复出来的RX时钟和Core参考时钟不是天然同源，逻辑侧用的user_clk如果直接连到MAC恢复时钟，会在时钟切换或链路重训练时出现毛刺。我的做法是系统内所有用户逻辑都在经过BUFG的user_clk时钟域工作，RX方向用异步FIFO跨到user_clk域，TX方向直接用user_clk输出到CMAC内部FIFO。
复位同步也是一个重要细节。开源代码里自带的全局复位是异步复位同步释放，这在单时钟域下没问题。但在100G的高时序压力下，复位信号如果直接扇出到几百个触发器，会造成严重的复位偏斜，影响时序收敛。我改用Xilinx原语生成同步复位树，分别给RX和TX方向做独立复位域，而且必须在MAC配置完成、链路up之后才能释放复位。实测下来，这样做不仅时序收敛更容易，还减少了链路误码率，复位释放时的毛刺问题也消失了。
2.3 Checksum卸载与ARP缓存处理
UDP的校验和计算在100G线速下是一个容易被低估的痛点。传统做法是收包后逐字节累加校验，但100G下数据速率太高，串行累加会成为时序瓶颈。开源代码里checksum模块是流水线式实现了RFC 1071标准算法，把16位累加拆成多个并行部分和流水段来拼凑最终结果。不过默认的位宽是64位，直接跑512位总线时会有兼容性问题，我改成了对512位数据进行按16位切片，分成32组并行累加再合并，只在首尾包边界做特殊处理。
ARP缓存方面，由于应用场景是FPGA直连服务器，IP/MAC对应关系基本固定，不需要频繁的动态刷新。我把ARP老化时间和自动请求逻辑简化了，只在系统启动时发送一次ARP请求解析服务器MAC，然后固定写入一个小的CAM表。这样避免了运行时ARP洪泛引起的不必要中断，也减少了RAM消耗。如果是要动态组网的场景，还是建议保留完整的ARP状态机。
3. 关键模块实测数据与资源占用
3.1 上板实测环境搭建与工具链
测试环境包括一块VU3P FPGA板卡，一台配备100G网卡的服务器，网卡型号是Mellanox ConnectX-5，用DAC直连光口在一起。FPGA侧加载的bitstream包含UDP协议栈、用户数据发生器和回环逻辑。服务器的操作系统为Ubuntu 22.04，测试工具使用iperf3进行UDP打流，同时用自写的python脚本通过raw socket发定制包，验证特定长度包的转发行为。
上板前先用xilinx的IBERT IP测试了光口物理层误码率，确保光模块和链路没有问题，避免后续排查时分不清是协议栈问题还是物理层问题。IBERT测试跑10分钟误码率为0，才敢把逻辑加载进去开始协议验证。
3.2 吞吐量测试结果与瓶颈定位
iperf3打流到64字节小包时，UDP吞吐稳定在83Gbps左右，距离满速100G还有不少差距，这个现象符合预期，因为小包场景下包头开销占比高，CMAC每帧需要的IPG和前缀也会占用一部分带宽。改发1518字节的大包时，吞吐跑到99.1Gbps，基本打满了线速。之后又用自定义发包工具做了混合包长测试，在64、128、512、1518字节混合流量下，吞吐保持在91Gbps以上，没有出现丢包。
进一步抓内部计数器的数据发现，配置模式下吞吐差异主要是用户RX侧的非对齐处理单元引入了部分气泡。因为并发小包时几乎每个包都要做非对齐字节搬移，处理端到端的流水线占用率高了，拉低了吞吐上限。后续优化方向是把非对齐搬移改成延迟写法，直接在局部做字节使能拼接，可以减少一拍的处理周期，预计能恢复到95Gbps以上。
3.3 资源利用率和时序收敛情况
移植完成后综合资源情况如下：LUT使用了整个芯片资源的23.7%，FF占用了15.2%，BRAM消耗了34个，其中大部分BRAM用在了用户数据缓冲和UDP payload缓存上。整体资源占用还有很大余量，后续可以在同样的芯片里再部署两套收发通路或者集成DDR控制逻辑。
时序收敛过程比较顺利，最关键的用户时钟达到322MHz，建立时间裕量为0.142ns，保持时间裕量0.287ns，满足设计要求。CMAC时钟域和用户时钟域之间的异步FIFO没有出现时序违规。使用单独的时钟约束文件把CMAC tx/rx时钟和用户时钟异步group，避免误报路径。这一点建议做100G工程的同行也这么设置，不然vivado会把无关路径全部分析一遍，很难收敛。
4. 踩过的坑与常见问题排查实录
4.1 光口链接正常但收不到上行数据：FEC对齐坑
刚开始上板时遇到一个很诡异的问题，光模块信号正常，link状态是up的，也带内计数器看到CMAC没有报错，但UDP层一个包都收不到。用chipscope抓CMAC的rx_axis_tvalid，发现数据始终为低。后来查了CMAC的Standard mode配置，发现FEC模式不匹配，默认配置没打开RS-FEC，实际链路是用RS-FEC编码的，CMAC收下来帧全被标记为fec_uncorrectable_error，然后直接丢弃了。
解决办法也很简单，在CMAC的配置寄存器里开启RS-FEC(RS_528_514)，并把FEC电感设置为standalone模式。这个问题提醒我，现在100G的光模块和交换机很多都默认开FEC，如果CMAC不配置对应模式，即便物理层link up了，实际数据通路上也是出不来的。排查顺序上，建议第一步就检查FEC模式与对端是否一致。
4.2 UDP Checksum校验错误导致的丢包：offset参数设错了
还有一个印象深刻的坑是TX方向的checksum偏移量计算错误。开源代码的UDP TX模块需要指定IP header和UDP header在AXI总线字节流中的位置偏移，我刚开始按照默认example设置，没考虑到接入的是512位总线的第2拍才开始有帧头数据，导致checksum计算时覆盖了错误的数据位置，发出去的UDP包所有checksum都是错的。服务器端收到了包，但校验不通过，直接丢弃。
排查的时候绕了很大弯路，一开始以为是物理层或者MAC的问题，反复用wireshark抓包也没有头绪，因为抓到的包看起来结构是完整的。后来在FPGA内部用iflax的调试模块直接把原始AXI数据通过DDR记录下来，对照包结构才发现checksum字段和数据内容不匹配。最终把偏移量按具体接入位置做了调整，用变量参数传入，测试通过。
4.3 突发流量下丢包：背压信号处理不正确
在测试server发送大量突发小包给FPGA时，出现了一种难以复现的偶发丢包，每秒钟丢几十个包，频率很低，但累计起来不可接受。一开始怀疑是UDP RX解析逻辑bug，观察了很长时间没有发现规律。后来定位到是TX方向的背压没处理好：用户逻辑处理完数据后，通过接口直接往TX方向塞数据，但TX模块在MAC输出FIFO接近满时会拉高backpressure，用户逻辑没有polling这个信号，导致数据在FIFO写端口等待时被覆盖。
修正方案是在用户逻辑和UDP TX模块之间增加一个握手状态机，对每拍数据都检查backpressure信号，backpressure为高时保持当前数据不动，等空闲再发送。这个处理看似简单，但确实容易在写原型代码时忽略，因为仿真时阻塞条件不够充分，看起来一切正常，上板高负载才暴露问题。
4.4 资源排查速查表
整理了这次调试中遇到的主要问题以及对应的检查点，方便后面遇到类似情况时快速定位。
| 现象 | 直接原因 | 排查方法 | 解决措施 |
|---|---|---|---|
| 物理link正常但收不到数据 | FEC模式不匹配 | 检查CMAC统计寄存器 | 两端配置相同的FEC模式 |
| 收到包但校验失败 | checksum偏移错误 | chipsope抓AXI数据对比包结构 | 确认帧头在总线中的偏移位置 |
| 突发流量偶发丢包 | 背压未处理 | 检查TX FIFO write当拍背压状态 | 增加握手状态机 |
| 高频时序不收敛 | 跨时钟域路径未约束 | 查看时序报告中的违例路径 | 加异步group约束 |
| 小包吞吐不达标 | 非对齐处理气泡多 | 内部计数器观察处理占用率 | 优化非对齐搬运逻辑 |
5. 移植完成后的一些个人体会
整个100G FPGA UDP协议栈移植加测试的过程，最深的感受是：协议栈本身的开源代码已经很成熟，真正的挑战其实在于系统集成和边界条件的处理。100G系统对时序、时钟域、背压、FEC这些细节的要求极为苛刻，任何一个环节考虑不周都会在上板阶段以极难排查的偶发问题形式暴露出来。
给后面做类似项目的同行几个具体的建议：第一，尽量使用CMAC硬核而不是软核实现MAC层，节省资源，稳定性更好，时序也更容易收敛；第二，移植开源协议栈时，先把系统时钟架构和复位方案想清楚再动手改代码，千万不要先改逻辑后补时钟约束，最后改起来非常痛苦；第三，上板之前务必把物理层IBERT测试跑一遍，确认链路本身没有问题再进入协议调试，否则排查问题会陷入协议和物理层互相混淆的泥潭。
还有一个不算经验的经验：在验证100G高速设计时，用chipscope抓波形已经不够高效了，数据量太大且触发条件难以精确控制。这次在里面加了一个轻量级的内部调试寄存器组，把关键通路上的计数器、状态机状态和FIFO水线通过PCIe读回来，配合一套简单的python解析脚本做长时间监控，定位突发问题的效率比在线逻辑分析仪高很多。这个思路我认为对于后续要做连续长时间稳定性测试的项目非常值得采纳。
