[参考译文] DP83869HM：DP83869HM SGMII 不一致的自动协商

您好、Magnus、

我们有一份SGMII 故障排除指南、其中汇编了解决 SGMII 问题的步骤。 您能否通读本文档、看看它是否有助于解决问题？

此致、

Shane

感谢您的答复。 是的、我们已经看到并通过了此故障排除指南。 遗憾的是、本指南中没有关于我们问题的解释、我们看到了这一点。  

您好、Magnus、

下面是我对此进行研究的几个想法：

1.您是否尝试过在 PHY 和 FPGA 上都禁用 SGMII 自动协商？ 这可以解决问题吗？

2.是否按照故障排除指南第 1.4 节中的说明进行了任何回送测试？

3.通过 0xC00[9]重新启动 SGMII 自动协商是否有任何效果？

4.在工作和失败的情况下是否设置了 0x37[1]？

5.您的所有电路板上是否存在问题、或者某些电路板是否显示了这种行为？

6.确保 PHY 基准时钟在数据表规格范围内、尤其是 ppm 规格范围内。

此致、

Shane

您好、Magnus、

1.用于禁用 SGMII 自动协商的寄存器写入为 0x14[7]。 如果您已经建立了相关链接、则可能需要重置。

2、手动重启自动协商或通过链路接通事件之间没有功能差异。

我仍然很好奇、对于失败的情况和工作案例、PHY 中是否设置了 0x37[1]。 我们的应用手册建议此位反映 MAC 对 SGMII 控制信息的确认。

此致、

Shane

1.0x14[7]= 0 是我们尝试过的、但没有导致链路正常工作。 执行此类操作后、您会建议使用哪些复位？ 我们尝试了 0x1F[14]=1 — 写入后是否需要清除该寄存器位？

SGMII_AUTO_NEG_STATUS 寄存器 (0x37) 具有以下值：
*良好情况：0x37 = 0x3 -> 0x37[0]= 1、0x37[1]= 1
*故障情况：0x37 = 0x2 -> 0x37[0]= 0、0x37[1]= 1
因此、即使在坏的情况下、MAC/FPGA 似乎确实响应了确认、请提供建议。

对于成功和失败的场景、我们已对 MAC 的 SGMII 自动协商第 37 条状态机进行采样、使其从“AN_ENABLE"更“更改为“LINK_OK"。“。 我们发现有趣的是以下内容：

1. 每个铜缆链路接通事件都会产生 2 个背对背 SGMII 自动协商序列。 这是预料之中的吗？
2. 在成功案例中、A.2 和 A.3 有不同的行为。 这是一个线索吗？
3. 在故障情况下、状态机似乎在 B.2 之后卡住、无法继续。
   
   

请结合我们有关 SGMII_AUTO_NEG_STATUS 值的其他响应来查看随附的文件。

文件：  

e2e.ti.com/.../AN-troubleshooting.pdf

您好、Magnus、

感谢您提供详细信息、以回答您的问题：

1.在这种情况下我会尝试软件复位 (0x001F = 4000)。 执行硬件复位会恢复寄存器值、因此会重新启用自动协商。

2、有趣的是、在场景 B.2 中、当 MAC 侧似乎没有确认时 PHY 显示确认。 在这种情况下、协商似乎在 an_restart 阶段分解。  在工作和失败的情况下、您在 0xC01[2]中看到什么值？ 我相信这将是 PHY 上的 SGMII 链路状态。

• 此外、您的 MAC 是否显示导致链路在 AN_restart 阶段停止的原因？ 根据我能说的、退出此阶段的唯一要求是 LINK_TIMER 完成

两个 SGMII 自动协商序列 (A.2/A.3) 看起来相同。 我相信你不需要谈判两次,虽然我不会看到这样做的问题,如果链接被提出。

4.我看到 A.1 与 A.2/A.3 的区别是 Link_ok 在低电平状态下开始、而 AN_EN 稍长（可能是由于上电电路）。

此致、

Shane

感谢您的反馈！

1.这是我们已经尝试禁用 MAC 和 PHY 但导致链路无法正常工作的情况。 但是、我们现在已经尝试仅在 PHY 0x14[7]处禁用、然后执行复位 0x1F=0x4000。 我们可以看到 PHY 仍然执行/响应 SGMII AN。 这真的会关断吗？

2.在指示链路接通的情况下、FX_STS 位 STTS_LINK_STATUS 位似乎被置为有效。  

您好、Magnus、

1、是、此位禁用 PHY 上的 SGMII 自动协商。

2.以下是我对你的其他问题的看法。

• 我怀疑双 SGMII A 可能会由 MAC 或 PHY 的重新协商请求导致。 根据我在规范第 37.2.4.1 节中看到的内容、可以从任一侧请求重新协商。 这看起来对应于状态机中的“dr_restart_an"变量“变量。
• 预期是 PHY 将更新的控制信息发送到 MAC 并让 MAC 确认。
• 根据状态机的波形、似乎没有设置 LINK_TIMER_DONE 标志。 在第 37 条规范中、必须设置 LINK_TIMER_DONE、才能从 AN_RESTART 转换为 ABILITY_DETECT。 SGMII 标准将 LINK_TIMER 从 10ms 降低至 1.6ms、这在 A.2/A.3 情况中很明显。 在 B.2 中、重启状态会在 1.6ms LINK_TIMER 完成之后持续很长时间。
• 通过查看 E2E 和我们发布的文档 、我无法确定 PHY 是否正在请求重新协商。 如果有办法在 MAC 侧跟踪这一点、那么可以提供更多见解。  

通常、当 SGMII 数据路径正确路由（环回显示没有错误）时、自动协商不会出现问题。 这是 PHY 还是 MAC 差异目前尚不清楚、但我还有几个问题：

• 您提到了它在所有电路板上都能看到、但程度各不相同。 这些板之间的差异是什么？ 某些电路板显示的数值是否低于其他电路板？
  • 如果您在电路板之间交换 PHY、该行为是否会跟踪 PHY 或其连接到的电路板？  
• 所有电路板都是使用一个 FPGA 进行测试、还是依赖于所使用的 FPGA？
• 问题发生的频率如何？ (1/10 链接、1/100、...)
• 以太网电缆长度或链路伙伴是否存在任何依赖关系？ 如果换用电缆或链路伙伴、行为是否会发生变化？
• 您是否能够共享 SGMII 布线的布局以供审核？

此致、

Shane

1.我们似乎遇到问题、因为正如我们已经指出的、PHY 在执行该寄存器写入时实际上并未禁用。 关于强制速度模式的注释、根据 CFG2 SGMII_AutoNeG_EN、这种模式或其他因素是否会影响 PHY 的行为？

2.预期届时应该专门有一个由 PHY 触发的事件“1" SGMII“ SGMII。
*我们有两个可以帮助解释这个问题吗? 可能其中一个设备请求重新协商、因为该过程未以完全兼容的方式执行。 在成功的情况下、我们看到第一次重新协商 (A2) 与 A3 略有不同、尽管从 MAC 的角度来看、这两个重协商都会产生 LINK_OK。
*您提到了 1.6ms 链路计时器; PHY 的默认计时器为 2us ,而 MAC 的标准计时器为 1.6ms。 这在这里如何发挥作用？ 我们尝试将 MAC 计时器扩展到 10ms、在该过程中我们看到了不同的行为、但仍然容易出错。
*我们已经尝试更改 PHY 上的 SGMII 链路计时器、没有看到太大影响、更改此值后是否需要执行复位？ 还是在下一次重新谈判之前进行更改就足够了？
*不幸的是,我们无法跟踪更多的已经在 MAC 上。

关于 SGMII 数据路径：
*问题发生在不同程度取决于董事会,然而这是一个“定性“评估,因为行为不一致。 错误率可以是 1/10 至 1/1000 之间的任何值、甚至可能更低、因此交换 PHY 可能不太有用。
*所有板都使用相同类型的 FPGA 和 Phy。
*更改铜链路伙伴和电缆或电缆长度似乎没有影响。
*如前所述,无论何时建立 SGMII 链路,我们都能在 MAC 和链路伙伴之间实现全双工 1G 数据流,以太网帧数量最多,完全无错误。 我们认为、对于我们当前的情况、这是一个比任何环回更相关的测试。 您是否认为尽管如此、SGMII 布局或布线可能仍然存在问题？

此致、
Magnus

1.我们似乎遇到问题、因为正如我们已经指出的、PHY 在执行该寄存器写入时实际上并未禁用。 关于强制速度模式的注释、根据 CFG2 SGMII_AutoNeG_EN、这种模式或其他因素是否会影响 PHY 的行为？

2.预期届时应该专门有一个由 PHY 触发的事件“1" SGMII“ SGMII。
*我们有两个可以帮助解释这个问题吗? 可能其中一个设备请求重新协商、因为该过程未以完全兼容的方式执行。 在成功的情况下、我们看到第一次重新协商 (A2) 与 A3 略有不同、尽管从 MAC 的角度来看、这两个重协商都会产生 LINK_OK。
*您提到了 1.6ms 链路计时器; PHY 的默认计时器为 2us ,而 MAC 的标准计时器为 1.6ms。 这在这里如何发挥作用？ 我们尝试将 MAC 计时器扩展到 10ms、在该过程中我们看到了不同的行为、但仍然容易出错。
*我们已经尝试更改 PHY 上的 SGMII 链路计时器、没有看到太大影响、更改此值后是否需要执行复位？ 还是在下一次重新谈判之前进行更改就足够了？
*不幸的是,我们无法跟踪更多的已经在 MAC 上。

关于 SGMII 数据路径：
*问题发生在不同程度取决于董事会,然而这是一个“定性“评估,因为行为不一致。 错误率可以是 1/10 至 1/1000 之间的任何值、甚至可能更低、因此交换 PHY 可能不太有用。
*所有板都使用相同类型的 FPGA 和 Phy。
*更改铜链路伙伴和电缆或电缆长度似乎没有影响。
*如前所述,无论何时建立 SGMII 链路,我们都能在 MAC 和链路伙伴之间实现全双工 1G 数据流,以太网帧数量最多,完全无错误。 我们认为、对于我们当前的情况、这是一个比任何环回更相关的测试。 您是否认为尽管如此、SGMII 布局或布线可能仍然存在问题？

此致、
Magnus

您好、Magnus、

1.禁用自动协商后、应将 SGMII 速度强制为 PHY 解析的 MDI 速度。 当在 PHY 上禁用自动协商功能时、也应在 MAC 上禁用该功能。

2.这些都是很好的问题,但很难说你注意到的行为是否导致了这个问题。 例如、工作条件下有双重自动协商、这样就能够无问题地传输帧。 如果是、则双重自动协商（更高级别）系统中的预期行为是否正确？ 从 PHY 的角度来看、该行为看起来正常。

• 这同样适用于自动协商计时器。 更改 PHY 自动协商计时器似乎没有任何影响、因此我认为这不是 PHY 计时器的问题。 在 MAC 侧更改此设置时、您看到的行为差异是什么？
• 更改 PHY 上的链路计时器时、只需在 MDI 上建立新的链路、而不需要复位。  

3.因此,在单个电路板上,您可能会看到 1/10 到 1/1000 链路的问题是正确的? 还是某些电路板显示 1/10、某些电路板显示 1/1000？ 如果第二种情况属实、则有助于看到两个电路板之间对 PHY 进行 ABA 交换、以了解性能是否遵循 PHY 或电路板。  

• 我同意,传递真正的数据错误是证据,你的布局是好的,但它永远不会伤害有第二个外观. 布局审核是 E2E 上的常见做法、因此如果您想查看一下、我可以这样做。

我有一个问题：通过 0xC00 寄存器重新启动 SGMII 自动协商过程是否可以解决发生时的问题？ 我认为、这相当于在 SGMII 端建立新的链路。

此致、

Shane

1.  0x14[7] SGMII_AN_EN 和 0xC00[12] CTRL_ANEG_EN 之间的区别是什么？ 它们之间有什么关系？  如前所述、禁用 0x14[7]不会停止对我们来说一切都仍然有效的过程。 是否需要禁用这两个器件？
2. 我们不知道这是否是预期行为、但至少我们可以得出结论、这不是标准行为、不需要双重协商。更改 MAC 上的计时器确实会影响状态机跟踪的时间轴、但可观察的行为仍然相同。
3. 没有相同的电路板可以在所有这些值之间变化。
4. 一旦问题发生、写入 0xC00[1]无法解决问题、链路保持断开状态。 我们在建立链路的情况下尝试了寄存器写入操作、并发现它确实重新启动了 SGMII A、只是为了确保。 有趣的是、拔下铜缆会立即导致 SGMII 链路成功地重新协商、因此这两个过程可能在某种程度上并不相同。

此致、

Magnus

您好、Magnus、

1.0x14[7]是 SGMII 转铜缆应用中的 SGMII 自动协商控制。 0xC00[12]用于桥接模式、例如 SGMII 转 RGMII 或 RGMII 转 SGMII。 您只需要禁用 0x14[7]以禁用 SGMII 转铜缆模式中的自动协商、但也应该在 MAC 上禁用自动协商。

4.只是为了确认、您将 0xC00[9]写入“1"是“是正确的吗？ 0xC00[1]被保留、因此我不确定这会对自动协商过程执行什么操作。

我可以尝试改装我们的其中一款 DP83869 EVM、以了解我是否可以使 SGMII 与另一个 EVM 的 SGMII 接口（例如 DP83867-S-EVM）建立链路。 这将是一个 PHY <-->背对背 SGMII 连接、至少应该验证 DP83869 SGMII 自动协商过程是否正常。 订购 SMA 连接器后需要时间才能安装在 EVM 上。

• 如果没有与第二种 PHY 或 MAC 类型相关联、就很难判断 MAC 或 PHY 是导致这种情况的原因。 使用 EVM 进行背对背测试是我可以想到的一种使用不同的 PHY 平台进行测试的方法。

此致、

Shane

1. 好的、只需要注意、在读取 0xC00[12]时、默认设置。
2. 您说得对、这是个拼写错误、我是指 0xC00[9]。 我知道需要在两个器件上禁用 SGMII、但我们这样做时、没有功能链路。 我们希望在没有 Over SGMII 的情况下实现工作状态。
   1. 对于调试、 如果我们仅通过 0x14[7]禁用 PHY 上的 SGMII 而不是 MAC、那么我们想知道会发生什么情况？ 我们观察到、在执行此操作并复位后、从 MAC 的角度来看、仍然完成并到达 LINK_OK。 我们发现这很奇怪、因为它应该是关闭的、但不知何故 MAC 可以完成。
   2. 检查 PHY 上 SGMII 链路状态的正确方法是禁用？  

此致、

Magnus

您好、Magnus、

我预计当 PHY 禁用了自动协商功能时、它不会等待 MAC 的任何确认、然后再发送数据。 我在该规范中没有看到描述禁用自动协商的部分、因此该实现很可能取决于制造商。

我们可能会在 SGMII 通信开始时发送配置页面、但我相信我们不会等到确认后再发送数据。 即使在禁用协商的情况下、这也可能允许 MAC 进行自动协商。

对于禁用时的链路状态、我将看到我们是否有执行此操作的寄存器。  

此致、

Shane  

您好、Magnus、

对于 SGMII 链路状态、可以使用 0xC01[5]。

此致、

Shane