[参考译文] DP83867IR：当 IFG 小于所需的最短时间 (96ns) 时的 RX_CTRL 行为

您好、J-San、

感谢您的答复。

************
1.

RX_CTRL 和 RX_CLK 信号的波形如下图所示。

下面还显示了 IFG 短于 96ns 的点的放大图像。

请注意、DP83867IR's RGMIIDCTL 寄存器（地址 0x0086）的位[3：0]被设为“1000b"，“，这、这意味着 RX_CLK 的延迟时间为 2.25ns。
考虑到 RX_CLK 延迟、RX_CTRL 在 RX_CLK 的下降沿变为低电平。
当 IFG 短于指定的最小值 (96ns) 时、是否会出现这种行为？

************
2.
感谢您提供 VTM_CFG 寄存器（地址 0x0053）的相关信息。

************
3.
我当前正在检查 MAC 侧的状态。
我会在检查后回复您。

************

此致、
Nakamura

Hi Nakamura-San,  

感谢您的答复。  

考虑到 RX_CLK 延迟、RX_CTRL 在 RX_CLK 的下降沿变为低电平。
当 IFG 小于指定的最小值 (96ns) 时、是否会出现这种行为？

在这种情况下、这意味着 RX_ER 和 RX_DV 都为高电平。 这可能是较短 IPG 的预期行为之一。  
可以通过修改寄存器 0053[3：0]来更改 PHY 的最小 IPG 阈值。 默认值为 5（12 字节）、可以降低到 3（10 字节）。 您能否修改此值来查看 RX_CTRL 行为是否发生了变化？

此致、
j

您好、J-San、

可通过修改寄存器 0053[3：0]来更改 PHY 的最小 IPG 阈值。 默认值为 5（12 字节）、可以降低到 3（10 字节）。 您能否修改此值以查看 RX_CTRL 行为是否发生变化？

我已将 VTM_CFG 寄存器的值设置为 3、目前正在进行调查。
获得结果后、我将再次与您联系。

此致、
Nakamura

Hi Nakamura-San,  

当我检查 MAC 端时、我发现 MAC 收到了第三个数据包、它是一个有效的数据包。
此时、VTM_CFG 寄存器仍为默认值。
第二个数据包（错误数据包）和第三个数据包之间的 IPG 为 68ns、但 PHY 似乎能够接收第三个数据包作为有效数据包。
PHY 是否会出现此行为？

这可能是预期的行为、因为 PHY 将第二个数据包视为无效数据包、因此 IPG 计数器可能没有重新配置、因此它可能认为下一个传入的 PHY 的 IPG 大于 96ns、而不是 68ns。  

请在结果可用后告诉我。  

此致、
j

您好、J-San、

将 VTM_CFG 寄存器值更改为 0x3 后、器件运行 24 小时、即使接收到 80ns IPG 数据包也不会发生错误。
我已经确认更改 VTM_CFG 寄存器的有效性。

我还有其他问题。
-你能给我指出任何文件,指出 VTM_CFG 寄存器的最小值是 0x3 吗? 另外、请解释最小值为 0x3 的原因。 我无法从数据表中确定这一点。
-请告诉我,如果你能考虑任何关于将 VTM_CFG 寄存器值设置为 0x3 的问题。

此致、
Nakamura

Hi Nakamura-San,

遗憾的是、目前没有最低价值的正式文件。 从理论上讲、该值可以更低、但我们在之前的客户案例和之后的内部验证中已经看到、如果该值低于 3、则会导致 PHY 出现问题。

将该值设置为 3 没有问题。 该值是 PHY 可以处理的已知最低阈值。

此致、

j

您好、J-San、

感谢您解释最小值为什么为 0x3。
将设置更改为 0x3。
作为参考、您能否介绍一下将客户或内部验证设置为 0x2 或 0x1 时遇到的任何 PHY 问题？

此致、
Nakamura

Hi Nakamura-San,  

据我所知、我们看到了以下情况：阈值过低时、PHY 将无效数据包读取为有效数据包。 0x3 是一种客户已验证并报告的配置、在一段时间内未导致功能问题。  

此致、
j