[参考译文] AM6548：PCIe PTM 本地时钟行为

我正在尝试了解我必须使用哪些选项来确保我的 HW TS 推送事件接近先前的 PTM_CLK_Updated 事件。

我相信这就是 TRM 建议的方法、尽管我不确定它有多可行、那就是：

软件可以在接收到 PTM 时钟更新中断时启用时间戳捕获。
EP 完成与的 PTM 对话框后、PTM 时钟更新中断立即生效
RC 并更新了其本地 PTM 计时器。 通过使用中断来捕获时间戳、软件可以确保
EP 本地时间最近已更新。

 当我设置 HW1_TS_PUSH_EN 位、同时所选的 PTM_LOCAL_CLOCK 位已经为高电平时、会发生什么情况？ TRM 表示硬件推入输入为"脉冲"、需要在所选 RCLK 的至少10个周期内保持有效、但它不包含很多详细信息。 我是否可以假设"脉冲"表示"上升沿检测"？ 在清除*_TS_PUSH_EN 位时、边沿检测是否已经激活、或者如果我在信号已经为高电平时设置该位、硬件是否会生成一个事件？

此致、

Dominic

Dominic、  

我想大家注意到的主要困惑是、PTM_LOCAL_CLOCK [63：0]是来自主时钟的连续运行、调整后的时钟。 64位总线以250MHz 运行、因此如果没有调整、64位总线将每4ns 更新一次、增量为4、因为时间戳以1ns 为单位。 PTM 内核具有内置硬件状态机、该状态机计算从 RC 侧接收到的最大值和时间戳的不同值、然后调整门架时钟、并影响 PTM_LOCAL_CLOCK 输出。  

例如、如果我们将 EP 配置为每10ms 启动一次 PTM 对话、则当 PTM 重新计算时、PTM_LOCAL_CLOCK 将获得"升压"调整、然后它将保持此速率直到下一次对话/调整。   

直接读取接收到的时间戳需要软件实施 PTM 计算。 您必须读取接收到的所有时间戳、然后计算路径延迟等  

如前所述、使用 PTM 同步芯片上的其他模块的首选方法是使用 HW1_TS_PUSH 事件、该事件来自 PTM_LOCAL 的选定位。 您可以使用它来计算 RC 时钟和本地时钟的差异、或直接使用 PCIe 本地 CPTS 来微调 GENF0输出、该输出可路由到芯片上的其他外设作为计时器输入。 您可以在应用手册中找到一些概述图、网址为：

https://www.ti.com/lit/pdf/spracp7

此致

Jian

我已经检查了 J721 TRM (SPUIL1A)、在我看来、PCIe<->CPTS 集成在那里得到了增强、以专门解决我上面描述的问题。 在 J721e 上、有一个 PTM_LOCAL_TIMER_OUT_VALID 信号连接到 HW1_TS_PUSH 输入而不是 PTM_LOCAL_CLOCK_[0-63]多路复用器、以及一个 PCIe_USER_PTM_TIMER_LOW/ HIGH 寄存器。 我假设(很遗憾、描述相当简短) PCIe_USER_PTM_TIMER 寄存器在更新(STEDETM)后立即锁存 PTM_LOCAL_CLOLOCK (J721e 不使用该术语) 匹配 RC、并且该寄存器将一直有效、直到下一个 PTM 对话框结束。 这样、我将有两个时间戳、一个在 PCIe/PTM 域中、另一个在本地时钟域中、并且可以计算频率和偏移。

您是否有机会确认使用 AM65x 无法通过 PCIe PTM 实现精确的时间同步、并且 J721e 中已修复此问题？

是否有可能在 AM65x SR 2.0中修复此问题、但尚未记录在案？

是否有权借助 AM65x 的 PCIe<->CPTS 集成的有限功能实现精确时间同步的权变措施？

此致、

Dominic

尊敬的 Jian：

感谢您的回复、但这没有回答我的问题。

是的、我知道 PTM_LOCAL_CLOCK 是来自主时钟的连续、经调整的时钟。 我的问题是如何调整该时钟以及它在10ms 更新之间的行为。 我的假设是、如果是本地时钟(该250MHz 总线的源时钟信号是哪个时钟信号？) 运行速度快于 RC、然后在10ms 更新后、PTM_LOCAL_CLOCK 将向后步。如果我的本地时钟运行速度低于 RC、则 PTM_LOCAL_CLOCK 将被前移。 在10ms 周期内、两个时钟将彼此漂移。

我绘制了几个 PTM 更新中 PCIe_EP_PTM_REQ_T1_LSB_OFF 和 PCIe_EP_PTM_REQ_MASTERT1_LSB_OFF 之间的差异。 最后、我使用冷冻喷剂冷却 x86：

如果没有额外的冷却、本地 T1时间戳始终比主器件 T1超前~80ns。 喷洒冷冻剂后、差异显著减小。 对我来说、这意味着 x86频率略有增加、并且 PTM_LOCAL_CLOCK 的频率不会进行调整以与 RC 匹配、而是仅在每次更新时步进。

[引用用户="jian35385"]

例如、如果我们将 EP 配置为每10ms 启动一次 PTM 对话、则当 PTM 重新计算时、PTM_LOCAL_CLOCK 将获得"升压"调整、然后它将保持此速率直到下一次对话/调整。   

[/报价]

您能描述一下"升压"吗？ PCIe 内核是要通过 CPTS 的 PPM 寄存器等方式来调整频率、即每 N 个增量加/减一个增量来增加或减慢时钟、还是只是根据最新的计算单步执行计数器？

[引用用户="jian35385"]

直接读取接收到的时间戳需要软件实施 PTM 计算。 您必须读取接收到的所有时间戳、然后计算路径延迟等  

[/报价]

我想使用接收到的时间戳中的信息自行计算频率差异、以解决无法正确同步 PTM_LOCAL_CLOCK 和 CPTS 时钟的问题。 虽然我仍然认为我可能能够补偿频率差异、但我认为我无法正确同步偏移。

此致、

Dominic

Dominic、  

您之前的帖子中有许多要点、我将尝试回答一些问题、然后我们可以继续迭代：

>您是否有机会确认 AM65x 无法通过 PCIe PTM 实现精确的时间同步，而且这已在 J721e 中修复？

[JI]您理解正确的是、如果 RC 时钟在10ms PTM 请求间隔内发生剧烈变化、那么 EP 将偏离 RC、直到下一次 PTM 对话。 AM65或其他平台都是如此。 要捕获此类更改、应在 EP 中对较短的间隔 PTM 对话进行编程。 您可以在1ms 以内对内部进行编程。  

J721e 使用不同的 PCIe 控制器、以不同的方式实现了 PTM。 主要区别在于、PTM 内核仅发送 EP PTM 计时器的快照、而不是连续时钟。  

>是否有可能在 AM65x SR 2.0中修复此问题，但尚未记录？

[JI]除了 DMSG 字节顺序问题外、SR2.0中的 PTM 实现没有变化。  与任何其他协议类似、时间从器件将以其最新的已知速率勾选、直到下一次同步。  

>是否有权借助 AM65x 的 PCIe<->CPTS 集成的有限功能实现精确时间同步的权变措施？

[JI]让我们对前两个问题进行协调、然后重新讨论"精确时间同步"的定义。  

其他一些说明：

 - 250MHz 总线频率来源于 PCIe 内核。 它是一个固定的本地时钟。  

 - PTM 内核(特定于 M65xx、不在 J7中)具有内置计时器、无论是否存在 PTM 对话、该计时器每4ns 发送一次调整后的时间戳。

此外、由于您使用 x86 RC 进行测试、请确认您使用的是 PG2芯片、因为 PG1中的错误将在连接到 x86时触发。  

此致

Jian

尊敬的 Jian：

感谢您的回复。

[引用 USER="jian35385"[JI]您的理解是正确的、如果 RC 时钟在10ms PTM 请求间隔内发生剧烈变化、那么 EP 将从 RC 漂移到下一次 PTM 对话。 对于 AM65或其他平台都是如此。

我不确定你的意思是"大变"。 我尝试解决的情况是、我要同步到一个单调的 RC。 如果我们假设两个系统的时钟容差为+-200ppm、这意味着 RC 可以在10ms 内增加10、002000 ns、而 EP 可能只会增加9、998、000ns。 这是除非有一些机制来调节 EP PTM 本地时钟速率。

[引用 user="jian35385"/>要捕获此类更改，应在 EP 中编程间隔较短的 PTM 对话。 您可以在1ms 以内对内部进行编程。  [/报价]

我也想缩短 PTM 对话间隔、但我在这里看到了一些问题：

• PTM 间隔必须非常短、以确保时钟的漂移不会太远。 我还不确定预期的时钟容差是多少、但 PCIe 等要求+-300ppm。 这意味着时钟可能会在1ms 内漂移600ns。
• 您说过"少于1ms"、但 PTM_REQ_LON_TIMER 以 ms 为单位指定。 有 PTM_REQ_FAST_TIMERS、但它被描述为"PTM 定时器的调试模式"。 您是否知道更高的 PTM 对话速率有何取舍？

[引用 user="jian35385">J721e 使用不同的 PCIe 控制器、以不同的方式实现 PTM。 主要区别在于、PTM 内核仅发送 EP PTM 计时器的快照、而不是连续时钟。  [/报价]

是的、它仅发送该快照、但能够同时生成 CPTS HW TS 推送事件。 这样就可以轻松地将最后一次已知良好的 PTM 时间与内部时基之一相关联。 我想我们可以使用它作为我的"精确"定义-来自两个时域的时间戳、这些时间戳仅受传播延迟、同步阶段等影响。

[引用 USER="jian35385"[JI] SR2.0中的 PTM 实现没有变化、但 DMSG 字节顺序问题除外。

(笑声)

此外、由于您使用 x86 RC 进行测试、请确认您使用的是 PG2芯片、因为 PG1中的错误将在连接到 x86时触发。

[/报价]

我看到 TRM 描述了新的位"PTM_REQ_PDEL_BYTE_REV"、但很遗憾、PG 1.0的勘误表中没有记录任何问题。 我现在使用的是 PG 1.0、但 PTM 对话框本身似乎可以正常工作。 ReponseD 消息是否同时作为发件人(RC)和接收人(EP)受到影响？ PG1.0错误如何影响 PTM 对话框？

[引用 user="jian35385)]与任何其他协议类似，时间从站将按其最新的已知速率计时，直到下一次同步。  [/报价]

您是否使用"时间从器件"引用了 PTM 本地时钟？ 在这种情况下、"最新已知速率"是什么意思？ 我一直回到这个问题、这个问题已经是这个主题的标题：PTM 本地时钟的行为是怎样的？ 它是以每250MHz 周期"4ns"单调增加、还是经过调整以匹配 RC 的最后已知速率？ 是否单步执行以匹配成功的 PTM 对话框中的 RC？

[引用用户="jian35385"] - 250MHz 总线频率来自 PCIe 内核。 它是一个固定的本地时钟。  [/报价]

您能再详细说明一下吗？ 我对整个 PCIe/SerDes 时钟有点不清楚。 我们使用的是基于处理器 SDK 样本的寄存器设置、但我不确定我是否完全理解这些设置。 该250MHz 时钟是由 PCIe REFCLK 引脚生成的、还是在内部生成的？ 我们将 CTRLMMR_SERDES0_CTRL[1：0]编程为0x1 (PCIe 0通道0)、将 CTRLMMR_SERDES0_CTRL[7：4]编程为0x4 (真的不确定实际含义)、并将 CTRLMMR_SERDES0_REFCLK_SEL[1：0]编程为0x3 (对于 MACLINHSDIV_100MHz)。

这个250MHz 时钟是基于通过 REFCLK 引脚的时钟输入生成的、还是基于内部生成的 MAINHSDIV_CLKOUT4生成的？ 据我了解、这将是决定 PTM 本地时钟与 RC PTM 时钟漂移的关键因素、对吧？

[引用 user="jian35385"] - PTM 内核(特定于 M65xx、不在 J7中)具有内置计时器、每4ns 发送一次调整后的时间戳、无论是否进行 PTM 对话。

再说一次：如何调整这些时间戳？ 它们是仅补偿由最后一个 PTM 对话框确定的最新偏移、还是进行调整以匹配 RC 的最后一个已知频率？

确保尽可能地同步系统时间是此项目的关键因素。 如果您能帮助我们了解如何充分利用硬件提供的各种可能性、那将会非常棒。

此致、

Dominic

Jian35385.

[JI]您理解正确的是、如果 RC 时钟在10ms PTM 请求间隔内发生剧烈变化、那么 EP 将偏离 RC、直到下一次 PTM 对话。 AM65或其他平台都是如此。

我不确定你的意思是"大变"。 我尝试解决的情况是、我要同步到一个单调的 RC。 如果我们假设两个系统的时钟容差为+-200ppm、这意味着 RC 可以在10ms 内增加10、002000 ns、而 EP 可能只会增加9、998、000ns。 这是除非有一些机制来调节 EP PTM 本地时钟速率。

[JI]在这种情况下、由于 EP 只知道上次同步的速率、因此在发起另一个 PTM 请求之前、他不会知道来自 RC 的新 ppm。 我认为这是由标准定义的、因为 PTM 对话仅由定义的 EP 发起。 另请注意、在 RC 侧、由于 RC 时间戳通常源自 REFCLK、因此它将遵循与 PCIe 相同的抖动要求、而不仅仅是容差要求。  

Jian35385.

要捕获此类更改、应在 EP 中对较短的间隔 PTM 对话进行编程。 您可以在1ms 以内对内部进行编程。  

我也想缩短 PTM 对话间隔、但我在这里看到了一些问题：

• PTM 间隔必须非常短、以确保时钟的漂移不会太远。 我还不确定预期的时钟容差是多少、但 PCIe 等要求+-300ppm。 这意味着时钟可能会在1ms 内漂移600ns。
• 您说过"少于1ms"、但 PTM_REQ_LON_TIMER 以 ms 为单位指定。 有 PTM_REQ_FAST_TIMERS、但它被描述为"PTM 定时器的调试模式"。 您是否知道更高的 PTM 对话速率有何取舍？

[JI]您可能是对的、我需要仔细检查、但由于边带数据的开销、我们很少使用小于1ms 的时间、而且、如果 RC 时钟快速变化、系统将会防止/适应(了解我们对此次计时仍有不同的看法)

Jian35385.

J721e 使用不同的 PCIe 控制器、以不同的方式实现了 PTM。 主要区别在于、PTM 内核仅发送 EP PTM 计时器的快照、而不是连续时钟。  

是的、它仅发送该快照、但能够同时生成 CPTS HW TS 推送事件。 这样就可以轻松地将最后一次已知良好的 PTM 时间与内部时基之一相关联。 我想我们可以将其用作"精确"的定义-来自两个时域的时间戳、这些时间戳仅受传播延迟、同步阶段等影响。

[JI]是的、我们在 J7中采用了这种方法。 您将有信任软件可以足够快地读取时间戳。 同意这一点、允许 EP 中的处理器内核直接访问 RC 发出的真正时间戳。  

Jian35385.

[JI]除了 DMSG 字节顺序问题外、SR2.0中的 PTM 实现没有变化。

(笑声)

此外、由于您使用 x86 RC 进行测试、请确认您使用的是 PG2芯片、因为 PG1中的错误将在连接到 x86时触发。

我看到 TRM 描述了新的位"PTM_REQ_PDEL_BYTE_REV"、但很遗憾、PG 1.0的勘误表中没有记录任何问题。 我现在使用的是 PG 1.0、但 PTM 对话框本身似乎可以正常工作。 ReponseD 消息是否同时作为发件人(RC)和接收人(EP)受到影响？ PG1.0错误如何影响 PTM 对话框？

[JI]发送回 x86的延迟将按反向字节顺序进行交互。 因此、您的 PTM 计算将使用错误的延迟。 当然，如果 x86将延迟设置为0，则不起作用。 请检查 PG1勘误表、应存在勘误表。  

Jian35385.

与任何其他协议类似、时间从器件将以其最新的已知速率勾选、直到下一次同步。  

您是否使用"时间从器件"引用了 PTM 本地时钟？ 在这种情况下、"最新已知速率"是什么意思？  我一直回到这个问题、这个问题已经是这个主题的标题：PTM 本地时钟的行为是怎样的？ 它是以每250MHz 周期"4ns"单调增加、还是经过调整以匹配 RC 的最后已知速率？ 是否单步执行以匹配成功的 PTM 对话框中的 RC？

[JI]我知道这是我们偏离的地方-让我们尝试几次迭代以对齐。 它是单调的、并且正在进行调节。 这意味着您可能会在总线上看到相同的值两次、但不会看到戳记后退-这将违反 PTM 协议。 至于它是一个步进函数、还是像 CPTS 那样的分散调整、我没有确切的答案。   

Jian35385.

 - 250MHz 总线频率来源于 PCIe 内核。 它是一个固定的本地时钟。  

您能再详细说明一下吗？ 我对整个 PCIe/SerDes 时钟有点不清楚。 我们使用的是基于处理器 SDK 样本的寄存器设置、但我不确定我是否完全理解这些设置。 该250MHz 时钟是由 PCIe REFCLK 引脚生成的、还是在内部生成的？ 我们将 CTRLMMR_SERDES0_CTRL[1：0]编程为0x1 (PCIe 0通道0)、将 CTRLMMR_SERDES0_CTRL[7：4]编程为0x4 (真的不确定实际含义)、并将 CTRLMMR_SERDES0_REFCLK_SEL[1：0]编程为0x3 (对于 MACLINHSDIV_100MHz)。

这个250MHz 时钟是基于通过 REFCLK 引脚的时钟输入生成的、还是基于内部生成的 MAINHSDIV_CLKOUT4生成的？ 据我了解、这将是决定 PTM 本地时钟与 RC PTM 时钟漂移的关键因素、对吧？

[JI] TRM 在这方面可能不够清晰- 250MH 时钟源自驱动 PCIe 控制器内核逻辑的内核时钟、它不会改变或调整。 如前所述、REFCLK 是 PCIe PHY 的参考时钟、由 PHY 的内部 CPU 用于生成8GHz 位时钟、它还驱动 PHY 连接到控制器的字节时钟接口。 到目前为止、我们都讨论的是 EP 侧、与 RC 或 PTM 无关。  

Jian35385.

 - PTM 内核(特定于 M65xx、不在 J7中)具有内置计时器、无论是否存在 PTM 对话、该计时器每4ns 发送一次调整后的时间戳。

再说一次：如何调整这些时间戳？ 它们是仅补偿由最后一个 PTM 对话框确定的最新偏移、还是进行调整以匹配 RC 的最后一个已知频率？

[JI]请参阅上文- PTM 内核具有自己的可调节内部计时器。  

确保尽可能地同步系统时间是此项目的关键因素。 如果您能帮助我们了解如何充分利用硬件提供的各种可能性、那将会非常棒。

[JI]我的方面没有问题，因为这是我们可以摆脱怀疑的核心的方式。  

此致、

Dominic

尊敬的 Jian：

[引用 user="jian35385"[JI]我知道这是我们偏离的位置-让我们尝试几次迭代以对齐。 它是单调的、并且正在进行调节。 这意味着您可能会在总线上看到相同的值两次、但不会看到戳记后退-这将违反 PTM 协议。 至于它是一个步进函数、还是像 CPTS 那样的分散调整、我没有确切的答案。   [/报价]

好的、我开始了解到、您正在尝试告诉我、EP 的 PTM 本地时钟应进行调整、以匹配 RC 的最新速率：

• 我在 PTM 规范中找不到指定请求者行为的任何内容(我在查看 PCIe 3.1a 第6.22章)。 您能否引用该器件中说 EP 的 PTM 本地时钟一定不能向后阶跃的部分？
  • 该规范确实表明 PTM 主器件时间需要单调且严格增加、但没有任何内容表明这会扩展到 EP 的本地时钟(因为它不是规范的一部分)

该规范确实说："当 PTM 主控时间和上行端口的本地时间之间的关系根据实施特定标准而变化时、stronlgy 建议上游端口使其内部 PTM 上下文无效。 PTM 主控时间和上行端口本地时间之间关系变化的一个示例是累积的 PPM 漂移。

• 您能告诉我 AM65x 中的 PTM 请求者实施是否遵循此建议、以及它使用的标准是什么？

• 我绘制 T1和 T1-Master 的实验显示了相当恒定的差异、这是通过冷却 x86而减少的。 对我来说、这表明差异是由 PPM 漂移确定的、由于对 x86进行冷却会略微增加其速率、因此减小了这种差异。
• 如果我增加了 PTM 对话间隔、我还看到差异增大。 当时、我查看的是 EP 配置寄存器中的 PTM 本地时钟以及 RC 配置寄存器中的 RC 时钟、这当然不准确、但差异与 PTM 对话间隔的增加相当线性。

[引用 user="jian35385"]无论它是一个阶跃函数，还是像 CPTS 那样进行分散调整，我都没有确切的答案。

我认为这是至关重要的。 只要我们不知道该时钟的行为、我们就不知道我们是否能够在 PTM 对话间隔的"任何位置"可靠地同步、或者我们是否只能在接近 PTM 本地时钟更新的位置可靠地同步。 您是否有机会从 Synopsys 获得这些信息？

如果你说的是真的、并且 EP 的 PTM 本地时钟也在严格增加、那么 IMHO 步进根本不起作用、因为在这种情况下、"步进"意味着将时间保持较长时间。

[引用 user="jian35385]\n 请检查 PG1勘误表，应提供勘误表。  [/报价]

遗憾的是、没有此类勘误表、至少"SPRZ452E–2018年7月–2020年6月修订版"中没有此类勘误表。

此致、

Dominic

尊敬的 Jian：

[引用 user="Dominic Rath">如果我增加 PTM 对话间隔、我也看到差异增大。 当时、我查看的是 EP 配置寄存器中的 PTM 本地时钟以及 RC 配置寄存器中的 RC 时钟、这当然不准确、但差异与 PTM 对话间隔的增加相当线性。[/引述]

我已使用增加的 PTM 对话间隔重新运行测试。 在10ms 的默认 PTM 对话间隔(PTM_REQ_LON_TIMER=0x9)下、T1和 MASTERT1之间的差值为~77ns。 如果我将 PTM 对话间隔增加到100ms (PTM_REQ_LON_TIMER=0x63)、则 T1和 MASTERT1之间的差值为~720ns。 如果我进一步将对话间隔增加到200ms、T1和 MASTERT1之间的差异将增加到~1418ns。

我将查看以下寄存器：

PCIe_EP_PTM_REQ_T1_LSB/MSB_OFF：PTM 请求者 T1时间戳 LSB/MSB

PCIe_EP_PTM_REQ_MASTERT1_LSB/MSB_OFF：T1 LSB 时的 PTM 请求者主时间

为了进一步验证这一点、我已经执行了一个测试、该测试连续读取 PCIe_EP_PTM_REQ_LOCAL_LSB/MSB_OFF 并检查当前值是否大于或小于先前的值。 在10秒的时间内、在256ms 的 PTM 对话周期中、发现 PTM 本地时钟向后步进17次。 测试代码读取 PTM 本地时钟~2、000万次、即我每~500ns 对 PTM 本地时钟采样一次。

我很确定 PTM 请求者本地时钟没有调整以匹配主器件的频率、而是仅步进至 PTM 对话框确定的最新值。

此致、

Dominic

Dominic、  

我想我们将您的疑问提炼为以下问题：

1. PTM 内核更新-突然或逐渐更新，它能否后退？

2、PCIe_EP_PTM_REQ_LOCAL_LSB/MSB_OFF 是否是 clk_OUT 总线的真正表示？ 寄存器值是否可以后退

3. CPT HWPUSH 事件可以是电平触发还是边沿触发？

我将追问这些问题、并返回给您

Jian

Dominic、  

请参阅以下有关我们讨论的问题的说明：

1. PTM 内核更新-突然或逐渐更新，它能否后退？

2、PCIe_EP_PTM_REQ_LOCAL_LSB/MSB_OFF 是否是 clk_OUT 总线的真正表示？ 寄存器值是否可以后退

[JI]我与 IP 所有者讨论过、他认为 EP 侧可以直接一次性地将基于 PTM 计算的调整应用于 PCIe_EP_PTM_REQ_LOCAL 寄存器。 因此它可以后退。 我将检查设计文件以进行确认。  

3. CPT HWPUSH 事件可以是电平触发还是边沿触发？

[JI]事件必须由边沿触发。 此信息位于 TRM 第11.1.3.4.4节中、其中还指定了脉宽需要为 RCLK 的10个时钟周期。  

此致

Jian

尊敬的 Jian：

感谢您的反馈、也感谢您拨打电话。

[引用 USER="jian35385"[JI]我与 IP 所有者讨论过、他认为 EP 端可以简单地 将基于 PTM 计算的调整直接作为一次性应用于 PCIe_EP_PTM_REQ_LOCAL 寄存器。 因此它可以后退。 我将检查设计文件以进行确认。  [/报价]

很抱歉，如果我不断地向你提出这方面的问题，但你写答案的方式仍然不清楚这对我们意味着什么。 我们在电话中同意、寄存器接口不会用于实际的同步目的。 我已经证明寄存器的值可以后退-问题是这种"调整... 也通过 PTM_LOCAL_CLOCK 应用于计数器输出。

[引用 USER="jian35385"[JI]事件必须由边沿触发。 此信息位于 TRM 第11.1.3.4.4节中、其中还指定了脉宽需要为 RCLK 的10个时钟周期。  [/报价]

如果 PTM_LOCAL_CLOCK_[63：0]向前或向后加速以解决 RC 和 EP 之间的时钟漂移、我相信唯一的选择是我尝试在电话呼叫中概述的方法：

• 等待 PTM 时钟更新中断
• 启用 HW TS 推送
• 等待 CPTS 事件中断
• 禁用 HW TS 推送
• 使用一个足够低阶的 PTM_LOCAL_CLOCK_[n]位、以便上升沿"靠近" PTM 时钟更新的中断

遗憾的是、从您的答案中、我仍然不知道如果我启用 HW TS 推送事件(例如 PCIe_CPTS_CONTRAL_REG 中的 HW1_TS_PUSH_EN 位)、当相应的 HW1_TS_PUSH 信号已经处于高电平时会发生什么情况。 这是一个通用 CPTS 问题、不限于 PCIe PTM 用例、因为如果我使用外部可访问的 CPTS0_HW[12]TSPUSH 信号之一、可能会发生同样的情况。

我相信问题是硬件是否存在 _TS_push_EN 位用于和 HW _TS_PUSH 信号本身、或者如果它用于边缘检测逻辑的输出：

我知道存在竞态条件、即、如果我在设置 HW1_TS_PUSH 信号之前查看 HW1_TS_PUSH 信号并找到该信号为低电平、然后在将该位设置为高电平后查看该信号、那么我不知道是否已经生成了事件、 或者它将在下一个上升沿生成。 但对于所有其他情况(前后均为低电平、前后均为高电平、前后均为高电平)、我将知道哪个边沿触发事件。

由于您提到了 TRM 的"10个时钟"要求("每个硬件时间戳输入必须至少在所选 RCLK 时钟的10个周期内有效。")：这是否意味着 HW TS 推送具有10个 RCLK 时钟的固定延迟？ 例如、如果我使用100MHz RCLK、是否保证在硬件的上升沿之后至少生成10个 RCLK 时钟时间戳事件 TS_PUSH 信号？

此致、

Dominic

[引用用户="Dominic Rath"]

很抱歉，如果我不断地向你提出这方面的问题，但你写答案的方式仍然不清楚这对我们意味着什么。 我们在电话中同意、寄存器接口不会用于实际的同步目的。 我已经证明寄存器的值可以后退-问题是这种"调整... 也通过 PTM_LOCAL_CLOCK 应用于计数器输出。

[/报价]

我们执行了另一项测试、其中我们配置了 PCIe CPTS、以根据 PTM_LOCAL_CLOCK 位22生成时间戳(每~4ms/~8ms 周期切换一次)。 EP PTM 与我们的 RC 同步、PTM 对话周期(PTM_REQ_LONG_TIMER)为256ms。 CPTS 捕获的时间戳的间隔正好为8388608ns (2^23)、但~32时间戳的间隔为~2200ns。 这意味着 PCIe EP 内核("clk_out bus")输出的 PTM_LOCAL_CLOCLOCK 值与每个 PTM 对话框上的 PCIe_EP_PTM_REQ_LOCAL_LSB/MSB_OFF 寄存器(每1...256ms 一次)类似、会发生向后阶跃。

我们执行了另一项测试、其中选择了 PTM_LOCAL_CLOCK 位26 (每~67ms 切换一次、即长时间保持稳定)、通过轮询该位的高电平等待、然后设置 HW1_TS_push_EN 位。 在这种情况下、CPTS 不会生成事件、因此我假设我概述的权变措施将起作用。

此致、

Dominic

[引用用户="jian35385"]

我看到 TRM 描述了新的位"PTM_REQ_PDEL_BYTE_REV"、但很遗憾、PG 1.0的勘误表中没有记录任何问题。 我现在使用的是 PG 1.0、但 PTM 对话框本身似乎可以正常工作。 ReponseD 消息是否同时作为发件人(RC)和接收人(EP)受到影响？ PG1.0错误如何影响 PTM 对话框？

[JI]发送回 x86的延迟将按反向字节顺序进行交互。 因此、您的 PTM 计算将使用错误的延迟。 当然，如果 x86将延迟设置为0，则不起作用。 请检查 PG1勘误表、应存在勘误表。  

[/报价]

我相信我在电话会议中已经提到过这一点、但勘误表(修订版 E)文档没有提到这个问题。

我已经使用 PG2.0 AM65x 进行了设置、除非我设置"PTM_REQ_PDEL_BYTE_REV"位、否则我们的时间同步会失败。

如果我查看 PCIe_EP_PTM_REQ_PROP_DELAY_OFF 寄存器、我会发现值为0x140 (几位数)、其中 PG 1.0器件或 PG 2.0器件、并设置了"PTM_REQ_PDEL_BYTE_REV"。 如果我使用 PG 2.0器件、但未设置"PTM_REQ_PDEL_BYTE_REV"位、则寄存器读为"0x40010000"、这是如果 PG 1.0器件出现问题、我会得到的错误值。

位设置后、行为与 PG1.0硬件相同、即 PTM_LOCAL_CLOCK 漂移与 RC 时钟的漂移(通过查看 PCIe_EP_PTM_REQ_T1_LSB_OFF 和 PCIe_EP_PTM_REQ_MASTERT1_LSB_OFF 进行验证)。

看起来、阿波罗湖 x86使用与 PG 1.0 AM65x 相同的反转字节顺序来处理 ReponseD 消息、或者 PG 1.0实现没有问题、PG 2.0使情况更糟(但可修复、得益于"PTM_REQ_PDEL_BYTE_REV"位)。

如果您能确认我的调查结果、那将会很好。

此致、

Dominic

离线讨论摘要：

 Jian to：

• 发送 AM64联系人并检查 J7。  
• 共享 TI PTM 编程模型
• 在大偏差情况下与 Dominic 保持一致  

Jian