[参考译文] DP83869HM：自动协商优化/问题

尊敬的 Dominic：

1)

• 我们将 ANAR[15](下一页能力)设置为0
• 我们通过 BMCR[9]重新谈判
• 预期：PHY 发送的 NP 位反映了此变化
• 观察：无论 ANAR 寄存器中该位的状态如何、PHY 发送的 NP 位仍为1：

这不是预期结果、但我将在内部设置中确认。 您能否分享显示 NP=1的 BMCR、ANAR 和波形/链路伙伴 ANLPAR 寄存器的寄存器读数？

2)

在两种情况下、带有 FAST_ANEG_EN 的短计时器可能会出现问题：

• 链路伙伴未启用 FAST_ANEG。 两个链路伙伴都应匹配模式以避免握手计时器不匹配而导致自动协商错误的情况
• MDI 上的链路质量较差。禁用 FAST_ANEG 后、自动协商链路训练过程有助于提高链路建立的裕度。 启用 FAST_ANEG 可缩短链路训练时间、当 MDI 链路质量较差时、可能导致链路问题(由于布局/原理图问题、电缆故障、环境噪声等)

如果链路伙伴未启用 FAST_ANEG、建议使用更长的计时器。 通常、如果链路伙伴不支持、我建议禁用 FAST_ANEG 以确保稳定性。

您能澄清一下您观察到的问题吗？ 链路/通信是否发生故障、PHY 和链路伙伴之间的模式组合是多少？

谢谢您、

Evan  

尊敬的 Dominic：

感谢您分享请求的数据。 为了进行澄清、除了(链路伙伴的) ANLPAR 报告接收下一页 Adv？

您对 FAST_ANEG "优化"计时器的理解与我的一致。 与各种非 TI 链路伙伴进行 FAST_ANEG 互操作测试的范围有限、因此我们无法保证 FAST_ANEG 与所有 LP 兼容、具体取决于用例和信号裕度。

您的应用是否支持通过软件动态配置 FAST_ANEG？
例如、->使用 FAST_ANEG 默认值尝试建立链路->如果链路失败、则禁用 FAST_ANEG。

您的应用对自动协商时间有何要求？ 我想了解一下互操作性置信度与 aneg 时间之间的权衡。

谢谢您、
Evan

您好 Evan、

Unknown 说：

感谢您分享请求的数据。 为了进行澄清、您看到波形本身中的 NP 位= 1、此外还看到(链路伙伴的) ANLPAR 报告接收下一页的 Adv？

我们看到波形中的 NP 位= 1、并且看到后续的下一页传输。 该位也在链路伙伴的 ANLPAR 中设置。

Unknown 说：

您的应用程序是否允许通过软件动态配置 FAST_ANEG？
例如、->尝试使用 FAST_ANEG 默认建立链路->如果链路失败、则禁用 FAST_ANEG。

我们会考虑这个、谢谢。

Unknown 说：

您对自动协商时间的申请要求是什么？ 我想了解一下互操作性信心与 aneg 时间之间的权衡。

这适用于 EtherCAT 子器件、因此所有链路伙伴将只使用100Mbit/s 全双工模式、但我们不能假设链路伙伴上有特定的 PHY/PHY 供应商。

越快越好、但可靠性比时间更重要。 我们看到的是自动协商的~3秒,但差异很大,为+-1或2秒。 我们查看了 DP83869文档、注意到了 FAST_ANEG 设置、并看到了相当大的改进。 不幸的是、它基本上没有文档记录。

您认为是否有机会获得有关 fast_ANEG 变化的可靠答案？ 我们的思路是、如果我们了解 FAST_ANEG 的作用、我们可以评估这可能会导致问题的情况、以及这是否与我们的用例相关。

此致、

Dominic

尊敬的 Dominic：

感谢您的澄清。

我正在与内部团队核实、以便对 FAST_ANEG 变更列表更有信心、如果我们能期待在启用此功能的情况下实现可靠的互操作用例。 感谢您的耐心。

谢谢您、
Evan