[参考译文] Starterware/AM4377：两条命令之间的 GPMC 延迟

这实际上可能是由许多因素造成的。 很难优化到 GPMC (或任何外设)的单个访问命令的流水线。 代码可能从较慢的存储器运行、也可能不被缓存、因此 ARM 提取和流水线可能会影响到 GPMC 命令的时序。 您必须检查生成的汇编代码、以查看您是否真正发送了紧跟着读取命令的写入操作。 此外、在写入之后从同一位置读取可能会引起 GPMC 有意的一些延迟。
延迟的另一个可能原因是不清楚 CYCLE2CYCLESAMECSEN 位域的值、这将影响周期到周期时序。
通过设置 DMA、可以更轻松地获得单周期读/写访问

谢谢、
James

James、
感谢您的回复和建议。
对于 CYCLE2CYCLESAMECSEN 位字段、它被选中、按预期返回0。
对于 DMA 解决方案、客户很难接受此应用中的 DMA 使用。 由于它不仅是连续的读取/写入操作、因此数据写入/读取具有相应的关系、这需要强序列。 因此、在这种情况下 DMA 是不可接受的。
我认为我们可能会考虑高速缓存的使用。 这主要是因为我们在 AM335x 平台上遇到类似的问题、然后通过启用数据缓存来解决。 因此、我将尝试寻求帮助、以确定这是否是处理当前问题的方法。

下面是 SH FAE 方面的最新更新。 如果需要任何其他信息、请随时告知我们：

客户配置 GPMC 读/写32位数据为140ns。 但是客户会发现、如果他们连续读取和写入 GPMC、则间隔时间将为170~200ns。 他们希望这个间隔时间可以被删除。
客户使用 GPIO 和示波器进行测试。 并且 GPIO 延迟时间已消除。

读取 GPMC 的时间(32位一次)
1188ns
2600ns
3960ns
41290ns

James、
他们希望 GPMC-FPGA 读写操作具有低延迟。 由于这是实时操作使用方案、对于之前由 MCU 实现的电机控制、例如 M3/M4、它们不仅要求在 GPMC 上、而且要求在 GPIO 上进行低延迟操作。 我们刚刚解决了 GPIO 延迟问题、现在 GPMC-FPGA 器件仍然无法为其应用提供良好的延迟数字。 这就是客户的要求。
我列出了每个操作之间的序列、只是试图声称它们不想使用 DMA 功能的原因。
对于装配体零件、我不确定它们是否已经完成。 我很快会检查它。 我是否可以通过检查来优化汇编代码以解决此问题？

Steven、我对汇编代码的真正目标是确保延迟不是由系统中的其他东西引起的。 它们的目标是确保发送到 GPMC 控制器的命令流水线足够好、以减少延迟。 正如我在第一个帖子中提到的、从低速存储器执行或不按顺序启动访问的代码(这可能是由 C 编译不良引起的)会增加延迟并降低对 GPMC 控制器的命令的效率。

此致、
James

James、
非常感谢！
我将在明天早上的电话中查看反馈。

顺便说一下、我知道很难保证 GPMC 控制器的延迟、我们是否可以尝试改善它？
我看到您提到过慢内存、这意味着使用 OCMC RAM 操作 GPMC 发送/接收数据是否有助于提高性能？ 什么是最高效的路径？ 你有什么想法吗？