[参考译文] TMS320F28075：本地共享存储器上的仲裁机制

您好！

[引用]是否存在循环仲裁意味着、根据之前的循环状态、CLA 读取可能会被暂停一个周期、等待 CPU 写入完成？ [/报价]

没错。 由于 CLA 读取、CPU 写入也可能会被挂起。 这一切都取决于循环状态。

此致、

Vivek Singh

Vivek、

这是否仅在 CPU 和 CLA 都尝试访问完全相同的地址时发生？或者、无论目标地址如何、只要它们都尝试访问相同的 LSRAM 区域、循环就适用？

谢谢、
皮埃尔

皮埃尔

当两个尝试访问相同的 LSRAM 块(即使地址不同且位于同一个块中)时、会发生仲裁/停止。

Vivek Singh

Vivek、

感谢您提供相关信息。 CLA 到 CPU 和 CPU 到 CLA 消息 RAM 是否不同？ 我是说0x1480和0x1500上的值。 它们是否会导致 CLA 执行中的延迟？

谢谢、
皮埃尔

仲裁方案是相同的、但消息 RAM 仅用于数据。

Vivek、

还有两个问题：

• 以前的 ePWM 类型是否已经出现过这种情况、例如 TMS320F28035上的 ePWM 类型？
• 这种轮循仲裁非常麻烦。 例如、这意味着我无法使用 CPU 更新 CLA 控制环路的设定点、而没有延迟控制环路的风险。 因此、CLA 执行的确定性方面始终是其主要优势之一、要确保这一点要困难得多。 是否有任何变通办法或其他功能可帮助缓解此问题？

皮埃尔

您好！

我不清楚您对 ePWM 类型的查询。 在这篇文章中、我们没有讨论 ePWM。

在仲裁时、STALL 只用于一个访问、因此不应在控制环路中引起大延迟。 此外、这仅在读取数据时发生。 对于 CLA 代码执行、LSxRAM 是专用的、因此没有问题。

Vivek Singh

Vivek、

我的缺点是、我在外设名称之间进行了混合。 我的问题是、仲裁方案是否与0类 CLA (类似于 TMS320F28035)和1类 CLA 相同。

关于非确定性延迟的重要性、我认为您对这个问题的看法太轻了。 我在手动优化的程序集中编写控制循环，该程序集的运行频率为~1.5MHz。 我对每个循环只有几十条指令、我需要确切地知道发生了什么以及何时发生。

即使是几个周期的随机延迟也会对控制方案造成严重破坏。 想象一下，它会导致写入 ePWM 比较器的操作发生在*从影子寄存器传输到活动寄存器之后*的一个周期，而不是之前的一个周期？ 结果是控制环路会随机导致一个完整控制周期的延迟。

赋予 CLA 绝对优先级也许更有意义。

此致、
皮埃尔

您好！

[引用] 我的错误、我在外设名称之间进行了混合。 我的问题是、仲裁方案是否与0类 CLA (类似于 TMS320F28035)和1类 CLA 相同。 [/报价]  

仲裁机制与 CLA 类型无关、而是与器件相关。 在 F28035器件上、RAM 被映射到 CPU 或 CLA (不是两者都映射)、因此没有仲裁。 在该器件上提供了仲裁、以便数据可以共享运行时间。  

[引述] 关于非确定性延迟的重要性、我认为您对这个问题的看法太轻了。 我在手动优化的程序集中编写控制循环，该程序集的运行频率为~1.5MHz。 我对每个循环只有几十条指令、我需要确切地知道发生了什么以及何时发生。 [/报价]

仲裁仅适用于数据访问、而不适用于代码执行。 CLA 执行代码的 RAM 专用于 CLA、CPU 无权访问。 如果仲裁引起的一个 CPU 周期延迟是一个大问题、那么避免 CLA 和 CPU 同时访问同一个 RAM 块。

此致、

Vivek Singh