ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

VCU128上100G以太网实现:IP核配置与硬件调试要点

VCU128上100G以太网实现:IP核配置与硬件调试要点 1. 为什么选VCU128来做100G不是性能焦虑是接口和生态先说结论这块板子不是给所有人准备的但如果你正好卡在需要100G以太网、又不想从零调SerDes参数和PCIe枚举这个位置上VCU128基本是当时最省心的一条路。我第一次拿到VCU128是在一个存储加速项目里需求很直白四路100G网口把数据从QSFP28光模块灌进FPGA做完特征提取之后从另一个100G口吐出去。之前团队在另一款平台上用ZCU106跑40GPCIe瓶颈和SerDes通道不够的问题折腾了快一个月。换到VCU128之后大部分时间反而花在了IP核配置和光模块兼容性上真正调底层收发器的时间少了很多。VCU128用的芯片是VU3P属于Virtex UltraScale家族逻辑资源和DSP资源都不是短板。真正关键的是它有四个QSFP28接口每个都直连到GTH/GTY收发器上布局上预留了足够的参考时钟和电源余量。做100G的时候你不再需要拿两个40G口去凑电路板级的事情Xilinx已经帮你做完了你要解决的是IP核怎么配、链路怎么能稳定link up的问题。我个人的建议是如果你的项目只需要单路100GVCU118其实更便宜但如果一开始就规划两路以上或者后面可能升级到200G/400GVCU128的QSFP28数量和收发器密度会给你省掉很多二次流片或者换板子的成本。另外VU3P的GTH收发器在100G速率下的眼图余量比想象中好这给后面积累模式下的稳定性留了比较大的余量。这块板子另一个值得提的点是它的PCIe Gen3 x16接口。100G数据进来之后很多时候要直接送进DDR或者通过DMA交给CPUVCU128的PCIe通道足够宽实测在DMA配置合理的情况下能跑到接近线速不会成为瓶颈。这一点在做网络测量或者流量回放的时候尤其重要不然你的100G口永远是绿的数据却全丢在内部总线上。2. 100G以太网IP核配置最容易翻车的地方是数据通路宽度和时钟域100G以太网IP核在Vivado里的配置界面看起来选项不多但每一个选错都会让你在调试台上多耗两三天。我把最容易踩的坑按严重程度排个序。2.1 数据通路宽度512位是默认正确解100G以太网MAC的AXI4-Stream接口数据位宽有512位和256位两种可选。默认是512位我强烈建议你保持默认。很多人觉得256位逻辑资源少、时序好收敛但实际在VCU128上跑100G的时候512位的用户时钟是322.265625MHz256位的时候用户时钟要跑到644.53125MHz。VU3P的布线资源在644MHz下面临着比较大的时序收敛压力尤其是你后面还要接自定义逻辑的时候大概率会在这里爆出负slack。反过来512位数据通路的用户时钟频率更低留给用户逻辑的时序预算更多。虽然每个时钟周期要处理更多的数据但AXI4-Stream的握手逻辑本身不复杂只要你的FIFO深度和反压机制设计得当线速处理不是问题。2.2 时钟模式不要再被独立时钟这个选项坑了IP核配置页里有Clock Mode选项分Independent Clock和Shared Clock两种。我开始图省事选了Independent Clock结果链路up是up了但ping对端设备的时候延迟非常不稳定偶尔还会丢包。后来看了PG203里关于时钟架构的说明才明白Independent Clock模式下TX用户时钟和RX用户时钟是异步的跨时钟域处理需要额外的CDC逻辑否则数据在极端情况下会丢。而Shared Clock模式下TX和RX共用同一个用户时钟源时序天然对齐对于100G这种高吞吐场景是更稳妥的选择。如果你必须用Independent Clock比如对接的MAC芯片本身就是独立时钟架构那么必须在用户逻辑里对RX路径上的所有状态信号做两级同步否则链路长时间跑下来必然会出现偶发错误。这个坑我不是第一个踩的论坛上类似的求助帖每年都有。2.3 流控和PFC先关掉跑通了再开100G以太网IP核默认开启流控但这个默认配置对FPGA来说是个隐患。流控帧处理会消耗MAC内部的时钟周期而且如果你的用户逻辑没有及时响应反压MAC会开始丢包并产生错误计数。我的做法是第一次配置就关掉Flow Control和Priority Flow Control先把Raw数据通路跑通确认无误后再按需开启。实测下来关掉流控之后RX数据通路的FIFO写入效率提高了约8%这在峰值流量测试时肉眼可见。另外关于FCS帧校验序列的处理我建议把它从用户接口里去使能。也就是说让MAC模块自己生成和检查FCS你不要在用户逻辑再去拼一遍CRC。这样做的好处是避免了两层CRC计算不一致的潜在问题而且对线速处理几乎没有任何影响。3. QSFP28光模块兼容性、DDM信息和散热如果说IP核配置是软件层面的坑那QSFP28光模块就是硬件的坑两条腿走路缺一条都得摔。3.1 不要默认所有模块都兼容上电前先看EEPROMVCU128的QSFP28接口在Vivado里有对应的Xilinx QSFP28收发器IP但这个IP的物理层兼容性和光模块的EEPROM内容有直接关系。我踩过最大的坑是某品牌的AOC线缆插上去之后link一直起不来而且模块的TX fault灯一直亮。排查了很久最后发现是模块EEPROM里的标准合规字段Revision Compliance填写不符合SFF-8636规范导致IP核初始化的时候认为模块不支持100G速率。从那以后每次换模块我都会先用I2C命令把EEPROM内容读出来看一眼重点检查以下几点规范版本号SFF-8636版本通道数应为4个通道标称比特率应为103.125Gbps发射和接收通道的合规字段如果EEPROM内容有异常很多模块厂商其实是愿意配合改固件的不要自己硬扛。3.2 DDM信息是你的第一道报警器要利用起来QSFP28模块内部的Digital Diagnostic MonitoringDDM信息包括温度、电压、光功率、偏置电流这些数据在FPGA侧都能通过I2C寄存器读出来。我测试的时候会在板卡驱动里加一个定时任务每隔1秒读一次模块的DDM信息记录下温度和光功率的变化曲线。不要小看这一步它能在问题爆发之前就暴露隐患。比如说我遇到过一次链路在连续跑了4小时后突然丢包率上升排查半天没找到FPGA侧的问题最后一看DDM日志模块的温度从68度涨到了85度光功率反而升高了。原因很简单散热片贴得不够紧模块内部激光器温度漂移导致光功率不稳定进而接收灵敏度和链路误码率恶化。换完散热片之后同一根模块连续跑了48小时温度稳定在62度附近链路再没出过一次误码。3.3 散热的位置和方向决定了你能跑多久VCU128的四个QSFP28接口都在板卡的同一侧如果你在标准机箱里用风扇风道如果设计不好最内侧的两个模块很容易积热。这个我深有体会。后来我给机箱加了一个独立的导风罩把两个风扇的冷风直接导向QSFP28区域温度直接降了10度左右。这里有一个小技巧加导风罩的时候要保证冷风能吹到QSFP28笼子的散热齿不要只对着板卡PCB吹否则散热效果很差。4. 从IP核到用户逻辑数据通路的搭建与控制IP核配置好、模块也link up了接下来就是真正的核心工作——在用户逻辑里把100G数据流正确、高效地接进来。这一步做不好前面所有工作都白费。4.1 用最简单的FIFO桥接开始不要一上来就套复杂框架很多人看到100G的AXI4-Stream接口第一反应是找个现成的DMA框架或者片上网络来实现数据分发结果复杂逻辑引入的时序问题和调试成本远超想象。我自己偏好的做法是第一步只写一个最简单的FIFO桥接模块把MAC的RX接口数据存进Block RAM FIFO再用一个回环逻辑把FIFO数据从TX接口发回去先验证一条完整的通路。这一步能确保MAC的收发链路本身没有问题也确认了用户逻辑的时序在512位数据通路下能收敛。4.2 反压机制必须想清楚否则数据就是丢了100G以太网的线速是148.8Mpps百万包每秒每个时钟周期都有可能来满帧或者背靠背的小包。如果你的用户逻辑处理不过来必须通过AXI4-Stream的tready信号把反压传给MAC。但注意反压不能在MAC内部就停下来因为MAC的FIFO深度有限长时间反压会导致FIFO溢出然后丢包。正确的做法是在用户逻辑入口放置一个足够深的异步FIFO建议至少8K x 512位当FIFO使用率达到80%以上时再对上一级产生反压。我最初用4K深度的时候在64字节小包全速灌入的测试中就出现了丢包。换成8K之后同样的测试零丢包。这个经验可能不适用于所有人的场景但对小包为主的业务比如金融行情转发来说FIFO深度直接决定了你能扛住多极端的流量突发。4.3 小包效率的优化一个容易被忽视的接口特性100G以太网IP核的AXI4-Stream接口有一个特性每收到一个帧会在tuser信号上拉高一个周期表示这是帧的起始。这个信号很多人忽略了但对小包处理来说极其重要。如果用户逻辑在小包场景下用逐字节的计数器去累加长度会白白消耗大量时钟周期。正确的做法是在tuser信号有效的那个周期直接读取tkeep或者从tdata里解析出长度信息这样每个包只需要1-2个时钟周期就能完成头部信息提取剩下时间可以去做内容处理。我现在的设计里用户逻辑侧对64字节小包的处理速率能达到每周期8个包是直接把tuser当成处理起点才做到的。5. ILA抓包调试加了探针以后链路反而断了说一个在调试阶段逼疯了很多人的现象。我在ILAIntegrated Logic Analyzer核里加了MAC的AXII-Stream接口信号做观测结果一点Run按钮链路立刻link down。原因不复杂但第一次碰到确实容易手足无措。ILA的核心思想是采样用户逻辑信号它本身要插入到数据通路的逻辑链路上这会导致信号路径上的时序发生变化。在100G这种高频、高速的数据通路上哪怕多一个LUT的延迟也有可能导致时钟收敛失败进而影响整个IP核的正常工作。我的解决办法是只在调试阶段使用ILA而且尽量把采样深度设小一点比如1024采样端口限制在关键信号上。另外优先使用Mark Debug功能去标记信号再通过Set Up Debug自动插入ILA而不是手动添加完整的ILA核。这样可以保证ILA对原始逻辑的影响最小。还有一个更隐蔽的问题当ILA采样频率很高时Vivado会默认选择使用BRAM资源来存储采样数据。在VCU128上如果你观察的信号跨越了多个时钟域ILA的设置里必须保证采样时钟的选择和信号实际所在时钟域一致否则采出来的数据是乱的而你根本不知道。6. 稳定性测试48小时压力测试是底线无论你自认为逻辑写得多稳、约束做得多好100G以太网没有跑过长稳测试就不算数。我的经验是新搭建的链路必须连续跑48小时无错误才有资格进入下一阶段。测试过程我自己会分三步走6.1 回环测试先跑FPGA内部回环直接用IP核内部的回环模式Near-End PMA Loopback跑24小时目的是确认收发器和时钟恢复电路本身的稳定性。这个过程不需要外部光模块参与纯板上信号通路可以用来排除模块和光纤的影响。6.2 外部回环光纤插着跑把光模块插上用一根光纤把TX和RX直连或者通过光衰减器把光功率调低一点再跑12小时。这一阶段验证的是光模块和SerDes之间的信号完整性和光模块本身的稳定性。6.3 对端设备联调真实环境下的最后一道关把FPGA和对端设备比如交换机的100G口连起来设置一个大的流量建议至少占到线速的60%以上再跑12小时。这个阶段主要验证的是跨设备的情况下时钟同步、前导码和FCS处理是否一致以及流控行为是否符合预期。我在这三步中踩过的最大坑是在6.3阶段——对端交换机使用的是不同品牌的MAC IP两边的前导码处理方式有细微差异导致FPGA收到的帧FCS全部错误。排查了很久才发现需要在IP核的帧处理选项里勾选去除前导码选项两边对齐以后链路瞬间就稳定了。7. 几个值得记住的Vivado配置细节与Vivado版本选择最后分享一下我在配置环境和过程中积累的一些心得。7.1 Vivado版本选择稳定优先于新功能VCU128在Vivado 2022.1以上版本有完整的board file支持但我实际使用中发现2022.1版本的100G Ethernet IP核在某些边界场景下会有已知的bug比如特定包长度组合下FCS错误而2023.1版本修复了大部分问题。我个人的建议是生产环境用2023.1或2023.2不要追新版本比如2024.x因为IP核升级后的默认参数可能会有变动反而引入新问题。如果是新项目直接选2023.1就当基准。7.2 约束文件里的一个关键参数参考时钟频率VCU128的四个QSFP28口分别对应了不同的GTY参考时钟引脚默认参考时钟频率是156.25MHz。这个频率对应的是100G速率下的默认分频系数。但有一种情况你会遇到如果板卡原理图上的参考时钟用的是161.1328125MHz或者其他频率那IP核配置里的参考时钟参数必须同步改掉否则收发器无法锁定。我自己吃过这个亏在另一像板卡上移植VCU128工程时参考时钟用的是153.6MHz我保留了原来工程里的156.25MHz配置结果TX的复位信号一直拉不起来。排查了一个晚上最后在收发器状态寄存器里看到RX CDR没有锁定才想起来去核对参考时钟。7.3 多路100G的场景下复位顺序很重要如果你像我一样同时使用两个或以上的100G口复位逻辑一定要设计成先复位参考时钟和PLL再复位串行收发器最后复位MAC和用户逻辑的流水线顺序。我第一次做双100G口的时候简单粗暴地用了同一个复位信号结果link up的时间随机有时候几秒有时候十几秒甚至偶尔起不来。后来按照XAPP系列文档里推荐的复位时序重写PPPLL复位逻辑四个口全部稳定在1秒内完成link up。现在我把复位逻辑独立成一个模块专门管理MAC复位、GTY收发器复位和用户逻辑复位的先后顺序这样不管是上电复位还是用户触发软复位链路都能快速恢复。8. 写在最后这套方案还能往哪扩展如果你已经按照上面的方法成功跑通了VCU128的100G链路下一步可以考虑扩展的方向其实不少。第一个方向是基于100G口的UDP硬件协议栈。MAC层跑通之后往上叠加UDP/IP的处理逻辑就能实现硬件级的数据收发延迟可以从软件协议栈的毫秒级降到几百纳秒级别。第二个方向是用多路100G做流量汇聚和负载均衡。VCU128有四个100G口配合内部的HBM如果型号带HBM的话或者DDR4可以搭建一个真实的流量分析平台在硬件层面实现五元组哈希分发。第三个方向是把XDMA和100G以太网串起来实现数据从网口到PCIe的无缝搬运。这个方向在DPU和智能网卡相关的项目里特别常见VCU128的PCIe Gen3 x16带宽足够支撑多路100G的线速转发。据我个人经验FPGA上跑100G以太网最难的其实不是IP核本身而是对数据通路、时钟和复位体系的整体理解。把上面这些坑都趟过一遍之后你再回头看Vivado里的那些配置选项会清晰很多。至少下次再遇到link down或者丢包的问题你知道该先查哪个寄存器而不是一头雾水地重来。
返回列表