[参考译文] DS250DF230：CDR 锁定不稳定

您好！

假定 RX1上的 CDR 锁定不稳定、无论交叉点配置如何、我是正确的吗？

CPU 和 RX1之间的插入损耗是多少？  是否有过均衡的机会？  CPU 发送的信号的 VOD 是多少？

谢谢。

德鲁

您好、感谢您的答复。

问题的结果是：

・无论交叉点配置如何、假定 RX1上的 CDR 锁定不稳定时、该方法是否正确？ ⇒ 正确。

关于 CPU 和 RX1之间有多少插入损耗的・？ ⇒ 在12.5Ghz 时约为-4dB。

・ 是否有过均衡的机会？ ⇒ 也许是有可能的。

・CPU 发送的信号的 VOD 是多少？ ⇒约为300mV。

如需更多信息、
基板材料为 Megtron 6。 导线长度如图中所示。

您好！

感谢您提供更新。  我有几个实验来尝试、看看这会如何影响 CDR 锁定稳定性。

1)是否有可能增加 CPU VOD？  这似乎有点在低侧。  我想知道 CPU VOD 在600 mVpp - 1000 mVpp 范围内是否会提高 CDR 锁定的稳定性。

2) 2)启用调整模式2和 DFE。  这样使得器件能够同时适应 CTLE 和 DFE。  DFE 有助于改善信号眼图。

3) 3)如果 CPU 信号的均衡程度过高、我们可以尝试几种方法来解决这个问题。  一种是启用 CTLE 升压覆盖并手动设置 CTLE。  从您发送的屏幕截图来看、CTLE 似乎是3。  我会尝试从3开始向下工作、以查看眼睛是否改善。  DS250DF230还具有 CTLE 旁路功能、该功能绕过4个 CTLE 升压级中的3个级。  这可以通过设置 ch_reg_0x2D[3：2]来启用。 = 2'b11.  有关更多详细信息、请参阅编程指南。

请尝试这些实验、并观察每个实验的 CDR 锁定稳定性和重定时器 HEO/VEO。  我认为这些实验的结果将帮助我们确定 CDR 锁定不稳定的根本原因。

谢谢。
德鲁

您好！

感谢您的建议。
我会等待客户的反应。

谢谢。

您好！

谢谢、当您听到后面的内容时、请告诉我。

谢谢。

德鲁

您好！

在实验前、我们的客户询问了我们有关情况。

他们在测试01配置中使用"SigCon Architect"观察"眼图监视器"。

观察 CPU 端回送中的"眼图监视器"。
CPU (LX2160A)--> DS250DF230 --> CPU (LX2160A)

此外、作为比较检查、请观察 SFP28侧环回的"眼图监视器"。
SFP28 --> DS250DF230 --> SFP28
SFP28侧通过25G 收发器(25GBASE-SR)连接到另一个设备(光纤网管交换机)。

工作表"TEST_01A"中找到 attachede2e.ti.com/.../25G_5F00_Retimer_5F00_setup_5F00_01A.xlsx
"SigCon Architect"上的每个屏幕均已连接。
(左侧两个屏幕是[CH0]，右侧是[CH1])

由于 DS250DF230的交叉点未切换、因此猜测如下。
[ch0] SFP28环路(SFP28 --> DS250DF230重定时器--> SFP28)
[CH1] CPU 环路(CPU --> DS250DF230重定时器--> CPU)

此外、设置和操作启动与"TEST_01"相同、但仅有以下几项。
1"重置设备"
2"适用于所有通道"
3"复位 CDR 所有通道"

[ch0] SFP28侧上的输入信号是稳定的、
另一个设备(光纤管理交换机)端保持链路接通状态。
・从 SFP28检测到的输入信号(RX0)信号正常
・来自 SFP28的输入信号(RX0)的 CDR 锁定状态稳定

从随附的"25G_Retimer_setup_01A.xlsx"中表格"test_01A"行197可以看出是"眼图监视器"屏幕。
与来自[CH0] SFP28的输入信号(RX0)的状态相比、来自[CH1] CPU (LX2160A)的输入信号(RX1)的电压电平稍低、眼图稍小。
他们认识到、这三个实验将确认此眼图是否得到改善以及 CDR 锁定是否稳定。

"眼图监视器"屏幕仅从第287行添加到[CH1]。
使用"单捕获"多次观察时、可能会发生这种情况。
这是什么状态？
顺便说一下、它不会在[CH0]中发生。

在进行验证实验之前、您能否对这种情况做出评论？

您好！

感谢您的更新。  眼图监视器依赖于 CDR 锁定、因此我不认为在 CDR 解锁的情况下、眼图监视器结果对 CH1有效。

关于 CH1被锁定的眼图测量(第287行)、这看起来非常奇怪、并且与 GUI 报告的 HEO/VEO 不匹配。  从"误差命中密度"来看、链路在眼图测量的一部分好像是朝下、而在另一部分是朝上。  这很奇怪。  在这些配置中是否观察到一致的 CDR 锁定？  线路197处的 CH1眼图测量与线路287处的 CH1眼图测量之间是否存在配置差异？

请尝试之前建议的一些实验、并告诉我这是否会提高 CH1 CDR 锁定的稳定性。

谢谢。

德鲁

您好！

客户报告了试验的结果。

结论、CDR 锁定不稳定。
即使仅使用建议的条件、它也不起作用、即使在将 REG 0x84[0]中的 VGA_SEL_GAIN 设置为"1"并进行确认后、结果也没有改变。 (在他们的环境中、CPU VOD 固定在300mV、因此我建议设置< 600mVppd)

他们说重定时器 HEO 看起来是稳定的、但有时 CDR 锁定会被释放。

附件是为验证而创建的 Linux shell 脚本的数据。

e2e.ti.com/.../test_5F00_01_2D00_03_5F00_20230217.txte2e.ti.com/.../test_5F00_01v_2D00_03v_5F00_20230217.txt
有关验证详细信息、请参阅随附的"TESTMEMO_20230217.txt"。

e2e.ti.com/.../TESTmemo_5F00_20230217.txt

此外、他们了解到、当 CDR 锁定时、眼图监视器会变得有效、因此他们似乎没有观察到 CDR 锁定不稳定的情况。
如果有任何其他必要的数据或信息、我们将要求您提供。
如果您能建议一些解决方案、我将不胜感激。

您好！

感谢您分享验证日志。  是否有可能在这个日志中包括寄存器0x02？  寄存器0x02包含有关 CDR 锁定以及门控 CDR 锁定的其他详细信息。

另一个问题：CPU 启用了链路训练还是自动协商？  如果可以、是否可以禁用它们以进行测试？  重定时器不支持链路训练、因为它没有线性信号链。  如果系统中需要自动协商、可以通过为无法锁定的数据启用 CDR 旁路来支持。 有关此内容、请参阅编程指南的第7.34节。

谢谢。
德鲁

您好！

客户报告了试验的结果。

结论、CDR 锁定不稳定。

以下是我们对您每一项的报告。

>-是否可以在此日志中包含寄存器0x02？
>>寄存器0x02包含有关 CDR 锁定和控制 CDR 锁定标准的更多详细信息。

⇒附件(e2e.ti.com/.../TEST_5F00_memo_5F00_20230302.txt)中的以下注释部分是相关日志。
REG_0x02[7：0]=添加了 CDR_STATUS。

> CPU 上是否启用了链路训练或自动协商？
>如果是,是否可以禁用它们以用于测试目的?
>如果您的系统需要它,您可以通过为无法锁定的数据启用 CDR 旁路来支持它。 更多相关信息、请参阅编程指南的第7.34节。

⇒我们已确认在 CPU 端禁用了链路训练和自动协商。
⇒关于启用 CDR 旁路、随附文件(TEST_MEMO_20230302.txt)中的以下注释即为相应的日志。
CDR 旁路、预锁定=原始数据、后=重定时数据
CDR 旁路、预锁=原始数据、后锁=原始数据
-->当预处理和后处理都设置为原始数据时，链接状态已稳定。

⇒我还尝试了启用/禁用 FEC 功能。
随附文件(test_memo_20230302.txt)中的以下注释为相应的日志。
将 RS-FEC 设置更改为不带 FEC 的设置。

就这些。
我很抱歉继续重复这一点，但我感谢你提出任何意见。

此致、

e2e.ti.com/.../test_5F00_01_2D00_03_5F00_cdr_5F00_bypass_5F00_pre_5F00_20230224.txte2e.ti.com/.../test_5F00_01_2D00_03_5F00_cdr_5F00_bypass_5F00_pre_5F00_post_5F00_20230224.txt

e2e.ti.com/.../test_5F00_01_2D00_03_5F00_reg_5F00_0x02_5F00_20230224.txte2e.ti.com/.../test_5F00_01v_2D00_03v_5F00_cdr_5F00_bypass_5F00_pre_5F00_20230224.txt

e2e.ti.com/.../test_5F00_01v_2D00_03v_5F00_cdr_5F00_bypass_5F00_pre_5F00_post_5F00_20230224.txte2e.ti.com/.../test_5F00_01v_2D00_03v_5F00_reg_5F00_0x02_5F00_20230224.txt

您好！

感谢您的更新并感谢您继续完成此过程。  我知道这一行为已经持续了一段时间、而且难以确定根本原因。  我正在查看日志、并计划明天提供详细的更新。

谢谢。

德鲁

您好！

很抱歉耽误你的时间。  通过查看日志、很遗憾、我没有看到任何有关 CDR 锁定丢失的清晰答案。

我有几个想法和问题。

您在前面已经提到过，除了 CPU --> SFP，SFP --> CPU 的典型配置外，还可以测试 SFP --> SFP 和 CPU --> CPU。  您能否说明在哪些配置中观察到链路不稳定？

也感谢您确认 CPU 上的链路训练和自动协商已禁用。  是否在链路伙伴上偶然启用了这些功能？

一种想法是尝试使用调整模式0进行测试。  这将禁用 CTLE 和 DFE 自动调整、因此需要手动设置。  回顾一下您之前分享的配置、Ctle 和 DFE 似乎主要适应0、因此这可能是一个合理的设置。

其他一些想法：

-向重定时器提供输入信号后,您是否在读取 CDR 状态之前为 CDR 锁定提供了足够的时间?  CDR 锁定采集时间小于100ms。

-有时在 ASIC 或模块为重定时器提供信号的任何初始化/配置过程中,将重定时器 CDR 保持在复位状态会有所帮助。  是否有可能查看这是否会影响重定时器的行为？

谢谢。

德鲁

你好。 感谢您回答我的问题。
我收到了一位客户对我的建议的回复和另一个问题。
下面列出了这些测试点。

[问题+答案。
(1)>之前您提到、除了典型的 CPU 配置(CPU--> SFP、SFP --> CPU)外、还可以测试 SFP --> SFP 和 CPU --> CPU。  

  >您能否说明在哪些配置中观察到链路不稳定？

(1个答案)
在 CPU→Retimer→SFP 和 SFP→Retimer→CPU 配置中⇒
由于链路在两个方向上都不工作，因此我们未启用交叉点(在易于验证的配置中)。
CPU→Retimer→CPU、SFP→Retimer→SFP 配置。
在这种情况下、达到了以下条件
在 SFP→Retimer 方向上、CDR 锁定保持稳定并且链路建立。
在 CPU→Retimer 方向上、CDR 锁定不稳定、不执行链路建立。

(2)> 还感谢您确认在 CPU 上已禁用链路训练和自动协商。  

  >在链路伙伴上是否偶然启用了这些功能？
 

(2个答案)
⇒我们不确定您的问题是什么,但我们有两个链接合作伙伴。
两个链路伙伴的链路训练和自动协商均保持禁用状态。

(3)>如何使用 ADAPT 模式0进行测试？
 >这将禁用 CTLE 和 DFE 自动调整，因此需要手动设置。  回顾一下您之前分享的配置、Ctle 和 DFE 似乎主要适应0、因此这可能是一个合理的设置。

(3个答案。)
⇒我已经检查过、结果没有变化。
CDR 锁定将保持不稳定。

(4)-在向重定时器提供输入信号后、是否在读取 CDR 状态之前为 CDR 锁定提供足够的时间？  

   CDR 锁定采集时间小于100ms。

(4个答案)
⇒是。
等待1秒以读取 CDR 状态。

(5)> 有时在 ASIC 或模块上为重定时器提供信号的任何初始化/配置过程中、将重定时器 CDR 保持在复位状态会有所帮助。  是否有可能查看这是否会影响重定时器的行为？

(5个答案)
⇒我们已经检查过，结果没有变化。
CDR 锁定保持不稳定。

(6-额外确认请求)
由于在先前的验证中链路状态是稳定的、因此执行了以下验证。
执行了以下验证。
> CDR 旁路、预锁定=原始数据、后锁定=原始数据
>当"预处理"和"后处理"都设置为"原始数据"时、链路状态稳定。

有关测试摘要、请参阅随附的"TEST_memo20230315"。
CPU→重定时器→SFP28 (CH-0)
SFP28→重定时器→CPU (CH-1)
两种配置设置之间的唯一区别在于以下部分。
CH-0
CDR 旁路、预锁=原始数据、后锁=原始数据
CH-1
CDR 旁路、预锁=静音、后锁=重定时数据

由于 CH-0、CPU→重定时器设置为 CDR 旁路、原始数据、CDR 锁定不稳定、但链路伙伴处于链路建立状态。
CH-1、SFP28→重定时器处于链路建立状态、且 CDR 锁定处于与之前相同的稳定状态。
使用此设置可以进行通信。
CPU <-->重定时器<--> SFP28 <--> 25G 收发器<-->光纤通信<--> PC (25G)

从目前的验证结果来看、CDR 锁定的不稳定性似乎是由一种模式而不是信号电平导致的。

就这些。
我很抱歉重复了我自己的经历，但提前感谢您的耐心。

e2e.ti.com/.../TEST_5F00_memo20230315.txte2e.ti.com/.../sfp28_5F00_retimer_5F00_setup_5F00_cdr_5F00_bypass.txte2e.ti.com/.../sfp28_5F00_retimer_5F00_setup_5F00_cdr_5F00_reset.txte2e.ti.com/.../sfp28_5F00_retimer_5F00_setup_5F00_init.txt

您好！

感谢更新和更多详细信息。   

Unknown 说：

⇒在 CPU→Retimer→SFP 和 SFP→Retimer→CPU 配置中。
由于链路在两个方向上都不工作，因此我们未启用交叉点(在易于验证的配置中)。
CPU→Retimer→CPU、SFP→Retimer→SFP 配置。
在这种情况下、达到了以下条件
在 SFP→Retimer 方向上、CDR 锁定保持稳定并且链路建立。
在 CPU→Retimer 方向上，CDR 锁定不稳定，未执行链路建立。

基于这一观察结果， 由于 CPU -->重定时器--> CPU 不稳定，而 SFP -->重定时器--> SFP 具有稳定的 CDR 锁定和链路接通，因此 CPU 的行为似乎在 CDR 锁定不稳定中起着关键作用。  在 SFP -->重定时器--> CPU 中，重定时器是否具有一致的 CDR 锁定？  我假设 IN CPU -->重定时器--> SFP，CDR 锁定不稳定。

您提到、您认为 CDR 锁定有一些模式依赖性。  是否可以从 CPU 仅发送 PRBS 模式并查看重定时器的行为？

我还有一个额外的实验。  我想知道增加 CDR 带宽是否有助于实现 CDR 锁定稳定性。  是否有可能尝试几种不同的 CDR 带宽设置、看看这会如何影响 CDR 锁定稳定性？  有关 CDR 带宽的详细信息可在编程指南的第7.31节中找到。

谢谢。

德鲁

您好！

感谢您的答复。

我们的客户的试验结果和确认得到了回答。

在 SFP --> Retimer --> CPU 中，CDR 锁定对于重定时器是否稳定？ 在 CPU -->重定时器--> SFP 中，我认为 CDR 锁是不稳定的。

(答案。)
CPU -->重定时器--> SFP28 (Retimer : CH-0)
：CDR 锁定不稳定，链路状态继续

SFP28 --> Retimer --> CPU (Retimer : CH-1 )
CDR 锁定稳定、链路状态继续

CPU <-->重定时器<--> SFP28 <--> 25G 收发器<-->光纤通信<--> PC (25G)
25G 收发器(25GBASE-SR)
在通信期间附加日志。
e2e.ti.com/.../4034.sfp28_5F00_ping_5F00_test_5F00_log_5F00_01_5F00_20230320.txt
执行脚本
。 / sfp28_retimer_status.sh 120 0 2 (SFP28 0端口)
。 / sfp28_retimer_status.sh 120 1 2 (SFP28 #1端口)

输出方向(CH 0)
CPU -->重定时器
监控 SD/CDR 状态、HEO、重定时器的 VEO
重定时器--> SFP28.
SFP28侧监控25G 收发器中的 CDR 锁定状态
输入方向(通道1)
SFP28 -->重定时器
监控 SD/CDR 状态、HEO、重定时器的 VEO
重定时器--> CPU
CPU 端监控 MAC (PCS)层链路状态

您刚才提到、您认为 CDR 锁定中有一种模式依赖关系。

(答案。)
我们不知道。
当 CDR 锁定被释放时、它看起来只是周期性的。

(问题)
是否可以通过仅从 CPU 发送 PRBS 模式来检查重定时器的行为？

(答案)
⇒验证环境与我们所做的以下测试相同。
CPU -->重定时器-->重定时器
SFP28 -->重定时器--> SFP28
禁用链路训练和自动协商。
无 FEC

观察 CPU -->重定时器的 CDR 锁定状态
TEST_01-03
测试01V - 03V (eq_VGA = 11)

在此测试中、CPU 仅发送了7个 PRBS 模式。
附上了观察 CDR 锁定状态的结果。
(请访问 e2e.ti.com/.../6786.TESTmemo_5F00_cdr_5F00_bandwidth_5F00_20230320.txt)

作为附加的实验、我们想知道是否可以通过增加 CDR 带宽来提高 CDR 锁定的稳定性。

是否有可能尝试几种不同的 CDR 带宽设置、看看它们对 CDR 锁定稳定性的影响？

(答案。)
⇒验证环境与我们所做的以下测试相同。
CPU -->重定时器-->重定时器
SFP28 -->重定时器--> SFP28
禁用链路训练和自动协商。
无 FEC

观察 CPU -->重定时器的 CDR 锁定状态
TEST_01-03
测试01V - 03V (eq_VGA = 11)
将 CDR 带宽设置添加到此测试中。
附上了观察 CDR 锁定状态的结果。

就这些。

很抱歉重复、但我们感谢您的验证。

e2e.ti.com/.../5504.test_5F00_01_2D00_03_5F00_reg_5F00_0x02_5F00_CDR_5F00_W_5F00_20230320.txte2e.ti.com/.../2117.test_5F00_01_2D00_03_5F00_reg_5F00_0x02_5F00_PRBS7_5F00_20230320.txte2e.ti.com/.../2816.test_5F00_01v_2D00_03v_5F00_reg_5F00_0x02_5F00_CDR_5F00_W_5F00_20230320.txte2e.ti.com/.../1512.test_5F00_01v_2D00_03v_5F00_reg_5F00_0x02_5F00_PRBS7_5F00_20230320.txt

您好！

是否可以设置电话来讨论此问题？  我知道这已经在调试中了一段时间、我想知道某个电话是否可以帮助我们更有效地解决问题。

谢谢。

德鲁

大家好。

很抱歉花这么长时间联系您。
我们也正在重新确认有关客户的呼叫申请的信息。
我让客户测量 CPU --> SFP28信号、但他回答说很难确认。

他们表示、如果要测量信号、则必须查看重定时器输入级的信号、但对于 BGA、则必须稍微切断图形以查看波形、 但是、根据他们过去使用10GbE 的经验、由于存在残桩、他们无法准确测量这个问题。
这次、由于它是25GbE、因此会更加困难。
他们没有用于测量25GbE 级别的设备、因此由于预算限制、很难将测量外包给第三方。

此外、还有一个问题是、当绕过重定时器内部时、具有内置25G 收发器的 CDR 会被锁定、您如何看待这一事实？

您好！

感谢与客户合作解决这个问题。

他们是否有适用于 CPU TX 的渠道模型和模型？  如果无法进行测量、也许我们可以尝试 IBIS-AMI 仿真、以查看它是否有助于我们理解问题。

Unknown 说：

另一个问题是，绕过重定时器内部时，带有内置25G 收发器的 CDR 会被锁定，您认为这是什么？

这表示是导致重定时器 CDR 失锁的原因、但具体情况尚不清楚。  假设重定时器输入具有适当的信号质量、并且数据速率与重定时器 CDR 设置的值相匹配、则更常见的问题之一是输入具有高抖动。  不过、通常、增加重定时器 CDR 带宽可以对此进行补偿。

某些系统中的另一种可能是重定时器无法锁定至 A 信号、但客户表示禁用了 AN 和 LT。

谢谢。

德鲁

您好！

感谢您的建议。
我与一位客户进行了交谈。

关于前面的问题"他们是否有适用于 CPU TX 的通道模型和模型？" 客户运行仿真并更改了 CTLE 和 DFE 值、而客户的眼图得到了改善客户报告说在更改 CTLE 和 DFE 值后、眼图得到了改善。
作为附录、他说基板材料是互斥6、并且信号线是内层的。

我还要回答有关在绕过上次讨论的25G 收发器中的重定时器内部时 SFP 内部 CDR 锁定的问题。
由于客户使用的是25.78125Gbps、我相信正确的用法是在数据表中将其设置为"Enabled"。
是否适合在此数据速率范围旁路掉 IC？ 此外、是否存在任何担忧？

还有一点、我们正在使用25Gbps 的默认 CPU 设置、将速率 ReG_0x2F[7：4]保留为默认值是否安全？
在什么情况下您会使用6？
与默认设置有何区别？

我很抱歉问了这么多问题、但如果您能帮助我、我将不胜感激。

您好！

很抱歉耽误你的时间。  很高兴听说他们在调整 CTLE/DFE 值后能够改善眼图。  我想我们曾建议使用调整模式0、此时需要手动设置这些模式。  调整 CTLE/DFE 后获得的眼图值是否优于使用调整模式2时获得的眼图值？

由于客户使用的是25.78125Gbps、因此启用 CDR 是正确的。  但是、由于 CDR 锁定丢失、这似乎也是导致出现问题的根本原因。  通常、没有必要在该数据速率下使用 CDR 旁路、尽管可以。

我们想到的 CDR 锁定丢失的原因有：

• 未满足 HEO/VEO 阈值
• PPM 不好
• 转换不足

是的、对于25G、默认值5应该没有问题。  如果您希望重定时器能够锁定到25.78125Gbps 或10.3125Gbps 信号、则可以使用案例6。  这对于与10GbE 和25GbE 兼容的系统非常好。

我的另一个问题是客户是否测量了他们的参考时钟、并确认它看起来不错。  通常、这不是我参与的调试案例中的问题、而只是额外思考。

谢谢。

德鲁

您好、很抱歉耽误了我们的时间。

我询问了客户的反应、好像还有一件紧急的事情需要处理、所以我们还不知道之后发生了什么。
他们将在5月后再次检查,然后我会告诉你的结果。

非常感谢您的支持。

您好！

感谢更新、没有关于延迟的问题。  当客户有带宽时、我们可以继续对此进行调试。

谢谢。

德鲁