[参考译文] DRA829J：检测 DDR 刷新并在跟踪总线上通知它们

您好！

有人想了解有关 此主题的任何信息吗？

谢谢

劳伦特

您好、Laurent、 您好 、Dmitry、

-0-

我根据我们最近一次的会议和本主题中的问题、使用 cp示 踪剂探头进行了一些实验。  我将在这里进行总结、我会通过电子邮件发送一些脚本更新。

-1-

对于延迟和吞吐量探头、我可以在低至3.07uS 的 MCU 探头上获得稳定的样品、而不会出现很多问题。  这与理论最大值和 cpt.xyz.abc.period 0x0匹配。  该模式下最小采样为1/频率* 0x3ff (对于 MCU、该采样值为 freq=333MHz)。   对于 MSMC 探针、随着采样周期的缩短、我的确注意到了时间戳问题。  看看影响、我可以证明这是由于探针时间分布集成中的 TDA4V 勘误表所致。  这里的好消息是、有一个可以应用于 TRACE32工具的软件工作机制。  我已经向 Lauterbach 提出了一个问题、并提供了有关如何解决该问题的信息。  他们正在查看信息。  对于 MSMC 探头(不存在时间干扰时)、我发现我能够在1.023uS 下获取1/freq * 0x3ff 样本(freq=1GHz)。  从我的测试来看、一旦应用了工具解码器的勘误修复、通常解码应该是可能的。  

对于事务探测器、根本不使用采样周期输入。  这些探测器的生成速度与流量生成速度一样快(其问题到完成的延迟)，但插槽有限，因此它在一定程度上统计了在短时间窗口中可以捕获多少个插槽。  我在调试器中用转储窗口做了一组实验、接收速率与转储窗口刷新时间相关联。  默认情况下为10ms (开始刷新窗口)。  将窗口刷新率设置为最大值后、两次更新之间的速率达到~700us。   接下来、我对 DDR 中单个地址上的 CPU (R5和 A72)循环进行了实验、并且我在有限的时间范围内启用了事务探测器。  对于一系列的事务、事务到事务的捕获时间约为~280nS。  一旦遇到计时错误、便停止解码。   此路径上的探头网络本身可以接收16Gbps 的数据、因此对于此测试、它看起来捕捉突发脉冲的限制因素是访问延迟本身。   我做了最后一个测试来尝试在2GHz CPU 的输出处捕获信息、然而、这完全被时序错误占据了主导地位。  一旦制定了解码器修复、就应该可以获取有关这些极低延迟事件的信息。

-2-

就触发而言、CP 跟踪器有两个通过 cTI 的输入触发器、允许基于匹配的跟踪启动、跟踪停止和1个输出触发器。  因此、如果在滤波器上发生匹配、则可以对单元进行编程、以在全局触发总线上生成脉冲。  可以配置 CTI 触发通道、以便可以生成 A72上的处理器中断、并且可以生成其他内核。

Richard、您好！

非常感谢您的详细实验和说明。
要使用此方法获取 DDR 刷新、我们将首先尝试使用 MSMC 探针。 但我们仍不确定以下两种 CP 示踪剂模式中的哪一种适合我们的用例。

延迟统计模式现在看起来更好、最大的问题是时间戳的 J7问题、该问题现在似乎可以通过权变措施来解决。 我们现在正在研究如何获得周期为~1us 的 DDR 刷新的良好统计数据。

对于事务探测、采用"事务限定符筛选"函数、我想配置筛选器、以便在所需的事务开始和停止时获取事务 HLTM 消息、从而获取事务的持续时间(通过时间戳)。 这是为了通过仅记录相关信息来更大限度地减少调试互连上的流量。
在 SDK 文档(08_06_00)的8.6 "使用 CP Tracers 进行流量分析"中、对筛选器进行了简要描述、但我无法直接找到如何记录   事务的开始和结束。
这是可行的吗？ 我是否监督了一种可能性、或者您是否看到了另一种解决方案来获取交易持续时间？

此致、

劳伦特