[参考译文] DS110DF111：端口不是每16个重新启动周期启动一次

Mark，您好！

这似乎是异常行为，并不是我以前遇到的具体情况。  能否提供重新计时器与 SFP+模块和处理器之间插入损耗的估计值。

此外，您是否可以提供常规操作和异常状态的寄存器转储。

谢谢，

绘制

谢谢 Drew，

我们认为这可能是链路处理器端的问题，但下面列出了工作状态和不良状态之间的 REG 差异。 我还有关于汽车谈判的问题。 我们的处理器接口设置为在启动时使用1000BaseX 自动协商链路速度。 我在重计时器中看不到自动协商设置。 这可能不是必需的，因为它只是一个重新计时的“管道”。 这是否意味着处理器正在自动协商与重计时器另一侧连接的内容-在我们的情况下是 SFP 模块？

再次感谢

标记

Mark，您好！

为了回答您关于自动协商期间重新计时器如何工作的问题，我们希望它在协商期间锁定到1.25Gbps 的自动协商信号， 然后在协商后锁定到10.3125 Gbps 信号(假设您使用的是默认数据速率，如果不是这种情况，请告诉我)。  当锁定到自动协商信号时，它应该只通过自动协商数据。

似乎由于某种原因，每16次重新启动，重新计时器都无法实现 CDR 锁定。  我们可以看到，CTLE BOOST 设置已更改，这表明重新计时器确实尝试调整 CTLE。

令人困惑的是，CDR 重置后该链接不会出现。  您能否检查执行 CDR 重置是否使设备实现 CDR 锁定？  如果自动协商失败，处理器是否继续发送数据？  重新计时器需要将有效数据锁定到才能生效。

另一个想法：我们可以通过从调整模式2 (默认) ch_reg_0x31[6:5]更改为调整模式0来排除重新计时器上的任何自适应问题。  自适应模式0没有自适应。  您需要手动设置任何您认为最优的 CTLE 和 DFE 值。  我提出这一问题的原因是，假设 CTLE 索引0正常工作，那么在失败的寄存器集中，CTLE 值似乎相当高。

谢谢，

绘制

您好，Drew，

我们已将此范围缩小到 TI 交换机。 我们的 Marvell 处理器使用两个 XCVR 连接到 SFP (通过重计时器)。 一个是固定的和10G，另一个是固定的1G (这在处理器配置中有多种原因)。 这两个 XCVR 连接到双向开关 TMUXHS4212IRKSR，该开关选择两个 XCVR 数据中的一个，以传递到计时器，同样也是在另一个方向。 我们以前没有将此开关视为问题的一部分，而是专注于处理器和重新计时器，但是，这种开关似乎正在进入某种延迟状态，并且不允许数据双向传输？ 如上所述，这种情况并非每次都发生，而是似乎每16个端口出现周期发生一次？ 有什么想法吗？  

再次感谢您的持续帮助。

此致

标记

Mark，您好！

很高兴听到您能够缩小问题范围！  我将跟进一位支持  TMUXHS4212的团队成员，并就此与您联系。

谢谢，

绘制

Mark，您好！

您的1G 信号的电压摆动是多少？

谢谢，

绘制