[参考译文] DP83867IS：关于千兆位主器件扰频模式

尊敬的 Atsusi-san：  

我不确定传统模式与正常模式描述的确切功能是什么。 此设置将更改千兆位应用中 PHY PCS 块内的加扰/解扰方法。  

我会尽力从我们的内部设计团队那里获得有关此职能 的详细信息、但这可能需要1-2周时间。  

传统模式不应用于正常运行。 我可以看到该位是只读的、因此它必须已通过其他内容进行切换。  

您是否能够执行 ABA 交换以查看特定 STB 链路伙伴是否发生了此行为？ 也许可以使用另一个867作为链路伙伴来查看是否观察到相同的行为。

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的答复。

我正在寻找有关传统模式和正常模式的更多信息。

您知道用户为什么不应使用传统模式吗？

但是、正如您所说、它是只读的、因此用户无法更改它。

请告诉我是否有针对此情况的解决方案。

我正在请求 ABA 交换、但可能需要一些时间来准备环境。

与此同时、我们想探讨其他办法。

尊敬的 Atsusi-san：

Unknown 说：

您知道为什么用户不应使用旧模式吗？

我相信这是因为此设置更改了千兆位 PCS (物理编码子层)块中的扰码方法。 这种扰频方法可能与连接方使用的方法不同、这将解释为什么无法正确读取数据包、因为这些数据包使用不同的方法进行编码和解码。

我会尽力让我们的设计团队更详细地解答这一问题、并在下周结束前与您联系

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的更新。

我将尝试写入0x050[1]=0。

什么是特定 PHY？

请告诉我你掌握的细节。

尊敬的 Atsusi-san：

在这种情况下、应启用此模式以连接另一个链接伙伴 PHY、而不是 Realtek PHY。 我不确定这是什么特定 PHY、但不应该为 Realtek PHY 切换。  

此致！

Vivaan

尊敬的 Vivaan-San：

我的客户读取了0x50、以便尝试写入0x50[1]=0。

位[1]已为"0"。

由此看来、传统模式已被禁用。

当0x50[1]=0和0x17[8]=1时、PHY 是设置为正常模式还是旧模式？

我们如何切换到正常模式？

你好、高桥山、

感谢您的提问。 Vivaan 今天很高兴,并将期待在 EOD 星期三回复您的查询。

此致、

Gerome.

你好、高桥山、  

此位0x50[1]的行为可能不同。 客户是否可以尝试将其写入0 (即使它已经显示为0)？ 我相信它可以充当 LATCH 开关、因此写入该位可能会禁用传统模式。 我无法在此重现此问题、因此我希望客户尝试此操作。

我目前仍在和设计团队内部讨论、而且会向大家介绍这方面的最新进展。  

此致！

Vivaan

Vivaan-San、

感谢您的答复。

我将让我的客户写入0x50[1]=0。

写入后、您是否希望读取寄存器0x17[8]=0 (正常模式)？

或者它是否仍然保持寄存器0x17[8]=1 (旧模式)？

你好、高桥山、  

由于我无法在实验室中对此进行测试、因此我不确定我们会期望什么行为。 下面是写入寄存器后可能出现的一些情况。

可能是、如果在传统模式链路处于活动状态时写入寄存器、PHY 将断开链路、并使用 0x17[8]=0 (正常模式)重新协商不同的链路

也可能是 PHY 在内部关闭了传统模式选项、但这不会反映在寄存器设置中。 在本例中、 0x17[8]=1、但我希望客户继续通过发送数据进行测试、以查看内部是否修复该问题

如果连接已经建立、写入该寄存器不会更改当前连接模式。 在这种情况下、也许客户可以在尝试建立链路之前尝试写入该寄存器。  

此致！

Vivaan

尊敬的 Vivaan-San：

我的客户写入了0x50[1]=0、但没有任何变化。
此后再次出现通信问题。

我们还有其他问题。

1) 1)如何专门确定传统模式和正常模式？
2) 2)它在传统模式下具体表现如何？
3) 3)寄存器0x50[1]真的是一个禁用旧模式的寄存器吗？
4)这次通信问题似乎是由其他原因引起的、但传统模式错误设置问题是否是必须解决的问题？

此致、

你好、高桥山、  

感谢您尝试使用寄存器0x50。 我不知道为什么它不起作用。 我会联系我们的设计团队、尽快得到解答。  

[报价 userid="50131313" url="~/support/interface-group/interface/f/interface-forum/1467528/dp83867is-about-gigabit-master-scramble-mode/5661872 #5661872"]1)传统模式和正常模式是如何专门确定的？
2)它在传统模式下的具体行为是怎样的?

遗憾的是、我对这些细节不是很熟悉、但是我会在大约一周内得到设计团队的解答并回复

[报价 USERID="501313" URL="~/support/interface-group/interface/f/interface-forum/1467528/dp83867is-about-gigabit-master-scramble-mode/5661872 #5661872"]3)寄存器0x50[1]实际上是一个禁用旧模式的寄存器？[/QUOT]

我被告知该位应从我们的设计团队那里禁用旧模式、但我无法自己复制这个问题来实际测试这个问题。 我将询问设计团队、并尝试明确如何禁用此模式。  

Unknown 说：

4)这次通信问题似乎是由其他原因引起的、但是传统模式错误设置问题是否是必须解决的问题？

是什么让您认为这次的行为是其他原因造成的？ 在此测试用例中、寄存器中是否未启用传统模式？ 根据我的理解、传统模式改变了编码结构、从而解释了观察到的数据包丢失。  

此致！

Vivaan

尊敬的 Vivaan-San：
非常感谢您的持续支持。

这个问题已经存在了很长一段时间。
由于客户的强烈要求、这一问题需要尽快解决。
如果您能尽快向我们提供有关传统模式的信息、我们将不胜感激。
我很抱歉打扰您。

您说：
是什么让您认为这次的行为是其他原因造成的？ 在此测试用例中、寄存器中是否未启用传统模式？ 根据我的理解、传统模式改变了编码结构、从而解释了观察到的数据包丢失。

在出现通信问题时设备确实设置为传统模式。
但是、我们无法确定这是否真的是一个问题、因为有关传统模式的信息很少。
我们需要有关传统模式的更多信息、以阐明真正的问题。

其他问题：
5) 5)寄存器0x50[1]是否是在链路断开时复位的寄存器？ 或者、即使您在写入一次硬件后将其复位、该值是否会保留？

除上述1)至4)之外、如果您也可以查看此内容、我将不胜感激。

你好、高桥山、  

我理解这种紧迫性、已与设计团队进行沟通、并希望在接下来的几天内进一步澄清此问题。 感谢您的耐心。  

[报价 USERID="501313" URL="~/support/interface-group/interface/f/interface-forum/1467528/dp83867is-about-gigabit-master-scramble-mode/5665863 #5665863"]5)寄存器0x50[1]是一个在链路断开时复位的寄存器？ 或者即使您在写入硬件一次后复位硬件、该值是否仍会保留？[/QUOT]

复位后、所有寄存器(包括寄存器0x50)均复位为默认值

此致！

Vivaan

尊敬的 Vivaan-San：

感谢您的答复。

我很抱歉。

我的问题不准确。

如果他们在链路接通时写入0x50[1]=0、然后链路断开、那么该位是否会被清除？

客户在链路建立期间写入此位、然后重复链路断开和链路建立多次、从而重现通信故障。

他们需要多次重复此过程、因为通信故障的频率不是100%。

我认为如果在链路断开时复位该位、则验证无效。

你好、高桥山、  

我没有这方面的全部资料、但我不认为应该在重新链接后重置。 我也会在设计团队中进一步阐明这一点。  

此致！

Vivaan