• 状态 Resolved
  • 已锁定 已锁定
  • 回复 11 回复
  • 订户 0 订户
  • 视图 997 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] DRA829V：用于运行时测量的迹线记录的准确性

admin
Guru**** 2543530 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1087499/dra829v-accuracy-of-trace-records-for-runtime-measurement

部件号：DRA829V

您好，


我目前正在测量MCU R5F内核上的软件运行时间，运行频率为1 GHz。 代码从MCU_OCRAM运行，堆栈位于核心的TCM中。 MSMC SRAM用作与其他内核共享的内存。 该应用程序基于RTOS PDK 07.03 ．00，由TI SBL启动。

在运行时间比预期长的地方，我更详细地了解了劳特巴赫T32 POWERTRACE调试程序收集的跟踪记录。
在跟踪列表中，我发现访问堆栈所需时间很长的情况令人惊讶。 例如，在这里，堆栈(R13)上的局部变量的初始化显然需要555ns。

TCM的高速缓存已被禁用，但由于内存非常快，我认为这不会产生这样的影响。

事实上，为函数测量的整体运行时间似乎是正确的，并且与单个记录一致。 在许多情况下，我能够通过 独立测量(读取硬件计时器，切换GPIO和使用示波器测量)来确认劳特巴赫调试器报告的整体运行时。

所以我的问题是

1)跟踪记录到特定代码行的测量时间和跟踪记录的对齐精度如何？

2)如何确定时间"实际"花费在哪里(以及为什么)？

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

    您好，Thomas：

    请提供以下详细信息：
    1)您从PDK运行哪种应用程序？  
    2)您是否在其他应用中也获得类似的读数？

    此致，
    第

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

    1)测试不是通过PDK应用程序执行的，而是通过基于PDK启动代码和驱动程序的自定义应用程序执行的。

    2)是的，我在不同的应用程序上见过几次。 一位同事也看到A72上的堆栈访问有类似的行为，但我们没有详细调查。

    此致

    Thomas

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

    您好，Thomas：

    对延迟响应深表歉意。  

    您能否分享一些参考代码，我可以使用这些代码来复制我的观察结果？

    此外，请检查在这些长时间操作期间是否存在任何缓存未命中。

    此致，
    第

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

    您好，Parth：

    问题在于，该影响随机出现在代码的不同部分。 我无法准确再现延迟发生的时间和地点。

    在查看 Lauterbach跟踪图时，如果重复调用的函数的执行时间比同一函数的其他调用要长得多，则可以确定发生这种情况的情况。

    下面是一个示例(与上面相同的应用程序，但功能不同)：

    在描记图中，该功能的"短"执行部分标记为绿色。 在下一个呼叫中，相同的代码需要更长的时间，标记为红色。 当我在此位置显示迹线列表(由垂直蓝线表示)时，705ns运行时间显然是由指令引起的

    STR r0，[R13，#0x0C]  

    当我看上一个(绿色)呼叫时，同一个指令只花了20毫秒。

    堆栈指针R13指的是TCM，缓存被禁用。 在  执行代码期间，PMU也没有报告任何数据高速缓存丢失。 当我步过函数调用时，我得到的每个调用的指令缓存未命中次数始终完全相同(~20)。 但是，很难判断是否也会发生延迟，因为在这种“停止并继续”调试过程中，跟踪数据变得非常无用。  

    那么回到五月初的问题：我对劳特巴赫调试器所显示的内容的解释是否正确？ 延迟是否真的是由TCM中的堆栈访问引起的？

    什么可能导致这种较大的运行时抖动？

    此致

    Thomas

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

    您好，Thomas：

    查看404.5681万查看 Lauterbach图表时，如果重复调用的函数的执行时间比其他函数要长，则可以确定发生的情况。

    所以这个反复调用的函数，是否每次都从同一个上下文调用？ 我想知道这些重复呼叫是如何发出的？

    此致，
    第

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

    是的，它来自相同的上下文。 这只是一个简单的测试应用程序，用于测量功能运行时。 该函数每500毫秒从计时器函数上下文中调用几次。

    对于计时器，我使用OSAL的TimerP功能。  在500毫秒之间，每隔1毫秒会发生另一个由OSAL处理的计时器中断，并执行其他一些要测试的功能。  

    此致

    Thomas

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

    您好，Thomas：

    能否确认函数执行未中断？ 您可以禁用系统中的所有中断(调用测试函数的一个中断除外)，并查看是否看到相同的行为。

    此致，
    第

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

    您好，Parth：

    如果有中断，我 应该在跟踪图中看到它。 但没有。 这会让我回到原来的问题：迹线数据的准确性如何？

    是否 存在未被跟踪硬件注意到的中断？

    此致

    Thomas

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

    您好Thomas：

    是从片上(TBR)或通过片外(TPIU)进行解码的轨迹。  您启用并尝试了哪些ETM.timemode模式？ 通常，TRACE32可以用不同的方式来计算时间。  它将使用内嵌时间戳或工具应用的时间戳，或者可以同时使用这两个时间戳。  您也可以让Lauterbach支持这个问题，因为他们有TDA4V板，是这里最深的专家。 这里的TRACE32 PDF文档通常也很好。  如果我正确调用，ARM ETM将发出跟踪航点。 并非每个说明都有航点。 解码器将使用elf符号+航点+各种时间标记重建报告中所示的时间。  通常会将一些指令执行时间汇总到给定的航点。 有些ARM内核允许使用精确到周期的跟踪计时选项，当这些选项出现时，CPU将在流中插入更多的计时信息，这有助于提供更高的每个指令计时精度。 R5不支持ARM提供的所有选项。

    如果您在其他情况下将时间与其他方式(本地PMU和GPIO)相关联，我倾向于相信所见的时间戳。 您可以运行trace.statistic.symbol报告以获得观察到的最小值/最大值/平均值/计数。 如果您的所有代码都在TCM中运行，我希望时间非常规律，抖动极少。 如果在R5内存外部运行窗体并启用了缓存，我希望函数运行时间有时会有大量的变化。   请注意...根据ARM Arch文档，TCM本身从未被缓存，您的MPU是否将其标记为，如在其他方法之前查找TCM映射。  高速缓存未命中和重新加载(I高速缓存或D高速缓存或两者组合)可能具有可变的重新加载时间，具体取决于系统争用和源。 例如，如果源代码为DDR，则您的访问可能与自动刷新或重新培训时间段冲突，并在uSeconds中受到影响。  即使是其他源(如MSMC SRAM)也可能在总线上或银行中发生争用，具体取决于系统中执行的其他代码。  您可能会发现相同的代码在不同的R5核心上运行的速度稍快，因为访问延迟不相同。

    此致，

    Richard W.

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

    您好Richard：

    感谢您的详细回答。 我之前已经查看了一些Lauderbachs PDF，但没有查看此特定问题。 我想再次来看一下它们是很有意义的。

    解码发生在片外(TPIU)，而ETM时间代码是 ASYNCTIMESTAMPS。

    与您在我的其他主题中提到的Snooper功能( TDA4VM: R5F指令高速缓存未命中由调试器引起-处理器论坛-处理器- TI E2E支持论坛)一起，我想我将获得一个很好的方法来了解处理器并找出发生的事情。

    谢谢，致以诚挚的问候

    Thomas

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

    您好Thomas：

    请注意，Cortex-R5上的PMU "运行时"无仪器采样技术仅限于ETM单元中的计数器。 核心中的计数器只能在核心停止时或通过协处理器指令插入读取。 如果您在Cortex-A内核上使用此Snooper样本方法进行配置，则没有限制，因为所有计数器(内核和ETM)都可在运行时访问。  无需检测(和干扰)代码就能获得良好的统计数据，这一点非常有用，因为TRACE32的即时报告无需后处理。 我强烈建议您浏览Snooper AppNote https://www2.lauterbach.com/pdf/app_snooper.pdf 。

    如果您更深入地了解ETM单元，您将会发现它，而且调试器可以以无仪器的方式执行大量实时流检查。  许多技术，在这些技术中，用户可以使用调试器管理的专用计数器和事件来记录带有计数器的代码。 与直接插入代码相比，使用模型实际上非常复杂，但在某些情况下，它是值得的。

    最后一个注意事项是，由于您有一个外部接收器连接到TPIU，如果将模拟或数字探头扩展添加到调试器，您还可以获得超过指令的时间相关事件+我讨论过的核心-微事件。  将电压，电流与指令相联系的时间非常好，因为可以根据CAN总线上的总线模式获得停止触发器或其他情况。

    此致，
    Richard W.