
本文档聚焦RGMII(Reduced Gigabit Media Independent Interface)接口延迟(Delay)时序要求的核心原理,从接口架构、传输机制、时序违例根源、补偿逻辑、硬件设计约束等维度展开深度解析。旨在解决硬件设计、PCB布线、时序调试中“RGMII为何必须配置TX/RX Delay”“无延迟配置为何会出现采样错误、丢包、链路不稳定”等核心问题,为千兆以太网RGMII接口的硬件设计、时序约束、参数调试提供标准化理论依据与工程指导。
本文档适用于FPGA、MCU、ARM主控与以太网PHY芯片的RGMII接口硬件开发、时序优化、问题定位,适配工业级、消费级千兆以太网硬件场景。
RGMII是GMII接口的精简版本,核心优化为引脚压缩:将GMII 8位并行数据总线精简为4位,通过时序机制等效实现千兆传输速率,大幅节省芯片引脚与PCB布线资源。其接口信号主要包含:4位发送数据(TXD[3:0])、4位接收数据(RXD[3:0])、发送控制(TX_CTL)、接收控制(RX_CTL)、发送时钟(TX_CLK)、接收时钟(RX_CLK)。
RGMII核心速率支撑逻辑为125MHz时钟双沿采样(DDR):在125MHz时钟的上升沿、下降沿同时传输有效数据,单时钟周期传输2次4bit数据,单周期总吞吐量8bit,最终实现125MHz×8bit=1Gbps千兆传输速率。
该机制是RGMII必须配置Delay的根本前提:相较于SDR单沿传输,DDR双沿传输的有效数据时序窗口大幅压缩,时序裕量极低,微小的时钟、数据相位偏差即可引发采样失效,必须通过延迟校准保证时序合规。
核心时序参数基准:125MHz时钟周期T=8ns,双沿均分后单沿有效采样窗口仅4ns,叠加芯片建立/保持时间、PCB走线偏差后,实际可用时序裕量不足2ns,对时钟与数据的相对相位精度要求极致严苛。
RGMII的TX_Delay(发送延迟)、RX_Delay(接收延迟)并非可选配置,而是接口时序规范强制要求,核心目的是补偿各类硬件固有偏差,让数据边沿精准落在时钟采样窗口中心,规避建立/保持时间违例。
RGMII属于源同步传输架构:发送端同步输出时钟与数据,接收端采用随路时钟采样数据。理想状态下,时钟边沿与数据中心对齐可实现稳定采样,但硬件实际场景中存在两类固有偏差:
一是芯片内部时序偏差:MAC/PHY芯片内部,时钟树、数据通路的布线长度、驱动单元延迟不一致,导致芯片引脚输出的时钟、数据信号本身存在固有相位偏移;
二是PCB走线偏差:硬件布线无法做到时钟线与数据线完全等长、等阻抗,FR-4板材下信号传播速度约150mm/ns,微小走线长度差会直接引入纳秒级时序偏差。
若无Delay补偿,时钟边沿会偏离数据稳定窗口,直接导致上升沿或下降沿采样到数据跳变沿,引发数据误采、比特错、链路丢包。
传统SDR接口仅需单沿采样,时序裕量充足,无需额外延迟补偿;而RGMII双沿采样的核心痛点是无冗余时序容错空间。
根据RGMII官方规范,数据信号需相对时钟信号保持1.0ns~2.0ns的固定相位延迟,该延迟可抵消芯片输出抖动、PCB走线 skew、信号反射、串扰带来的时序偏移,让上升沿、下降沿两个采样窗口均能匹配数据稳定区间,保证双沿采样的一致性与可靠性。
时序稳定性的核心判定标准为建立时间(Tsetup)、保持时间(Thold)合规:建立时间是采样时钟到来前,数据需提前稳定的最小时间;保持时间是时钟采样后,数据需持续稳定的最小时间。
未配置Delay或Delay参数异常时,会出现两类典型违例:一是Delay过小,数据相对于时钟超前,导致保持时间不足,时钟下降沿采样时数据已跳变;二是Delay过大,数据相对于时钟滞后,导致建立时间不足,时钟上升沿采样时数据未稳定。两类违例均会直接造成千兆链路协商失败、随机丢包、高速传输断线等问题。
RGMII收发双向时序通路独立,延迟需求不同,需分别配置TX、RX延迟,不可通用参数,核心原理差异如下:
发送方向通路:MAC芯片输出TX_CLK、TXD[3:0]、TX_CTL信号,传输至PHY芯片完成数据发送。
硬件固有问题:MAC芯片内部时钟驱动链路延迟小于数据驱动链路延迟,且PCB布线中时钟线、数据线存在长度差,导致时钟边沿超前数据。此时PHY采样时,会提前采集到未稳定的数据,触发建立时间违例。
补偿逻辑:TX_Delay为数据相对发送时钟的延迟,通过MAC端可编程延迟单元,微调TXD、TX_CTL信号相位,延后数据输出时序,让数据稳定窗口精准对齐TX_CLK双采样边沿,满足PHY端采样时序要求。常规工程配置值为1.5ns~2.0ns。
接收方向通路:PHY芯片输出RX_CLK、RXD[3:0]、RX_CTL信号,传输至MAC芯片完成数据接收。
硬件固有问题:PHY输出的随路时钟与数据存在相位偏差,且PCB传输、信号损耗会进一步放大 skew,导致MAC端采样窗口偏移,双沿采样一致性差。
补偿逻辑:RX_Delay为接收数据相对接收时钟的延迟,通过MAC端延迟单元校准RX数据相位,抵消PHY输出偏差与PCB传输偏差,保证MAC端双沿采样均能捕获稳定数据,规避保持时间违例。常规工程配置值为1.0ns~1.8ns。
在硬件设计中省略Delay配置、延迟参数配置错误,会引发阶梯式时序故障,从隐性不稳定到显性链路失效,具体表现如下:
RGMII延迟补偿分为芯片硬件延迟与PCB布线延迟两类,工程中优先采用芯片可编程延迟,精度更高、适配性更强:
在千兆以太网设计中,即使严格控制了 RGMII 走线长度(如上篇强调的≤15cm),仍可能遭遇 “速率掉至百兆” 的诡异问题。某项目中,BMC 与 PHY 芯片的 RGMII 链路走线远远小于15cm,却频繁出现千兆协商失败,最终排查发现:时钟与数据的时序偏移(Skew)超标,成为压垮速率的 “最后一根稻草”。

本文将拆解 RGMII 时序的核心要求,结合实测案例解析失准根源,提供从设计约束到动态校准的全流程解决方案。
PHY芯片处原理图如下:



其中:TX信号为BMC发送、PHY接收;RX信号为BMC接收、PHY发送。RGMII实现千兆速率时,DATA信号单lane速率为250Mbps,单个UI为4ns。TX/RX信号时序理想状态为:CLK相对DATA0-3有2ns左右的时延,此时DATA信号建立时间保持时间平均分割。
下图所示为某款千兆PHY芯片对于RGMII建立时间保持时间的要求,建立时间保持时间最小1ns:

另一款千兆PHY芯片要求TX信号建立时间保持时间最小1.2ns;RX信号建立时间保持时间最小1ns:

以RX信号为例,RXCLK 2ns理想时延既可通过硬件实现,也可通过软件实现。硬件实现方式为:通过调整上面原理图中RXDLY引脚(PIN26)的配置电阻,使上拉电阻上件、下拉电阻NC。此时,发送端CLK会延迟1.8ns发出信号,如下图所示。软件实现方式为:通过调整寄存器配置,给CLK信号增加延时。BMC端、PHY端均可配置。

目前的RXDLY引脚配置电阻为上拉电阻上件,下拉电阻NC,此时,RXCLK延迟1.8ns。对BMC与PHY之间的RGMII RX信号进行测试。选择一根DATA信号以及RXCLK,在BMC对应引脚下方过孔处进行测试,BMC芯片为BGA封装。实测波形如下,其中,绿色信号为RXCLK;黄色信号为RXDATA:

可以看出,相对于DATA信号,RXCLK信号延后了大概0.5UI。这与硬件配置状态一致。然而目前PING大包丢包严重。因此怀疑在BMC芯片内部,对RXCLK还做了延时。
为验证这一点,将PHY这一端RXDLY引脚状态改为下拉电阻上件、上拉电阻NC,即PHY发出的RXCLK不做延时,如下图所示:

此时测到的波形如下:

CLK与DATA完全重合,波形与硬件配置状态一致,符合预期。此时PING大包正常。
“BMC内部设置了RX DELAY”这种推测是基于测试得到的。上述测试波形发现RXCLK 与RXDATA完全重合时,PING 大包没问题;RXCLK 相对RXDATA有2ns延时PING 大包丢包严重。因此推测BMC内部设置了RX DELAY。由于是在BMC内部设置的,在BMC管脚处测得的波形无法反映此DELAY。但此寄存器没有开放,看不到寄存器状态。经与BMC厂家确认,BMC内部确实设置了RX DELAY。
由于BMC内部设置了RX DELAY,且此DELAY无法修改,因此,将硬件上的RX DELAY取消,即RXDLY引脚配置为下拉电阻上件、上拉电阻NC。问题解决。
如上文所说:2ns理想时延既可通过硬件实现,也可通过软件实现。因此在设计之初需要明确硬件和软件状态。以RXCLK为例,下表整理了几种常用的实现2ns时延的配置方法:

注意,有些芯片不支持硬件调整时序,此时只能使用软件实现。而通过软件调整时序时,更推荐在发送端芯片处调整(上表第二种方法)。比如TX信号就在BMC端调整,RX信号就在PHY端调整。这样,在接收端测试信号时,就能直接观察到CLK信号的真实时序。否则就会像本案例中一样,在BMC端引脚处测得的RXCLK波形无法反映进入BMC之后,软件调整后的时序,导致硬件软件两种手段重复使用。
另外,当不使用硬件方式调整时序时,电阻配置方式为:下拉电阻上件、上拉电阻NC。不可以上下拉电阻均NC。因为,如下图所示,在PHY芯片内部,此引脚有弱上拉,如果下拉电阻不上件,此时引脚依然被拉高了。

如果说走线长度是 RGMII 设计的 “显性红线”,那么时序对齐就是 “隐性底线”。本文案例证明:即使满足了 15cm 的走线限制,忽略时钟与数据的相位关系、芯片容限特性,仍会导致千兆速率 “夭折”。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。