极海Cortex-M52内核MCU G32R501在CoreMark的表现如何

《极海芯得》系列内容为用户使用极海系列产品的经验总结，均转载自21ic论坛极海半导体专区，全文未作任何修改，未经原文作者授权禁止转载。

1. 前言

要真正衡量一颗MCU的运算实力，CoreMark成绩往往是一个比较客观、公认的参考指标。到底这个G32R501跑起CoreMark来能交出怎样的成绩单？今天就让我们一起“探秘”一番，看这款Cortex-M52 MCU在CoreMark上的表现究竟是“平平无奇”还是“惊艳四座”！

本篇就给大家呈现各版本配置下跑分的情况——不同Flash/RAM运行区域会对CoreMark产生什么样滴影响？

2. CoreMark移植：前置准备

2.1 移植过程

其实，CoreMark移植到G32R501跟常见的APM32之类MCU的思路相差不大。

• 首先，下载官方CoreMark源码；

• 然后，根据Geehy的标准库/SDK修改工程环境、时钟配置；

• 最后，编写或引用标准的串口输出（printf重定向）让CoreMark测试完成后打印结果即可。

2.2 printf重定向

关于G32R501如何做串口打印，可参考“国内首款M52内核：G32R501 EVAL板卡开箱记录”（https://bbs.21ic.com/icview-3466854-1-1.html?_dsign=08ebddb2），其中展示了 GPIO28 / GPIO29 的 UART 通道配置，以及如何重载 fputc 函数。只要能让CoreMark结果顺利“跑”到终端，就万事OK了。

3. 跑分注意事项：G32R501内存访问花样多

在CoreMark跑分时，我们往往会精确追求“运行在哪个存储区域、主频几何、是否有等待周期”等等。G32R501有点特别之处就是Flash访问路径和可配置的内存结构。简单总结如下：

(1) Flash访问（FACC vs. CPU Cache） G32R501的CPU0和CPU1皆可通过两条不同路径读Flash：

ITCM -> FACC -> Flash：针对ITCM空间访问的加速逻辑；

CPU CACHE -> C-Bus -> busmatrix -> Flash：针对C-Bus空间访问，每次访问可由CPU Cache执行加速。

这意味着，在链接脚本中把代码放到不同“段”(ITCM Flash位置或C-Bus Flash位置)，MCU的访问方式有所区别。ITCM段主要依赖FACC加速，而C-Bus段依赖CPU Cache加速。

这意味着，在链接脚本中把代码放到不同“段”(ITCM Flash位置或C-Bus Flash位置)，MCU的访问方式有所区别。ITCM段主要依赖FACC加速，而C-Bus段依赖CPU Cache加速。

(2) SRAM灵活分区 G32R501总共有128KB的SRAM，可通过CFGSMS模块对其分块配置，比如可以划分一部分SRAM作为ITCM、另一些作为DTCM，或者纯粹当普通SRAM等。这样可满足不同应用场景的速度或灵活性需求。

有了这些可玩要素，自然而然就想看看CoreMark在三种常见场景下的差异：

从“C-Bus Flash”运行（即通过CPU Cache加速）；

从“ITCM Flash”运行（FACC加速）；

从“ITCM RAM”运行（这就更快了，理论上可直接贴近CPU）。

4. 跑分配置：三大场景

为了更好对比，我在工程中配置了不同的tag（运行位置各不同），分别使用Geehy SDK提供的链接脚本，路径：G32R501_SDK_V1.1.0device_supportg32r501commonsct

(1) g32r501_cbus_flash.sct

对应把代码映射到 C-Bus Flash

(2) g32r501_itcm_flash.sct

对应把代码映射到 ITCM Flash

(3) g32r501_itcm_ram.sct

对应把代码直接放进 ITCM RAM

需要注意的是，对于ITCM_RAM运行的核心可执行代码，默认情况下板卡的启动还是在Flash里。所以需要按照下面的流程才能让ram里面的代码顺利运行：

先用“g32r501_cbus_flash工程”擦除flash，

再启动“g32r501_itcm_ram工程”调试，进入仿真后让CPU以全速执行，最后退出仿真状态。这样它才能真正从ITCM_RAM去运行CoreMark。

5. 首轮PK：三大场景的表现

先看看在未手动启用CPU Cache的情况下，我们得到的CoreMark/MHz成绩（注：CoreMark量纲还可能和实际主频相关，这里以CoreMark/MHz为横轴做对比）：

(1) C-Bus Flash

CoreMark/MHz 1.0 : 1.643746

这个数字不算出彩，和普通中端MCU跑分相当。

(2) ITCM Flash

CoreMark/MHz 1.0 : 3.861335

哇，翻个倍还多。说明走ITCM -> FACC方式确实给力。

(3) ITCM RAM

CoreMark/MHz 1.0 : 4.166570

再提升了一丢丢，果然直接跑在RAM上通常会速度更快。和理论的M52内核跑分差距不大

可以看出，C-Bus Flash的1.64左右对比ITCM Flash和ITCM RAM，差距极大。不禁让人好奇：“C-Bus不是也有CPU Cache加速吗？为何比ITCM Flash慢这么多呢？”别急，我们还没手动打开CPU Cache呢，它应该是默认没启动。

6. 再进阶：开启CPU Cache 后的惊喜

既然C-Bus Flash可以配合CPU Cache，那我们就再来一试。只需要在代码里调用以下两行即可：

// Enable Instruction Cache

SCB_EnableICache();

// Enable Data Cache

SCB_EnableDCache();

然后重新测试，得到的新成绩是：

(1) C-Bus Flash（已启用Cache）

CoreMark/MHz 1.0 : 4.022346

哇，一下子从1.64飙到4.02，翻了两倍多，这才是真正领略到了Cache的力量啊。

(2) 其他两个就没什么变化了

ITCM Flash，它本来走的是FACC加速，不依赖CPU Cache。

ITCM RAM，说明这部分也本身就很快了，Cache不 Cache影响也不大。

如此一来，在C-Bus Flash开启CPU Cache后，甚至可以和ITCM RAM跑分平起平坐。看得出，给C-Bus这边加Cache能带来明显效能飞跃，也就合理解释了“为什么 ITCM Flash 在没有启用CPU Cache时就能跑到3.86”的现象——它本身有另一条加速通道 FACC 做后台支持。所以一旦给C-Bus运输线上再加个CPU Cache的“加速捷径”，差距就一下子被抹平甚至反超！

7. G32R501：性能、特色与更多想象

G32R501在不同内存访问配置下，CoreMark/MHz可稳定落在4.0～4.16之间，已非常接近纯官方Cortex-M52的参考值4.30。

来源: https://armkeil.blob.core.windows.net/developer/Files/pdf/product-brief/arm-cortex-m-processor-comparison-table.pdf

精彩的部分在于，G32R501还是双核M52架构，并拥有自研“紫电数学指令扩展”与Arm Helium(MVE)矢量扩展，三重硬件“Buff”。CoreMark作为纯整数基准，本身并未包含大量DSP或矢量化测试。而在实际应用中，如果启用紫电扩展与Helium指令调度更多DSP或矢量运算，尤其是像电机矢量控制、滤波、FFT这类场景，性能提升空间会更大。

对于G32R501的CoreMark测试数据你还满意么？欢迎在评论区留言一起讨论吧。

注：文章作者在原帖中提供了代码文件，有需要请至原文21ic论坛

原文地址：https://bbs.21ic.com/icview-3467118-1-2.html?_dsign=fd1a5b81