深入解析EMAC/MDIO与SGMII寄存器：网络诊断与性能调优实战

1. 项目概述：为什么我们需要深入理解EMAC/MDIO与SGMII寄存器

在嵌入式网络设备开发，尤其是涉及高性能处理器或网络交换芯片的项目中，我们常常会遇到一些“玄学”问题：设备上电后网络灯不亮、协商速率不对、或者在实际高负载下出现偶发性的丢包和性能抖动。面对这些问题，如果只停留在应用层，比如反复检查驱动配置或者网络协议栈参数，往往事倍功半，甚至无从下手。真正的“破局点”通常藏在硬件寄存器里。今天，我想结合TI KeyStone架构的文档，深入聊聊EMAC/MDIO、SGMII状态寄存器以及STATS统计寄存器这套组合拳。它们不是冰冷的内存地址，而是嵌在芯片里的“黑匣子”和“仪表盘”，能让你直接透视物理链路的健康状况和数据流的微观动态。理解并善用它们，是从“网络能用”迈向“网络稳定且高性能”的关键一步。

很多工程师对MDIO（管理数据输入输出）接口的印象可能只停留在“用来配置PHY芯片寄存器”。这没错，但它更是EMAC（以太网媒体访问控制器）与外部PHY或SerDes（串行器/解串器）之间至关重要的管理通道。而SGMII（串行千兆媒体独立接口）作为一种高速串行接口，其链路建立、自协商过程完全由硬件状态机控制，状态就实时反映在SGMII相关的寄存器中。至于STATS寄存器组，它则是EMAC内核默默工作的“记账本”，从每一个成功收发的帧，到每一次CRC错误、冲突、超长帧，都被分门别类地记录下来。当你发现网络吞吐量不达标时，是应用层发送慢了，还是底层已经丢包了？是物理链路有干扰，还是MAC层发生了过多的冲突？答案都在这本“账”里。接下来，我将把这些寄存器拆开揉碎，结合实际的调试场景，告诉你如何把它们变成你手中最强大的网络诊断工具。

2. SGMII寄存器深度解析：从链路建立到自协商

SGMII接口的稳定是千兆以太网通信的基石。与传统的MII/GMII并行接口不同，SGMII采用一对差分线进行高速串行通信，其链路建立、速率/双工模式协商过程更为复杂，且主要由硬件逻辑完成。软件驱动需要通过读取特定的状态寄存器来获知这一过程的结果，并据此判断链路是否正常。

2.1 STATUS寄存器：链路健康的“心跳监测仪”

STATUS寄存器（偏移地址需查阅具体芯片手册）是判断SGMII链路层状态最直接的窗口。它的每一个比特位都对应着一个关键的状态信号。我们逐位来看其背后的意义和调试价值。

Bit 4 - LOCK：这是最重要的位之一。它指示SGMII SerDes（串行器/解串器）的PLL（锁相环）是否已经锁定。你可以把它理解为SerDes硬件是否已经成功从接收到的串行数据流中恢复出了稳定的时钟信号。没有时钟，一切数据都无法正确解析。在调试中，如果LINK灯不亮，第一步就应该查这个位。如果LOCK=0，那么后续的LINK、AN_COMPLETE等状态都是无效的。问题可能出在硬件连接（差分线对调反、阻抗不匹配）、参考时钟不准、或SerDes模块的电源/配置上。

Bit 2 - MR_AN_COMPLETE（自协商完成）：当LOCK=1后，这个位才有效。它表示SGMII的自协商过程已经完成。SGMII的自协商不同于传统以太网在双绞线上的Auto-Negotiation，它主要通过交换MR_ADV_ABILITY和MR_LP_ADV_ABILITY寄存器中的配置信息来完成。在驱动初始化流程中，一个常见的检查点是：等待LOCK置位后，再等待MR_AN_COMPLETE置位，超时则报错。如果这个位一直为0，可能是对端设备不支持SGMII或自协商，或者双方的广告能力寄存器（后面会讲）配置无法匹配。

Bit 1 - AN_ERROR（自协商错误）：这是一个错误标志位。根据文档描述，当协商过程中命令了半双工千兆模式时，会触发此错误。这是因为SGMII规范通常只支持全双工模式。在实践里，如果你在调试自定义FPGA或非标准PHY的SGMII对接时遇到链路不稳定，检查这个位很有必要。它可能提示了对端设备发送了不符合规范的协商参数。

Bit 0 - LINK（链路状态）：这是我们最熟悉的“链路激活”指示在寄存器层面的映射。同样，它仅在LOCK=1后有效。LINK=1表示物理层链路已经建立，MAC层可以开始收发数据。这里有个关键点：在软件上看到LINK UP，只代表物理信号通路通了，不代表上层网络一定能通。如果LINK=0但LOCK=1，可能是自协商失败，或者对端设备未上电/未连接。

Bit 5 - FIB_SIG_DETECT（光纤信号检测）：这个位直接映射到SGMII模块的一个输入引脚状态。当使用光纤模块（SFP）时，模块会通过这个引脚向MAC报告是否检测到光信号。这对于光纤链路诊断非常有用。如果LINK始终无法建立，但LOCK已经OK，可以查一下这个位。如果FIB_SIG_DETECT=0，那问题很可能出在光纤链路本身（光纤断裂、光模块损坏、光功率不足），而不是芯片或配置问题。

实操心得：状态读取的时机与顺序在驱动代码中读取这些状态位时，切忌“一次性读取并判断”。因为硬件状态的变化需要时间。一个稳健的做法是：

1. 上电或复位后，先等待一个稳定延时（例如100ms），让SerDes PLL有足够时间尝试锁定。
2. 循环读取STATUS寄存器，检查LOCK位。可以设置一个超时（如1秒），超时未锁定则进入错误处理流程。
3. LOCK置位后，再循环检查MR_AN_COMPLETE位。同样需要设置超时。
4. 只有MR_AN_COMPLETE=1且AN_ERROR=0时，才认为自协商成功，此时LINK位才可信。 这种分步、带超时的检查逻辑，能让你在调试时快速定位问题阶段，是硬件问题（LOCK失败）还是协商问题（AN不完成）。

2.2 自协商能力寄存器：对话的“名片交换”

SGMII的自协商过程，本质上是本端和对端设备通过寄存器交换各自的“能力名片”。这个过程主要由两个寄存器完成。

MR_ADV_ABILITY（本端广告能力寄存器）：这是一个可读可写的寄存器。在自协商开始前，软件需要向这里写入本端设备支持的能力。其低16位对应SGMII规范中的tx_config_reg[15:0]。关键字段包括：

• Bit 15 (Link):通常置1，表示本端希望建立链路。
• Bit 14 (Ack):自协商确认位，硬件在协商过程中会操作此位。
• Bit 12 (Duplex):双工模式。对于SGMII，此位必须写1（全双工），因为SGMII不支持半双工模式。
• Bit[11:10] (Speed):速率。10b表示1000 Mbps，01b表示100 Mbps，00b表示10 Mbps。你可以在这里广告多种速率（如果硬件支持），但对端最终会选择双方共有的最高速率。

MR_LP_ADV_ABILITY（链路伙伴广告能力寄存器）：这是一个只读寄存器。当自协商完成（MR_AN_COMPLETE=1）后，这里保存的就是对端设备通过自协商告知我们的能力信息。其格式与MR_ADV_ABILITY完全相同。调试时，对比本端广告的能力和对端报告的能力，是诊断协商问题的黄金法则。

例如，你的设备广告了[1000M, Full Duplex]，但读取MR_LP_ADV_ABILITY后发现对端只支持[100M, Full Duplex]，那么最终链路必然会建立在100M全双工模式。如果你预期是千兆，那就需要检查对端设备的配置或硬件能力。又或者，你发现对端报告的Duplex位是0（半双工），那很可能遇到了一个非标准或不完全兼容SGMII的设备，链路即使能通也可能不稳定。

注意事项：��存器配置的“坑”

1. 上电默认值：很多芯片的MR_ADV_ABILITY寄存器上电复位后是0。如果你不主动配置它，硬件可能会尝试以一个默认的（可能是最低的）能力去协商，导致链路速率达不到预期。因此，在启动EMAC和SGMII模块时，务必根据你的硬件设计，正确初始化MR_ADV_ABILITY寄存器。
2. 软复位的影响：对SGMII或SerDes模块进行软复位后，这些寄存器的配置可能会被清除。确保你的复位初始化序列里包含了重新配置广告能力寄存器的步骤。
3. 只读与读写：MR_LP_ADV_ABILITY是只读的，试图写入不会改变其值，但可能会产生总线错误。操作寄存器前务必核对芯片手册的读写属性。

3. STATS统计寄存器全解读：网络流量的“显微镜”

如果说SGMII寄存器让我们看清了“路”是否通畅，那么STATS寄存器组则让我们看清了“路上跑的车”的详细情况。EMAC内部的统计模块就像一个不知疲倦的审计员，为数十种网络事件进行计数。这些计数器是32位宽的，会从0xFFFFFFFF溢出到0x00000000。理解每个计数器的精确含义，是进行精准网络性能分析和故障定位的基础。

3.1 接收方向统计：洞察入站流量健康度

接收方向的统计寄存器，帮助我们分析进入设备的数据流是否存在问题。

RXGOODFRAMES（良好接收帧）：这是最基础的“成功接收”计数器。一个帧要被计入这里，必须满足：地址匹配（单播/广播/组播或混杂模式）、长度在64字节到RX_MAXLEN之间、且无CRC错误、对齐错误或编码错误。这个计数器持续不增长，是判断“收不到包”的直接证据。如果它增长，但上层应用没收到，问题可能出在DMA描述符配置、驱动接收队列或内存分配上。

RXCRCERRORS（接收CRC错误）：记录因CRC校验失败而被丢弃的帧数。此计数器非零是物理层或链路层存在干扰的强烈信号。可能的原因包括：网线质量差、接口连接器接触不良、PCB布线受到严重串扰、电源噪声导致信号完整性变差。如果这个值在持续快速增长，几乎可以断定是硬件环境问题。

RXALIGNCODEERRORS（接收对齐/编码错误）：这个计数器记录两种错误：对齐错误（帧包含奇数个半字节且CRC校验失败）和编码错误（在帧接收期间MRXER引脚被拉高至少一个位时间）。编码错误通常与特定的物理层编码规则（如4B/5B， 8B/10B）相关，可能指示SerDes的PLL失锁或数据对齐出错。在调试SGMII等高速串行链路时，这个计数器突然增加需要警惕时钟或数据恢复问题。

RXOVERSIZEDFRAMES & RXUNDERSIZEDFRAMES（超长帧与短帧）：分别记录长度超过RX_MAXLEN和小于64字节的帧。RX_MAXLEN通常由寄存器配置（如RXMAXLEN），默认可能是1518或9022（支持巨帧时）。短帧的偶尔出现可能是正常的（例如冲突产生的碎片），但持续出现短帧或超长帧，可能意味着网络中存在故障设备，或者你的设备配置的MTU与网络中的实际帧长不匹配。

RXJABBERFRAMES（接收Jabber帧）：指长度超过RX_MAXLEN并且有CRC/对齐/编码错误的帧。这通常是严重的物理层故障表现，比如一个设备失控地持续发送垃圾数据。

RXFRAGMENTS（接收碎片）：特指长度小于64字节并且有CRC/对齐/编码错误的数据帧（非MAC控制帧）。在共享式半双工以太网中，冲突会产生碎片。但在全双工交换环境中，此计数器应几乎为0。如果增长，可能指示存在严重的链路层干扰或硬件故障。

RXFILTERED（被过滤的接收帧）：这个计数器非常关键。它记录的是那些地址不匹配（且未开启混杂模式）而被EMAC硬件直接丢弃的帧。在排查“为什么收不到某个MAC地址的包”时，如果RXGOODFRAMES不增加，但RXFILTERED在增加，那问题就很明确了：帧收到了，但被MAC地址过滤规则挡在了门外。你需要检查目标MAC地址是否配置正确，或者考虑临时开启混杂模式进行抓包调试。

RXOCTETS（接收总字节数）：所有良好帧的字节总数。这个计数器可以用来计算平均帧长、吞吐量等性能指标。例如，平均帧长 = RXOCTETS / RXGOODFRAMES。

3.2 发送方向统计：揭示出站流量瓶颈与冲突

发送方向的统计寄存器，反映了本地设备发出数据时遇到的种种情况。

TXGOODFRAMES（良好发送帧）：成功发送出去的帧，无延迟冲突、无过度冲突、无载波丢失、无欠载运行（Underrun）。这是衡量发送成功率的基线。

TXDEFERREDFRAMES（延迟发送帧）：记录那些第一次尝试发送时就发现介质繁忙（即检测到载波）而不得不等待的帧。在半双工网络中，这个计数器有一定增长是正常的，反映了CSMA/CD协议的工作。但在全双工模式下，这个计数器应该几乎不增长。如果全双工下此值增长，可能意味着MAC的发送逻辑或与交换机的配合有问题。

TXCOLLISIONFRAMES（发送冲突帧）：这是诊断半双工网络性能的核心计数器之一。它记录发生冲突的次数（注意是次数，不是帧数，一帧可能经历多次冲突）。在半双工网络中，冲突是固有的，但冲突率（冲突次数/总发送尝试）需要控制在一个很低的水平（例如<1%）。如果冲突率过高，表明网络负载过重或电缆系统有问题（如线缆过长导致时延过大，超过了冲突检测窗口）。

TXSINGLECOLLFRAMES & TXMULTCOLLFRAMES（单次冲突帧 & 多次冲突帧）：这两个计数器对冲突进行了更细致的划分。单次冲突后重发成功，对性能影响较小。而多次冲突（2-15次）则意味着帧在反复重试，会显著增加延迟和降低吞吐。如果TXMULTCOLLFRAMES数值很高，甚至接近TXCOLLISIONFRAMES，说明网络处于极度拥塞状态，需要优化网络拓扑或流量。

TXEXCESSIVECOLLISIONS（过度冲突）：记录那些因为冲突次数超过16次（或芯片设定的最大重试次数）而被最终丢弃的帧。这个计数器一旦增长，就意味着发生了“发送失败”，是导致上层应用感知到丢包的直接原因之一。需要结合冲突计数一起分析。

TXLATECOLLISIONS（延迟冲突）：冲突发生在帧发送开始后的512比特时间之后。在标准的CSMA/CD中，这属于异常情况，通常是由于网络直径过大（如使用的中继器过多）导致往返时延超过了“冲突窗口”。在全双工模式下，理论上不应发生冲突，更不应有延迟冲突。如果此计数器增长，必须彻底检查网络配置和硬件。

TXUNDERRUN（发送欠载运行）：当MAC层准备发送数据时，如果DMA未能及时将帧数据从内存搬运到发送FIFO中，就会发生欠载运行，导致发送失败。此计数器增长是系统性能瓶颈的明确信号。可能的原因包括：系统总线（如DDR、AXI）负载过重、CPU被高优先级任务占用导致未能及时填充描述符、或者发送队列配置得太浅。优化DMA描述符环、提高发送中断优先级、或检查内存访问效率是常见的解决思路。

3.3 其他关键统计与帧长分布

NETOCTETS（网络总字节数）：这是RXOCTETS和TXOCTETS的总和，提供了端口总流量的一个快照。

帧长分布统计（64OCTETFRAMES, 65T127OCTETFRAMES...）：从64字节到1024字节及以上，统计寄存器将成功收发的帧按长度范围进行了分类。分析帧长分布是性能调优和容量规划的重要手段。

• 如��网络中充斥着大量64字节的小帧（如某些实时控制报文），虽然总字节数不大，但每秒帧数（PPS）会很高，对交换机和处理器的包处理能力是巨大考验。
• 如果1024TUPOCTETFRAMES（通常指1024-1518字节的帧，或巨帧）计数很多，说明网络在高效地传输大块数据，吞吐量高，但同样需要确保MTU配置正确，避免分片。

RXSOFOVERRUNS & RXMOFOVERRUNS & RXDMAOVERRUNS（接收溢出）：这三个寄存器分别统计接收FIFO或DMA在帧开始、帧中间以及总的溢出次数。溢出是导致丢包的“头号杀手”之一。当数据到达的速度持续超过DMA搬运或处理器处理的速度时，FIFO缓冲区被填满，新来的数据就会被丢弃。如果这些计数器在增长，你需要：

1. 检查接收中断的服务例程是否执行时间过长。
2. 增加接收描述符环的大小。
3. 优化DMA搬运策略（如使用更好的描述符链）。
4. 检查系统内存带宽是否成为瓶颈。

4. 实战：基于寄存器数据的网络问题诊断流程

了解了每个寄存器的含义后，我们如何将它们串联起来，形成一套有效的诊断方法？下面我结合几个典型场景，分享我的排查思路。

4.1 场景一：链路无法建立（LINK DOWN）

1. 查物理连接与电源：这是第一步，检查网线、光模块、对端设备是否上电。
2. 读SGMII STATUS寄存器：
   • 如果LOCK = 0，问题集中在物理层或SerDes。检查PCB上SGMII差分线的阻抗、长度匹配、参考时钟是否稳定且频率正确。用示波器或眼图仪查看SerDes发送端的信号质量。
   • 如果LOCK = 1但MR_AN_COMPLETE = 0，问题在自协商阶段。读取本端的MR_ADV_ABILITY和对端的MR_LP_ADV_ABILITY（如果可读），看双方广告的能力是否匹配（特别是速率和双工）。尝试强制配置速率/双工模式，绕过自协商（如果芯片支持）。
   • 如果MR_AN_COMPLETE = 1但LINK = 0，可能违反了某种链路规则，或者对端主动断开了链路。
   • 检查AN_ERROR位，看是否有协商错误。
3. 查MDIO通信：确保CPU通过MDIO总线能正确读写PHY芯片的寄存器。如果PHY芯片的寄存器读写都失败，那可能是MDIO总线连接、上拉电阻或驱动配置问题。

4.2 场景二：链路已通，但吞吐量低或丢包严重

1. 看宏观流量：读取RXGOODFRAMES,TXGOODFRAMES,RXOCTETS,TXOCTETS。计算实际吞吐量，并与理论值、应用层报告的值对比，确认丢包发生在哪一层。
2. 查接收侧错误：
   • RXCRCERRORS高：重点排查物理链路干扰、信号完整性。
   • RXALIGNCODEERRORS高：重点排查SerDes/PLL时钟稳定性、数据对齐。
   • RXOVERSIZEDFRAMES或RXUNDERSIZEDFRAMES高：检查网络中的异常设备或MTU配置。
   • RXFILTERED高：检查MAC地址过滤设置，确认是否在混杂模式下能收到包。
   • RXSOFOVERRUNS等高：系统接收侧成为瓶颈，优化中断和DMA。
3. 查发送侧错误与瓶颈：
   • TXUNDERRUN高：系统发送侧成为瓶颈，优化发送描述符和内存访问。
   • TXCOLLISIONFRAMES高（半双工）：网络负载过重，考虑改用全双工或优化网络拓扑。
   • TXEXCESSIVECOLLISIONS高：发送失败，导致应用层丢包，需结合冲突计数分析。
   • TXLATECOLLISIONS高（全双工异常）：检查网络配置，确认是否为全双工。
4. 查帧长分布：看64OCTETFRAMES的比例。如果小帧比例极高，可能是协议开销大或应用特性导致，需要考虑设备的小包处理能力是否达标。

4.3 场景三：网络时延抖动大

1. 查冲突与延迟：关注TXDEFERREDFRAMES和TXCOLLISIONFRAMES。在半双工网络中，这些是引入时延和抖动的主要因素。切换到全双工是根本解决方案。
2. 查系统负载：监控TXUNDERRUN和接收溢出计数器。如果这些计数器在流量大时增长，说明系统处理不过来，时延和抖动必然增大。需要做系统级性能剖析和优化。
3. 查流量模型：分析帧长分布。突发性的大量小帧可能导致瞬时拥塞，增加排队时延。

5. 寄存器操作实践与编程技巧

理论最终要落到代码上。操作这些寄存器，通常是通过内存映射I/O（MMIO）的方式。

5.1 寄存器访问基础

在C语言中，我们通常将寄存器地址定义为易失性指针：

#include <stdint.h> // 假设 EMAC 统计模块基地址为 0x4A100000 #define EMAC_STATS_BASE ((volatile uint32_t *)0x4A100000) // 定义各个统计寄存器的偏移量（示例，需查具体手册） #define RXGOODFRAMES_OFFSET 0x00 #define RXCRCERRORS_OFFSET 0x10 #define TXGOODFRAMES_OFFSET 0x34 #define TXUNDERRUN_OFFSET 0x5C // 读取良好接收帧计数 uint32_t get_rx_good_frames(void) { return EMAC_STATS_BASE[RXGOODFRAMES_OFFSET / sizeof(uint32_t)]; } // 清除所有统计计数器（根据GMIIEN模式） void clear_all_stats(void) { // 假设 GMIIEN = 1， 写0xFFFFFFFF进行递减清零 // 需要遍历所有统计寄存器偏移量 for(int i = 0; i < TOTAL_STATS_REG_COUNT; i++) { EMAC_STATS_BASE[i] = 0xFFFFFFFF; // Write-to-decrement } // 如果 GMIIEN = 0， 则写0x00000000清零 // for(int i = 0; i < TOTAL_STATS_REG_COUNT; i++) { // EMAC_STATS_BASE[i] = 0x00000000; // } }

关键点：

• volatile关键字：必须使用，防止编译器对寄存器访问进行优化（如缓存读取值或重排写操作）。
• 访问宽度：文档强调“All write accesses must be 32-bit accesses”。必须使用32位对齐的访问指令。在C语言中，使用uint32_t指针可以保证这一点。
• 清零操作：这是最容易出错的地方。务必根据MACCONTROL寄存器中GMIIEN位的状态，决定是写入0xFFFFFFFF（写-递减模式）还是0x00000000（直接写模式）来清零计数器。写错模式会导致计数器值被意外修改。

5.2 统计数据的采集与分析策略

直接读取32位计数器很简单，但要用于长期监控和分析，需要考虑更多：

1. 计数器溢出处理：32位计数器在10Gbps线速下，对于某些计数器（如字节计数器）溢出会很快。你的监控程序需要能处理溢出。一个常见的方法是：定期（如每秒）采样计数器值，计算与上一次采样的差值。计算差值时，需要将uint32_t的差值计算封装在一个处理溢出的函数中：

   uint32_t get_counter_diff(uint32_t previous, uint32_t current) { if (current >= previous) { return current - previous; } else { // 发生了溢出 return (0xFFFFFFFF - previous) + 1 + current; } }

2. 性能计数器分组：不要一次性读取所有统计寄存器，这会产生大量的内存访问。根据你的监控目标，分组读取。例如：

   • 健康度检查组：RXGOODFRAMES,RXCRCERRORS,TXGOODFRAMES,TXUNDERRUN。
   • 深度诊断组：当发现错误时，再详细读取所有错误类计数器。
   • 性能分析组：RXOCTETS,TXOCTETS, 帧长分布寄存器，用于计算吞吐量和平均帧长。

3. 中断驱动 vs 轮询：文档提到，当任何统计计数器值达到或超过0x80000000时，可以触发统计中断（如果使能）。这对于检测特定错误事件的突然飙升很有用。但更常见的做法是使用定时器轮询采样，以获取持续的性能趋势数据。

4. 数据可视化：将采样到的差值数据（如每秒错误数、吞吐量）通过日志或系统监控接口（如SNMP、自定义TCP服务）上报，在PC上使用工具（如Grafana）绘制成图表，可以非常直观地发现网络异常与性能瓶颈的关联关系。

5.3 调试案例：定位一个诡异的间歇性丢包

我曾遇到一个案例：设备在长时间运行后，每隔几小时会出现持续数秒的丢包，应用层ping出现超时。通过常规的ping和日志排查无果。

我的排查步骤：

1. 编写一个后台监控线程，每秒读取一次关键统计寄存器：RXGOODFRAMES,RXCRCERRORS,RXALIGNCODEERRORS,RXSOFOVERRUNS,TXGOODFRAMES,TXUNDERRUN，并计算差值。
2. 让设备在测试环境中重现问题。
3. 问题发生时，监控日志显示：RXGOODFRAMES的增长在丢包期间完全停止，但RXCRCERRORS和RXALIGNCODEERRORS没有任何增长。RXSOFOVERRUNS有轻微增长，但不显著。TXGOODFRAMES也停止了增长。
4. 这个现象很奇怪：接收和发送同时“冻结”了，但没有明显的物理层错误（CRC等）。
5. 我扩大了监控范围，加入了SGMIISTATUS寄存器。发现在丢包发生的瞬间，LOCK位短暂地跳变到了0，大约几十毫秒后又恢复了1。
6. 真相大白：SerDes的PLL发生了瞬时失锁。这很可能是电源噪声导致的。我们用示波器监控SerDes模块的供电电压，果然在问题发生时捕捉到了一个毛刺。
7. 解决方案：优化PCB的电源去耦设计，在SerDes电源引脚附近增加了更高质量的钽电容和陶瓷电容，并调整了电源路径的布局。问题彻底解决。

这个案例说明了，将高层网络问题（丢包）与底层硬件状态寄存器（LOCK）关联起来，是解决复杂嵌入式网络问题的关键思维。STATS寄存器告诉你“发生了什么”（收发包停了），而SGMII寄存器告诉你“为什么”（链路物理层断了）。两者结合，才能完成完整的诊断链条。