Corundum这个项目搞FPGA网络加速的圈子里应该没人不认识。它把一整套100G网卡的数据通路全部开源在GitHub上PCIe DMA、多队列调度、10G/25G/100G MAC、IEEE 1588时间戳、报文过滤器、统计计数器加上配套的Linux内核驱动全部用Verilog写得清清楚楚。硬件工程师再也不用对着厂商那堆黑盒IP发愁想改队列深度改队列深度、想加自定义过滤逻辑加自定义过滤逻辑。我最近在做的就是把这套开源网卡从原本的Xilinx平台移植到Bittware VV4这块基于Intel Agilex 7 FPGA的PCIe加速卡上。VV4板卡自带双QSFP28 100G光口和PCIe Gen4 x16主机接口跟Corundum的定位非常契合。这篇文章是系列的第一篇先把项目背景、方案选型、移植风险和第一阶段实操讲清楚把为什么要移和第一步怎么走说明白。想把手头Corundum工程换平台、准备基于开源网卡做产品原型、或者单纯对FPGA实现100G网卡感兴趣的工程师这篇都值得花十分钟看看。1. 项目背景与移植动机1.1 为什么偏偏是Corundum开源网卡方案其实不算少但大多数停留在一个能ping通的水平。Corundum能做到的完整度在这类项目里是独一档的。它不只是一个MAC控制器而是从硬件到软件的全栈方案RTL侧有高性能DMA描述符引擎、多队列调度器、精确时间同步、报文分类过滤主机侧有标准Linux内核驱动用户态可以直接用ethtool、NAPI这套生态。更关键的是它的设计思路。Corundum的数据通路几乎全部用标准AXI4和AXI4-Stream接口连接模块边界非常干净。这意味着大部分逻辑是平台无关的只有供电芯片、PCIe硬核、高速收发器这些地方才依赖具体FPGA厂商。我在Xilinx的VCU118上跑过它的参考设计也被它的代码结构惊到过——你能在RTL里直接看到每个队列的desc ring是怎么被DMA引擎轮询的这对做网络性能调优和研究的人来说是无价之宝。选它做移植对象还有一层现实考虑现在做100G网络卸载、流量分析、低延迟交易这类应用的团队几乎都绕不开自己能不能控制硬件数据面这个问题。厂商的参考设计能跑但改起来很痛苦Corundum改起来就是改普通RTL体验完全不一样。1.2 Bittware VV4这块板卡值不值得折腾Bittware VV4的核心逻辑器件是Intel Agilex 7 FPGA这是Intel目前的主力高端平台。板卡上最显眼的资源是双QSFP28接口物理层直接支持100G光模块插上就能用完全对口Corundum的目标场景。主机接口是PCIe Gen4 x16理论带宽足够跑满100G线速不会在主机总线上卡脖子。板载还有一路DDR4内存后续如果需要做报文缓存、流表存储可以直接挂在Corundum的AXI接口下面扩展。电源和时钟拓扑是厂商设计好的高速收发器的参考时钟有专门的时钟芯片驱动比自己在裸FPGA上攒一套稳定得多。从硬件角度看VV4就是为100G网络加速卡这个定位准备的跟Corundum的100G NIC需求几乎是一一对应的。有意思的是Bittware官方也提供网络相关的参考设计但走的是Intel传统路线Platform Designer里拖IP、配置一堆参数、生成一个工程。问题在于官方参考设计是半封闭的关键数据通路被IP核包着想看细节看不了想改队列机制也改不了。用Corundum就完全不同了——它在PCIe和MAC之上完全开放你甚至可以把仲裁器换成自己的实现。1.3 移植风险先摆在桌面上动手之前我列了一张风险评估表把这次移植的坑都提前标了出来。做这种跨平台移植最忌讳的就是一上来觉得都是FPGA改改就能跑结果烧到板子上起不来半天找不到原因。风险项影响等级主要困难PCIe硬核差异高Xilinx XDMA/IP直连与Intel Hard IP的TLP接口、时钟复位行为完全不同100G以太网IP差异高CMAC换成E-tile硬核后高速收发器、FEC、AXI接口时序都要重新对齐时序收敛中器件结构不同原来的XDC约束全部失效需要按Quartus重新调Linux驱动适配中需要改vendor/device ID和少量MMIO寄存器枚举逻辑第三方工具链依赖低Corundum的纯逻辑部分不依赖厂商IP编译基本无障碍应对策略也很简单把整个移植拆成独立阶段每个阶段设置明确的验收标准跑通一步再走下一步。这个思路在后面会反复用到。2. 移植前的思路拆解2.1 Corundum架构里哪些是资产、哪些是债务拿到一份大工程我习惯先画一条平台无关/平台相关的分界线。Corundum的RTL目录里rtl/和lib/下绝大多数模块都是标准Verilog信号接口全部走AXI4、AXI4-Stream、AXI4-Lite。DMA描述符引擎、队列调度器、流过滤器、PTP时钟子系统、报文统计计数器这些占据了工程百分之八十的代码量而这部分几乎可以一行不改地搬过来。真正绑死在Xilinx平台上的只有五类东西PCIe硬核、以太网MAC硬核、高速串行收发器GTY、全局时钟缓冲和MMCM/PLL这类原语、还有一整套XDC约束文件。把这些比作基础设施Corundum自己的逻辑是上层建筑。所以移植的本质不是重写而是把这五类基础设施换一套新的再让上层建筑的接口适配进去。我拿到VV4后做的第一件事就是打开Corundum的Xilinx参考工程逐项核实哪些IP是例化出来的、哪些是纯RTL。这个步骤千万别省。很多移植失败都死在以为某个模块是纯RTL结果里面藏着Xilinx原语这种细节上。2.2 需要替换的模块清单下面这张表是我整理的替换清单基本就是这次移植所有工作量的边界了Xilinx组件在Corundum中的角色Intel替代方案XDMA/QDMA或pcie4硬核封装把PCIe TLP换成AXI接口Intel Agilex Hard IP for PCIeUltraScale Integrated 100G EthernetCMAC100G以太网MAC/PCS/PMAIntel E-tile/F-tile Hard IP for EthernetGTY Transceiver100G高速串行收发器Agilex收发器PHY通常在以太网IP内AXI Interconnect / AXI-Stream Interconnect总线互联Corundum自带互联或Platform Designer生成MMCM/PLL、BUFG/BUFG_GT时钟生成与全局缓冲Intel PLL IP、Global Clock、altclkctrl原语XDC引脚与时序约束物理约束与时序约束QSF引脚分配和SDC时序约束这里也要提醒一句很多互联逻辑不需要非得用厂商IP。Corundum自己就带了一套axis_*、axi_*的互联RTL在Xilinx工程里它们反而是主力。只有在DMA高带宽路径上遇到的互联才需要考虑用硬核或者精心调过时序的IP这是个取舍问题后面编译时序收不收敛就会暴露出来。2.3 移植路线图四步走战略我给自己定的总路线分四步每一步都有独立验收标准阶段一是先让空工程能编译出比特流验收标准是Quartus综合布局布线全部通过目标器件正确。阶段二是打通PCIe链路验收标准是Linux主机能枚举到设备、BAR空间能读写、DMA描述符环能正常运转。阶段三是打通100G数据面验收标准是光纤自环后MAC能link up、使用ping和iperf能跑通报文收发。阶段四是全功能联调与性能优化验收标准是多队列、1588、统计功能全部可用并尽量往线速100G靠。为什么这么拆因为IP替换是最大的风险源如果一次把PCIe、以太网、时钟全换完编译报错都不知道该查哪一块。先搞定工程骨架等于把房子地基打好后面每一层都在这基础上验证问题定位会清晰很多。3. 实战第一步工具链、源码与工程骨架3.1 Quartus Prime Pro准备工作Intel高端器件的编译工具是Quartus Prime Pro注意不是标准版。Agilex 7必须Pro版本才支持而且对电脑要求不低综合100G规模的工程内存建议32GB起步编译时间动辄一两个小时要有心理准备。我本地用的是22.4版本支持Agilex 7全系列器件。许可证是个要提前处理的事情。Agilex的器件支持、PCIe硬核IP、以太网硬核IP这些分别对应不同的license feature。Quartus在IP Generation时就会检查license没绑定好直接报错白白浪费时间。拿到板卡后第一件事就是把板卡型号对应的FPGA具体后缀确认清楚因为同一块板卡可能存在不同速度等级或不同tile组合的版本工程选错器件后面全白干。安装时别偷懒把Platform Designer以前叫Qsys组件勾上。Corundum移植里两个大头IP——PCIe和以太网——都要在Platform Designer里例化少了它后面寸步难行。Quartus本身还带了Signal Tap逻辑分析仪调试上板问题的时候会反复用到也一并确认装好了。3.2 拿到Corundum源码后怎么组织Corundum代码直接从GitHub克隆项目结构非常清晰。rtl/目录放的是核心数据通路、MAC wrapper、DMA引擎lib/目录放的是AXI相关的基础组件比如异步FIFO、宽度转换、时钟跨域处理fpga/目录按目标板卡组织参考工程modules/目录是Linux内核驱动。在Xilinx参考工程里工程顶层通常把PCIe、MAC这些厂商IP包在外围Corundum自己的逻辑作为核心例化在中间。移植第一步我做的不是立刻改代码而是先在本地把Xilinx工程的compile_order.txt或文件列表梳理出来对照rtl/和lib/把每个文件归属搞清楚避免漏文件。漏Verilog文件在编译时会有明确报错还好说最怕漏的是IP相关的约束文件编译过了但时序一团糟。我建议在fpga/下为VV4新建一个独立目录不要直接在Xilinx工程上改。这样两边工程可以并存对照哪边出了问题都能回溯。目录内部把厂商IP产生的文件单独放一个子目录跟Corundum的RTL隔离开以后升级Corundum版本时直接替换上层RTL目录就行。3.3 新建VV4工程从原理图到QSF约束先看板卡原理图这步没有捷径。需要确认的几组关键信号PCIe的参考时钟引脚和PERST复位引脚、QSFP28光口的高速收发器引脚对、低速管理总线I2C、板载时钟芯片输出引脚、复位按钮和状态LED。把这些从原理图里摘出来整理成一张引脚清单再开始写QSF文件。QSF里面最基础的是引脚位置和IO标准set_location_assignment PIN_AT27 -to pcie_refclk_p set_location_assignment PIN_AT28 -to pcie_refclk_n set_location_assignment PIN_AY15 -to pcie_perstn set_location_assignment PIN_D5 -to qsfp0_rx_p[0] set_location_assignment PIN_D6 -to qsfp0_rx_n[0] set_location_assignment PIN_F5 -to qsfp0_tx_p[0] set_location_assignment PIN_F6 -to qsfp0_tx_n[0] set_instance_assignment -name IO_STANDARD 1.2V -to pcie_refclk_p set_instance_assignment -name IO_STANDARD 1.2V -to pcie_refclk_n上面这段是示例格式实际的引脚编号和电平标准必须对板卡原理图挨个核实尤其收发器引脚是差分对名字里的p/n方向不能写反。第一版QSF不用把板卡上所有外设都约束完先把时钟、复位、PCIe、光口、LED这几条主线弄好其余外设后续需要时再加。时序约束我用的是SDC文件在Quartus里通过create_clock把输入时钟、收发器参考时钟定义清楚。刚开始不用追求把所有path都约束完美但PCIe和以太网的时钟必须约束正确否则IP核在时序分析时会报一堆unconstrained path影响后续收敛判断。3.4 时钟树和原语替换第一天最常见的坑Corundum在Xilinx工程里的时钟拓扑大致是这样PCIe参考时钟一路给PCIe硬核一路经MMCM分频出100M左右的管理时钟100G MAC需要322.265625MHz的用户时钟由板上可编程时钟芯片产生。这些时钟在Xilinx里通过BUFG、BUFG_GT这些原语接到全局时钟网络。到了Intel平台原语写法完全不同。Xilinx的BUFG对应Intel的全局时钟网络通常不需要显式例化原语Quartus会自动把时钟信号分配到全局网络。但IBUFDS这类差分输入缓冲就得用Intel的altiobuf_in或者直接靠引脚约束里的IO_STANDARD解决。MMCM/PLL则换成Intel PLL IP配置界面里输入频率、输出频率、锁定信号用法思路一致只是端口名不同。我第一天就踩了复位信号的坑。Xilinx的AXI外设普遍用低有效复位比如aresetnIntel很多IP核高有效复位而且要求复位释放必须与时钟同步。Corundum内部大量跨时钟域FIFO对复位释放时机非常敏感处理不好会出现一上电DMA队列状态就乱掉的问题。解决办法是在每个时钟域入口加一个同步复位释放模块用两三级触发器把异步复位同步化之后再释放保证全局所有模块在同一个时钟沿看到复位失效。这一阶段结束后我拿到的是一份可以正常编译出比特流的空壳工程顶层只有时钟、复位、LED这些外围逻辑PCIe和MAC还没接进来。但这一步是整个移植的地基后面所有模块的约束、时钟分配、引脚分配都以它为基础值得在开始就做扎实。4. PCIe硬核先把主机接口打通4.1 Xilinx侧Corundum是怎么接PCIe的在Xilinx参考工程里Corundum的PCIe层实际上是厂商硬核自研DMA引擎的组合。Xilinx的XDMA/QDMA IP负责把PCIe总线上的TLP包转成AXI4-Stream接口Corundum自己的DMA描述符引擎在这个接口上完成队列描述符搬运、中断上报和寄存器访问。这意味着移植的关键不是重新写DMA引擎而是找一个Intel PCIe硬核把它同样转成AXI4-Stream接口并且把用户时钟、复位、中断这几个外围行为对齐到Corundum的预期。别小看这个对齐里面全是细节TLP的tag分配空间、完成包的超时时间、BAR空间大小和类型、MSI-X中断的表结构每一项都会直接影响驱动能不能正常工作。我强烈建议在动手改代码之前先去Corundum的文档和代码里把pcie相关模块看透特别是它怎么处理读写请求的地址映射。这一步的认知清晰程度决定后面调试DMA超时问题时的效率。4.2 Intel Agilex Hard IP for PCIe的生成与配置打开Platform Designer添加Intel Agilex Hard IP for PCIe配置界面里需要重点确认这几个选项第一是模式必须选支持用户逻辑通过AXI-Stream访问的Native模式不要选成带调试TLP或者简化成固定配置的模式否则拿到的接口完全对不上。第二是链路宽度和速率VV4的PCIe Gen4 x16直接照填如果调试阶段想降速可以在IP里先配置成Gen3 x16稳定后再切回Gen4这个思路在排查链路不稳时很好用。第三是BAR空间Corundum驱动主要靠BAR0访问控制寄存器BAR大小给到1MB足够BAR类型建议配成32位非预取跟驱动里的映射逻辑匹配。第四是MSI-X中断Corundum每个队列一个中断向量务必保证IP生成的MSI-X Table容量大于队列数否则中断分配会失败。生成IP后Platform Designer会产出一个HDL封装和对应的_hw.tcl在Quartus工程里像普通模块一样例化即可。生成的接口里s_axis_tx_*、m_axis_rx_*这些信号就是接下来要接到Corundum DMA引擎上的入口。4.3 把TLP接口接回Corundum DMA引擎这一步其实是在做接线员的工作。Corundum的DMA引擎期望的输入是若干组AXI4-Stream接口一侧连PCIe硬核的RX/TX数据通路一侧连内部AXI互联。需要对齐的除了数据、valid/ready之外还有tlast、tuser这些控制信号的语义。Intel硬核的tuser定义与Xilinx XDMA不一定相同。Xilinx的XDMA在tuser里带描述符完成标志、错误标志这些信息Intel硬核也有自己的TLP错误标记。两边解析逻辑完全不同不能想当然地直连。我的做法是在Corundum的pcie模块和Intel硬核之间加一层薄薄的适配逻辑把tuser按两边协议重新编码并且加上必要的时序寄存提高时序收敛性。这块逻辑很小但它能隔离两个平台的差异后面换板卡或者换IP版本时只改这一层就够。时钟和复位的接法同样关键。Intel硬核输出的用户时钟会随着链路训练状态变化而Corundum DMA引擎要求所有AXI接口在复位释放后时钟必须稳定。PCIe硬核的user_reset输出通常在高有效要经过同步复位模块转换后才能给Corundum的aresetn使用。这个顺序如果乱了常见的表现是驱动加载后DMA寄存器能读但一发起描述符搬运就超时。4.4 主机枚举与驱动加载验证硬件和逻辑都接好后第一次上板验证的目标很简单主机能枚举到设备、BAR能访问、驱动能加载。烧录完成后在Linux下先看lspci输出lspci -vvv | grep -A 5 -i ethernet确认厂商号和设备号正确、链路速率显示Gen4 x16。Corundum驱动源码里会有一张PCI ID表需要把VV4的vendor/device ID加进去内核才会绑到corundum驱动。改完重新编译模块insmod加载后再检查一下ls /dev/corundum* cat /proc/interrupts | grep corundum能看到字符设备和MSI-X中断向量说明PCIe链路已经通了。接着可以跑一轮BAR0寄存器读写自检把设备ID寄存器读出来跟lspci结果比对一致就说明PCIe硬核到DMA引擎这条路径是通的。这一步是整个移植的命脉它通了后面以太网部分无论怎么折腾都还有一条可靠的主机调试通道。5. 100G以太网从CMAC换到E-tile/F-tile硬核5.1 Xilinx CMAC在Corundum里长什么样Corundum在Xilinx工程里对100G MAC的封装很典型上层是它自己的mac模块负责处理AXI-Stream接口、插入删除前导码、维护MAC统计下层是Xilinx的UltraScale Integrated 100G Ethernet IP也就是常说的CMAC。CMAC内置了PCS、PMA和可选的RS-FEC用户接口是512bit位宽的AXI4-Stream时钟跑在322.265625MHz——注意这个频率不是整数它是100G线速除以用户接口位宽再考虑编码开销后的结果。CMAC有个特点它把所有复杂的高速串行逻辑都藏在硬核里用户看到的只有AXI接口和一些状态信号。这对上层设计很友好但移植时就麻烦了——Intel侧没有一个长得一模一样的CMACE-tile硬核的接口布局、时钟生成方式、复位语义都有差异必须做适配。5.2 Intel E-tile以太网硬核的例化要点在Platform Designer里添加E-tile Hard IP for Ethernet如果板卡收发器位置走F-tile则选对应的F-tile版本配置里选100G速率。Agilex的以太网硬核支持多速率可以把10G/25G/50G/100G都勾上这样后续想在一个物理口上做速率切换会方便很多。不过多速率会占用更多硬核资源和额外逻辑第一版移植我建议先用固定100G功能通跑后再考虑扩展。FEC选项要看光模块和使用场景。长距离单模光模块一般开RS-FEC短距离DAC线缆或者自环测试可以关掉。Corundum的统计模块里对FEC错误计数有专门的寄存器位如果你MAC层配置和PHY侧FEC状态对不上会出现一种很诡异的现象——link up了但不停有CRC错包查半天才发现是FEC mismatch。所以第一版自环测试直接关FEC同时把对端的自动协商也关掉减少变量。IP生成后会附带一个收发器PHY的例化不需要单独再拖一个Transceiver Native PHY这是E-tile设计里比较省心的地方。用户接口同样是512bit AXI-Stream时钟322.265625MHz由硬核内部逻辑自动生成顶层只需把参考时钟管脚约束好。5.3 接口适配与光模块自环测试Intel硬核和CMAC的AXI接口都叫axis_tx、axis_rx但控制信号细节有差异。我先列几个容易出问题的地方tx_axis_tuser在Xilinx CMAC里通常表示报文错误标记和报文起始位置在Intel硬核里tuser的位宽和每一位的含义不同需要对照IP手册逐位定义来适配。还有rx_axis_tkeep的处理两边都是按字节有效标志但Corundum的MAC模块对tkeep的归一化逻辑可能在256bit和512bit位宽下的判断条件不同不能直接套用Xilinx的wrapper代码。我写的适配模块思路是把Intel硬核的收发AXI接口统一映射到Corundum MAC预期的接口协议上把tuser、错误标记、PTP时间戳信号分门别类转换。这段逻辑不长但它是整个移植中语义对齐最集中的地方后面所有面向用户的功能都跑在这层转换之上。自环测试我建议从内部回环开始——在硬核内部把TX数据环回到RX路径确认MAC和IP都在正常工作然后再用一根短光纤或DAC线缆把两个光口直接相连做板级自环。这两个环回之间如果出现差异就能立刻判断问题出在IP配置还是外部光模块链路上。通电后观察link up状态如果能起来直接在主机上ping对端接口的IP通了就说明100G MAC这条数据通路正式贯通。5.4 时序收敛第一轮编译怎么调PCIe和MAC都接进去后整工程第一次全编译才是真正的考验。Quartus布局布线跑完打开时序报告目标时钟是刚才那个322.265625MHz和PCIe用户时钟。第一版不收敛非常正常重点是知道怎么调。最常用的三板斧第一是给关键路径加寄存器切片在AXI互联里打开pipeline stage选项让长路径被寄存器切开第二是限制逻辑综合策略在Quartus里把对应时钟域的优化策略调成performance允许综合器复制关键逻辑第三是检查是否有时钟跨域的路径被误约束成同一时钟域导致timing报告里出现伪路径。Compile报告里还有一个重要指标是收发器tile的资源占用率如果某个tile附近布局拥塞严重也会拖累时序。必要时用set_location_assignment手动约束几个关键模块的位置把它们从拥塞区域拉开。这些优化做下来322MHz这个时钟域通常都能收敛。如果死活差几十ps先检查SDC里异步跨时钟域的set_false_path是否遗漏——很多时序超差的根子不是电路慢而是约束没写全。6. 移植排错速查与经验谈6.1 高频错误对照表这段时间遇到的坑我整理成了一张速查表。不敢说覆盖所有情况但对照着排查至少能帮你少走半天弯路现象可能原因解决办法Quartus编译报大量引脚分配错误QSF引脚名与顶层端口名不匹配核对原理图net名和RTL端口名用assignments编辑器自动生成综合通过但布局布线失败某区域资源过密或IO bank电压配置错误检查收发器所在bank的VCCT电压配置检查tile资源占用率PCIe枚举不到设备参考时钟未起振、PERST时序不对、Gen4链路协商失败先看PCIe硬核的link status寄存器试降Gen3检查PERST上电时序驱动加载后BAR读取全FFPCIe硬核的BAR空间配置与驱动不一致核对BAR类型、大小、prefetchable属性光口link up但CRC错包不停FEC配置不匹配、光模块协商模式未关统一两端FEC开关自环测试关闭自动协商DMA发起传输后超时描述符地址未按64字节对齐、PCIe地址映射错误检查DMA引擎对描述符地址对齐要求核对BAR偏移322MHz时序不收敛跨模块组合逻辑过长、时钟域约束缺失加流水寄存器切片补set_false_path调整综合策略6.2 三个值得单独说说的坑第一个坑是Intel硬核的接口模式选择。PCIe硬核在Platform Designer里有一个Native和AXI Bridge之类的模式选项选错了生成的接口完全是两个物种。我当时第一次生成了带Avalon-MM接口的版本跟Corundum的AXI4-Stream引擎完全对不上等于整个PCIe适配逻辑白写了一半。教训很直接动手生成IP前先把Corundum期望的接口协议列出来再对着IP配置界面一项项勾。第二个坑是复位极性。Corundum里AXI接口几乎全是低有效复位aresetn这个后缀我是闭着眼都能认出来。但Intel硬核很多复位输出是高有效甚至有些子模块的复位要求跟时钟沿对齐。第一次上板时我没有做充分的复位同步就直接相连结果DMA引擎的队列状态机出现偶发死锁查了两天才定位到复位释放时跳变导致FIFO读写指针错位。自定义同步复位模块的问题绝不是小题大做。第三个坑是tuser的语义差异。这个前面提过但值得再强调一次两个厂商的tuser定义差异非常大连位宽都不一样。不要试图写一个通用tuser解析器来自欺欺人直接在适配层里查手册逐位映射虽然枯燥但这是最稳的路径。6.3 调试方法论先环回、再外环、一次只动一个变量总体调试方针我总结成三句话先环回再外环先信号级再系统级一次只动一个变量。上板调试时我习惯先用Signal Tap抓关键状态信号。Intel平台对应的工具叫Signal Tap Logic Analyzer是Quartus自带的逻辑分析仪可以实时抓内部信号波形。比如DMA超时问题就在Signal Tap里抓描述符读请求的valid/ready和地址总线一眼就能看出地址是不是发错了。这种硬件调试方法比在Linux侧看dmesg高效得多因为很多问题在数据进入主机之前就已经错了。一次只动一个变量听起来像废话但在这种多模块移植的现场特别管用。PCIe、时钟、MAC、DMA这四条线交织在一起如果同时改了复位逻辑、又改了tuser映射、还换了FEC配置一旦出错根本不知道是哪个改动导致的。每次改一个点、重新编译、上板复测慢是慢点但每一步的结论都是可信的到后面联调时会省无数时间。7. 下一步计划与个人体会7.1 接下来要做的第一阶段的成果是工程骨架、PCIe链路、100G MAC链路都已经跑通主机能枚举设备光口自环能ping通核心数据通路基本成型。但离一个好用的100G网卡还有距离。下一步要做的第一件事是多队列调优把DMA引擎的队列深度、中断合并参数和实测吞吐对齐跑一轮iperf看单队列和四队列分别能到多少。然后是1588时间戳功能的验证这是Corundum相对普通网卡最能打的功能之一要确认PTP报文在硬件路径上的时戳注入和提取都符合预期。再往后还有稳定性测试长时间打流看是否有丢包和CRC错误统计计数器是否精确以及带外管理路径的完善。这些内容我计划放在系列的第二篇、第三篇里分别展开。7.2 我的一点体会这次移植做下来最大的感触是开源不等于白拿。Corundum把网卡逻辑挖得很深这是它的价值但当你把它接到一个新平台上时厂商硬核之间那些细微的接口差异、复位时序、时钟生成方式每一项都藏着需要消化的细节。说句实在话这活儿不是说看懂Verilog就能干的它是硬件平台IP理解RTL移植调试三件事的叠加。如果让我给准备做类似移植的同行提一句建议那就是一定先把Corundum在Xilinx参考工程里的完整设计理解透彻再动手换平台。理解透彻的标志是你能不看工程文件就画出PCIe、MAC、DMA引擎之间的接口关系图你清楚哪些信号是AXI标准定义、哪些是Xilinx私有语义。到这个程度再动手后续的坑基本都有预期。我自己也是被几个问题反复教育之后才真正理解这一点所以这篇里这些接线层面的细节写得格外啰嗦但每一个都是真金白银换来的经验。