[参考译文] DP83867IS：利用环回功能

尊敬的 Vivaan-San：

很抱歉这么晚才回复。

我已经收到连接方的寄存器信息。

我会通过私人消息将其发送给您。

尊敬的 Atsusi-san：  

感谢您提供这些信息。 我注意到每个具有不同值的器件都有2列、我想澄清一下每列的含义。  

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的答复。

我对没有解释表示歉意。

左列显示了​​通信故障期间的寄存器值、右列显示了​​正常通信期间的寄存器值。

尊敬的 Atsusi-san：  

感谢您的澄清。 很遗憾、基于该寄存器转储、我没有看到任何新信息。 在这种情况下、唯一的区别看起来是867配置为从模式、而不是主模式。  

在这种情况下、我唯一想到的另一个因素是时钟信号。 由于只有867是主器件时才会观察到该行为、因此我想 验证输入时钟晶振是否满足要求 包括这些值。 该时钟用作内部基准时钟、然后嵌入到发送给链路伙伴的数据中。 然后、连接方从数据中恢复这个时钟。  

一旦我们确认这些要求已得到满足、我们就应该得到满足 测试 CLK_OUT 引脚 它输出该内部参考时钟。 如果尚未通过配置(strap)启用该功能、我们可以使用 寄存器0x170中的位6、用于激活 CLK_OUT . 我们必须确保此时钟也处于+/- 50ppm 范围内。 由此、我们可以验证此行为是否是由 PHY 内部时钟导致的。 如果时钟似乎在这些限制范围内、我建议您使用 检查链路伙伴的时钟 因为 链路伙伴可能无法从嵌入式数据中正确恢复该时钟、这可能是导致这种行为的原因。  

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的答复。

问题1：

您能给我讲一讲主/从和嵌入式时钟吗？
我可能理解不正确。

我已了解、无论它是主器件还是从器件、发送器(Tx)都会嵌入时钟、而接收器(Rx)会将其恢复。
(换句话说、链路的主设备和从设备都嵌入并恢复时钟。)
我的理解错了吗？

或者、主器件在发送和接收时始终嵌入时钟、而从器件在发送和接收时仅恢复时钟？

问题2：

我们应使用示波器检查的时钟是否意味着 XI？

客户系统通过合规性测试。 时钟(XI)仍然可能是原因吗？
我不熟悉合规性测试、但是不是同时在主/从角色上进行了测试？

问题3：

我们应该如何检查连接方是否能够正确恢复嵌入式时钟？

尊敬的 Atsusi-san：  

[报价 userid="50131313" url="~/support/interface-group/interface/f/interface-forum/1462386/dp83867is-utilizing-the-loopback-function/5627094 #5627094"]

我可能理解不正确。

我已了解、无论它是主器件还是从器件、发送器(Tx)都会嵌入时钟、而接收器(Rx)会将其恢复。

[报价]

根据 IEEE 802.3ab 标准、主设备是其本地时钟用于同步数据的设备。 主器件使用该本地时钟并将其嵌入到数据流中。 这个时钟随后由从器件恢复、而这个恢复时钟也可用于从器件发回给主器件的任何内容。 正确的、从器件也将时钟嵌入到数据中、但它实际上是从主器件发送的数据中恢复的时钟、因此最终、时序是由主器件时钟决定的、尽管这是间接的。  

有关工作原理的更多信息、请查看 IEEE 标准802.3第40条。

[报价 userid="50131313" url="~/support/interface-group/interface/f/interface-forum/1462386/dp83867is-utilizing-the-loopback-function/5627094 #5627094"]

问题2：

我们应使用示波器检查的时钟是否意味着 XI？

客户系统通过合规性测试。 时钟(XI)仍然可能是原因吗？
我不熟悉合规性测试、但是不是同时在主/从角色上进行了测试？

[报价]

这将取决于客户使用的配置。 如果客户使用振荡器输入、则可以检查 XI 以确保满足以下列出的要求。 如果客户在使用晶振、那么晶振技术规格应该说明它是否满足我上一次答复中提到的要求。 对于晶振、我还想检查 CLK_OUT 信号、因为它的测量更加可靠。  

合规性测试不包括时钟 ppm 测量、因此仍可能是该行为的原因。 合规性测试不受主/从分辨率的影响、因此我认为它不是针对这两种模式进行测试的。  

Unknown 说：

我们应如何检查连接伙伴是否能够正确恢复嵌入式时钟？

我想到的一种方法是检查 FIFO 行为。 通常、时钟不匹配会导致接收端产生 FIFO 错误、在本例中将是 STB。 由于 STB 不是 TI 器件、我不确定具体如何查找该 FIFO 信息。

我们还可以尝试使用与 STB 不同的 PHY 在主模式下进行 ABA 交换并测试867、以缩小该行为的范围。  

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的详细解释。

首先、让我们检查867的输入时钟要求和 CLK_OUT。

其他信息：

我发现867通过自动协商解析到主器件的速率大约为50%(即从器件分辨率约为50%)。

当867设置为主机时、并不一定意味着会出现通信问题。

但是、当出现问题时、867始终是主器件。

您对此有何新看法？

(例如、如果它可以作为主器件正常建立链路、则不太可能是时钟引起的。)

尊敬的 Atsusi-san：  

感谢您提供更多信息。 虽然我仍想检查时钟、但我们还可以测试一些其他东西。  

首先、我想 使用 PHY 的反向环回功能进行测试。 您可以在寄存器0x16中启用反向环回功能、从链路伙伴端发送数据包、并观察是否存在任何空闲错误。 这将告诉我们空闲错误是由 MDI/Link 伙伴侧还是867的 MII 侧引起的。

如果该测试通过并显示其行为不是 MDI 侧造成的、我们可以检查867和所用的 SoC/MAC 接口的平均时钟频率。 这也可能是产生空闲错误的原因。  

正如我在上一次答复中提到的、进行 ABA 交换有助于我们将这种行为隔离到一半或另一半、然后我们可以进一步缩小范围。  

此致！

Vivaan

尊敬的 Vivaan-San：

客户执行了与另一个链路伙伴的链路建立测试、而未多次强制执行主/从连接。

将867设置为主机的概率为50%、因此通过增加测试次数来吸收。

未出现问题。

我们将尝试回送测试。

您建议我进行反向环回。

我对所附"Reverse loopback.pdf"的理解是否正确？

根据数据表、支持的环回功能因 MAC I/F 和数据速率而异。

PHY 设置为1000Mbps、即 SGMII。

867在此配置中是否支持反向环回？

我从下表中找不到这一点。

发生通信问题时、链路已建立、但没有 ping 响应。

在这种情况下仍可以执行环回吗？

e2e.ti.com/.../Reverse-loopback.pdf