做FPGA接PHY芯片的工程师十有八九会跟RGMII这个接口纠缠一阵子。引脚少、速率高、能直接跑千兆RGMII几乎是SoC和FPGA侧最通用的以太网物理层接口。我前段时间调一块Zynq外部千兆PHY的板子现象是link能起来但iperf一跑就掉线ILA抓出来的接收数据整段错位。折腾了两天最后问题落在一个点RGMII接口时序里那2ns延时没配明白。真不是玄学是MAC和PHY两侧对“数据什么时候有效”的理解不一致。这篇文章我把RGMII从PHY到MAC这条链路里的2ns延时为什么必须加、加在哪、怎么配、怎么验证一次说透并附上我在实际板子上测到的数据。文章适合三类人看正在写RGMII时序约束的FPGA工程师做硬件调试但被PHY寄存器搞到头疼的嵌入式工程师以及准备评估PHY芯片时序性能的通信方向同学。不需要懂很深的理论但最好用过Vivado、接触过一点MDIO配置不然里面某些操作步骤会有点跳。1. 项目概述与核心需求解析1.1 RGMII到底是什么——4根数据线双沿采样的精简接口RGMIIReduced Gigabit Media Independent Interface是为了替代GMII被提出来的。GMII在千兆模式下有8根数据线、125MHz时钟单沿采样一个周期送8bit总带宽1Gbps接口引脚不算少。RGMII把数据线砍到4根时钟还是125MHz但改成了双沿采样上升沿和下降沿各送4bit合起来一个时钟周期还是8bit带宽没变引脚却少了一半。具体到信号上RGMII收发各有一组发送侧是TXC、TXD[3:0]、TX_CTL由MAC发给PHY接收侧是RXC、RXD[3:0]、RX_CTL由PHY发给MAC。TXC和RXC在千兆模式下都是125MHz但数据是在上下两个沿都有效所以每个bit的实际有效窗口只有4ns。TX_CTL和RX_CTL也不是单纯的控制线它们在时钟上升沿对应TX_EN/RX_DV下降沿对应TX_ERR/RX_ER等于一根线当两根用。这套设计最大的问题恰恰出在“上下沿都有数据”这件事上。GMII时代时钟频率低、数据窗口宽接收端随便找个沿采样基本都不会踩到数据跳变边缘。到了RGMII数据窗口被压到4ns时钟沿如果和数据变化边沿正好重叠接收端采样的就是“正在变化中的电平”建立时间和保持时间全都岌岌可危。所以RGMII必须让数据有效窗口的中心点对准采样时钟沿这就是2ns延时的由来。1.2 为什么偏偏是2ns从Tskew到中心对齐的完整推导很多朋友一开始不理解为什么RGMII规范里反复强调“约2ns延时”。其实算起来非常直接。千兆模式下RXC是125MHz周期8ns但数据是DDR上升沿一个bit、下降沿一个bit所以每个bit周期实际是4ns。要让接收端采样点落在数据窗口正中间就得把数据或者时钟偏移半个bit周期也就是2ns。注意是半个bit周期不是半个时钟周期。有些人把这个概念搞混按4ns去配配置出来的结果等于数据变化点又回到了采样沿附近反而更糟。这2ns可以加在数据通路上也可以加在时钟通路上效果上都是让采样沿从“数据边界”挪到“数据中心”。那为什么PHY/MAC不直接把数据做delay非要把这个难题抛给用户原因在于芯片厂商没法确定对端是什么方案。有的PHY内置了延时有的MAC侧FPGA已经做了IO延时如果两边同时加加起来就可能凑成4ns甚至更大直接废掉。这也是很多板子“常温能通、一热就挂”的根本原因。所以RGMII的2ns不是一个固定值而是一个需要按实际场景选择的折中值核心是保证接收端建立时间和保持时间都有足够余量。1.3 影响范围从PCB设计到软件驱动的全链路问题RGMII时序问题的影响面比很多人想象得大。表面上它是“时序约束”问题实际上牵扯到PCB走线长度、PHY寄存器配置、FPGA原语选型、MDIO驱动、以及高低温下的稳定性验证。任何一环疏忽表现出来的症状都是“链路不稳定”或者“偶发CRC错误”定位起来非常难受。我这次项目里的板子走线本身并不长PCB评审时也做过等长但等长只解决了物理长度一致的问题没有解决RGMII协议层面的“边沿对齐”问题。换句话说走线做得好只代表偏斜小不代表协议对。协议要求的是“数据有效窗口中心对采样沿”这必须在逻辑层额外配置靠走线长度去凑2ns不现实——FR4上1 inch大约对应165ps延时想凑出2ns要12 inch以上的长度差正常板卡根本塞不下。2. RGMII的2ns延时加在哪PHY寄存器、FPGA约束与PCB走线2.1 方案APHY芯片寄存器调整TX/RX延时最省事的方式是用MDIO总线把PHY芯片内部的RGMII延时打开。市面上常见的千兆PHY像Realtek RTL8211系列、Marvell 88E1512、裕太微YT8531等基本都在寄存器里提供了RGMII TX Delay和RX Delay的控制位。这些位的作用是在PHY内部为TXD/TX_CTL或RXD/RX_CTL增加约2ns延时让数据变化点相对采样沿偏移一个bit半周期。以RTL8211F为例不同型号寄存器地址差异很大拿到别的PHY一定要查手册RGMII TX Delay控制位在0x14寄存器的bit11RX Delay控制位在0x15寄存器的bit11置1后内部延时约2ns。配置方式一般走MDIO接口在Linux下可以用mdio-tools在FPGA里可以自己写一个MDIO Master小模块。伪代码逻辑非常简单// 读当前寄存器值 uint16_t val mdio_read(phy_addr, 0x14); // 使能RGMII TX Delay保留其他bit val | (1 11); mdio_write(phy_addr, 0x14, val); val mdio_read(phy_addr, 0x15); val | (1 11); // 使能RX Delay mdio_write(phy_addr, 0x15, val);用PHY内置延时的好处是MAC侧不需要做任何逻辑改动约束文件也只是象征性写一下。坏处是不同厂商、不同批次的PHY延时的精度和温漂特性差别很大。我实测过某款国产PHY在25℃时内部延时有2.1ns但到85℃掉到1.6ns余量明显变差。所以如果做高低温都要稳的产品不能完全依赖PHY内部延时最好还是让FPGA侧能主动控制采样点。2.2 方案BFPGA内用ODDR/IDDR原语配合时序约束对FPGA用户来说另一个常见方案是完全不管PHY的延时寄存器在FPGA内部用IDDR/ODDR原语把DDR数据转换成两个半字节的SDR数据然后用XDC约束把2ns偏移算进去。这个方案最灵活也是我做项目时优先选用的方式。先看接收方向。PHY发过来的RXD[3:0]在RXC的上升沿和下降沿都有效FPGA不能直接把RXD当普通并行数据采必须用IDDR把双沿数据拆开。Xilinx 7系列/Zynq的IDDR可以配置成SAME_EDGE_PIPELINED模式上升沿采到的低4bit和下降沿采到的高4bit在同一个时钟周期并行输出。ODDR反向操作把两个半字节在TXC的双沿发送出去。约束上XDC里要做两件事。第一把RXC和TXC声明成时钟并和外部PHY的时序关系对应起来第二用set_input_delay和set_output_delay告诉工具数据相对于时钟是哪种偏斜关系。下面是接收方向的典型写法实际数值需要按PCB走线长度和PHY手册重新算不能直接抄# 外部PHY提供RXC作为FPGA的接收时钟 create_generated_clock -name clk_rxc -source [get_ports eth_rxc] -divide_by 1 # 假设RXD相对RXC的延时窗口在0.5ns到2.0ns之间 set_input_delay -clock clk_rxc -max 2.0 [get_ports {eth_rxd[*] eth_rx_ctl}] set_input_delay -clock clk_rxc -min 0.5 [get_ports {eth_rxd[*] eth_rx_ctl}]发送方向类似只不过换成set_output_delay对象是TXC时钟输出的TXD和TX_CTL。需要注意的是如果PHY侧已经开了2ns延时FPGA这边的约束就要相应调整不能让两边叠加出4ns偏移。这也是调试中容易踩的坑。2.3 方案CPCB蛇形走线延时理论上RGMII的2ns偏斜也可以靠PCB走线做常见做法是让时钟线比数据线长一段或者反过来。FR4板材上信号传播速度大概6 inch/ns反推2ns就是12 inch长度差。这个长度在真实板卡上几乎不可能接受除非PHY和MAC离得非常远并且走线天然有巨大长度差否则不建议作为主方案。更合理的做法是让PCB走线尽量等长把偏斜控制在picoseconds级别剩下的事交给PHY寄存器或者FPGA约束去处理。PCB等长只是保证“不引入额外问题”不能指望用走线去解决协议层面“边沿对齐采样”的设计缺陷。3. 实操记录从默认配置到2ns精准落地的三个步骤3.1 硬件环境与初始故障现象这次调试用的硬件是Zynq-7020加一颗国产千兆PHYMDIO地址0x00PHY工作在RGMII 1000Base-T模式FPGA内部跑一个自研的以太网MAC数据通路用AXI-Stream接DMA。刚开始上电后千兆link能建立PHY状态寄存器读到link up、速率1000M、全双工。但一跑iperf就露馅TCP吞吐只有两三百兆而且持续几分钟后网口直接挂掉ping不通必须重新link。用ILA抓接收侧RXD和RX_CTL发现数据不是“偶尔错一bit”而是整个4bit组循环错位。比如MAC期望接收到的是0xA5 0x5A这种交错数据实际采出来的序列整体看起来像“后半字节拿到了前半字节的位置”。这说明IDDR拆分高低半字节的相位关系不对RXC采样沿落在了数据跳变沿上属于非常典型的RGMII延时不匹配。3.2 第一步先用PHY寄存器做一个“粗暴”的2ns偏置定位到时序问题后最先尝试的是最快速的方案把PHY内部RX Delay打开让PHY输出的RXD相对RXC整体偏移2ns。用MDIO工具直接操作先把寄存器读回来确认bit原始值再置位写回。配置完成后重新抓ILA发现RXD和RX_CTL的相位关系明显改善原来错位的半字节回到了正确位置。这一步的价值在于快速验证“问题确实出在延时上”。如果打开PHY内部延时后现象立刻变好就不需要在FPGA侧瞎猜约束值。但这里有个陷阱PHY的RX Delay打开后FPGA侧约束万一还是按“无延时”写时序分析结果就会和实际电路不一致所以下一步必须回头修正XDC里的input delay。3.3 第二步FPGA侧同步调整XDC约束PHY延时打开后我在XDC里把接收方向的数据和时钟关系调整成“中心对齐”的样子。仍以上面的约束为例RXD相对RXC的input delay窗口从默认的0~0.5ns改成0.5~2.0ns发送方向也做了对称调整。然后跑综合布线重点看时序报告里rxd_in和rx_ctl_in这两条路径的setup slack和hold slack。第一次调整后setup slack还有0.2nshold slack只剩0.05ns几乎贴着线。这种情况说明延时的“总量”差不多对了但窗口宽度还偏紧。我继续把input delay的min值从0.5ns微调到0.3nsmax保持不变hold slack最后升到0.18ns。这一点点调整就是用长跑稳定性换来的参数余量。3.4 第三步用ILA加长时间压力测试验证约束调整完成后先跑一轮短测试在Zynq里用ILA持续抓取RXD、RX_CTL还有MAC输出的CRC错帧计数器。抓了5万帧CRC错误计数保持0。接着把ILA关掉用iperf做30分钟TCP流速度稳定在930Mbps左右再ping 1000个1000字节的大包0丢包。这个时候才可以判断这次配置基本对了。这里有个经验ILA虽然能直观看到线上波形但它本身会占用大量BRAM和布线资源可能改变布局布线结果。验证阶段用ILA看现象没问题但最后稳定性测试时最好把ILA删掉或者只保留一个极小的计数器避免“ILA存在时正常、综合成最终版本后反而出问题”这种诡异情况。4. 实测数据与踩坑实录高温、低温、双重延时叠加4.1 三种工况下的Setup/Hold余量对比下面这组数据来自同一块板子、同一版逻辑只改变延时配置方式在三种温度环境下各跑2小时压力测试得到。测试用的是Vivado时序报告里的slack数据以及MAC层CRC错误计数器。工况延时配置方案Setup SlackHold Slack压力测试结果25℃/1.0V仅PHY内部RX Delay0.34ns0.26ns2小时0错包85℃/0.95V仅PHY内部RX Delay0.08ns0.21ns偶发CRC错误约1小时1次85℃/0.95VPHY内部延时FPGA修正约束0.19ns0.33ns2小时0错包-40℃/1.05VPHY和FPGA两侧同时加2ns-0.12ns0.10ns频繁错包link偶发断开第一行对照实验证明25℃下PHY内部延时够用。第二行是芯片温度升高、内部延时量变小、走线阻抗也随温度变化带来的组合结果hold slack虽然还行但setup slack已经压到0.08ns稍有噪声就会触发亚稳态。第三行说明FPGA侧介入修正后把余量重新拉开。第四行则是典型的“两边同时加延时”翻车现场PHY的2ns加上FPGA的2ns总共偏移了约4ns又回到了数据跳变沿采样而且低温下器件延时变大hold路径直接违规。4.2 踩坑实录延时方向给反导致的半字节错位调试过程中我踩过最典型的一个坑是把延时方向给反了。当时想着“数据晚了就把采样沿往后推”结果XDC里set_input_delay的max/min写反了导致工具认为数据窗口在采样沿左边而实际数据在采样沿右边。整条链路高速跑起来后MAC收到的接收数据从0x12345678变成了0x34127856高半字节和低半字节完全调换。这种“半字节错位”现象最迷惑人因为它看起来像字节序问题很多工程师会去改DMA描述符或者改MAC的字节序配置改来改去都不生效。我后来靠ILA把RXD、RX_CTL、RXC三个信号拉到同一个窗口里对比才意识到错位不是软件顺序错了而是IDDR高低半字节的相位选反了。排查这类问题有个顺手的小技巧如果ILA抓到的RX_CTL高半字节和低半字节正好和RXD错开一个bit位优先查约束里的input delay方向不要先动逻辑代码。RGMII的数据相位只有“提前2ns”和“滞后2ns”两种可能把max/min交换一下重新布线比翻代码快得多。4.3 小技巧如何用一根网线和Wireshark快速判断延时方向错误没有ILA条件的时候也可以用软件方法辅助判断。把FPGA侧MAC收到的数据通过AXI接口送到处理器里然后以raw socket发到PC端Wireshark抓包。如果RGMII延时方向不对Wireshark里看到的以太网帧目的MAC地址会整体错位比如本应是00:11:22:33:44:55抓出来变成11:00:33:22:55:44或者00:22:11:44:33:66这种半字节交叉错乱。这个现象相当有辨识度。如果是单bit错位通常是信号质量问题或者电平问题如果是两个半字节规律性互换基本就是RGMII时序相位不对。我后来甚至把这种方法当成了现场快速诊断工具不用开Vivado一根网线加Wireshark就能判断是不是相位问题再决定要不要回实验室改约束。5. 快速自查清单RGMII时序配置查这几项就够了项目收尾阶段我把这次调试过程中踩过的坑整理成了一张自查表后续再做RGMII相关板卡时直接逐项核对能省掉大量排查时间。这里分享出来覆盖了从寄存器到约束到实物验证的关键检查项。检查项操作方法合格标准PHY延时配置MDIO读寄存器确认TX/RX Delay位与方案一致只在一侧开启2ns延时时钟约束检查XDC里RXC/TXC的create_generated_clock时钟已定义且与物理引脚对应input/output delayreport_timing_summary查rxd_in/txd_out路径setup/hold slack均大于0.15nsIDDR/ODDR相位ILA抓RXD和RX_CTL的上下半字节数据与CTL对应关系与协议一致高低温稳定性高低温箱各跑2小时iperfping0错包、0丢包、link不闪断两侧延时叠加确认PHY内置延时和FPGA约束不同时启用总偏移接近2ns远离0ns和4ns最后再分享一点个人体会。RGMII的2ns延时本质上是协议为了省引脚而把数据窗口压缩后留下的“历史债”。它不是一个需要精密计算到皮秒的参数而是一个需要保证“采样点落在数据窗口中间”的工程约束。与其死记2ns这个数不如理解它背后那套“半bit周期中心对齐”的逻辑这样无论换PHY型号还是换FPGA平台都能快速定位问题。实测下来只要抓住“只在一侧加延时留足温度余量用ILA验证相位用长跑确认稳定”这四条原则RGMII基本不会再折腾人。