[参考译文] RM48L952：内存访问性能

您好！

我们现在使用新的存储器设置播放了一段时间、读取速度仍然很慢(至少在某些情况下是如此)...

问题1：当 RM48没有缓存时、配置哪种正常存储器类型是否重要？ 我想、在查看 R4的 ARM 文档后无关紧要(只了解我所阅读的一个部件)。。。
问题背景：
SAFERTOS 不会列出所有选项(看起来 portmpu.h 中缺少所有共享选项，确切地说是值6,7,0xC) ，但它列出的选项比 HalCoGen 多得多。 HalCogen GUI 不允许选择 SafeRTOS 使用的值(确切地说、GUI 不会显示任何包含"其他属性"的选项。

简短测试不显示2、3、8和0xB 之间的差异(可通过 SafeRTOS 接头进行选择)。 当然、也可以手动设置这些共享值(但认为应该有一些逻辑原因、为什么这些值是来自 SafeRTOS 头文件的错误值)、0xC 也会像任何其他值一样工作。

SafeRTOS 用于自己的内部 MPU 区域 (保护内核数据)对于 RAM、它使用 OS 标头中不允许更改的0x0B (MPU_NORMAL _OIWBWA_NONSHARED)。


Q2：DMA 是否与 MPU 相关的存储器设置完全独立？ 是否可以设置任何存储器类型 shared/non-shared、即使 DMA 也会与 CPU 同时访问相同的存储器位置？
问题背景：
存储器区域从 MPU_STRONGLYORDERED_sharable 明显更改为正常加速写入速度、但 DMA 速度保持不变。 已经了解到 DMA 是另一个具有自己的"规则和功能"的独立总线主控、因此可以看到的效果最有可能是有效/正常/正常？

使用 DMA，尽管配置了 memcpy()，但从 int->ext 移动12000字节的数据大约需要300us。正常情况下，相同的移动需要~150us，而强顺序则需要~380us。


问题3：为什么 SDRAM 的读取速度不仅慢，而且还非常慢？
问题背景：

我们有简单的测试、我们使用宏命令重复这些测试、并使用 PMU 计算 clk (使用补偿)、还使用 us-counter 双校验结果。 此外、还通过分解器验证了指令的正确乘积、并且不存在循环：
a)从内部/外部读取
b)写入内部/外部
c)从 int 移动到 ext / ext 移动到 int
d)在内部/外部移动

a 和 b) r：1000 CLKS | w：2492 CLKS | r_ext：68025 CLKS | w_ext：1000 CLKS
c) motelvet_ext：2000 CLKS | motelvet_int：68026 CLKS
d) moveinside_int：3492 CLKS | moveinside_ext：68026 CLKS

美国时间双次检查(由于时间可能会改变或刚刚改变、因此220是正常的差异、而且我们的时间不会得到补偿、并且在 PMU 开始和停止之前和之后会进行时间戳记)：
a 和 b)取值：5us => 1100 CLKS
采用：12us => 2640 CLKS
采用：310us => 68200 CLKS
取值：6us => 1320时钟

c)采用：10us => 2200 CLKS
采取了：309us => 67980 CLKS

d)采用：17us => 3740 CLKS
采用：310us => 68200 CLKS

可以看到、PMU 计算与 PMU 测量非常匹配。

Q4：为什么对 SDRAM 执行的读取操作看起来高度依赖于以前执行的操作？
问题背景：
我们将写入测试更改为包含写入结果后读取的 STR、LDR、STR、LDR 模式、而不是纯 STR、STR、STR
d1000 (* pu32Addr = u32Value；)；
->
d1000 (*pu32Addr = u32Value；(void)*pu32Addr；)；

人们会期望、现在'w_ext'将像'r_ext'所花费的时间一样永恒
R：1003 CLKS | w：8000 CLKS | r_ext：68024 CLKS | w_ext：6000 CLKS

然后修改了读取测试以包含写入、并且我们突然没有任何性能问题。
d1000 ((void)*pu32Addr；)
->
d1000 (*pu32Addr = 0；(void)*pu32Addr；)
R：7000 CLKS | w：7000 CLKS | r_ext：6000 CLKS | w_ext：6000 CLKS

Q5：PMU 测量 CPU CLKS、它如何以1 clk 的格式写入 EMIF、哪个 clk 是 CPU clk 的1/4 (也在 Q4中读取)？ 只是想知道测试设置中是否有这样的错误、即使是三重检查了所有内容并验证了写入操作确实已进入 SDRAM。 流水线是否会以某种方式将其与存储缓冲区一起解释、以及可能还有什么"隐藏的段"？

===问题结束===

从第3季度和第4季度可以看出、很难说出第三季度出现的读操作缓慢和第四季度因应用而被忽略的影响。 看起来有一种变化、即单个读取速度快或非常慢、这将是随机的... 根据测试、如果读取速度始终达到"快速"状态、则可能会产生很大的影响、因为将存储器从强状态更改为正常状态、从而加速写入、影响~5%(单位)(平均值为~88%、 现在、该值为~83%、器件的外部输出相同) 、应用 CPU 负载也是如此。

仅有关 stronly_ordered 的信息、原始测试结果为(写入也很长)：
R：1000 CLKS | w：2492 CLKS | r_ext：68026 CLKS | w_ext：56023 CLKS
MODELAG_ext：56024 CLKS | MODELAG_INT：68028 CLKS
moveinside_int：3492 CLKS | moveinside_ext：124022 CLKS

还注意到 memcpy()使用(在 IAR 中) STM 和 LDM 指令，而自己的专为循环而设计当然使用 STR&LDR。 当为循环优化位时(使用 DO10、因此需要拆分后舍入到1/10、以1舍入的方式移动10 uint32)、memcpy 随 STR&LDM 的4个寄存器(=4 uint32)移动 int->ext 的性能在理论上是相同的、但 ext->int memcpy LDM 指令看起来比 STR 快~2倍(移动了12000字节)。

带 DO10的 for 循环：
ext->int: memcpy tur: 928us
Int->ext memcpy 采用了：152us
寻找使用 LDM 和 STM (4寄存器)的实数 memcpy()函数：
ext->int: memcpy 采用了：499us
int -> ext：memcpy 采用了：152 us

随附的是测试代码、其中可以看到和复制原始测试逻辑(从 SAFERTOS 任务运行导致操作系统在操作系统启动时配置/启用 MPU)、尚未尝试使用评估板和 CCS。 可以删除美国时间测量值、因为这些测量值只是为了验证 PMU 的工作和测量值是否正常(因为在进行补偿测量时、我首先使用了所有4个计数器(当然时开始和停止了1个计数器)、并尝试检查每个人是否提供了相同的补偿、但它们没有、 即使是在编译之间、单计数器(EVT1)也希望提供一个+2 CLKS、这也许是流水线相关的... 还注意到、从结果中减去补偿时、超过1条指令的测量可能会导致"负"值(在从结果中进行实际测量之前)。 感觉计算出的精度不是很高(可能需要在执行任何操作之前使用一些流水线和存储缓冲区清空指令)、这就是为什么在测试中使用1000条指令来最大限度地减少+-2 clk 测量的影响。

此致、
Jarkko

e2e.ti.com/.../6064.testcode_5F00_1000.c

您好、Jarkko、

我添加了蓝色的注释。

此致、

Sunil

----------------------------------------------------

我们现在使用新的存储器设置播放了一段时间、读取速度仍然很慢(至少在某些情况下是如此)...

问题1：当 RM48没有缓存时、配置哪种正常存储器类型是否重要？ 我想、在查看 R4的 ARM 文档后无关紧要(只了解我所阅读的一个部件)。。。

>>你是对的。 唯一对访问产生影响的配置是存储器是配置为"正常"还是"器件"、还是配置为"严格排序"类型。

问题背景：
SAFERTOS 不会列出所有选项(看起来 portmpu.h 中缺少所有共享选项，确切地说是值6,7,0xC) ，但它列出的选项比 HalCoGen 多得多。 HalCogen GUI 不允许选择 SafeRTOS 使用的值(确切地说、GUI 不会显示任何包含"其他属性"的选项。

简短测试不显示2、3、8和0xB 之间的差异(可通过 SafeRTOS 接头进行选择)。 当然、也可以手动设置这些共享值(但认为应该有一些逻辑原因、为什么这些值是来自 SafeRTOS 头文件的错误值)、0xC 也会像任何其他值一样工作。

SafeRTOS 用于自己的内部 MPU 区域 (保护内核数据)对于 RAM、它使用 OS 标头中不允许更改的0x0B (MPU_NORMAL _OIWBWA_NONSHARED)。


Q2：DMA 是否与 MPU 相关的存储器设置完全独立？ 是否可以设置任何存储器类型 shared/non-shared、即使 DMA 也会与 CPU 同时访问相同的存储器位置？

问题背景：

存储器区域从 MPU_STRONGLYORDERED_sharable 明显更改为正常加速写入速度、但 DMA 速度保持不变。 已经了解到 DMA 是另一个具有自己的"规则和功能"的独立总线主控、因此可以看到的效果最有可能是有效/正常/正常？

>>"共享"或"非共享"类型不影响 CPU 和 DMA 之间的并发访问。 此设置用于管理访问共享存储器区域的多个 CPU。 为了防止基于地址的虚假写入到内存区域、DMA 有其自己的 MPU。

使用 DMA，尽管配置了 memcpy()，但从 int->ext 移动12000字节的数据大约需要300us。正常情况下，相同的移动需要~150us，而强顺序则需要~380us。

>>存储器类型配置主要影响 CPU 的写入速度。 对于 DMA 访问、请尝试读取最大元素大小(64位)、以便使用 DMA 的打包/解包功能。

问题3：为什么 SDRAM 的读取速度不仅慢，而且还非常慢？

>>外部存储器根据其在互连中的位置与 CPU "远"、因此每次读取访问都需要花费20多个周期来完成。 此外、SDRAM 时钟仅限于55MHz。 这些因素决定了 SDRAM 的读性能。 典型的用例(应该)是在启动/断电时或应用期间偶尔从外部存储器读取数据。

问题背景：

我们有简单的测试、我们使用宏命令重复这些测试、并使用 PMU 计算 clk (使用补偿)、还使用 us-counter 双校验结果。 此外、还通过分解器验证了指令的正确乘积、并且不存在循环：
a)从内部/外部读取
b)写入内部/外部
c)从 int 移动到 ext / ext 移动到 int
d)在内部/外部移动

a 和 b) r：1000 CLKS | w：2492 CLKS | r_ext：68025 CLKS | w_ext：1000 CLKS
c) motelvet_ext：2000 CLKS | motelvet_int：68026 CLKS
d) moveinside_int：3492 CLKS | moveinside_ext：68026 CLKS

美国时间双次检查(由于时间可能会改变或刚刚改变、因此220是正常的差异、而且我们的时间不会得到补偿、并且在 PMU 开始和停止之前和之后会进行时间戳记)：
a 和 b)取值：5us => 1100 CLKS
采用：12us => 2640 CLKS
采用：310us => 68200 CLKS
取值：6us => 1320时钟

c)采用：10us => 2200 CLKS
采取了：309us => 67980 CLKS

d)采用：17us => 3740 CLKS
采用：310us => 68200 CLKS

可以看到、PMU 计算与 PMU 测量非常匹配。

Q4：为什么对 SDRAM 执行的读取操作看起来高度依赖于以前执行的操作？
问题背景：

>>我必须检查此内容并返回给您。 在继续下一次写入之前、您是否从刚刚写入的位置读回？

我们将写入测试更改为包含写入结果后读取的 STR、LDR、STR、LDR 模式、而不是纯 STR、STR、STR
d1000 (* pu32Addr = u32Value；)；
->
d1000 (*pu32Addr = u32Value；(void)*pu32Addr；)；

人们会期望、现在'w_ext'将像'r_ext'所花费的时间一样永恒
R：1003 CLKS | w：8000 CLKS | r_ext：68024 CLKS | w_ext：6000 CLKS

然后修改了读取测试以包含写入、并且我们突然没有任何性能问题。
d1000 ((void)*pu32Addr；)
->
d1000 (*pu32Addr = 0；(void)*pu32Addr；)
R：7000 CLKS | w：7000 CLKS | r_ext：6000 CLKS | w_ext：6000 CLKS

Q5：PMU 测量 CPU CLKS、它如何以1 clk 的格式写入 EMIF、哪个 clk 是 CPU clk 的1/4 (也在 Q4中读取)？ 只是想知道测试设置中是否有这样的错误、即使是三重检查了所有内容并验证了写入操作确实已进入 SDRAM。 流水线是否会以某种方式将其与存储缓冲区一起解释、以及可能还有什么"隐藏的段"？

>>是的、写入内部存储缓冲区需要一个 CPU 周期。 这只能在外部存储器配置为"正常"类型时实现。 然后、CPU 可以自由移动到下一条指令、而对外部存储器的写入由互连元件"管理"。

===问题结束===

从第3季度和第4季度可以看出、很难说出第三季度出现的读操作缓慢和第四季度因应用而被忽略的影响。 看起来有一种变化、即单个读取速度快或非常慢、这将是随机的... 根据测试、如果读取速度始终达到"快速"状态、则可能会产生很大的影响、因为将存储器从强状态更改为正常状态、从而加速写入、影响~5%(单位)(平均值为~88%、 现在、该值为~83%、器件的外部输出相同) 、应用 CPU 负载也是如此。

仅有关 stronly_ordered 的信息、原始测试结果为(写入也很长)：
R：1000 CLKS | w：2492 CLKS | r_ext：68026 CLKS | w_ext：56023 CLKS
MODELAG_ext：56024 CLKS | MODELAG_INT：68028 CLKS
moveinside_int：3492 CLKS | moveinside_ext：124022 CLKS

还注意到 memcpy()使用(在 IAR 中) STM 和 LDM 指令，而自己的专为循环而设计当然使用 STR&LDR。 当为循环优化位时(使用 DO10、因此需要拆分后舍入到1/10、以1舍入的方式移动10 uint32)、memcpy 随 STR&LDM 的4个寄存器(=4 uint32)移动 int->ext 的性能在理论上是相同的、但 ext->int memcpy LDM 指令看起来比 STR 快~2倍(移动了12000字节)。

带 DO10的 for 循环：
ext->int: memcpy tur: 928us
Int->ext memcpy 采用了：152us
寻找使用 LDM 和 STM (4寄存器)的实数 memcpy()函数：
ext->int: memcpy 采用了：499us
int -> ext：memcpy 采用了：152 us

随附的是测试代码、其中可以看到和复制原始测试逻辑(从 SAFERTOS 任务运行导致操作系统在操作系统启动时配置/启用 MPU)、尚未尝试使用评估板和 CCS。 可以删除美国时间测量值、因为这些测量值只是为了验证 PMU 的工作和测量值是否正常(因为在进行补偿测量时、我首先使用了所有4个计数器(当然时开始和停止了1个计数器)、并尝试检查每个人是否提供了相同的补偿、但它们没有、 即使是在编译之间、单计数器(EVT1)也希望提供一个+2 CLKS、这也许是流水线相关的... 还注意到、从结果中减去补偿时、超过1条指令的测量可能会导致"负"值(在从结果中进行实际测量之前)。 感觉计算出的精度不是很高(可能需要在执行任何操作之前使用一些流水线和存储缓冲区清空指令)、这就是为什么在测试中使用1000条指令来最大限度地减少+-2 clk 测量的影响。

感谢您的回答！ 猜测我们不必再专注于存储器类型。 从理论上讲、仅阅读部分是仍有问题的部分(另请参阅文章底部的内容、也可以看到、编写内容需要一些时间、现在比通常时间要花费更多的时间)。

[引用用户="Sunil Oak "]

>>我必须检查此内容并返回给您。 在继续下一次写入之前、您是否从刚刚写入的位置读回？

[/报价]

是的、我们从刚刚写入的同一位置读取(变量/指针被声明为易失性、因此尽管刚刚写入0、新的取指令应该一直发生)。 另请注意、这1000个原始读取操作在一行中、所有这些操作都在同一地址中执行。

注意：顺序看起来很重要、首先写入(STR)的结果是这样(之前的帖子中已经有过这种情况、为了便于比较、请将其放在这里)
d1000 (*pu32Addr = 0；(void)*pu32Addr；)
R：7000 CLKS | w：7000 CLKS | r_ext：6000 CLKS | w_ext：6000 CLKS

如果我们只写最后一个、那么第一个 LDR 没有 STR、然后 REST 999 LDR 前面有 STR、我们就会得到88个 CPU CLKS 的延迟、这实际上应该描述执行第一个 LDR 指令的延迟/时间...
d1000 ((void)*pu32Addr；*pu32Addr = 0； )
R：6995 CLKS | w：7000 CLKS | r_ext：6088 CLKS | w_ext：6000 CLKS

[引用用户="Sunil Oak "]

>>外部存储器根据其在互连中的位置与 CPU "远"、因此每次读取访问都需要花费20多个周期来完成。 此外、SDRAM 时钟仅限于55MHz。 这些因素决定了 SDRAM 的读性能。

[/报价]

Q6：我假设20个周期以上是 CPU 周期、为什么要像上面的实验显示那样用"88" CPU 时钟来执行1个 LDR 到 SDRAM 中(原始测试日志显示为对于1000个读取、68000个 CPU 时钟：s、也是68clk/读取)？

~20+ CPU 时钟是可以理解的、但如上所示、它看起来需要88或68个 CPU 周期... 根据 TRM (SPNU503C–March2018)、EMIF 周期如下：RAS、CAS、我们的 CAS 延迟为2、因此总共4个 EMIF CLK、读取32位数据时、在4个 EMIF CLKS 基础上需要2个 EMIF CLKS、因此总共6个 EMIF CLKS、即24个 CPU CLKS。 根据相同的 TRM、写入速度应该更快、因为没有 CAS 延迟、数据可以与 CAS 一起提供)、对于32位单次写入、写入应该是12个 CPU 时钟。

这就是我对"极慢"读取的意思、因为它看起来需要~20 EMIF CLKS 来读取某些内容、有时它不需要那么长的时间...

电源 在原始测试代码中发现1个次要错误，u32MoveToRam()从目标 DO1000错过了"+"(*pu32DestAddr =*pu32SourceAddr++；)。 这会导致"motive_ext"和"moveinside_ext"结果出现延迟、因为现在目标地址发生了变化。 在汇编器中、它仍然是1 STR 命令、只是将 offset 添加为新参数(以前是 STR R0、R5、现在是 STR R0、[R5、#0x...]、LDR 始终与 LDR R0、[R4、0x...]相同)。
下面是"固定版本"结果、它的功能与最初的设计方式相同
C：motelvet_ext：12900 CLKS | motelvet_int：68024 CLKS
D：moveinside_int：3492 CLKS | moveinside_ext：106891 CLKS

现在、当目标地址单步前进而不是固定时、motelvos_ext 所用的时间延长了6倍(以前为2000 clk)
moveinside_ext 结果加倍(为 68026、与纯读取延迟相同)。 完全无法理解从阵列开始的目的是如何加快进程的速度、因为始终正确转发读取地址。 在这两种情况下、读取永远不会发生在与写入相同的地址上、而是在 Q4中发生纯粹的写入/读取测试...

[引用用户="Sunil Oak "]

>>是的、写入内部存储缓冲区需要一个 CPU 周期。 这只能在外部存储器配置为"正常"类型时实现。 然后、CPU 可以自由移动到下一条指令、而对外部存储器的写入由互连元件"管理"。

[/报价]

可以存储缓冲区和互连实际上连续处理1000个写入、EMIF 写入至少需要12个 CPU 时钟、因此在发送1000个项目后、最后应该有~900个项目排队、其中只有~100个项目被处理。 由于写入地址是固定的、要写入的数据是固定的、因此它可能会有所帮助/有所不同？

现在、当复制是固定的并且目标地址也发生变化时、它看起来需要12、9个 CPU 周期/写入(motelvos_ext：12900 CLKS)、这很容易落入预期的 EMIF 周期中、并将证明在某些情况下、存储缓冲区和互连确实会产生一些影响、这使得测试/评估更加困难。

但现在内部 SDRAM 的移动也需要"永恒"(moveinside_ext：106891 CLKS)之前的"moveinside_ext：68026 CLKs"、因此它增加到了40000 CLKS、即40clk/传输。 如上所述，int->ext Move show/打 样，写入应该只需要~12clks/write，但在本例中需要40clk... 总时间应该仅增加~12000...

此致、
Jarkko

我们已经调整了 SDRAM 的某个位的时序(看起来会影响(0)/10-12个 CPU 时钟~3个 EMIF 时钟、具体取决于执行的操作)、并且还删除了自动刷新(这有助于4个 CPU 时钟/操作= 1个 EMIF 时钟)。

需要手动删除自动刷新、因为 halcogen 启用了自动刷新(由于勘误表中的 EMIF#5？) 但不会在 EMIF_SDRAMIni()中将其恢复为空。

调整了时序、使其与 SDRAM 规范真正匹配：

R：1003 CLKS | w：2492 CLKS | r_ext：56033 CLKS | w_ext：1000 CLKS // r_ext：12000更快，w_ext：storebuffer

MODELAG_ext：12871 CLKS | MODELAG_INT：57985 CLKS //读取速度提高10000

moveinside_int：3492 CLKS | moveinside_ext：88923 CLKS // 12000更快


然后、当在时序调整之前调用 sys_startup ()之后删除 SDCR_SR 位时：

R：1000 CLKS | w：2492 CLKS | r_ext：52100 CLKS | w_ext：1000 CLKS // r_ext：4000、w_ext：storebuffer

MODELAG_ext：12834 CLKS | MODELAG_INT：54109 CLKS //移动到 SDRAM (写)“无影响”(~100)，从 SDRAM (读)移动：4000，

moveinside_int：3492 CLKS | moveinside_ext：80693 CLKS //读取和写入=2*4000

没有任何其他更改的原始(正常模式更改)为：

R：1000 CLKS | w：2493 CLKS | r_ext：68023 CLKS | w_ext：1000 CLKS //阅读：从这个改进16000

MODELAG_ext：12900 CLKS | MODELAG_INT：68025 CLKS //阅读：从这个改进了14000

moveinside_int：3492 CLKS | moveinside_ext：106891 CLKS // 与此项相比有20000个改进


因此、"memcpy"现在需要后续时间(由于存储缓冲区等、不再专注于单次重复写入或读取)
内部存储器现在需要80个 CPU 时钟=> 20个 EMIF 时钟//读取和写入
-至存储器12、8个 CPU 时钟=> 3个 EMIF 时钟//写入
-从存储器54 CPU 时钟=> 13、5 EMIF 时钟//读取

是20-(13、5+3)= 3、5个 EMIF 时钟无法解释、为什么读取、写入、读取、写入... 模式比 读取、读取、读取...+写入写入要花费更多的时间。？
此外、与非常匹配 TRM 的写入相比、读取本身所花费的时间要比写入基于 TRM (24CPU clk：s)的预期时间长得多

此致、
Jarkko

您好、Jarkko、

我本周不在办公室、下周将回到工作中。 我希望能够模拟和解释周期差异。 根据其他总线主控的互连活动、可能仍有一些变化、这些变化不会被准确仿真、但是实际的访问时间数将相当准确。

此致、

Sunil

您好！

我在接下来的4周内休假、但我们身边的其他人可能/应该监控进度(我们也有假日季)。 希望他们还能插入几张图片、正确/清晰地说明问题(不要自己拥有)、但我们在总线分析仪中一直看到1张读取 正常、突发中断正常、 但每次读取后、 有9个 EMIF 时钟为"NOP"、只有在这些"NOP"之后、下一次读取才开始... 基本上、"NOP"可以/将会解释缓慢的原因、但我们不能明白为什么这些原因首先出现在那里...

此致、
Jarkko

您好、Sunil、

这些图像来自相同的 SDRAM 读取周期、我已将命令编辑为其中一个图像。 如您所见、我们还没有删除很多 NOP 命令。

此致、

Leevi Hokkanen

您好、Sunil、

我已经持续了一段时间的调查。 我已经达到了这样的地步，我能够再取得一点进展，甚至没有进展。 因此、我将尝试解释到目前为止我发现的内容以及背后的代码。 实际代码作为文件附加、我将逐步解释我预期会发生的情况和实际发生的情况。 然后、我只能等待实际的解释、以及是否可以实现我们在的操作。

我使用 Hercules RM48x 开发套件测试了外部存储器接口性能。 我们的想法是不使用多余的代码、以便更轻松地查看正在发生的情况。 因此、我使用霍尔代码发生器来配置所有必要的寄存器、以使 CPU 启动并运行。 然后、我手动配置了以下 EMIF 寄存器、以便完全确定使用了哪些时序值：

－         SDRAM 配置寄存器                                      SDCR

－         SDRAM 刷新控制寄存器                                    SDRCR

         - SDRAM 时序寄存器                         SDTIMR

         - SDRAM 自刷新退出时序寄存器           SDSRETR

然后、我立即开始使用 EMIF。 我没有遵循 SDRAM 初始化序列、但我没有发现任何关于 EMIF 端性能影响的提到、如果没有这样做的话。 这个测试的目的是确定 EMIF 性能、而不是确定 SDRAM 的可靠性。

然后、我进行了两个简单的循环。 第一个寄存器向 SDRAM 写入10 32位值(从0到9)、并在写入之间将地址递增1。 第二个循环读回的数据与在前一个循环中写入的数据相同。

结果与我的预期不同。 由于 EMIF 仅使用8列突发模式(如果我正确读取了数据表)、我希望在写入循环期间看到以下命令：

         -写入

         7 NOP

         -写入

-         NOP

         -突发终止

但是、我得到以下命令重复10次：

         -写入

-         NOP

         -突发终止

-         NOP

因此、正如我们可以看到的、期望和现实在这里没有达到。 EMIF 在突发终止前没有写入8 16位值、而是在每个32位之后终止(数据大小也是如此)。

以下示波器图像显示了 MCU 和 SDRAM 之间的情况。 第一幅图像具有全部10个写入周期和10个读取周期、随后的图像被放大为同一记录的不同部分。

光标之间有10个写入周期和10个读取周期

光标之间有10个写入周期、其余为10个读取周期

光标之间的所有10个写入周期

在光标之间缩放的第一个写入周期

光标之间的所有10个读取周期

在光标之间缩放的第一个读取周期

当我使用相同的代码时、除了使用64位值而不是32位值写入 SDRAM 外、结果略有变化。 所有64位都是在突发终止之前写入的、然后使用新的写命令写入下一个值。

以下示波器图像显示了 MCU 和 SDRAM 之间的情况。 第一幅图像具有全部10个写入周期和10个读取周期、随后的图像被放大为同一记录的不同部分。

光标之间有10个写入周期和10个读取周期

光标之间有10个写入周期、其余为10个读取周期

光标之间的所有10个写入周期

在光标之间缩放的第一个写入周期

光标之间的所有10个读取周期

在光标之间缩放的第一个读取周期

基于这些结果(以及许多其他测量结果)，我很少有什么可能出错的想法，但我无法验证这些想法。

我知道，只要 CPU 端有“待处理”请求，突发就会持续。 但是、似乎只有当数据类型是写入 SDRAM 时、突发才会继续。 这似乎是一个奇怪的要求、没有多大意义、因为数据类型大小限制会在达到8列突发之前达到。

可能是 CPU 速度太慢，以至于它无法创建足够多的请求到 EMIF，这就是 EMIF 终止写入和读取的原因，因为它不会看到更多来自 CPU 的请求。 但是，如果220 MHz 内核频率无法与55 MHz 内存接口保持一致，似乎有些问题。 这是一个简单的代码、任何实际应用都需要更复杂的代码。

如果 CPU 等待 EMIF 的响应、则可能会导致 CPU 速度缓慢；如果是这种情况、我想知道如何消除它。 这也有很大意义、因为突发模式完全没用。

如果 CPU 没有足够快地获得下一条指令、它也可能会很慢。 对于微控制器和 CPU 的内部操作、我不是很专业、但缓存应该负责这方面的工作、对吧？

大家可以看到、我对这个问题的关注越多、我的问题就越多。 因此需要一些专业帮助。

e2e.ti.com/.../2311.Source.c

此致、

Leevi Hokkanen

编辑1：添加了缺失的源文件。

编辑2：将32位写入/读取示波器图像更改为正确的(与64位写入/读取图像相同)。

编辑3：将源代码更改为在 SDRAM 读/写中使用32位数据类型、正如测试中使用的那样。

您好、Sunil、

如果只有 uint64_t 能够在我说过要附加文件时保留该文件的次数...
但是、现在您可以在我之前的帖子的末尾找到该源代码文件。


此致、
Leevi Hokkanen