This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TNETE2201B:SYNC 问题

Guru**** 2586055 points
Other Parts Discussed in Thread: TNETE2201B

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/977447/tnete2201b-sync-issue

器件型号:TNETE2201B

尊敬的技术支持团队:

当接收到特定数据时、 由 RBC0提供的62.5MHz 时钟波形继续异常。

此时、K28.5会 定期输入、但 SYNC 不会显示高电平(SYNCEN 启用)。

并非总是发生此问题(有时会发生)。

当更改 LCKREFN、例如高→低→高时、输出正确的62.5MHz 时钟、SYNC 也是高电平。

因此、我想 CDR 在同步问题期间不会锁定。  

■接收到同步模式  

TNETE2201B 按照模式连续接收。

/K28.5/D21.5/D0.1/D0.0/或 K28.5/D2.2/D0.1/D0.0/

有关 RBC0的 μ■行为

当一个问题发生时、经确认、在输出一个正常的62.5MHz 时钟5个周期后、它在上升沿被拉伸一次、在下降波形上被拉伸一次。 之后、该状态会重复出现

如果差分输入(K28.5)为零、则 RBC0的输出时钟会改变相位、 而 TNETE2201B 会将 RBC0的时钟拉伸一次。
我认为这是正确的器件规格行为(图2。 数据表上的字重新调整时序特性波形)、用于 K28.5字符检测。

■问题

①Is  当 SYNC 尚未处于高位且 CDR 尚未锁定时、RBC0作为器件的预期行为(扩展时钟两次)是什么?

②Have 您曾见过此同步和 RBC0问题吗?

③Please 调查此事件的路由原因并确认其纹波。

  例如,是否出现除 Autonego 代码 (/K28.5/D21.5/D0.1/D0.0/或 K28.5/D2.2/D0.1/D0.0/)以外的问题 ?

此致、

TTD

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的技术支持团队:

    您目前是否有任何更新?

    我认为 CDR 通常不会锁定以下情况。

    电源噪声为・μ V

    ・REFCLK 具有一些抖动。

    ・Ω 输入串行数据具有一些抖动

    此致、

    TTD

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    实验中给出的 LCKREFN 已置位且器件能够锁定、这意味着我们已重新启动或重新启动 PLL 锁定过程。 如数据表"接收 PLL 操作"中所述、传入数据中的任意相移会导致 PLL 尝试锁定。 电源噪声似乎可能会导致 PLL 漂移、因此在进行电源滤波时应特别注意。  

    此致、Nasser

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Nasser、

    感谢你的答复。

    PLL 尝试重新锁定、例如"接收 PLL 操作"、但 PLL 是否可能无法在2.4us (输入数据相移)和500us (上电场景: 我的设置是 Rc0和 RC1 = 2.2nF)内锁定?

    此外、如果在重新锁定期间电源或输入数据不稳定、是否会发生上述情况?

    μ■"接收 PLL 操作"的描述

    µs 在正常运行期间发生瞬态、此瞬态被定义为传入数据中的任意相移和/或高达200ppm 的频率漂移、那么 PLL 将在2.4 μ s 内恢复锁定。 µs µF 这些值的任何条件都被视为上电情况、PLL 在500 μ s 内使用0.1 μ F 电容器恢复锁定。PLL 在上电后的10ms 内恢复锁定(请参阅以下注释)。

    此致、

    TTD

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    如果传入数据(相移或拉伸)存在不稳定性、或者存在电源噪声、则可能会导致 VCO 控制电压漂移、从而导致无法锁定或以高位错误锁定。 最好先使用干净的实验室电源、以确保此问题不会导致电源噪声。  

    此致、Nasser

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Nasser、  

    我知道传入数据的不稳定性和电源上的噪声会导致 PLL 解锁。

    顺便说一下、您是否曾遇到过我的 RBC0问题(扩展时钟两次)?

    也许、当地的 TI FAE 会向您发送有关此问题的文档详细信息。

    下面 的特定模式有时不会看起来 PLL。  

    /K28.5/D21.5/D0.1/D0.0/或 K28.5/D2.2/D0.1/D0.0/

    此器件将 K28.5 (-RD)检测为逗号、因此如果收到 K28.5 (+RD)、则跳过检测逗号(平均同步保持低电平)、对吧?

    预期边界上的■逗号字符(第7页)

    --------------------------------------------------

    K28.5字符在光纤信道标准中定义为包含0011111010 (以负数开头的视差)的模式

    7个 MSB (0011111)称为逗号字符。 K28.5字符专门用于对齐数据字。

    --------------------------------------------------

    此致、

    TTD

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    我确实看到您之前的演示显示了由于空闲字符(K28.5)而使 RBC0拉伸两次。 鉴于其他客户尚未报告这种情况、K28.5在光纤通道中非常常见、我想知道您使用的数据模式是否有特定的内容。 RBC0是经过分频的恢复时钟。 一种可能是传入数据速率可能处于裕度上。 例如、您能否确认传入数据速率为1.25Gbps+/-0.01%或100ppm 以内?  我想知道、这可能是为什么我们看到在这种情况下 RBC0拉伸、导致 VCO 控制电压漂移的原因。 然后、通过应用 LCKREFN、它再次重新居中。

    此致、Nasser

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Nasser、  

    感谢你的答复。

    我不知道为什么它不锁定。

    由于它发生在/ C /=/ D0.1 / D0.0 /或/ D0.1 / D0.2 /时、是否可以在 TI 实验室中重现此事件?

    它并不总是失败、因为它的发生概率会随着 LCKREFN 返回、因此似乎有一个对位模式的依赖、即 CDR 有时不能很好地工作。

    ■时钟偏差

    测量仪器连接到另一侧时的偏差为-3.3ppm、处于指定值范围内。
    该测量仪器可更改偏差为±100ppm 的时钟。
    作为一项试验、我们确认了+100ppm (实际测量值为100.7ppm)和-100ppm (实际测量值为-99.3ppm)的频率、然后确认该事件在所有状态(包括0ppm)中均得以再现。此外、我们还确认了多种器件类型彼此面对原因事件、 我们预计、由于接收时钟的偏差、原因很低。

    ■清洁电源

    我们连接了一个外部清洁调节电源并进行了复制测试、但即使在外部电源状态下、我们也确认了事件的重现。

    ■补充信息

    我将通过 TI FAE 分享文档的详细信息。

    我不知道它是否有用、但我还在事件发生时测量了 RBC0的频率。
    测量结果在随附的文件"补编1"中进行了说明。
    考虑到时钟扩展、PLL 似乎拉入了正确的时钟。
    此外、如"补编2"中所述、当 RBC0为"H"时发生拉伸的事实与未输入数据表或差分时观察到的波形不同、这可能是一个提示。 思考。
    对于由此给您带来的不便、我们深表歉意、但我们希望您也可以参考这一点。

    此致、

    TTD

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    感谢您向我发送演示文稿。

    您能否告诉我、如果您对 SYNCEN 引脚进行脉冲、这是否会清除延伸的 RBC 时钟?

    此致、Nasser