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.

[参考译文] LMK04832:LMK04832 sysref 相位对齐不起作用

Guru**** 2952510 points

Other Parts Discussed in Thread: LMK04832, LMK04828, LMK04832EVM

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

https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1652132/lmk04832-lmk04832-sysref-phase-alignment-not-working

器件型号: LMK04832
主题中讨论的其他器件: LMK04828、

我们有两个 LMK04832 器件、希望同步输出。
 
两种器件都使用在 100MHz 上运行的 OSC 输入。 这两者相当对齐。
我们正在驱动 FPGA 中每个器件的 SYNC 输入、并且我们已验证它们是否相当对齐。我们从 FPGA 发送 10ns 脉冲作为 SYNC 输入。
 
我们遵循以下步骤:
  1. 将 0x51 写入寄存器 0x143。 这将设置 SYNC_EN、SYNC_1SHOT_EN 并设置 SYNC_MODE 以使用 SYNC 引脚。
  2. 将 0x00 写入寄存器 0x139。 这会将 SYSREF_MUX 设置为正常(使用 SYNC 引脚)
  3. 将 0x00 写入寄存器 0x144。 这启用了系统参考时钟和输出时钟同步
  4. 从 FPGA 发送同步脉冲
  5. 将 0xFF 写入寄存器 0x144。 这将禁用系统时钟和输出时钟上的同步
  6. 将 0x11 写入寄存器 0x143。 我们了解到需要禁用 SYNC_1SHOT_EN、不确定原因。
  7. 将 0x03 写入寄存器 0x139。 这会将 SYSREF_MUX 设置为连续模式、以便在输出引脚上获得系统参考
 
我们完成了上述一些变体、例如、未启用 SYNC_1SHOT_EN。 我们还尝试使用 CLKin0 路径。
 
我们进行调试的方法是使用示波器查看两个器件的 sysref。 由于两者尚未同步、因此两者之间存在给定的偏差。
我们期望、如果我们只针对一个器件执行上述同步过程、并且将同步脉冲移动 10ns/20ns/等、则两个芯片的两个系统参考信号之间的偏移会按相同的延迟量进行调整。 我们没有看到这种情况。 两个器件的系统参考输出之间的相对偏移保持不变。
 
我们对器件接收同步脉冲很有信心。 如果我们没有启用单稳态位并生成同步脉冲(上述过程的步骤 4)、我们可以看到脉冲反映在器件的 syncref 输出中。

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

    首先、确保 SYSREF_DDLY≥8。 SYSREF_DDLY=0 是保留值、如果在 SYSREF_DDLY=0 时执行同步过程、可能不会产生可预测的行为。

    其次、确保在发送 SYNC 脉冲之前、您还在该过程中的某个时刻将 SYSREF_CLR=1 置为有效。 用户可以修改步骤 1 以将 0xD1 写入 0x143、这就足够了。 这将清除 SYSREF 本地延迟并确保它们已为运行做好准备。

    在 SYSREF_MUX 之后有一个单次触发计时器。 分频器复位过程 (SYNC) 和 SYSREF 分频器分配均使用 SYSREF_MUX 和 SYSREF 分配路径。 如果在将 SYSREF_MUX 切换为连续时启用了单次触发、则会在每次 SYSREF 分频器上升沿触发时在输出引脚上获得单次触发的输出。  

    如果在不使用 SYNC_1SHOT_EN 的情况下执行 SYNC 过程、则分频器将保持复位状态、直到时钟分配路径锁存逻辑低电平条件(即当来自 FPGA 的 SYNC 脉冲结束时)。 如果 SYNC 脉冲下降沿始终相对于 SYSREF 分频器处于相同的相位偏移(无论上升沿延迟如何)、这可能会影响您的结果、但这并不能解释在启用单稳态时观察到问题的原因。

    首先、尝试使用两个建议的修正案 (SYSREF_DDLY≥8、包括 SYSREF_CLR=1、方法是修改步骤 1 将 0xD1 写入 0x143) 来重复该过程。 如果您仍然发现问题、请告知我们、我们将进一步调查。

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

    感谢您发送编修。我们会重新检视您的建议。
    我尝试了您的建议、在第 1 步中将 0xD1 写入 0x143。
    我还将 SYSREF_DDLY 设置为 8:
    将 0x00 写入 0x13C
    将 0x08 写入 0x13D

    行为没有改变。 我仅在一个芯片上运行了同步过程。 即使在第一次尝试之后、两个芯片的系统参考输出的相对位置也没有改变。 当然,我们在过程中丢失了系统参考,但当它回来时,它是在相同的相对位置之前。 我移动了同步脉冲并确认它没有任何区别、就好像同步过程被完全忽略一样。

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

    作为完整性检查、您是否可以尝试修改所测量的 SYSREF (SCLKx_y_DDLY) 的本地数字延迟字段、并确认延迟变化为等效的 VCO 周期数? 例如、如果您设置了 2 个周期、并将数字延迟修改为 6 个周期、我们预计会看到纳秒的相移 (4 / 2500MHz)。 可以在输出运行时修改此字段。

    另一项完整性检查:发送 SYNC 脉冲时、您是否会看到时钟输出在 SYNC 事件持续时间内暂时保持在静态状态(加上由 DCLKx_y_DDLY 确定的几个 VCO 周期)? 这有助于确认正在复位任何分频器。

    第三次完整性检查:您是否可以通过 SPI 将 0xF1 和 0xD1 写入 0x143、从而将步骤 4 中的 SYNC_POL 位 (0x143[5]) 依次切换为 1 和 0、而不是通过 FPGA GPIO 发送 SYNC 脉冲? SPI 时序可能相对于其他操作是异步的、对于单器件同步、可以在与 SYSREF 没有确定性关系的情况下重复该过程、从而强制对生成的 SYSREF 分频器相位进行随机化。 如果即使这会产生相同的 SYSREF 相位、我也会感到非常惊讶。

    您描述了仅针对一个器件将 SYNC 脉冲移动 10ns/20ns/等。 仅针对一个器件将同步脉冲移动 10ns 意味着什么? 是否有一些系统 GCD 频率用作 SYNC 实验的可重复 t=0ns 基准? 假设是、坐标系是否可能随 SYNC 脉冲移动、从而消除所产生的相移? 我在您的过程中没有看到任何错误、您描述的行为听起来像是器件被正确编程;其余的解释表明外部 SYNC 脉冲的时序是负责任的。 如果 SPI 时序关系未锁相到 SYSREF、第三次完整性检查应该研究这种可能性。

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

    我看到 SCLK8_9_DDLY(寄存器 0x126)有一些奇怪的地方、我无法解释。 在 TICS Pro 中、该值显示为 2。 导出寄存器十六进制值时、该值显示为 1。
    如果我将该寄存器设置为 0 和 4 之间的任意值、则系统参考信号不会移动。 如果我将其设置为 8 到 15 之间的任意值、则系统参考会移动 3.2ns (8 x 400ps)。

    作为完整性检查、我使用了示波器查看了 SPI 信号。 它们看起来很好。 时钟在 4MHz 下运行、当我写入 0x126 时、SCLK 和 MOSI 很有意义。
     该寄存器的数据表说明似乎表明它需要最小值 8、但 POR 默认值为 0。
    也许您可以说明一下这一点。

    我注意到、在进行重新同步处理之前、我们从 TICS Pro 导出十六进制值、并据此初始化寄存器。 在我看来、我们会尝试覆盖一些只读寄存器、例如器件 ID。 这种行为合适吗?

    第二次健全性检查:发送 SYNC 脉冲时我没有看到时钟输出冻结。

    第三个健全性检查:我已经做了这个,并再次验证了它,就在现在。 切换 SYNC_POL 而不是在我的重新同步过程中发送同步脉冲、确实会相对于其他 LMK 器件移动 sysref。 正如预期的那样、当 SPI 同步在随机时间发生时、两个 LMK 器件之间的相位关系随机移动。 312.5MHz 时钟似乎也在移动。

    这是否会让我们知道大约 10ns 的脉冲宽度存在问题? 如前所述、当未设置一次性触发时、我可以看到脉冲传播到系统参考输出、因此我相信器件正在接收脉冲。

    即使在 SPI 重新同步方法中、我们看到 sysref 实际移动、时钟输出似乎也不会冻结。 我对此没有 100%的信心、因为我不经常使用示波器的这一功能。

    我 100%确定当我尝试使用 10ns 脉冲重新同步时:在该脉冲置为有效期间、时钟保持正常运行。

    让我来看看我是如何监控所有这些情况的、希望这将会回答您的问题。

    两个 LMK 器件接收到相同的对齐 100MHz osc 输入。 当我初始化两个器件时、两个器件的系统参考输出都会保持固定偏移。 因此、当我在 LMK 1 sysref 输出的上升沿触发时、我可以看到 LMK 2 sysref 在随机相位上输出并且不移动。

    在此之后、我不会触摸 LMK 1 的任何寄存器、 该器件的 sysref 成为我的参考点。

    当我在 LMK2 上以 10ns 脉冲执行重新同步程序时、我可以看到 LMK 2 sysref 输出中断、但该过程完成后、它与 LMK 1 保持相同的相位、就像过程完成之前一样。

    还有一个与 100MHz osc 输入同步的信号、FPGA 使用参考。 如果您在示波器上绘制两个 LMK sysref 输出的图片、我可以将 10ns 脉冲围绕相对于这两个波形的任何位置移动。 我期望、如果重新同步工作正常、则两个系统参考的相对相位会根据在不同位置置位的 SYNC 脉冲而变化。 但是、无论脉冲位于何处、两个系统参考之间的相对相位都保持不变。 请记住、LMK1 寄存器不变、FPGA 无法移动另一个使其能够移动同步脉冲的参考信号。

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

    纠正我的前一篇文章,其中我说:
    “如果我将其设置为 8 到 15 之间的任何值“

    我想说:
    “如果我将其设置为 5 到 15 之间的任何值“

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

    我将同步脉冲增加到了 150ns。 如果我写入 0x11、我可以看到脉冲流向 sysref 输出、而不是在步骤 1 中将 0xD1 写入 0x143。 我这样做是为了确认芯片看到同步脉冲。

    从顶部引出的第三个迹线是进入芯片的脉冲、第四个迹线是芯片外的系统参考(顶部的两个迹线是来自 LMK1 芯片的系统参考,我将其用作参考)。 脉冲通过芯片似乎有一个 BOUT 的 16ns 延迟。

    为什么切换 SYNC_POL 会导致同步、但 150ns 脉冲不会导致同步? SYNC_POL 的时间更长、因为我们的 SPI 访问速度非常慢。 由于我们要设置单稳态位、因此仅上升沿应该很重要。

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

    这只是我所看到的情况的一个视图。 前两个信号是来自 LMK1 的相同 sysef 信号。 下面两个来自 LMK2。 我可以在此窗口中的任何位置将 SYNC(现在宽度为 150ns)置为有效、两者的相对位置不会改变:

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

    现在我改用 SYNC_POL 进行同步、这两种器件的相对位置会移动。 如果我继续这样做、这两者会相对于彼此随机移动、因为 SPI 访问是在随机时间发生的。

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

    您描述的行为非常奇怪。 很难想象 SCLKX_Y_DDLY 写入如何不产生预期行为。

    您是否确定两个电路板上的器件是 LMK04832、其中一个或两个器件并非具有相同的封装和引脚排列、但寄存器组略有不同(例如 LMK04828)? SCLKX_Y_DDLY 由 0x02 从 LMK04828 偏移到 LMK04832、这可能会解释观察到的行为;但我怀疑您是否会从 SYSREF 中看到任何内容、因为其中一个位写入 LMK04832 寄存器-> LMK04828 器件转换应该会关闭奇数输出上的 SYSREF。 我想您也会注意到、如果您将 CLKOUT8 和 CLKOUT9 配置为 SYSREF、但 CLKOUT8 在其中一个器件上未产生 SYSREF(LMK04828 没有 SYSREF 到 CLKOUT8 的路径)。

    脚注:SYSREF_DDLY 需要至少 8 个、SCLKX_Y_DDLY 值介于 0x00 至 0x0A 之间(旁路至 11 个周期)。 数据表出错了、我们正在更新它。

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

    我已验证 ID_PROD(寄存器 0x4 和 0x5)和 ID_MASKREF(寄存器 0x6)是否与 LMK04832 数据表匹配。
    我重复了将寄存器 0x126 (SCLK8_9_DDLY) 从 0x0 设置为 0xA 的实验、并通过读回寄存器来验证这些设置。
    仅当值从 0x04 变为 0x5 时、才会出现跳变。 是否有任何其他可以解释该行为的寄存器设置?
    我将同步脉冲增加到 640us(没有充分理由,只是想知道为什么切换 SYNC_POL 的速度缓慢)。 行为无变化。

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

    很抱歉、由于出席会议、我的答复将有所延迟。

    本地延迟相当于由时钟分配路径和选择延迟抽头的多路复用器计时的 D 型触发器链。 将 SYSREF_CLR 位 (0x143[7]) 置为有效 15 个 VCO 周期应该足以完全清除触发器并将本地延迟恢复到清除状态。 SYSREF_CLR 电路内具有亚稳态锁存器、可防止任何后续意外状态、并且在 SYSREF_CLR 位置位时、延迟链的输入保持在固定状态。 根据我能说的、您描述的行为(仅在从 0x4 更改为 0x5 时才会跳转)无法使用您共享的配置。

    我可以在我们的实验中在 LMK04832 上加载您的配置并运行等效实验、我可以看到 SYSREF 的时序完全符合预期(当 SYNC_1SHOT_EN=1 时、延迟与 SYNC 脉冲上升沿对齐、当 SYNC_1SHOT_EN=0 时、与 SYNC 脉冲下降沿对齐;SCLK8_9_DDLY 更新每个周期移位一个 VCO 周期)。  结合可以观察到、即使在 SPI 同步期间时钟也没有保持在复位状态(假设您的观察结果和范围使用正确)、我对我们看到的内容没有很好的解释。  

    我们可以从这里去哪里?

    • 我可以尝试查看 SPI 波形以进行 SCLKx_y_DDLY 写入、并确认它是合理的、没有边沿情况等 听起来 SPI 工作正常、但可能有一些情况是可行的、有些则没有。 我想查看完整的单寄存器写入事务的 CLK、MOSI 和 CS*线路。 寄存器写入 SCLKx_y_DDLY(例如 0x126)很重要、在这里我们会看到意外行为。
    • 您是否可能以某种方式处于零延迟模式、或者反馈 SYSREF 作为封闭 PLL 的基准? 您在此主题的第一篇文章中开始的配置不使用反馈多路复用器、PLL1 被禁用、除非使用 LMK04832 完成了一些真正奇怪的操作、否则分频器的相位应完全由与同步源的时序关系控制。 但是、如果零延迟模式处于活动状态、或者如果在 LMK04832 周围嵌套了第二个外部 PLL、并且该外部 PLL 将 SYSREF 用作反馈源、这可能会导致延迟调整产生明显的效果不足;但是、它并不能解释同步事件期间分频器未能复位。
    • 您是否尝试过在两个电路板上重复该实验? 它们是否都具有相同的行为? 也许这是一个单器件缺陷、我们非常不幸。  
    • 我们确定这是 LMK04832 吗? 我们回读只读寄存器、但这样做的只是确认它不是 LMK0482x 或任何其他对 0x4 和 0x5 寄存器具有单独的回读结果的寄存器 — 例如,一个假冒器件可能会轻易克隆只读寄存器,但可能会在 SYNC/SYSREF 等复杂子系统中错过其他细微的行为。 我非常怀疑这是我们正在处理的,但如果这种行为在多个系统中是可重现的,并且没有其他环境因素影响循环,我们必须开始探索异国情调的解释。 您是否从 TI 购买了 LMK04832? 电路板是您自己的电路板、还是可能从 TI 以外的地方拉出 LMK04832 的第三方组件?

    脚注:我之前错过了写入只读寄存器的问题 — 只读寄存器的写入端口断开连接,因此写入这些寄存器是可能的,但会导致无操作。

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

    无需担心延误。 感谢你的帮助。

    我毫不怀疑我们所看到的是我们的问题、而不是芯片。 我一直认为我们没有正确配置芯片、但可能还有其他问题。

    我转向道歉。  SCLKX_Y_DDLY 健全性检查失败是一个导频错误。 我当时使用 312.5MHz 时钟对 sysref 进行采样、该时钟也来自 LMK 器件、并在示波器上运行。 我忘记了这一点、当然不会出现 400ps 的延迟。 更正后、我现在可以看到延迟一直起作用到 0xA。

    有关我们的设置的更多信息:我们使用的是机箱中扣紧的 COTS 板。 我无法访问电路板信号。 我在示波器上捕获的是电路板上所发生情况的 FPGA 解释。 我可以访问板的背板连接器、并将 FPGA 内部信号路由到我正在使用示波器监控的两个背板连接器引脚。 因此、当我为两个电路板显示 LMK sysref 时、它们是通过 FPGA 路由到测试引脚的 LMK 信号。 两个电路板上都发生了这种情况。 因此、由于仪表的存在、可能会有几 ns 的偏差。

    几天之后、我们已经通过了健全性检查、接下来的问题是为什么按照我概述的过程(您建议的更正)、我们无法获得与同步脉冲保持一致的系统参考输出。 但是、使用 SYNC_POL 切换的 SYNC 似乎有效。 我知道芯片会看到同步脉冲、因为如果我不启用 1shot 并且没有设置 sysref_CLR 位、我可以看到脉冲显示在 sysref 输出上。 我调整了脉冲宽度、可以看到系统参考输出上的脉冲宽度与同步脉冲宽度相匹配。 因此、我非常确定芯片正在检测到脉冲。 当两个板上的 LMK 根据我提交的 TCS 进行配置时、我们可以看到两个板之间的 sysref 完全锁定且存在一些随机相位。 我尝试仅在一个电路板上运行同步过程、然后移动同步的位置。 移动 SYNC 脉冲时、可以在示波器上看到 SYNC 脉冲相对于两个合成信号的位置会发生变化。 同步完成后、两个电路板上 sysref 的相对位置不会改变。 如果使用 SYNC_POL 方法进行同步、则可以看到两个电路板上 sysref 的相对位置发生了变化。 SPI 访问是在随机时间发生的、如果我继续这样做、相对位置会不断变化。 很抱歉,长段,但我试图总结在以前的文章中讨论的事情。

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

    下面是我看到的内容的视图:

    顶部信号(黄色)是同步信号:现在宽度为 150ns。

    下一个(绿色)是 LMK 312.5MHz 时钟输出:SYNC 置为有效时仍运行。

    底部两个是来自其他 LMK 的 sysref。

    这里、我将同步脉冲移动了 20ns。 您可以通过相对于第二个电路板的系统参考(两个底部信号)移动多少、因为该基准不移动。 回想一下、此时、两个 LMK 器件的 sysref 输出通过随机相位相互锁定。 因此、如果 SYNC 相对于第二个 LMK 移动、则它会为第一个 LMK 移动相同的量。

    下面是我的“重新同步“脚本现在执行的操作(我意识到其中一些是一次性更新,不需要每次都运行):
    将 0x00 写入 0x13C

    将 0x08 写入 0x13D

    将 0x33 写入 0x148 (SPI 回读信号路径,不需要位于此处)

    将 0xD1 写入 0x143

    将 0x00 写入 0x139

    将 0x00 写入 0x144

    生成同步脉冲

    将 0xFF 写入 0x144

    将 0x11 写入 0x143

    将 0x3 写入 0x139

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

    很高兴听到 SCLKx_y_DDLY 重新测试验证其正常工作。

    您是否已检查 SPI 时序是否与 SYNC 脉冲正确对齐? 由于 SPI 时钟频率只有几 MHz、因此同步脉冲的持续时间与 SPI 时钟周期相当、我想知道同步脉冲是否真的在寄存器 0x144 设置为 0x00 和 0x144 设置为 0xFF 之间的间隔内传输。 可能此写入是异步的、缓冲的或进入队列的、需要插入某种屏障或睡眠、以确保 0x144 写入在同步脉冲开始之前完成。 缓冲或排队的 SPI 写入可以按照接收顺序执行、这就解释了 SPI SYNC_POL 切换似乎有效的原因。

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

    问得好。 步进之间存在很长的延迟、它们都通过相同的路径。 我们看不出它们是如何扰乱秩序的。

    我开始在 LMK04832EVM 上测试该序列。 与我们使用的系统相比、有几个方面有所不同:
    *我从函数发生器创建了一个 6.25Hz 的自由运行 100ns 同步脉冲。 这与 6.25MHz sysref 输出很好地锁定。 但是、由于我要在 TICS Pro 软件中执行步骤、我们将通过多个脉冲。 也许一次性只锁住第一个?
    *我的函数发生器没有输出不同的信号,而这似乎是 OSCin 所需要的。 但是、CLKin1 似乎适用于单端输入。


    加载 TCS 文件并进行这些修改后、PLL2 被锁定、我可以看到同步输入和 sysref 输出被锁定。 这两个寄存器在 I “Write All Registers“后随机出现。 执行 sycn 步骤后、它们似乎始终具有相同的相位:sysref 的下降沿在 SYNC 上升沿之后大约为 12.5ns。 这很好、但为什么它在我们的系统中不起作用?

    我运行了另一个测试:将同步脉冲电压摆幅降低至 1.2V 以下(似乎是 VIHmin?)。 同步不起作用。 我禁用了 sync_1shot_en 和 sysref_clr、并将 sysref_mux 切换为“正常同步“、我可以在 sysref 输出中看到同步脉冲。 我在我们的系统中使用它来表明芯片看到了同步脉冲。 然而,这个实验似乎表明,如果摆幅低于 VIHmin ,芯片的某些部分可以看到脉冲,而部分芯片不能! 因此、如果我们的 COTS 板存在同步电压摆幅问题、这可以解释我们遇到的问题。 你对此有何看法?

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

    这听起来很合理。 同步子系统中进行 CMOS 到 CML 和 CML 到 CMOS 的转换、以支持对时钟分配路径重新计时。 低于 1.2V 的信号可能会到达 SYSREF 分配路径、而没有实际达到复位时钟分频器所需的振幅、但振幅足以切换输出驱动器。

    但是、这能否解释 CLKIN0 的行为? 在该线程的第一个帖子中、您建议已尝试对 CLKIN0 进行相同的设置、但未成功。 两条路径上的输入振幅是否过低? 整个系统 CLKIN0 路径上的实验是否在没有同步行为的情况下产生相同的输出脉冲、如果是、结果也可以在 EVM 上复制吗? 或者我们是否需要多种解释?

    请注意、为了使 CLKIN0 用作 SYNC 源、需要将 CLKIN0_DEMUX(寄存器 0x147[1:0])设置为 SYSREF 多路复用器 (0x0)。 我想知道在测试之前是否没有设置该设置、从而阻止任何 CLKIN0 信号到达 SYSREF 分配路径。

    我也不清楚您的意思是“我们正在通过多个脉冲“。 只要检测到 SYNC 引脚(或 CLKIN0)上的上升沿、单稳态就应该会产生持续一定数量时钟分配路径周期的单脉冲。 如果您看到多个脉冲,这表明您看到了多个上升沿 — 这可能来自非单调上升沿(CMOS 振铃?)、SYNC 引脚处的过压/欠压等 如果这与主要问题无关、我不想花时间探索这种现象、听起来似乎会影响您诊断问题的能力、因此如果您需要深入研究、请告诉我。

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

    我想进一步探索 CLKIN0 路径。 我对以前的测试方式没有信心。 我会回到您的身边。

    关于“多个脉冲通过“... 当我们在系统中进行测试时、我将在下面的“生成同步脉冲“时隙中生成一个 150ns 脉冲(以前为 10ns):

    将 0x00 写入 0x144

    生成同步脉冲

    将 0xFF 写入 0x144

    使用 EVM 进行测试时、同步脉冲来自自由运行的 6.25Hz 信号。 因此、在我将 0x144 设置为 0x00 再将其设置回 0xFF 之间、多个 6.25Hz 上升沿已经过。

    我刚才指出了我如何在系统中测试同步与使用 EVM 之间存在这种差异。

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

    我懂了。 150ns 仍然超过了单稳态或非单稳态的时间。

    单稳态在同步源的任何上升沿触发,不进行锁存 — 一旦单稳态持续时间完成,另一个上升沿可再次触发它。 我认为在输出为高电平时不可重触发、但我从未对脉冲进行过足够短的测试、因此至关重要。 无论如何、对于启用单次触发的情况、当 0x144 -> 0x00 和 0x144 -> 0xFF 之间的时间为多秒时、您会看到器件发出多个脉冲。 观察到的行为符合预期,至少在这个小部分的难题。

    我将等待 CLKIN0 测试的结果。

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

    你在这里指出的事实证明是我们的问题。 即使步骤按顺序进行、生成脉冲的电路也可以关闭几十毫秒。 我们没有一个很好的方法来监视相对于脉冲的相关 SPI 访问、因此错过了这个时间。 一旦我们纠正了此问题、事情就会按预期开始运行。 非常感谢您的帮助、因为您的建议帮助我们找出问题并更好地了解芯片。

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

    很高兴听到这个消息。 如果您有任何其他问题、请联系我们。 我们非常乐意为您提供帮助!