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.

[参考译文] AM6442:确保 PRU 在仲裁中胜出

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1622953/am6442-make-sure-pru-wins-arbitration

器件型号: AM6442

我正在开发一个需要 PRU 读取 DRAM0 的应用、但我需要确切知道 LBBO 指令需要多少个周期;每次都需要多少个周期。

为此、我需要确保如果有任何其他内核正在写入 DRAM0、PRU 将始终在仲裁中胜出、从而使时钟周期数保持不变。

这篇 E2E 文章中、PRU 工程师提到了一种方法、可确保 PRU 在每次尝试读取 DRAM0 时赢得仲裁。

"If you want to completely avoid arbitration delay, you could program the non-PRU core to perform multiple 4 Byte writes instead of a single long write. In that case, the PRU would win arbitration every clock cycle it initiates a read. 

根据我的理解、如果 R5F 正在使用以下 API 写入 DRAM、那么由于每次单独写入的值小于 4 字节、每当 PRU 尝试读取 DRAM 时、它就将赢得仲裁。

我了解仲裁胜出意味着 R5F 将在四字节写入期间暂停、PRU 将读取存储器、然后 R5F 将完成写入调用中的剩余字节?

R5F API 调用: HW_WR_REG16(0x30000000 +偏移,值);

 

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

    警告未来读者:此响应中的信息 不能保证正确。 我还在自己掌握这些信息。  一些细节可能是错误的。 如果我们稍后未在此主题中提供结论性解决方案、请随时创建新的 E2E 帖子、询问更新。

    您好 Darren、

    问得好。 下面我来回答一下我目前的理解、然后再次咨询 硬件设计人员。

    供参考:硬件验证是一项正在进行的工作

    我正在与另一名员工合作、验证此常见问题解答中提供的所有信息、修复所有问题、然后更新 PRU 读取延迟应用手册、并将测试代码发布到 OpenPRU 存储库:
    【常见问题解答】PRU:如何计算读取和写入延迟? 

    首先、我们测试各个读取、然后测试仲裁延迟。 仲裁延迟可能需要 写成 单独的文件。 不幸的是,我不确定我们是否会有带宽在 3 月份进行仲裁测试。

    如果您有兴趣查看 测试代码,或者您想使用我们的测试代码,然后用它来编写您自己的仲裁测试,请告诉我。 我非常高兴能在这方面与你们合作。

    那么、当前的理解是什么?  

    首先、该常见问题解答中有关内部总线架构的信息如所示 不会 完全正确。 遗憾的是、任何地方都没有更好的文档、因此我已经与开发人员一起逐位了解了实际的内部硬件设计。 希望我下周能提供更多信息。 现在,我认为一切都是一个假设,直到它已经通过实验验证。

    首先、如果 R5F 的工作方式与 PRU 的工作方式相同、我不希望 R5F 内核本身实际上暂停执行(我不是 R5/RTOS 专家,因此可能是错的)。 至少在 PRU 上、写入是一次性的。 写入仍然可能存在细微的仲裁延迟(例如,两个不同内核写入同一输出端口,或 XFR2VBUS 加速器和 PRU 内核写入同一输出端口)、但一旦写入退出 PRU 子系统、PRU 执行将继续、无论 PRU 数据通过系统总线生成并进入目标存储器所需的时间如何。

    话虽如此,大家的理解也是我目前的理解 — 如果 R5F 数据在 PRU 子系统的内部 CBASS(VBUSP 架构)中排队、并且来自 R5F 的数据在其中一个 PRU 内核尝试读取或写入 DMEM0 的同时尝试命中 DMEM0、那么 PRU 内核(所有 PRU 内核)应该能够优先于来自 PRU 子系统外的访问。 R5F 数据应在总线中暂停、直到 PRU 完成执行、然后再推送到 DMEM0。

    此致、

    Nick

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

    您好!

    想要提供更新。 我将上面列出的常见问题解答重写为 2 个单独的常见问题解答。  

    有关读取/写入延迟的常见问题解答位于此处:
    【常见问题解答】PRU 读取和写入延迟

    虽然我添加了有关 XFR2VBUS 工作原理的信息、但大多数内容都没有变化。

    有关仲裁延迟的常见问题解答如下:

     【常见问题解答】PRU 仲裁延迟 

    我对此版本的方框图相当有信心、但我仍需要验证 PRU 子系统内部 CBASS 内的优先级。 现在、暂时看起来 PRU 和 TX_PRU 内核的优先级将高于外部读取、但 RTU 内核的优先级将低于外部读取。 仍在验证、如果我没有提供明确的响应、请在星期一上 ping 通该线程。

    此致、

    Nick