100G以太网在FPGA上跑UDP，这事儿听起来挺唬人，但真做起来，其实就是一层窗户纸。前阵子我刚好把一个开源UDP协议栈从10G往100G上挪，从看代码到上板跑通，踩了一堆坑也摸出一些门道。写这篇东西，就是想把整个移植上板的流程、我踩过的坑、以及最后怎么把问题一个个摁回去的，完整记录一遍。
不管你手里是Xilinx还是Intel的片子，只要你准备碰100G UDP，这文章应该能帮你省下一两周的瞎折腾时间。先说结论：100G UDP移植上板本身不复杂，复杂的是你对自己用的IP核、总线协议和时序收敛的理解深度。
1. 为什么非要自己折腾100G UDP协议栈
在开始聊技术细节前，先说说为什么要干这件事。有人可能会说，现成的闭源IP一大把，花钱买了直接调不就行了？这话没错，但前提是你预算充足，而且项目时间表宽松。但很多场景下，你需要的其实是UDP这种无连接、低延迟的传输方式，而不是动辄几十万授权费的完整TCP/IP卸载引擎。
1.1 100G UDP的真实应用场景
UDP在100G这个速率段的需求，主要集中在几个领域：
- 高速数据采集：示波器、雷达、软件无线电这类设备，需要把ADC采到的大流量数据实时搬到上位机。UDP丢包重传机制简单，硬件实现代价低，满速率跑也不心疼。
- 数据中心内部通信：AI训练集群的参数同步、分布式存储的数据分发，追求的是极低延迟和超高吞吐。TCP的拥塞控制在这种场景下反而是累赘。
- 科研仪器互联：粒子对撞机、射电望远镜阵列这类大型科学装置，动辄几百路高速数据需要汇聚。开源方案意味着你可以精确控制每一路数据的时序，甚至可以为了特殊需求魔改协议。
在这些场景里，UDP的不可靠反而成了优点：我不需要你保证我一定收到，我只需要你尽量快、尽量不丢地往我这边灌数据。剩下的纠错、排序、重传，都交给应用层来处理。
1.2 为什么选开源的移植方案
闭源IP虽然省心，但有几个绕不开的痛：第一，核心逻辑黑盒，出了问题你只能提工单等回复；第二，定制化困难，你想在发送路径上加个时间戳、或者在接收路径上过滤特定报文，都得看人家脸色；第三，授权费用和版税机制对于很多预算敏感的项目来说，确实不便宜。
开源协议栈的好处就是透明可控。代码就在那儿，你可以一行行地看，看它的状态机怎么跳、FIFO怎么管理、校验和怎么计算。出了问题，你理论上可以把问题定位到行号。而且从10G往100G挪，大部分代码逻辑是通用的，改的只是总线位宽和时钟频率。这活儿说白了就是一门手艺活，学会了自己留着，下次换个板子还能用。
2. 移植前的准备工作与方案选型
这块儿特别关键。我见过太多人上来就把代码down下来开始编译，结果光IP核版本不一致就折腾了两天。准备工作做的越扎实，后面调试越省事。
2.1 硬件平台评估
要跑100G，先看看手头的FPGA够不够格。这里说的够格不只是逻辑资源够不够，更关键的是高速收发器（Transceiver）的速率等级和数量。
- 至少需要1个100G速率的硬核MAC：虽然可以用软核通过逻辑去拼一个100G MAC，但那样子资源和时序都会非常紧张。像Xilinx的UltraScale+ VU9P、VU13P，或者Intel的Agilex系列，基本都内置了硬核的100G MAC（在Xilinx里叫CMAC，在Intel里叫Hard IP for Ethernet）。选用硬核还有个好处，它帮你把PCS/PMA层的很多烦人细节都处理好了，你只需要关心怎么把数据喂给它、怎么把数据从它那儿接走。
- 检查可用的GTY/GTM收发器数量：一个100G端口通常需要4路或8路高速收发器来组成一个通道组（取决于你用的是CAUI-4还是CAUI-10）。板子上可能有很多收发器，但不是每一个都能跑到100G速率，得查一下芯片手册，看哪些Bank支持你要的速率。
- 评估DDR带宽：虽然UDP本身不存数据，但如果你要做缓存、重排序或者流量整形，DDR的带宽会成为一个瓶颈。100G线速意味着大约12.5GB/s的数据吞吐，DDR4-2400单通道理论带宽也就19.2GB/s，扣掉刷新和效率损耗，你实际能用的带宽得精打细算。
2.2 开源协议栈项目的挑选技巧
市面上的开源UDP协议栈不少，但能支持100G的其实凤毛麟角。国内比较有名的是那套从Open-NFPLus演化出来的项目，国外的也有几套在GitHub上挂着。挑的时候重点看几个指标：
- 是否原生支持高总线位宽：100G下，如果使用512位的数据总线，时钟频率大约是322MHz（这是最常用的频率点）；如果你用256位总线，频率就得跑到644MHz，这对时序的要求就非常苛刻了。所以建议选原生支持512位总线的栈。
- 是否有完整的RX/TX路径：有些开源项目只是简单地把MAC包解出来丢给用户，但UDP需要的头部解析、校验和计算、ARP处理、ICMP回显等这些细节，它并不一定都实现了。选的时候要看代码里有没有完整的状态机。
- FIFO或缓存的设计是否成熟：UDP接收端可能会有多个包同时到达，如果只有一个FIFO，很容易产生头阻塞。好的设计会为不同的端口号设置独立的缓存队列，或者至少有一个足够大的暂存区，避免丢包。
我当时选的方案是基于一个在10G上已经验证过、架构比较干净的项目，其总线接口恰好是通用的AXI4-Stream，这让我后续对接CMAC IP核时省了很多事。
2.3 开发环境的搭建要点
Vivado版本的选择，有时候比代码本身更影响心情。版本太老，可能不支持你选的芯片型号；版本太新，又可能存在各种兼容性问题。我个人的建议是，除非必须，否则就用官方主推的稳定版本。对于100G设计，Vivado 2020.2以上版本对UltraScale+的支持都已经很成熟了。仿真工具方面，如果只是做RTL级的功能仿真，Vivado自带的XSim完全够用。但如果你要做时序仿真或者跑一些复杂的UVM环境，那还是得回归ModelSim或QuestaSim。我自己是习惯先把逻辑用纯RTL仿真验证一遍，再把IP核加进去做系统级仿真，最后才上板。
3. 整体架构设计与总线标准解析
这一章是整个移植的核心，讲清楚开源的协议栈和Xilinx CMAC之间是怎么连接起来的。如果你能把这个逻辑理清楚，那你就不只是会移植，而是真正理解这套系统了。
3.1 AXI4-Stream总线在100G场景下的应用
不管是什么协议栈，最终和硬核MAC通信的一定是AXI4-Stream总线。AXI4-Stream是一种无地址的总线协议，专门用来做高速数据流传输。它有四个最核心的信号：
- tdata：数据总线，可以是8、64、128、256、512位等任意宽度。在100G场景下，几乎都是512位。
- tkeep：字节使能信号。它用来指示对应的tdata字节是否有效。因为一个以太网帧不一定是64字节的整数倍，所以需要tkeep来标记最后一拍数据的有效字节数。
- tuser：用户自定义信号。在以太网场景下，通常用来传递错误标记、帧起始标记等。比如Xilinx的CMAC，会在tuser里塞入一个指示当前帧是否有CRC错误的信息。
- tlast：帧结束标志，高电平表示一拍是当前帧的最后一拍。
看到没，这个总线协议里没有握手的ready/valid信号，为什么它还能保证不丢数据？其实它是有握手信号的，只是在AXI4-Stream里被拆分成了TVALID和TREADY。TVALID拉高，表示主设备（Master）这拍发送的数据是有效的；TREADY拉高，表示从设备（Slave）这拍可以接收数据。只有当TVALID和TREADY同时拉高时，这一拍数据才算被成功传输。
3.2 协议栈内部模块的层次拆解
一个完整的UDP协议栈，从上到下大概分成这么几层：
- MAC层控制与状态：负责管理CMAC IP核的初始化、复位时序、链路状态监测。例如检查链路是否建立（PCS/PMA层是否完成同步）、有没有远端错误。
- MAC帧解析与封装：这时你拿到的数据是以太网帧。在这个模块里，接收方向要剥离MAC头部（目的MAC、源MAC、EtherType），判断这是个IPv4帧、ARP帧还是其他类型的帧。发送方向则要负责填充MAC地址、EtherType，并计算CRC校验码（或者把这个活儿交给CMAC硬件）。
- IP层处理：对接收方向，需要检查IP头部校验和、判断目的IP是不是本机、解析协议字段（是UDP还是ICMP）、处理分片重组逻辑。对发送方向，则需要填写源/目的IP、计算IP头部校验和、处理MTU分片。
- UDP层处理：对接收方向，检查UDP校验和，根据目的端口号将数据分发到不同的用户接口。对发送方向，则根据用户指定的目的IP和端口，封装UDP头，计算校验和。
- ARP/ICMP模块：这是让整个协议栈能够正常工作的“管理面”。ARP用于解析局域网内的IP地址和MAC地址的映射关系，ICMP用于回应Ping请求，方便你调试链路是否通。
每一层之间，大多数都用FIFO隔开，这样可以隔离时钟域，也可以防止模块间的相互干扰导致的时序问题。
4. 核心移植过程实战记录
接下来是真正的“搬砖”环节。我会按照实际的移植步骤，把每一步干什么、为什么这么干，以及我在这一步踩过的坑，都记录下来。
4.1 从10G到100G的代码改造细节
如果你手里的源码是10G的，那么恭喜你，你至少不需要从零开始解决UDP协议的逻辑问题。但是10G和100G的区别，可不仅仅是把时钟频率从156.25MHz变成322.265MHz这么简单。
- 数据位宽的变更：10G设计通常用64位数据总线，跑到156.25MHz。100G设计推荐用512位数据总线，跑322MHz。这不仅仅是把位宽翻几倍的问题。你想想，一个最小以太网帧只有64字节（加上前导码和FCS是84字节），如果总线位宽是512位（64字节），那么一个最小帧在总线上只需要一拍就能传完。你要怎样在只有一拍的周期里，完成FIFO读取、包头解析、甚至校验和计算？这就对逻辑的并行化提出了很高的要求。时序状态机必须重新设计，很多地方需要做成流水线。
- 校验和计算的并行化：UDP和IP头部校验和是16位反码求和。在10G下，你可以把整个帧的数据串行地累加，时间来得及。但在100G下，数据是一个周期64字节地涌进来，你要在同一个周期内完成对当前64字节数据的处理，如果还用串行加法器，那肯定完蛋。好的做法是用“加法器树”把64字节数据拆成16个32位数，然后并行求和，最后再合并进位。这部分逻辑是纯组合逻辑，时序压力巨大，通常需要插入流水寄存器。
- FIFO的深度调整：因为总线上一个周期可以传输更多的数据，所以你不再需要超深的FIFO来缓存，过深的FIFO反而会增加延迟和资源消耗。但是因为每个包的到达间隔变短，你需要确保FIFO能在极短的时间内处理完一个包，而不会被下一个包给冲掉，这就涉及到FIFO读写速率匹配的问题。建议使用Xilinx的原语或者IP核配置出独立时钟域的FIFO。
4.2 与Xilinx CMAC IP核的对接过程
CMAC是硬核，它提供的是标准的AXI4-Stream接口。但它的用户侧总线，数据位宽默认是512位。它的时钟可以配置为322.265MHz（此时为512位总线）或者644.53125MHz（此时为256位总线）。你需要将你的协议栈的用户侧接口，接到这个总线上。
- 复位时序：CMAC对复位时序有严格要求。复位释放后，它内部要完成GT收发器的校准、PCS/PMA通道的对齐等动作。你必须在设计中留够充足的时间，等待CMAC的
gt_rxuserrdy和gt_txuserrdy信号拉高后，才能开始发送数据。 - 用户侧状态信号：CMAC提供了几个重要的状态信号。
rx_axis_tuser里，其实并不仅仅是帧错误标志，在Xilinx的文档里，它还被定义为携带了当前帧的字节长度、错误指示等信息。在对接时，一定要仔细阅读IP手册里关于tuser信号位宽的定义，我见过有人直接把tuser整段忽略掉，结果丢包了还找不到原因。 - 流控机制：CMAC的接收侧可能会因为GT接收通道的背压而拉低
rx_axis_tready。协议栈的接收FIFO要能够正确处理这种反压。同理，发送侧，如果用户逻辑持续不断地发数据，但CMAC内部FIFO满了，它会拉低tx_axis_tready，你的发送逻辑必须能够暂停发送。
4.3 时钟与复位策略的实现
100G设计对时钟和复位的要求非常苛刻。我自己习惯这样组织时钟树：
- 一个独立的、高精度的差分时钟源作为参考时钟，接到GT的参考时钟引脚，频率为156.25MHz（这是100G以太网的标准参考时钟频率）。
- 核心逻辑时钟（用户侧）使用CMAC输出的
clk_tx_user和clk_rx_user，这是由CMAC内部根据链路速率自动生成的稳定时钟。 - 用户逻辑里，尽量避免自己用PLL生成需要和GT参考时钟同源的时钟，那样容易产生确定性延迟问题。
在复位设计上，千万别用全局异步复位然后把所有逻辑都扔进去。好的做法是使用同步复位，并且要根据不同的时钟域做异步复位同步释放，保证所有触发器在释放复位时，是在同一个时钟沿上动作。
4.4 地址与端口的映射关系
UDP协议栈里最核心的东西，其实就是一个查找表。你得告诉这个栈：本机的IP是多少，本机的MAC是多少，哪个UDP端口的数据往哪个用户通道送。在移植的时候，这部分通常是写死在RTL里的，不够灵活，运行时要改就得重新综合。我当时改成了一个小的RAM表，通过微处理器接口（比如AXI-Lite）动态配置，这样测试的时候就不用来回改代码重新编译了。
这个设计调整虽然代码量不大，但非常实用，尤其是做长时间稳定性测试的时候，需要反复切换测试端口和流量方向。
5. 上板测试的完整流程与技巧
代码移植完了，仿真过了，该上板了。这一步是真正考验人的地方。你可能会遇到仿真完全没问题的代码，一上板就跑飞的情况，这太常见了。上板测试的核心，不仅仅是看灯亮不亮，而是要看“线速”下稳不稳定。
5.1 测试环境的搭建与检查清单
- 硬件准备：一台带有100G端口的服务器（或者用两台100G交换机的端口环回）、以及一块带有100G QSFP28端口的FPGA板卡。更重要的是，你需要一个支持100G的光模块和一根配套的测试线缆，有条件的话，最好有一台示波器，用来观察高速信号的眼图。
- 软件准备：在电脑上装好Wireshark，用于抓包分析。如果你有Ixia或者思博伦的流量仪，那更好，没有的话就用我们后面要讲的软件方案替代。
上板前先对着这个清单过一遍：
- 板卡的JTAG能连上吗？
- FPGA配置成功了吗？
- QSFP28光模块的供电和复位是否正常？
- CMAC的GT参考时钟是否稳定？可以通过ILA去抓取CMAC的状态寄存器来看。
- 链路是否已经建立？即
cmac_link_status信号是否为1？
5.2 Iperf3和Scapy的100G UDP打流测试方法
在没有专用流量仪的情况下，软件打流工具就成了首选。
- 发送端测试：在服务器上使用
iperf3 -c <FPGA_IP> -u -b 0 -l 1400 -t 60，其中-b 0表示不限带宽，-l指定包长，-t指定测试时间。需要注意的是，100G的线速打流，普通的CPU是远远扛不住的，经常会出现所谓的“发送端瓶颈”，即发不出去那么多包。你可以多开几个iperf3客户端进程，每个进程绑定不同的CPU核心，并且使用taskset命令把它们绑到不同的核上，才能勉强打满100G。这个办法治标不治本，但用来验证FPGA的接收能力足够了。 - 双向测试与统计：接收端（FPGA这边）通过内部的计数器，分别统计收到的总包数、总字节数、错误包数。如果接收速率和发送速率能对得上，并且错误包数为0，那说明接收链路是通的。
- 用Scapy构造特殊报文：为了更精细地验证协议栈的逻辑（比如验证ARP功能、验证非法校验和是否会被丢弃、验证分片包是否正确重组），我会用Scapy直接从socket层发送自定义的报文。例如，构造一个UDP校验和错误的包发给FPGA，看它是否丢弃，以及是否会上报错误中断。
5.3 回环测试与吞吐量验证
上板测试第一步，通常是做个简单的环回测试。这个环回既可以直接在CMAC内部配置回环（把发送数据原封不动地收回来），也可以在外部光模块上通过光回环头来实现。
回环的目的：验证物理层链路正常。 直接在CMAC配置内部回环，能看到数据从TX走到RX，并且无误码，说明GT串行收发器和PCS/PMA层没问题。
这个测试完毕后，我们要测真正意义上的逻辑环回——即FPGA收到UDP包后，经过用户逻辑处理，再原路发回去。这样测可以验证整个UDP协议栈的收发双通路是否都能正常工作。具体操作时，我在协议栈内部加了一个简单的回环FIFO，把接收到的UDP数据重新封装成发送包，送回给上位机。上位机发100万个包，能收到100万个包，说明协议栈的数据通路是流畅的。
5.4 通过Wireshark分析上行报文
测试进入尾声，我们要验证FPGA作为发送端，发出的报文格式是否正确。用Wireshark在电脑上抓包，一般重点看几项：
- MAC层目的地址是否正确指向了电脑的网卡地址（注意，如果是发给网关的，就要填网关MAC）。
- EtherType字段是否正确。
- IP层源/目的IP、头的长度、标识符（ID）、标志位有没有问题。
- UDP层源/目的端口、长度字段、校验和是不是正常。
在调试时，还可以人为地让FPGA发送一些错误包（设置UDP校验和为错误值），然后用Wireshark抓包看看电脑上是否显示“Checksum Offload”之类的警告，以此确认电脑侧的校验和计算行为。
6. 测试结果分析：如何判断链路真的“健康”
测试不只是看功能通没通，还要看它快不快，稳不稳。这里整理了我在测试时关注的核心指标和分析方法。
6.1 如何评估线速条件下的丢包率与误码率
丢包率是很直观的指标。如果你用100G的流量去打，瞬间收到的包数少于发送的包数，那就算丢包了。丢包的原因分两类：
- 物理层误码：由光模块、连接器、信号完整性引起。这会导致CRC校验失败，从而被CMAC标记为错误帧。这类问题需要检查光模块、线缆、以及PCB走线，甚至要跑一段时间的
prbs测试来看误码率。 - 逻辑层丢包：接收路径上FIFO溢出、状态机误判、总线占用冲突等。这类问题通常要提高抓包时的观察精度，使用ILA去抓取关键信号，看看到底是哪一拍FIFO满了。
误码率测试，通常要用到一种叫PRBS（伪随机二进制序列）的测试报文。你发送一连串的伪随机数据，在接收端用相同的多项式来校验生成的序列是否一致，不一致的位即为误码位。如果长时间运行，误码率为0，说明物理层非常健康。
6.2 接收错误包数的统计与故障定位
FPGA内部要设计计数器，分别统计各种错误类型：
- “CRC错误帧计数”
- “帧长度错误计数”（比如收到小于64字节的Runt包，或大于1518字节的Jumbo包）
- “IP校验和错误计数”
- “UDP校验和错误计数”
如果在测试中发现CRC错误计数不为0，那么大概率是物理层出问题了。你需检查光模块是不是插紧了，光功率有没有异常，线缆有没有损坏。如果CRC没问题，但是UDP校验和错误计数上涨，那就是协议栈里校验和计算的逻辑有bug，需要回仿真里去找。有了这些计数器，你能快速缩小问题范围，而不是一头雾水。
6.3 以太网数据包分析：PCAP与Wireshark过滤规则
对抓包文件（PCAP）的分析能力，直接关系到你调试问题的效率。这里有几个常用的Wireshark过滤表达式，能在排查时帮上大忙：
udp.port == 5001 tcp.port == 5201 ip.src == 192.168.1.10 eth.src == 00:0a:35:01:02:03应用这些过滤规则，可以迅速从海量数据包中筛选出可疑目标。尤其是当你的FPGA在高速发送、电脑端在用多线程接收时，通过PCAP分析能够直观看到每个线程绑定的端口流量是否均匀，来判断负载均衡策略是否生效。
7. 实际调试过程中遇到的几个“坑”
这部分我记录几个典型的、容易让人卡壳的调试案例。希望对你有帮助。
7.1 CMAC链路状态对不上的问题
现象：逻辑复位完成后，CMAC的gt_rxuserrdy始终为0，链路始终up不起来。
排查过程：我用ILA抓取了CMAC的gt_powergood、gt_tx_resetdone、gt_rx_resetdone信号。发现gt_powergood为1，但gt_tx_resetdone一直不拉高。通过查阅芯片手册，怀疑是GT参考时钟从初始化阶段就不正确。用示波器测量了板上的GT参考时钟晶振，发现频率正确，但幅度不够，导致GT始终检测不到有效参考时钟。更换了板上的参考时钟电路后，复位顺利通过。
结论：上板遇到链路问题，先查高速收发器的参考时钟和复位信号。信号完整性问题切记要用仪表确认，不能只看寄存器。
7.2 RX路径FIFO溢出导致的随机丢包
现象：在打流时，总会有固定比例的丢包，比如发10万个包丢20个，还都是随机的。
排查过程：这种随机丢包最烦人，很难在仿真里复现。这时我在FPGA逻辑里置了一个标志位，只要接收FIFO的almost_full信号拉高过，就置位并向串口打印。跑了几分钟打流，串口果然打印了这个标志位。确认是FIFO溢出导致的。
原因分析：回看代码，发现我的接收模块使用的是“存储转发”模式，即必须收到整个完整帧后才把数据发给上层逻辑。这样FIFO的深度就需要大于一个最大帧长（可能由于Jumbo Frame支持，达到9KB），但实际配置的深度只有4KB。当一个超大帧到达时，FIFO肯定会满，从而拉低tready造成背压，而CMAC一旦检测到反压，就会丢弃或打标当前帧。
解决办法：把FIFO深度扩到16KB，或者把逻辑改成“直通模式”（边收边发），问题解决。
7.3 发送时钟与逻辑时钟不同源的时序问题
现象：时序收敛跑不过，特别是从逻辑时钟域到CMAC发送时钟域的跨时钟域路径，总是出现很长的布线延迟。
分析：这是因为我的逻辑时钟和CMAC发送时钟是完全异步的，导致了跨时钟域的数据同步问题。虽然在功能上没错，但在时序上增加了很大的不确定性。
解决办法：在逻辑和CMAC之间加入一个异步FIFO，将数据从逻辑时钟域同步到CMAC用户时钟域。这样一来，两边只需各自约束时钟域的路径即可，跨时钟域的路径被FIFO隔断，时序立刻收敛。
8. 写在最后的总结与感悟
100G UDP的移植测试，本质上是一个“标准化接口”对接问题，只要硬件平台选型正确、IP核配置准确、总线协议吃得透，大部分问题都是可以系统性解决的。整个过程里，最花时间的往往不是你写代码的过程，而是在继承的旧代码和第三方代码之间，反复确认它们之间的约定与假设。
我个人在这次项目中最大的收获，不是“能跑100G UDP”这个结果，而是更加系统地理解了一个真实的100G以太网数据通路里，从物理层GT、到数据链路层MAC、再到网络层IP和传输层UDP，各层之间的协作方式，以及如何用开源的力量来补齐商业IP短板。
最后再分享一个小技巧：UDP协议栈这类东西，看起来复杂，但真正核心的处理逻辑就那么几块，多仿真、多上板、多踩坑，慢慢你对整套数据流的直觉就建立起来了。下次哪怕要把这套东西移植到别人的板子上，或者从100G换到400G，你也能心里有数。毕竟底层逻辑万变不离其宗，速率提升只是换了个更宽的马路而已。
