1. 一次让我印象深刻的link up失败从现象到AN怀疑去年做一块40G交换板的调试板卡上用的是某款支持10G/40G的PHY光模块插的是40GBASE-LR4。硬件回来后第一次上电链路死活起不来。主控日志里MAC侧一直在刷link down光模块的LOS灯倒是灭的说明光信号本身没问题。当时的第一反应是检查SerDes配置TX/RX lane极性、速率寄存器、参考时钟频率这些常规项都确认无误后问题依旧。后面翻了PHY的状态寄存器才看到ANAuto-Negotiation状态位一直停在未完成随后又在协商超时计数寄存器里看到了不断累加的超时值。到这里问题才真正被聚焦到auto-negotiation这条线上。这个场景在10G/40G PHY调试里非常典型。高速PHY的AN不像百兆或者千兆那么无感它参与的事情更多、状态机更复杂而且一旦AN不通过MAC、交换芯片、光模块这些外围器件看起来可能全都是正常的——但链路就是不通。所以这篇文章我打算从实际调试的视角把10G/40G PHY的auto-negotiation功能从原理到排障完整梳理一遍希望遇到类似问题的朋友能少走弯路。2. 10G/40G的AN到底在协商什么它和千兆AN根本不是一回事很多做过千兆以太网调试的人对AN的印象停留在协商双工模式和速率。到了10G/40G这一代如果你的认知还停留在这个层面调试时大概率会被绕晕。AN在这代PHY里的角色已经变化了而且不同接口形态下AN的处理逻辑也完全不同。2.1 两种截然不同的AN工作场景10G/40G PHY大体分两类应用场景一类是铜缆PHY比如10GBASE-T、40GBASE-T另一类是背板/直连铜缆场景40GBASE-CR4、100GBASE-CR10、各种backplane接口。铜缆PHY的AN沿用了IEEE 802.3 Clause 28的框架是Clause 28在万兆速率上的扩展。它除了协商速率和主从时钟关系外还要协商FEC模式、以及后续是否进入link training阶段。这里有个容易忽略的点10GBASE-T即便AN完成了物理链路其实还没有完全建立后面还要走一段link training过程来调整发送端的信号预加重参数。背板/CR场景用的则是IEEE 802.3 Clause 73定义的AN配合Clause 72的link training机制。Clause 73有一个非常重要的功能它协商的不只是速率还协商每个lane的training帧使能、FEC能力等。40GBASE-CR4这种4 lane并行传输的场景AN还负责协调对端4条lane的启动时序保证所有lane在同一个时间窗口内进入training并完成收敛。2.2 AN协商的具体内容和时间轴一次完整的10G/40G AN协商流程上大概能分成这么几步本地PHY发送包含本端能力集的AN base page。对端PHY也会同时发送它自己的base page双方通过DME编码在差分对上交换信息。双方接收并解析对端的能力然后进入协商判定。如果双方能力有交集则把交集的最高优先级能力作为最终结果。AN完成后根据协商结果决定是否开启FEC、进入link training或直接进入数据模式。base page里实际承载的字段10GBASE-T和40GBASE-CR4稍有差异但核心字段不外乎这几类速率/技术能力宣告FEC能力宣告是否支持FC-FEC、RS-FEC以及具体模式主从时钟宣告与期望值对于CR/backplane场景还包括lane数、training使能等协商项目10GBASE-T40GBASE-CR4/backplane速率10G固定无需多速率协商40G固定但会协商lane数FEC协商是否使用、哪种FEC协商FC-FEC或RS-FEC主从时钟必须协商影响PLL锁定基本不需要恢复时钟来自接收端Link training协商后强制进入通过AN协商是否使能物理介质双绞线RJ45铜缆/背板差分走线这个表格是调试时很有用的一个参考。当你看到AN失败时首先要想清楚你这套系统里AN到底在协商哪几项而不是笼统地查AN状态位。2.3 为什么不能照搬千兆时代的AN调试经验千兆AN调试多数人习惯的做法是看双工/速率两个寄存器的值再不行就关掉AN直接强制到1000M全双工。这个思路在千兆时代确实有效因为千兆PHY的AN和SerDes参数基本是解耦的AN不通过往往也就是个配置问题绕过去不影响信号质量。但10G/40G不一样。就拿40GBASE-CR4来说AN后面紧跟着link training过程。Training的过程就是发送端根据对端反馈调整发射均衡参数直到对端接收端把误码率降到可接受范围。如果直接跳过AN就等于跳过了整个training机制的启动逻辑即使把PHY硬掰到40G模式信号质量也几乎不可能达标。这就是为什么在高速度接口上AN不是可以绕过的配置过程而是物理链路建立链条里不可缺失的一环。3. 调试前的环境准备Clause 45寄存器地图和手里必须有的工具10G/40G PHY调试和低速PHY有个很大的差异寄存器访问机制从Clause 22升级到了Clause 45。很多第一次接触这类PHY的朋友上来就按千兆的习惯读寄存器0x00、0x01结果读回的数据跟光头强头顶一样光秃秃的——什么都没有。3.1 Clause 45 MMD机制是调试的基础门槛Clause 45的寄存器空间按MMDManageable Device划分成了多个独立寄存器组。每个MMD代表PHY内部一个功能模块比如PMA/PMD物理介质接入层、PCS物理编码子层、PHY XS、DTE XS、TC传输汇聚层、AN自动协商模块等。访问一个寄存器需要读写两段地址先指定MMD地址和寄存器偏移再执行数据读写。写MMD地址的方法因MDIO控制器实现而异有的需要往独立的address寄存器写两次一次高16位一次低16位有的支持一条命令直接下发。调试时最好先用read loopback或者读已知寄存器的默认值确认MDIO通路是通畅的再去读具体状态位。AN相关的关键寄存器实际调测中常用这几个寄存器位置名称bit位含义MMD 7, reg 0x0AN控制bit 12AN使能MMD 7, reg 0x0AN控制bit 5AN重启MMD 7, reg 0x1AN状态bit 5AN完成MMD 7, reg 0x1AN状态bit 4收到对端pageMMD 7, reg 0x1AN状态bit 11对端支持ANMMD 7, reg 0x10AN本端能力宣告—本地宣告的能力集MMD 7, reg 0x11对端能力解析—解出来的对端signalingMMD 7, reg 0x13AN协商结果—最终协商出的模式提示不同厂商PHY的MMD地址分配和寄存器偏移可能有出入但AN状态、AN控制这两个MMD的位置基本沿用标准定义。第一次调试前还是建议先花十分钟把目标PHY的数据手册翻到寄存器章节对照确认一遍。3.2 搭建一套趁手的调试栈我调试PHY时常用的组合是主控CPU的MDIO控制器做寄存器读写板级串口打印日志配合一个独立的调试助手来手工读写寄存器。串口调试助手在这里的作用非常关键。通过串口把寄存器读写命令封装成命令行随时可以单步查看AN相关状态。实际调测中我会在uboot或者裸机里挂一个极简的MDIO读写命令比如读命令格式是mdio read [phy_addr] [dev_addr] [reg_addr]写命令是mdio write [phy_addr] [dev_addr] [reg_addr] [value]。这样每次测试一个条件就能快速抓取一组状态寄存器的快照。3.3 示波器和误码仪在这类调试里承担什么角色寄存器只能告诉你在协议层面AN走到了哪一步物理信号层面的事情寄存器基本管不了。示波器主要用来看差分发出端是否有正常摆幅以及local crossover检测后lane的极性是否正确。注意看的是PMA/PMD输出是否在AN阶段发出的DME信号的频域特征正常而不是只看有没有波形。误码仪在AN调试里的用途主要在后面阶段AN协商完成、进入link training之后需要统计training是否收敛、FEC是否出现错误码字这些都离不开误码仪或者PHY内部的BIST功能。如果手头没有独立误码仪可以用PHY的内部loopback自测配合计数器寄存器来评估。4. AN故障的完整定位链路从状态位到最终根因拿到一块AN起不来的板子我的排查顺序通常是从协议层往下压先确认AN状态机在哪个环节停住再决定下一步去看哪个物理量。4.1 先确认MDIO通路和PHY设备ID是否正常这一步看起来多余但实际踩过太多次坑了。因为板级硬件问题或者MDIO引脚配置问题经常出现什么都读到不到的情况如果一开始不确认通路后面所有判断都是空中楼阁。操作上很简单读PHY的MMD 1PMA/PMD下device identifier寄存器0x2和0x3跟数据手册上的值对比。对不上就直接排查MDC/MDIO引脚的上下拉、电平转换电路、PHY地址配置电阻。对得上再进入AN的排查流程。4.2 按顺序解读AN状态机的每一步AN状态可以从MMD 7的AN状态寄存器读出来。我自己习惯看以下位的组合bit 5AN complete这个位拉高代表标准AN流程已经完成。bit 4page received表示收到过对端的base page。bit 11link partner AN able对端是否具备AN能力。bit 3parallel detection fault并行检测异常10G/40G铜缆里也可能出现。如果AN complete一直为0看page received是否为1。如果page received是0说明双方根本没交换成功base page问题可能出在物理连接层——线缆问题、对端未上电、差分对极性反了、甚至对上的是两个不同速率的光模块。如果page received为1但AN complete为0说明page交换成功但协商判定停在某个环节。这时候重点看本端和能力宣告寄存器的匹配情况尤其是FEC模式和主从时钟的冲突。4.3 区分AN没完成还是AN完成但training失败这是一个极其容易混淆的环节。有些PHY厂商的寄存器定义里AN complete这个位表示AN流程自身完成了但MAC层的link状态要等training收敛后才会上报。我遇到过一次情况AN状态已经显示完成对端能力也解析正常但链路死活link不上。后来查training状态寄存器发现link training状态机一直卡在系数收敛阶段原来是发射端的预加重参数配置错了。区分的方法很简单读PCS或者PMA的training状态相关寄存器以及PHY的link status位。如果AN完成但training状态未完成问题基本上在模拟前端参数、线缆质量、或者对端training使能位没有开。4.4 排除对端能力集不匹配的疑难杂症对端能力集不匹配在纯10G/40G模式下不多见但在做兼容性测试、对接不同品牌PHY芯片的场景下很常见。一个典型例子本端PHY宣告支持RS-FEC对端PHY只宣告支持FC-FEC两边虽然有交集都可以工作在FEC off模式但如果necensing逻辑写得激进有些PHY会直接把协商结果判为fail。遇到这种问题靠的是逐bit比对能力宣告寄存器和解析寄存器。把双方宣告的base page内容分别打出来手动做一次协议规定优先级判定看两边能不能交出交集很容易看出是哪一端的firmware在能力匹配上过于苛刻。4.5 主从时钟冲突铜缆10G/40G的特有坑10GBASE-T/40GBASE-T的AN有个在光模块场景里不存在的问题主从时钟。两端PHY都希望成为主设备的时候AN就会一直处于restart循环。从AN状态寄存器里能看到的是AN complete反复被清零、page received反复拉高。判断是否主从冲突可以读AN状态寄存器中的master/slave相关位。注意很多PHY允许配置成prefer master或prefer slave如果两端都配成prefer master基本可以断定要出事。实际定位时用调试助手分别把两端的配置读出来不匹配就改一端的优先级。现象可能原因排查优先级AN complete永远为0page received为0物理连接、线缆、对端掉电最高page received为1AN卡死FEC能力不匹配、主从冲突中AN完成但link不上link training未收敛、发射参数异常高AN完成link也上但误码率高FEC协商结果不符合预期中5. 那些文档里不会写的坑实测环境中的琐碎问题到了这一节我想分享一些在实际调试过程中反复遇到、但厂商文档和数据手册里往往不会提醒你的细节。这些坑单独拿出来都不是大事但每一个都能耗掉你半天时间。5.1 坑一寄存器访问的MMD没切干净不少PHY芯片的MDIO控制器设计是当前激活MMD模式你只要切到MMD 7后面读所有的寄存器都默认在MMD 7下直到你切到别的MMD。但有些复杂的PHY内部不同MMD的寄存器访问还需要额外时钟周期的等待尤其是DME训练和AN正在跑的时候寄存器访问时序会被内部状态机抢占。直接读回来的数据可能是一个中间态。解决方式对关键状态不要看单次读回的值而是连续读三次取稳定结果。AN类状态位如果出现抖动大概率是访问碰撞或者状态机正在切换。这一点在一些国产PHY上表现更明显跟firmware的实现有关。5.2 坑二怀疑AN前先怀疑光模块有次调试40GBASE-LR4半天找不到AN失败的原因寄存器状态显示完全没有收到对端page。我换了根光纤、重插了光模块还是不行。最后把光模块拿到另一块板上测试发现是模块的I2C通信异常导致PHY读不到模块的present信号AN被硬件拉低禁用。这个经历带来的教训是AN虽然是个协议过程但它在PHY内部往往被很多外部条件gate住。光模块的present引脚、reset引脚、甚至电源好信号如果异常都会让AN状态机根本不启动。调试时先用简单手段确认光模块能被PHY正常识别再深入AN的状态位分析。5.3 坑三软件复位后不重新配置ANPHY芯片的复位方式五花八门。硬复位引脚下拉再释放通常PHY会回到默认状态并自动开始AN。但软件复位通过寄存器bit触发软复位之后有些PHY会保留配置寄存器值有些则会全部清零回到默认值。如果固件里的AN配置是在上电初始化代码里设置的软复位后忘了重新下发就会出现一种很隐蔽的现象硬复位时链路正常软复位后链路起不来。这类问题排查起来特别容易自我怀疑。到后面我都会在测试脚本里固定加一条软复位后等待100ms重新配置AN并重启AN的命令避免这个问题反复出现。5.4 坑四AN关闭未必是错误操作在做40G背板调测时有一种常见场景板内PHY到交换芯片之间是固定速率、固定FEC配置的短距离链路不需要也不希望跑AN。这种情况下把AN关掉、强制配置成指定模式是完全合理的设计。但要注意关掉AN后必须确保两端配置完全一致包括FEC模式、training是否使能。如果一端开AN一端关AN通常表现为对端检测到AN能力失败后链路完全静默。调试时如果发现一端配置了AN disable建议读对端PHY的AN能力协商结果确认它是不是也在disable状态。对于直连背板这类场景有一种调试技巧一开始先用AN模式把链路调通确认物理信号质量没问题之后再逐步挪到force mode这样能有效隔离配置问题和信号问题。5.5 坑五误码率异常要回到FEC协商结果上找原因最后分享一个和AN相关的深水区问题。有次链路已经成功建立AN complete也正常但吞吐测试一直报错。看FEC统计corrected codeword数量非常大uncorrected codeword偶发。后来一查是AN协商出来的FEC模式比硬件实际能支持的模式低了一档对端虽然配合工作在低档FEC模式但实际信号余量不足导致纠错码字持续增加。这个问题的根子还是在AN的能力宣告上。本端PHY如果宣告的能力范围大于实际能达到的性能范围协商出来一个能力上成立但性能上勉强的结果链路就处于一种能通但很脆的状态。定位这类问题一定要把AN协商出的FEC模式、实际误码率、信号余量三者关联起来看而不是单看哪个都正常就认为没问题。调试10G/40G PHY的AN说到底是把协议状态机、寄存器状态和物理信号三者对照起来看。协议层走到哪一步寄存器就会呈现哪个状态物理层出了问题协议层就会卡在某个环节。三者能互相对应上问题基本就藏不住了。我个人习惯是每操作一步就把当前所有相关寄存器的快照打出来存档这能在大范围试错后快速定位到到底是哪一步引入的问题。希望这篇文章能帮你在调试这类高速PHY时少走几段弯路。