延时校准的必要性归纳总结

做RGMII接口开发的人，早晚都会碰到一个问题：板子焊好了，程序烧进去了，网口死活不通。

我记得第一次调RGMII的时候，查了三天，示波器都快戳冒烟了。最后发现是时钟和数据的相位偏了不到1纳秒。就这一点点偏差，整个链路直接罢工。从那以后我养成了一个习惯——只要板子回来，第一件事就是做延时校准，不管芯片手册里说“自动对齐”有多漂亮。

这一节咱们就掰扯清楚：延时校准到底为什么非做不可？

RGMII 时序规范到底有多严？

RGMII 是源同步接口。什么意思？时钟是和数据一起从发送端发过来的。接收端靠这个时钟去采数据。理想情况是时钟跳变刚好落在数据的眼图正中间。但规范只给了很小的容差。

我们来看一组典型参数（来自 IEEE 802.3 和常见 PHY 手册）：

看到没？整个链路的允许偏差总共只有±1.2 ns。而你随便一个过孔、一段不等的走线，就能吃掉0.3~0.5 ns。如果芯片内部的输出延迟再散一点，加在一起很容易超过1 ns。超了，就出问题。

实际硬件中，偏差从哪来？

你想想看，一个系统里有那么多环节，每一个都可能给时序挖坑：

• PCB 走线不等长 —— 即使严格等长，过孔、拐角、参考层切换也会引入Skew。我在一个四层板上见过：明明走的等长线，实测时钟比数据快了0.7 ns，因为时钟线换了一层，过孔引入额外延迟。
• 芯片内部延迟差异 —— 同一批次的PHY和MAC，输出延迟可能差0.4 ns。不同批次、不同温度下更大。
• 温度与电压漂移 —— 芯片结温从25℃升到85℃，内部buffer延迟能变化0.2~0.3 ns。电源纹波大的板子，变化更明显。
• 参考时钟抖动 —— 如果全局时钟质量不好，抖动直接叠加到RGMII上。

说白了，你画板时做再好的等长仿真，也不可能覆盖所有工况。而实际产品要过高低温、上电自检、长期老化……一旦某个工况下时序超限，通信就会丢包、误码甚至断开。

不校准的下场——我踩过的坑

曾经有一款网关产品，量产了500台。老化测试时发现大约3%的机器在40℃环境下工作10分钟后网口自动降速，从1000M掉到100M。查了快一个月，最后抓到根因：RGMII的TXD延时偏移超了，接收端在高温下建立时间不足，导致CRC错误暴增，PHY自动协商降速。

那批板子其实画了等长线，也做了仿真，但仿真用的是典型值，没考虑芯片个体差异和高低温。后来在量产程序中加了延时校准流程，重新测了100台，全温区全部通过，再没出过问题。

再来看看不校准可能引发的具体症状：

1. PHY 无法 Link Up —— 上电后协商失败，或者只协商到100M/10M。
2. 高频丢包 —— iperf 测速时吞吐量忽高忽低，CRC 错误计数持续增长。
3. 特定操作触发断连 —— 比如大文件传输、大量小包并发时，链路突然断开再重连。
4. 高低温下功能不稳定 —— 常温好好的，一进烘箱就闹情绪。

校准的核心逻辑——一张图看懂

延时校准的根本目的，就是让接收端采到的数据眼图居中。无论是调整 PHY 那边的 TX 延时，还是调整 MAC 这边的 RX 延时，本质上都是给时钟或数据增加一个可控的相移，把实际的时序关系“掰回”到规范允许的窗口内。

下面这张图把整个必要性串起来了：

从图里能看明白：正常的信号经过实际电路后会产生偏移，如果偏移太大，时序就违规，通信故障就来了。唯一的出路就是做延时校准，把偏移掰回来。校准之后再回读确认，直到时序裕量回到安全区。

校准的收益——值得花这个功夫

说了这么多坏处，来点正面的。我做过一个对比项目：同一款板子，A组跑出厂固件（带校准流程），B组跑没校准的固件。结果如下：