千兆以太网联调这事儿，说难不难，说简单真不简单。尤其是把 Xilinx 的 Tri_mode_ethernet_mac 和 Marvell 的 88E1518 PHY 拼到一块儿，跑通 1000M 满速率的时候，时序细节一个没盯住，轻则 RSSI 掉的厉害，重则 link 灯亮了照样 ping 不通。这两个芯片的组合在工业板卡、网络交换、测试仪器里都特别常见，我这次做的项目正好就是一套完整的 MAC + RGMII + PHY 通路，从 IP 配置、PHY 初始化到时序收敛、链路回环，中间踩了不少坑。这篇博文就是把整个联调过程拆开，把 Tri_mode_ethernet_mac 和 88E1518 之间的时序约束、寄存器配置、调试手法都理清楚，适合正在做 FPGA 以太网接口、或者准备调 PHY 的硬件和嵌入式工程师参考，新手也能照着一步步复现。
1. 联调前必须搞懂的硬件框架和时序模型
1.1 88E1518 是什么三速 PHY，为什么大家都在用
Marvell 的 88E1518 是一款三速以太网 PHY，支持 10M / 100M / 1000M，铜口（copper）和光纤口（fiber）都能接，接口侧除了最常见的 RGMII，还支持 SGMII。这颗芯片在工业板和通信板上出镜率很高，一颗片子解决一个网口，价格、功耗、供货都算靠谱。它内部有自协商、自适应均衡、MDI/MDIX 自动翻转这些功能，只要硬件电路不是反人类设计，基本不用太操心物理层的匹配问题。
但也就是因为它功能多，寄存器配置反而容易踩雷。比如 RGMII 的 TX/RX 延时是开还是关、自协商要不要强制、PHY 地址是多少、工作在 copper 还是 fiber 模式，这些都得靠 MDIO 总线去读写在 0x0000、0x0004、0x0010、0x0013 这些寄存器上。如果上电时 strap 引脚拉得不合适，后面软件怎么配都别扭，尤其是复位引脚同时复用了模式配置，这个后面细说。
1.2 Tri_mode_ethernet_mac IP 在链路里的位置
Xilinx 的 Tri-Mode Ethernet MAC IP 属于软核，例化在 FPGA 里，负责 MAC 层的事：帧封装、CRC 校验、流控、FIFO 缓冲，以及和 PHY 之间的接口时序。这个 IP 可以配置成 GMII / RGMII / SGMII 等接口形态，我们在工程里选的是 RGMII，因为引脚少，8 根数据线加 2 根控制线再加 2 根时钟线就搞定了，PCB 走线压力小很多。
IP 对外连接 PHY 的逻辑说白了就是一套源同步接口：发送端由 MAC 提供时钟，数据跟随时钟输出；接收端由 PHY 恢复出 RX 时钟，再把数据跟在时钟后面送进来。握手关系看起来简单，难就难在 PHY 送回来的时钟和数据之间的相位关系是不是稳定、是不是在 FPGA 触发器的 setup/hold 窗口内，这个问题不解决，后患无穷。
很多初次接触的人会把 MAC 和 PHY 当成一个整体，觉得 IP 都例化好了、PHY 也上电了，链路就应该通了。实际上这两者中间隔着一层 RGMII 时序协议，时钟相位、沿对齐方式、delay 配置稍有偏差，就会产生持续 CRC 错误。我们后面所有的工作，本质上都是在解决“数据能不能被正确采样”这一个问题。
1.3 RGMII 的 DDR 时序到底怎么走
RGMII 接口在千兆模式下是 DDR 方式：时钟频率 125MHz，在上升沿采样传输第 0～3 位，在下降沿采样第 4～7 位。也就是说 8 根数据总线被压缩成了 4 根，控制信号 TX_CTL/RX_CTL 也走同样的 DDR 方式。这样做的目的是省引脚，代价是每一个数据信号的实际速率变成 250Mbps，时序裕量被压得很小。
更关键的是 RGMII 的标准规定，发送端数据和时钟是“沿对齐”的，也就是时钟跳变沿正好对准数据翻转的中心窗口边缘。数据到接收端之后，接收端需要自己想办法把时钟移动半个周期，才能采到数据稳定的中间位置。这就是为什么所有 RGMII 方案里都会出现“delay”这个词：要么在 PHY 里加内部延时，要么在 PCB 上绕等长线做成延时，要么在 FPGA 里用 IDELAY 去移相位，总得有人出来承担这个移相的任务，否则采样就是建立时间/保持时间双重不满足。
这个“沿对齐转中心对齐”的过程，要先在原理图和 PCB 阶段就想清楚，不能等板子回来再拿软件硬调。下面几个章节我会把 88E1518 和 Tri_mode_ethernet_mac 各自的延时机制、约束写法、以及调试方法串起来讲。
2. 上板前先算清楚：关键时序参数和约束测算
2.1 125MHz 时钟树和 TX/RX 时钟来源
在 RGMII 千兆模式里，MAC 给 PHY 提供发送时钟 GTX_CLK，频率是 125MHz，同时这个时钟也作为 RGMII_TXC 信号由 MAC 引脚直接输出。Tri_mode_ethernet_mac IP 内部会产生这个 125MHz 发送时钟，但需要外部给它一个稳定的参考源，一般是由板上的晶振或者 FPGA 内部的 MMCM/PLL 提供。百兆和十兆模式下，这个时钟会动态降到 25MHz 和 2.5MHz，IP 会自动处理，但前提是外部时钟源能够跟着速率切换，或者 IP 内部有相应的时钟逻辑。
接收方向不一样，RX 时钟不是 FPGA 给的，是 PHY 从线路上恢复出来的 RGMII_RXC，频率同样跟随速率变化。对 FPGA 来说，这属于一个异步时钟域，不能想当然地和发送时钟当成同一个时钟处理。所以 XDC 约束里要明确区分：MAC 内部 125MHz 用户时钟、RGMII_TXC 输出时钟、RGMII_RXC 输入时钟，三个时钟域要单独约束，必要的时钟域之间设置 set_clock_groups 或 false path，防止 Vivado 工具用不合理的路径去约束接口。
刚开始做这个项目时，我犯过一个典型错误：直接把 RGMII_RXC 和内部 125MHz 时钟当成同源时钟，结果时序报告里冒出无数条莫名其妙的 setup violation。后来才意识到，RGMII_RXC 是 PHY 恢复时钟，和本地参考时钟完全没有相位关系，工具是不该去分析它们之间的路径的。
2.2 RGMII 2.0 内部延迟怎么配，MAC 和 PHY 谁出 delay
RGMII 2.0 标准引入了“内部延时”的约定，允许发送端或者接收端在芯片内部把数据/控制信号延迟大约 2ns，使得到达接收端时数据窗口中心对准时钟跳变沿。具体有两种做法：
- 发送端延时（TX delay）：MAC 输出数据时，把数据通道统一延迟约 2ns，让数据和时钟不再是沿对齐，而是中心对齐后再发给 PHY。
- 接收端延时（RX delay）：接收端的 PHY 或 MAC 对输入数据做延迟，补偿发送端沿对齐带来的采样困难。
88E1518 的优势是它的 RGMII 延时可以独立配置，通过寄存器 0x0004 的 RGMII Timing Control 字段，分别控制 TX delay 和 RX delay 打开还是关闭。常见的组合是让 PHY 同时开启 TX delay 和 RX delay，也就是设备树里常说的 rgmii-id 模式。这样 MAC 侧就不用做额外处理，FPGA 里省掉一组 IDELAY，硬件走线也简单，因为 PHY 内部已经把时序修好了。
我实际遇到的情况是，硬件同事为了“稳妥”，把 PHY 的 TX delay 开了、RX delay 没开，想让我在 FPGA 里用 IDELAY 去调接收时钟相位。这么做也不是不行，但调试成本一下子就上去了，每次换一块板子都可能要重新扫 delay 值。如果项目能改配置，我强烈建议优先选择 PHY 双 delay 全开，让 PHY 把脏活累活全干了，FPGA 侧只保证约束正确就行。如果板子已经定型、delay 没开全，再用 IDELAY 扫描的方式做补偿，后面我会讲具体的扫法。
2.3 input/output delay 约束怎么写进 XDC
RGMII 是源同步接口，XDC 里必须用 set_input_delay 和 set_output_delay 来约束端口时序。不能光靠 create_clock 完事，不然 Vivado 不知道数据和时钟沿之间的相位关系，布局布线就会乱来。
对于 RGMII 接收方向，假设 PHY 已经开启了 RX delay 和 TX delay，数据窗口大致是中心对齐的，那么约束可以近似写为：
# 假设 RGMII_RXC 由 PHY 恢复输入 create_clock -name rgmii_rxc -period 8.000 [get_ports {rgmii_rxc}] # 数据/控制相对 rxc 的 input delay，max/min 分别为窗口前后沿 set_input_delay -clock rgmii_rxc -max 2.100 [get_ports {rgmii_rxd[*] rgmii_rxctl}] set_input_delay -clock rgmii_rxc -min 1.900 [get_ports {rgmii_rxd[*] rgmii_rxctl}]这组数字不是随便拍的，需要根据 88E1518 datasheet 里的 RGMII 时序参数推算：tSKEW_TX 约 500ps，数据窗口在 125MHz 下一个 bit 是 8ns，delay 打开后时钟沿和安全区大约落在数据有效窗口的中心附近。工程上一般先按 PHY 手册推荐的 1.9~2.1ns 作为初值，后续通过 IDELAY 扫描或者误码统计来修正。
发送方向同理：
set_output_delay -clock rgmii_txc -max 2.100 [get_ports {rgmii_txd[*] rgmii_txctl}] set_output_delay -clock rgmii_txc -min 1.900 [get_ports {rgmii_txd[*] rgmii_txctl}]需要注意的是，RGMII 是 DDR 采样，如果工具版本支持，用 set_input_delay 的 -clock_edge 和 -min 分别约束上升沿和下降沿是最严谨的做法。但如果 PHY 延时配置是固定的 2ns 中心对齐，直接用上面的简化约束也没问题，跑出来的结果可以作为初始布局依据，真正的校准还是靠板级调试，纯靠静态时序分析保证不了所有板子的一致性。
3. PHY 初始化与硬件配置实操
3.1 上电时序与复位释放顺序
88E1518 的上电要求并不复杂，但必须遵守：电源 VDDIO、VDD 稳定后，RESETn 至少保持低电平 10ms，然后拉高，之后芯片开始加载 strap 引脚配置，再过一段时间 MDIO 才能正常访问。第一次联调时我就踩过这个坑：FPGA 里把复位信号拉高得太快，PHY 还没完成内部初始化，MDIO 读出来的 ID 全是对的，但控制寄存器写不进去，害得我查了半天逻辑。
后来我在工程里加入了一个上电延时状态机，专门负责给 PHY 复位：FPGA 上电后先等待 50ms，确保电源输出稳定，然后拉低 RESETn 20ms，再拉高，再等 100ms 才允许 MDIO 开始读写。这个时序比 PHY 手册要求宽松很多，但实际板子测试下来非常稳，尤其是电源质量差的工控板，多等这几十毫秒能省掉大量疑难杂症。
还要注意 RESETn 引脚在 88E1518 上往往和 LED 配置、接口模式配置共用，硬件电路上拉的电阻网络决定了 PHY 上电后的默认工作模式。如果板子上电后 MDIO 能读到 ID 但接口自协商一直起不来，大概率是 strap 模式没配置对，这时候要从硬件电路图入手，而不是反复改软件。
3.2 MDIO 总线访问和寄存器回读
MDIO 是管理接口，两线制：MDC 是管理时钟，MDIO 是双向数据线。Tri_mode_ethernet_mac IP 自带 MDIO 控制器，但如果你像我一样用的裸机逻辑或者自己写的软核，最简单的办法是用 GPIO 模拟 MDIO 时序。MDC 频率别太高，建议 2.5MHz 以下，过高的 MDC 在长走线和多 PHY 挂载时容易出问题。
MDIO 读操作流程很简单：先发 32 位 preamble，然后发 起始 + 操作码 + PHY 地址 + 寄存器地址 + 2 个 turnaround 周期，再读 16 位数据。写操作类似，但 turnaround 方向不同。88E1518 的 PHY 地址由 PHYAD[4:0] 引脚决定，很多评估板默认是 0x00，但工业板上为了挂多颗 PHY 通常会手动拨到 0x01、0x02 等，所以软件配置里必须先回读 0x0002 和 0x0003 寄存器确认 PHY ID，确认能读到 0x0141 这样的预期值，再去配其他寄存器。
读回 ID 还有一个好处：能判断硬件链路是否基本正常。如果 MDIO 一直读到 0xFFFF，说明 PHY 可能没上电、复位没释放、PHY 地址不对，或者 MDIO 上拉电阻没焊。这种问题越早发现越好，别等到链路调不通了才回头查。
3.3 寄存器配置顺序：软配还是 strap 硬拉
88E1518 的很多配置既可以靠 strap 引脚在上电时固定，也可以通过 MDIO 寄存器在运行中修改。两种方式各有适用场景。
strap 方式的好处是上电即生效，不依赖软件初始化，缺点是不够灵活，改配置要动硬件。寄存器方式的好处是可以在初始化脚本里动态调整，适合需要切换速率、切换光纤/铜口、或者做回环测试的场景。
我这边的通用配置顺序是这样：
- 复位释放后，先读 0x0002/0x0003，确认 PHY ID。
- 配置 0x0000 控制寄存器：关闭回环、默认开启自协商、复位数字电路，等待 self-clear。
- 配置 0x0004 RGMII 时序控制寄存器，打开 TX/RX delay，值按手册推荐设置。
- 配置 0x0010 自动协商通告，通告 1000M-Full、100M-Full/Half、10M-Full/Half。
- 配置 0x0013 1000BASE-T 控制寄存器，使能 1000M 自协商。
- 重新发起自协商，等待 0x0001 的状态位变为完成、link 状态 up。
这套顺序的核心思路是：先复位，再定接口时序，再通知 PHY 要通告哪些速率，最后才启动自协商。顺序反过来容易出现 PHY 已经自协商完毕但 delay 还没配置好的情况，导致链路虽然 up 了，但收发数据一直错。
下面给一个简化版的寄存器速查表，方便调试时对照：
| 寄存器 | 作用 | 典型配置 |
|---|---|---|
| 0x0000 | 控制寄存器：软复位、自协商、环回 | 0x1000 或 0x1200 |
| 0x0001 | 状态寄存器：link 状态、自协商完成 | 只读，用于判断 |
| 0x0002/0x0003 | PHY ID | 只读，用于确认芯片 |
| 0x0004 | RGMII TX/RX delay | 按 RGMII 时序要求设置 |
| 0x0010 | 自动协商通告 | 0x01E1 等 |
| 0x0013 | 1000BASE-T 控制 | 使能 1000M 自协商 |
这里的值需要根据你板子的 PHY 地址和实际需求调整，但顺序不要乱动。如果你用的是 Linux 嵌入式系统，设备树里配置 phy-mode 的时候，记得要和 88E1518 的 delay 配置保持一致：PHY 开了双 delay 就写 "rgmii-id"，只开 TX delay 就写 "rgmii-txid"，只开 RX delay 就写 "rgmii-rxid"，完全不开就写 "rgmii"。这里写错一个字母，MAC 驱动的初始化和 PHY 的软件配置就对不上，会出现只能百兆、不能千兆这种奇葩现象。
4. 从建工程到链路自环的完整联调流程
4.1 Vivado IP 配置和引脚分配要点
在 Vivado 里例化 Tri-Mode Ethernet MAC，关键选项包括：接口类型选 RGMII、速度能力选 10/100/1000M、使能全双工和自协商，管理接口可以选 AXI4-Lite，这样后续可以通过寄存器控制 MAC 的工作模式和状态。IP 生成时会自动带出一组示例约束，但只是参考，实际引脚分配还得按照自己的板子来。
引脚分配环节，最容易忽略的是时钟和复位引脚的电平标准。RGMII 接口信号通常是 2.5V 或者 3.3V 电平，88E1518 的 VDDIO 决定了 PHY 侧的电平标准，FPGA 侧的 IO Bank 电压必须和 PHY 侧匹配，否则会出现“看起来电压都对，但数据错的离谱”的情况。我在 PCB 设计时就把 RGMII 总线集中在同一个 Bank，统一约束成 LVCMOS25 或 LVCMOS33。
另外 RGMII 的 PCB 走线虽然只有 12 根左右，但 1000M 模式下信号速率已经到 250Mbps，走线最好做等长控制，尤其是 RGMII_TXC 和 TXD[3:0] 之间、RGMII_RXC 和 RXD[3:0] 之间，长度差不超过 500mil 比较保险。终端串联电阻按芯片手册来，一般 22Ω 或 33Ω 串在源端，看实际信号质量调。
4.2 板上实测：用 ILA 观察 RGMII 数据
上板第一件事，不是直接跑通网络，而是抓 RGMII 波形。用 Vivado 的 ILA 例化几个探针，观察 RGMII_TXC、RGMII_TXD、RGMII_TX_CTL、RGMII_RXC、RGMII_RXD、RGMII_RX_CTL，触发条件设成 TX_CTL 拉高的第一个包，然后看数据包出不来还是进来了。
如果 TX 侧数据完全不动，先查 MAC IP 有没有正常发起发送。如果 TX 侧有数据但 RX 侧一点反应都没有，问题基本集中在 PHY 或网口物理链路，这时候可以做 PHY 的 digital loopback，也就是让 PHY 把 MAC 发过来的数据直接环回给 MAC，不走网络变压器，不需要对端设备就能验证 MAC 到 PHY 的 RGMII 接口。88E1518 的 0x0000 控制寄存器 bit14 就是 loopback 开关，置 1 后，MAC 发出的包会原样回到 MAC 的接收通路。
用 loopback 的好处是把问题范围一分为二：如果 loopback 模式下收发正常，说明 MAC 和 RGMII 接口没问题，问题出在 PHY 对外物理层或者线缆对端；如果 loopback 都不通，那就是 MAC 到 PHY 这一段时序或配置的问题，再往下查就很清楚了。
还有一种更极端的测试叫 PHY 背靠背：用两颗 88E1518，把一端的 RGMII 桥接到另一端的 RGMII（或者通过配置让一颗 PHY 的 MAC 侧直连另一颗 PHY 的 MAC 侧），绕开网络变压器和网线，专门用来验证 PHY 寄存器和时钟质量。这个玩法适合硬件联调的早期，能把环境变量拉到最小。
4.3 接收时钟采样点校准与 IDELAY 扫描
如果 PHY 侧的 RGMII delay 没有全开，或者板卡走线等长做得比较差，接收方向就会出现采样不稳定，表现是 CRC 错误时有时无、百兆勉强通但千兆必丢包。这时候就得在 FPGA 里对 RGMII_RXC 做相位调整，最直接的手段是 IODELAY。
Tri_mode_ethernet_mac IP 在 RGMII 模式下，接收时钟是外部输入的，我可以在外部对 RGMII_RXC 做 IDELAY，改变它在 FPGA 内部到达触发器的相位。IDELAYE2 的 tap 分辨率大约 78ps，31 个 tap 全开约 2.4ns，足以覆盖 125MHz 下一个数据窗口的相位调整需求。
扫描方法很粗暴但有效：把 IDELAY_VALUE 作为一个可配置寄存器暴露给调试逻辑，用 ILA 或者直接用回环测试发包，从 0 到 31 遍历 tap，记录每个 tap 值下的 CRC 错误计数。正常时你会看到一个“无错误窗口”，比如 tap 从 8 到 22 都稳定，那就取中间值 15 作为工作点，留下足够的裕量。
这里有个细节：如果 PHY 开了 RX delay，那 RGMII_RXC 和 RXD 之间的关系已经是中心对齐了，FPGA 里最好不要再多加 IDELAY，或者只加一个很小的偏移。延时加多了等于把原本好的采样点又移到了窗口边缘，得不偿失。所以调试前务必把 PHY 侧的 delay 配置摸清楚，再决定 FPGA 侧要不要干预。
4.4 回环验证：从 MAC 环到 PHY 环
最终联调时我会按顺序跑三级回环：
第一级是 MAC 内部逻辑环回，Tri_mode_ethernet_mac IP 支持把发送数据在内部直接送给接收通路，不需要 PHY 参与，用来验证 MAC IP 配置、DMA/FIFO、用户逻辑是否正确。这一级如果通不过，先别碰 PHY，问题在 FPGA 内部。
第二级是 PHY digital loopback，就是刚才说的 0x0000 bit14，验证 MAC 到 PHY 的 RGMII 接口、MDIO 配置、时钟连接是否正常。这一级能过滤掉绝大部分时序问题，因为数据根本不经过模拟前端。
第三级才是真实的网线对打，接 PC 或者另一块板子，用 iperf 或者自写的发包逻辑做压力测试，同时观察 MAC 侧的 crc_error 计数和 runt 计数。如果这级也稳定跑几个小时不报错，千兆链路才算真正闭环。
5. 那些年踩过的坑：常见故障与排查定位
5.1 Link 灯亮了但 PING 不通
这是最经典的 RGMII 问题。link 灯亮说明 PHY 物理层的自协商成功，但数据通路不一定对。最常见的原因，就是 RGMII 采样相位不对，导致 MAC 收到了大量 CRC 错误帧，网络层直接丢弃。
排查步骤先看 MAC 的统计计数：如果 rx_frame_crc_error 一直增长，基本就是采样问题。先用 PHY loopback 排除物理层，再通过 IDELAY 扫描调整接收时钟相位。如果链路能通但丢包率极高，还要检查发送方向的时序，RGMII_TXC 和数据之间的 delay 是否匹配 PHY 的采样要求。我遇到过 TX delay 配置打开了，但 XDC 里 output delay 约束还写的沿对齐，导致工具布线时过度插入延迟，把边缘又推歪了。
简单总结，link up 只代表 PHY 之间“握手”成功，不代表 MAC 和 PHY 之间数据通路正常，RGMII 上的 DDR 时序是独立的一条线，必须单独调。
5.2 MDIO 读不到 PHY ID
MDIO 读回全是 F，先别怀疑代码，按顺序查三样：PHY 的复位释放没有、MDIO 上拉电阻有没有贴、PHY 地址是否和代码一致。我用 GPIO 模拟 MDIO 的时候还遇到过一种情况：MDC 和 MDIO 两根线在 FPGA 里分配到了不同的 Bank，一个 2.5V 一个 3.3V，导致 PHY 侧电平识别异常，读回来的数据时对时错。后来强制约束成同一个电平标准，问题就消失了。
MDIO 通信一旦稳定，建议先读 0x0002/0x0003，能读到 0x0141 就说明管理通道没问题，再谈后面的配置。很多工程师上来就写一堆寄存器，结果写了个寂寞，连 PHY ID 都读到 F，浪费时间。
5.3 FPGA 时序报告有 violation，但板子又能跑
这种情况最迷惑人。如果时序报告里 RGMII 接口路径有 violation，但实测数据偶尔能通，说明你离“稳定量产”还差得远，现在能跑是运气。RGMII 的约束必须让 Vivado 明确知道数据窗口和时钟沿的相对位置，否则工具不敢动布局布线，出来的结果就有随机性，有的板子行有的板子不行，有的温度一变就不行。
我处理这种问题的习惯是：先确保 XDC 里对 RGMII 的 input/output delay 数值是正确的，再检查有没有多余的 set_false_path 或 set_multicycle_path 把关键路径盖掉了。确认约束没写歪之后，再去看实际的 setup/hold violation 数值，一般通过调整 delay 配置或者优化引脚电平标准能解决，实在不行就在 IDELAY 上做修正。
5.4 常见故障速查表
| 现象 | 优先排查方向 | 处理思路 |
|---|---|---|
| Link 灯不亮 | PHY 配置、变压器、网口 | 手动强制自协商，查 PHY 状态寄存器，确认 copper 模式 |
| Link 灯亮但 ping 不通 | RGMII 采样相位 | PHY loopback 分层定位，IDELAY 扫描定采样点 |
| CRC 错误持续增长 | RX delay 配置、IDELAY | 减小/增大 IDELAY tap，检查 PHY 0x0004 寄存器 |
| MDIO 读不到 ID | 复位、上拉、PHY 地址 | 示波器抓 MDIO/MDC，检查电平标准 |
| 只能协商上百兆 | 1000BASE-T 配置、delay 模式 | 检查 0x0013 寄存器，确认 RGMII 接口无误 |
| 长时间跑机偶发抖动 | 电源纹波、时钟源抖动 | 改善 PHY 供电滤波，检查参考时钟质量 |
这个表是我实际项目里最常用的排查路径，遇到问题先对号入座，能省不少弯路。调试千兆以太网的难点不在于某一件事很难，而在于问题可能隐藏在电源、时钟、配置、时序、PCB 走线任意一个环节，系统性排查才是最快的路。
我个人在项目里的体会是，Tri_mode_ethernet_mac 和 88E1518 这套组合本身非常成熟，绝大多数问题都出在“联调”而不是“芯片”上。先把 RGMII 时序模型吃透，再严格按复位、MDIO 配置、采样校准、分层回环的流程走，千兆链路其实是可以很稳的。如果你现在板子还在设计阶段，硬件上一定把 PHY strap、delay 模式、MDIO 上拉这些细节留好，软件上先按 PHY 双 delay 的推荐配置做，这会让你后面少熬好几个通宵。
