扫码关注
网口Link已经亮了，为什么千兆一跑流量就开始丢包？
有一类以太网问题特别容易误导人：RJ45的Link灯亮了，系统也能拿到IP，Ping小包甚至基本正常。
可一跑iperf、大文件或者持续高流量，CRC Error、RX Error、丢包就开始往上涨。
这时候很多人会去换网线、查磁性器件、查PHY模拟波形。可如果问题只在千兆明显，降到100M就稳定，MAC和PHY之间的RGMII时序反而应该尽早检查。
Ethernet PHY一边连接网线侧的MDI，另一边通过RGMII、SGMII、RMII等接口和MCU、SoC或FPGA里的MAC通信。
Link Detect主要发生在PHY与网线这一侧。也就是说，PHY已经和对端协商到1Gbps，并不自动证明PHY到MAC这几根数字线的采样时序也完全正确。
所以完全可能出现：Link一直在线，PHY模拟侧看起来正常，但MAC收到的数据偶发bit错误，最终表现为CRC错误和丢包。
图1：RGMII位于MAC与PHY之间，TX和RX都有独立的Clock、Data和Control信号。
RGMII在1Gbps下使用125MHz时钟，并且在时钟上升沿、下降沿都传输数据。
表面上125MHz并不高，但双沿传输以后，每一组有效数据窗口只有约4ns。
更关键的是，RGMII并不是让Clock和Data完全同时到达接收端。接收端需要一定Clock-to-Data Skew，让数据在采样沿附近留出足够Setup/Hold裕量。
常见RGMII规范要求接收端Clock相对Data延迟约1～2ns量级。这个Delay可能由PHY内部产生，也可能由MAC内部产生，还可能靠PCB走线实现。真正危险的是：两边都加了Delay，或者两边都没加。
图2：RGMII可靠采样的关键是Clock与Data之间必须保留足够的Setup、Hold和Skew裕量。
很多PHY寄存器有RGMII-ID、TX Delay、RX Delay之类配置。
SoC端也可能在Device Tree、寄存器或Pin Controller里提供RGMII、RGMII-ID、RGMII-RXID、RGMII-TXID等模式。
如果工程师只看到“推荐开启2ns Delay”，没有确认这个Delay到底应该由哪一端提供，就可能形成双重延迟。
反过来，如果原理图默认依赖PHY内部Delay，但初始化代码把它关掉，PCB又没有做额外Clock延长，同样会导致采样边沿贴着数据跳变点。
时序裕量不足并不一定意味着每个bit都错。
温度、IO电压、器件工艺、边沿速度和同时翻转噪声都会让实际Delay产生变化。某些帧可能完全正确，某些帧在边界条件下才出现bit Error。
低流量时错误概率低，看起来像“偶发网络抖动”；一旦持续千兆大流量，单位时间经过的数据量大幅增加，CRC Error就迅速累积。
如果强制降到100M以后问题明显缓解，也很符合这个逻辑：RGMII低速模式的时序压力远小于1Gbps。
图3：以太网系统需要把MAC-PHY数字接口与PHY-Magnetics-MDI模拟接口分开理解和排查。
第一，先看PHY/MAC统计寄存器。确认是RX CRC、TX Error、FIFO还是其他错误在增长。
第二，核对PHY寄存器和SoC配置，明确TX Clock Delay、RX Clock Delay分别由谁提供。不要靠“默认应该开”去猜。
第三，用示波器在接收端附近同时测Clock和某一路Data。真正要看的是接收端实际Setup/Hold裕量，而不是只看频率是不是125MHz。
第四，用PHY内部Loopback或PRBS/BIST分段。MAC↔PHY内部回环正常、外部线缆测试也正常，就能进一步缩小故障边界。
第五，再看PCB：Clock/Data长度差、串阻位置、参考平面连续性、IO电压以及是否跨层。
一句工程判断：网口Link亮，是“网线这一侧通了”；千兆数据不丢，还要证明RGMII这一侧的时序也真的通了。
声明：
本文由凡亿教育整理，转载请注明来源！
投稿/招聘/广告/课程合作/资源置换 请加微信：13237418207
