Corundum开源100G网卡跨平台移植：从Xilinx到Intel Agilex 7实践

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，改改就能跑"，结果烧到板子上起不来，半天找不到原因。

应对策略也很简单：把整个移植拆成独立阶段，每个阶段设置明确的验收标准，跑通一步再走下一步。这个思路在后面会反复用到。

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 需要替换的模块清单

下面这张表是我整理的替换清单，基本就是这次移植所有工作量的边界了：

这里也要提醒一句：很多互联逻辑不需要非得用厂商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外设普遍用低有效复位，比如aresetn；Intel很多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侧没有一个"长得一模一样"的CMAC，E-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 高频错误对照表

这段时间遇到的坑，我整理成了一张速查表。不敢说覆盖所有情况，但对照着排查，至少能帮你少走半天弯路：

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私有语义。到这个程度再动手，后续的坑基本都有预期。我自己也是被几个问题反复教育之后才真正理解这一点，所以这篇里这些"接线"层面的细节，写得格外啰嗦，但每一个都是真金白银换来的经验。