[参考译文] LMK04828：意外的双倍步进和数字延迟

Alberto、

很抱歉耽误你的时间。   我已经在实验中对此进行了测试、我可以在实验中重复您的问题。   

修复方法是确保  将 DCLKoutX_DDLYd_CNTH/L 和 DCLKoutX_DDLY_CNTH/L 设置为相同的值。   

此致、

会的

Alberto、

我明天将在实验中调试、看看我是否能找到其他东西。   

此致、

会的

Alberto、  

您能否共享测试此功能的寄存器写入、以便我可以测试您的配置。 如果您 也可以共享 TICSPRO .tcs 文件、这将非常有帮助。  

此致、

会的

您好、  

这是 TCS 文件内容

e2e.ti.com/.../LMK04828_5F00_PD87_5F00_5_5F00_feedback_5F00_CK6_5F00_v05.tcs

受监控的端口为端口 CLKout0

则手动过程为：

应用延迟" 正激 "我们设置了  

DDLY_PD H/L 更改为 4.

DDLKout0_DDLYdCNTH/L 更改为 4、 启用 DDLYd0_EN

并执行1个步骤

应用延迟" 向后 "我们设置了  

DDLY_PD H/L 更改为 3

将 DDLKout0_DDLYdCNTH/L 更改成了 3

并执行1个步骤

在我们的测试中、我们不使用手动过程、而是通过嵌入式控制器来控制芯片：

我们将时钟设置在时钟/数据眼图的中间

我们定义我们想要后退和前进的步数(steps_val)：  
*注:移动始终为1步,但重复"steps_val" 次
*注意:经过一个周期后,时钟/数据关系应回到相同的位置

我们定义周期数

运行测试

通过示波器进行监测时、我们可以看到、在"向后" 方向上、会跳过一个步骤

这一点得到确认、因为在几个周期结束时、与测试开始时相比、时钟/数据关系发生了变化

可以监控相同的结果、将受测的 CLK0与未应用延迟的另一个时钟进行比较

这是其中操作的简化代码快照
(steps_val 是步数)

while do_loop！= False：
睡眠(0.5)

I = 0
##Forward (前进)
WRITE_CLK_DIST (0x0102、0x44、1)
WRITE_CLK_DIST (0x0101、0x44、1)
当我!=步骤 val :
睡眠(0.5)
WRITE_CLK_DIST (0x0142、0x01、1)
i = i+1
睡眠(0.5)

I=0
##后退
WRITE_CLK_DIST (0x0102、0x33、1)
WRITE_CLK_DIST (0x0101、0x33、1)
当我!=步骤 val :
睡眠(0.5)
WRITE_CLK_DIST (0x0142、0x01、1)
i = i+1

睡眠(0.5)

如果这样做有帮助、请告诉我

另一条评论将：  

我们可以使用 GUI 提取命令以发送 DDL_PD 设置、但此寄存器(CLKout0为0x0102)似乎 不存在于数据表中  

谢谢

Alberto、

感谢您发送编修。  我正在继续对此进行调查。

此致、

会的  

Alberto、

我已经被圈进来提供我的想法。 我离开办公室的时间很长、因此需要一点时间才能了解完整的背景信息。

目前、我记得 LMK04828-LMK04828数据表中的一条注意事项、我从未有机会重新移植回 EP 数据表。 我不确定这是否适用于您的情况、因为您的频率看起来足够高、可以避免此问题、并且考虑到对后果的描述(省略延迟步骤)似乎与您的问题描述(额外的延迟步骤)相矛盾。 但我会在以防万一的情况下发布它。

我将继续思考这一点、并在周一美国时间提供更多想法。

尊敬的 Derek、感谢您的支持

我同意这似乎不适用：  

我们所有的时钟均为350M

我们始终执行1步调整(重复 N 次、每次1步)

给定 SW 回路、调整之间的延迟大于(70ns + 2.8n 周期)  

如果您有其他注意事项、请随时告诉我们

谢谢  

Alberto、

我们仍在研究该主题、一旦我们获得更多信息、我们将向您提供更新。

此致！

Andrea

据我所知、我从未见过有人要求后退一步。 可能尚未对其进行验证。

我暂时离开实验室、因此无法自己进行测试、但我会将结果传递给团队的其他成员进行尝试。 同时、如果您的设置允许：

• 理论1：DCC+HS 和动态延迟之间的相互作用
  • 当 DCC+HS 开启时、一半时钟边沿与 VCO 的下降沿对齐、而不是上升沿对齐。 这可能会为 VCO 周期的计数创建竞态条件、或者可能会以意外的方式重复计数。
  • 要测试 DCC+HS 是否影响动态延迟函数、您可以将 DCLKoutX_MUX 设置为仅分频器并重复测试。
  • 您还可以尝试将 CNTH 编程为4并将 CNTL 编程为2 -也许 DCC+HS 需要 CNTH 对奇数除法求和？
• 理论2:有些东西是奇怪的分歧
  
  • 没有详细的机制、只是奇数除法比较奇怪
  • 我们可以测试具有偶数分频的交替频率(带或不带 DCC+HS、对于偶数分频、它应该不会产生任何差异)、并查看是否发现了该问题。
• 理论3:某种东西是很奇怪的,有分歧< 8.
  • 通常、同时是可编程且支持超出2次幂步进值的值的高速分频器需要大量设计开销才能正确实现。 动态数字延迟可能会出现未被观察到的问题、因为对于原始动态延迟验证中使用的测量设备而言、观察到的值频率过高。
  • 我们再次可以测试具有高/低分频值的交替频率、并查看是否发现了该问题。

我认为您应该至少能尝试理论1、以及理论2或理论3的一些简单案例(8分频、9分频)。 我们还可以在最后尝试所有这些、前提是明天我可以让其他人在实验室中进行设置。

尊敬的 Derek：  

我还暂时离开实验室几周、所以我会看看我的同事是否有机会测试其中的一些选项

BTW、可能无法更改分频器 ： 鉴于我们需要生成350M 时钟、唯一适合这两个 VCO 范围的频率实际上是带7分频器的电流(2450)

350乘以  x7 = 2450、x8=2800、x9=3150

• VCO0：2370-2630
• VCO1：2920-3080

如果我们能够进行一些测试、我会让您随时关注最新情况

太好了、我们将尝试在最后执行相同的测试

我知道您的应用可能受困于您选择的分频器值、我的目的纯粹是获取替代数据点、而不考虑最终的输出频率、即通过更改参数和观察结果行为来调试分频器。 在任何情况下、我们都有您的.tcs 文件、因此我们简单地自己执行这些测试。

Alberto、

我只是想为您提供更新。  我仍在尝试重现您的问题、并尝试我们的潜在解决方案。  我会在发现新内容时向您通报最新情况。

此致、

会的

您好、  

仅供参考、我们昨天使用 Derek 建议的偶数分频器测试了配置：  

分配器8  

向前 ： _CNTH =  4.  并且_CNTL =  5
反向运行：_CNTL =  3.  并且_CNTL =  4.

结果仍然相同:"向后"方向上的错误

William 抱歉,我更正了我以前的消息:

向前 ： _CNTH =  4.  并且_CNTL =  5
反向运行：_CNTL =  3.  并且_CNTL =  4.

结果仍然相同:"向后"方向上的错误

[报价]

结果是、即使我们要求执行1步、我们有时也会观察到"双步"、这种情况在反向和正向两种方向上都会发生  

Alberto、

感谢您提供的信息。  在创建与您所示脚本类似的脚本后、我终于能够重现您的问题。  我将尝试 Derek 的建议,看看是否有任何方法找到这些故障的根本原因。

此致、

会的

Alberto、

我只是想提供一个更新。  由于经历了数千个延迟步进、我无法可靠地重现干扰。  您能够复制的频率如何？   

只要知道我们在继续努力寻找根本原因、我们就会感谢提供任何补充信息。

此致、

会的

让我快速澄清一下-我们重复了几天前报告的问题、但在重新审视测试设置以进行更广泛的评估后、我们无法再次重现这些问题。 某些设置步骤可能必须/不得执行、这会在某些情况下导致动态延迟按预期工作、但在其他情况下偶尔会失败。 我们知道某种事情肯定在发生、因为我们已经看到了这种情况、但不清楚一周前发生了什么变化。

我们提供了用于评估动态延迟功能的伪代码以及包含初始寄存器设置的 TCS 文件。 在测试过程中是否采取了任何其他步骤？ 例如、您是否同步了分频器？ 我看到您的初始 POST 表示输出与输入同步、我不确定这是否意味着 PLL 已锁定、或者这是否意味着首先执行了同步过程、例如数据表第9.3.3.1节中的过程。

尊敬的 Derek：

该测试非常少、除了上电、没有额外的程序、加载 TCS 文件、目视检查我们要监测的参考时钟和时钟是否已锁定、然后运行测试(使用外部 SPI 控制器和 Python 脚本)。

有时、为了在开始时获得更简单的视觉参考点、我们已经对 TI 工具进行了手动移位、以便在开始测试之前对齐时钟边沿(期望是向前移动 X 个步长、向后移动 X 个步长、可以返回到同一个点)。 无论如何、无论我们是否开始对齐、问题总是会发生。

为了简化调查、我创建了一个十六进制文件、该文件通过运行大约50次的正向/反向序列来复制我们的测试、该序列可以直接从 TI 的 TICS Pro 工具和同一个编程器启动。

该过程降至最低：

1. 上电
2. 使用 TCS 文件加载配置
3. 目视检查时钟是否锁定在示波器上
4. 使用以下命令从 TICS Pro 加载 hex 文件：file -> import hex register file

这个问题总是显而易见的、通常它只需向前/向后重复两次或三次即可看到序列已经超出预期的窗口。

附注
在配置文件中、除了为分频器和触发器写入计数器以应用延迟之外、我还对"R142 0x014200"寄存器进行了一些虚拟写入、这些写入仅用于减慢移位速度、以便更容易在示波器上看到移位。


e2e.ti.com/.../50xsingle_5F00_seq_5F00_test.rar

Alberto、

谢谢你。  我现在可以 在50左右的延迟调整范围内不可重复地观察到延迟干扰。  在进一步测试后、我将在下周为您提供最新消息。 感谢您的耐心。

此致、

会的

您好、William、  

遗憾的是、这在我们的应用中无法实现、因为我们在寻找"绝对"输入到输出延迟、而不是从一个输出到其他输出的相对延迟：

这就是我们为什么按顺序在 ZDB 模式下工作、为与输入时钟同步的数据计时的原因

延迟所有其他信号会对所有其他卡/数据同步产生影响、并且不会对特定时钟产生预期的影响  

我真的很抱歉、但我们需要更改为另一个解决方案、因为该器件无法支持应用、并且我们已经过多地延迟了下一个原型的启动

感谢您的支持、我们对此表示感谢

Alberto