PHY以太网寄存器解析(4)

器（Receive Equalization Control）（如BCM56700芯片），这两个配置有什么区别？分别起到了什么作用？

2.4自动协商降格

由于1000BASE-T连接对UTP线缆的要求是比较苛刻的，而100M连接对线缆的要求就相对宽松，因此目前很多千兆电口的PHY芯片（BCM和Marvell都有，典型代表BCM5488S和88E1240，不过BCM5488S这个功能名叫Ethernet@WireSpeed mode。）提供了一个自动协商降格（Downshift）机制，就是在AN阶段如果协商双方都支持1000BASE-T，但是协商完成后却不能建立1000BASE-T Link，PHY经过一定次数的尝试之后将自动降格到100M协商来建立Link。这本来是个挺好用的功能，但是由于不是IEEE802.3的标准，因此芯片在实现上多少有些不够严谨。而且在实际应用中如果一个千兆口无端被协商成了100M，也容易对客户造成误解。因此该功能最好不要打开（对应的寄存器Downshift Enable位置0）。

案例：还是S5750-48GT/4SFP，BCM5488S，调试中发现，用20厘米短线将端口互联可以正常Link，不过调试中偶然发现将网线频繁的插拔几次，最后接上以后发现端口居然Link状态为100M，当时百思不得其解。于是去测试端口的FLP信号，发现正常时候和故障时候的FLP有差异如波形图所示。很显然PHY的自动协商发送信息自己没有通告1000BASE-T的能力，自然不能Link到千兆。

正常时的FLP， 16位信息为1000，0111，1010，0001。小端在前即为0x85E1。NEXT PAGE=1

16

异常时的FLP， 16位信息为1000，0111，1010，0000。小端在前即为0x05E1。NEXT PAGE=0

再去仔细学习了一遍BCM5488S的相关资料，发现了一个Ethernet@WireSpeed功能，这个功能的描述为：When bit 4 = 1, Ethernet@WireSpeed mode is enabled. If the link cannot be established within two to nine attempts (the number of attempts is set by bits[4:2] in register 1Ch, shadow value 00100), the BCM5488S downgrades its advertised abilities and again tries to establish a link. When bit 4 is cleared, the BCM5488S advertises its abilities according to registers 04h and 09h.。也就是说，当两个端口协商的努力失败后（协商次数取决于5488S的0x1C寄存器的bit[4:2]，可在2~9次之间调整），5488S会对其工作能力进行降级，即从千兆降到百兆。查到这里问题就比较清楚了，配置一下寄存器，关闭Ethernet@WireSpeed功能问题就解决了。

思考：在这个案例，发现自动协商信息和正常状态不一致是通过测试FLP看出来的，能不能通过分析寄存器来得到这些信息，需要看哪个寄存器，哪一端的寄存器？

2.5 Auto-Crossover配置

所周知，两个以太网端口要正确地建立Link，必须将一个端口的发送信号连接到另一个端口的接收端上（1000BASE-T为同线双向，但是也要考虑线对顺序），否则的话会Link失败。以太网端口的UTP对外接口有两种模式，分别叫MDI和MDIX，对应的，连接用网线也有直连线和交叉线之分。由于一个端口到底是MDI还是MDIX从外观上是看不出来的，为了免除人们调线连接的麻烦，IEEE802.3后来定义了一个Auto-Crossover功能（还有个别名叫Auto-MDIX），PHY可以自动改变其pin脚为MDI或MDIX模式来建立正确的Link。可是这个功能是要依赖FLP信号来实现的，因此在端口关闭AN的情况下Auto-Crossover功能也随之不起作用了。这是一个经常被忽略的问题，大家往往都认为可以Auto-Crossover的PHY可以随意的进行连接，在端口Link不上的时候潜意识中

17

就没有想过线连的对不对！

随着技术的进步，现在很多PHY开发出了不依赖FLP的Auto-crossover功能，可以在关闭AN的情况下依然有效，但是可惜的是这个功能一般有个控制寄存器，更可恶的是默认情况下是不打开的，因此在调试以及应用中要万分注意，看看PHY关于Auto-crossover when AN is disable（当然也有可能是以其他词汇来描述的）的配置是不是配对了。要不然就相当于给自己留了一个陷阱。

案例：内蒙农行，我司M8600-48GT线卡和cisco 7507以太网口卡PA-1FE-TX互联，只能协商出百兆半双工速率，若强制成百兆全双工则不能link。而使用Cisco 2950强制百兆全双工可以link。从现象看，cisco 7507以太网口卡PA-1FE-TX应该是不具备自动协商能力，强制100M Full配置Link不上，有两种可能，一则M8600-48GT的强制配置没有关闭自协商，另一种可能就是MDI连接错误。和软件确认，M8600-48GT强制配置中肯定已经关闭自协商，核对BCM5488S的寄存器配置，发现Force Auto-MDIX Mode这个配置位被设置成0 = Auto-MDIX is disabled when auto-negotiation is disabled，导致不能Link。

思考：

1、这个案例中我们为什么可以推论cisco 7507以太网口卡PA-1FE-TX不具备AN能力？

2、如果不知道寄存器配置，如何方便的验证两个端口不能Link是不是因为没有Auto-crossover功能导致的？

2.6 MDI信号边沿速率调整

PHY的MDI接口信号是直接连接线缆和其他设备互联的信号，信号的好坏直接影响连接的正确性和兼容性，因此此MDI信号需要根据IEEE802.3的指标进行测试。在实际应用中，受实际设计应用环境以及外围器件的影响，MDI信号有可能信号的上升下降时间变差，有些PHY提供了调整信号边沿速率的寄存七，可以根据需要和测试结果对MDI信号的边沿速率（Edge Rate）进行调整，以达到满足测试指标的要求。

案例：S2928G进行100BASE-T的测试，发现信号的上升下降时间超出测试指标要求，最大值达到了5.138ns（指标为3~5ns）。一般来说遇上这种情况我们都会一筹莫展，因为信号是芯片输出来的，而外围的阻容设计MDI接口也是相当经典成熟的设计，没有多少可以调整的余地。可是仔细的去学习PHY芯片BCM5498的相关芯片，发现其Errata中有关于100BASE-T信号测试超标的描述，按照资料的解决方法，修改芯片的寄存器配置信号就达标了。通过这一案例我想我们至少可以得到两点教训，其一是做设计一定要仔细学习芯片的勘误表，否则很多厂家已经发现并提供解决方案的问题我们可能由于无知而投入很大的时间和精力去查，吃力不讨好；其二就是，对于芯片输出的信号，我们并不是无可奈何的！芯片的输出信号受到很多因素的影响，芯片的工作电源、时钟还有内部的寄存器配置都可以改变芯片输出信号的指标，在这一点上我们应该放开思路，而不要因为是芯片内部的事情就望而生畏。

2.7 错误指示寄存器

在前面章节中我们有讨论过，PHY的标准寄存器集有一些错误状态指示信息，比如MASTER-SLAVE Status Register（寄存器10）中有Local Receiver Status，

18

Remote Receiver Status，Idle Error Count等错误信息，充分利用这些信息对我们在调试以及故障处理中定位问题原因将有很大的帮助。除了标准寄存器集定义的这些错误指示信息之外，PHY厂商往往还定义了一些其他的错误指示信息，方便实用者对链路状态进行监测和分析，下面对一些常见的错误信息及其应用进行分析。

CRC Error Count：PHY的CRC错帧统计计数器。本来CRC校验是MAC的功能，但是现在很多PHY也实现了CRC校验的功能，不过这个计数器一般只有8bit，也就是只能统计最多256个错帧。在查证CRC错帧问题的时候，除了察看MAC的MIB以外，还可以辅以PHY的CRC错帧统计计数器，通过综合这些信息来初步判断，出错的位置在PHY以上或者PHY以下。而且，结合Idle Error Count也可以进行判断，一般如果是MDI信号问题导致的CRC会伴随有Idle错误，如果是对方MAC发过来的帧内容有误，则应该不会出现Idle错误。这些信息在故障诊断中可以发挥相当重要的作用。

案例：S2951XG常温烤机测试发现，将端口两两短接起来，从外面引入一个包发现跑不起来，起初以为是软件配置有广播风暴抑制的原因，检查软件配置却没有发现异常，后来读取端口MIB发现有大量的CRC错包。于是判断跑不起来的原因是引入的帧转发后全错掉丢完了，可是为什么出CRC呢？除了MIB信息，读取88E1145的Idle Error Count和CRC error count发现PHY也检测到了CRC错误，同时伴随有大量的Idle Error记录，因此判断故障原因应该和PHY底层信号有关。于是详细核对88E1145底层有关的配置，发现软件对MDI接口的输出信号幅度（VOD）进行了调整，将VOD提高了14%，这个配置是之前为了解决88E1145 D0版本芯片长线性能不过而做的调整，可能已经不适用于S2951XG上的88E1145E1版芯片。将VOD配置修改到默认配置，故障解决。

Transmit Error：发送错误指示。Transmit Error是IEEE802.3描述的一个错误状态，MAC芯片在发送的时候如果出现了某种错误，则通过MII（GMII）的TX_ER信号通知PHY，这时候PHY将在MDI上发送一个特殊的码组代表Transmit Error状态。因此PHY的Transmit Error指示寄存器一般来说并不是指本端错误，而是指PHY接收到了Linkpartner的Transmit Error信息，这时候说明，出错的位置应该是在Linkpartner的MAC上。

案例：我司RSR50主板固化的千兆口和M7600-24GT模块互连的时候，M76的端口会收到一些CRC错包，在客户现场更换H3C的交换机和RSR50互连也一样发现H3C的交换机端口有收到CRC错包。该现象在我们本地实验室重现不出来，给查证工作带来很大的难度。

在初期一度怀疑是RSR50兼容性问题，因此在我们这边按照规范重新进行了一轮全面的兼容性测试，没有发现任何异常问题。然后对RSR50CPU连接PHY的GMII接口进行测试，各信号指标均达标，基本上排除时序临界导致出错的怀疑。在分析M76的端口计数没有什么发现的情况下，从现场读取M76的PHY寄存器回来分析，发现其中一个疑点是PHY的状态寄存器中有指示端口检测到Transmit Error。注意，这里的Transmit Error并不是意味着端口自己发送发现错误，而是LinkPartner通过特殊的编码（如4B5B编码中的/H/码组）发送过来的地表示其发送操作出错的指示。这个操作应该是MAC发现错误以后主动通报的，因此故障怀疑的重点应该从PHY、接口、链路等这些模块转移到MAC层，重点查RSR50的CPU（集成端口MAC模块）设计和配置，最终通过修改CPU的FIFO配置解决了问题。

在这个故障的解决过程中，还走了一些弯路。其实由于对Transmit Error的含义理解不够透彻，当时我们看到这个错误只是以后并没有明确的就开始把重点集中在CPU BCM1250上，当时的想法是为了弄清到底什么样的包出了CRC，于是寄了一台S2924G过去作为抓包

19

之用（S2924G有个功能可以配置端口不进行CRC校验从而将CRC包原样转发出来而不过滤），但是却发现将S2924G连接到RSR50之后没有再出CRC错包了，经分析怀疑S2924G的MAC对Transmit Error的处理可能和M76-24GT不一样，于是将RSR50上GMII接口的TX_ER信号断开，再和S2924G连接，再观察也出现CRC错包了。到此才确定，出错的原因肯定是BCM1250内部出了问题。

除了以上列举出来的错误指示，PHY其实还有很多错误指示寄存器可以为我们的故障定位分析提供帮助，比如AN Error，Parallel Detect Error等这些错误信息含义都一目了然，但是在端口故障的时候确实非常重要的证据信息。还有新的芯片可能还提供了其他的错误指示，其含义的作用需要结合芯片的相关资料和标准规范学习研究，在实际工作中加以应用。

20

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库PHY以太网寄存器解析(4)在线全文阅读。