《極海芯得》系列內(nèi)容為用戶使用極海系列產(chǎn)品的經(jīng)驗總結(jié)，均轉(zhuǎn)載自21ic論壇極海半導(dǎo)體專區(qū)，全文未作任何修改，未經(jīng)原文作者授權(quán)禁止轉(zhuǎn)載。

1. 前言

要真正衡量一顆MCU的運算實力，CoreMark成績往往是一個比較客觀、公認的參考指標。到底這個G32R501跑起CoreMark來能交出怎樣的成績單？今天就讓我們一起“探秘”一番，看這款Cortex-M52 MCU在CoreMark上的表現(xiàn)究竟是“平平無奇”還是“驚艷四座”！

本篇就給大家呈現(xiàn)各版本配置下跑分的情況——不同F(xiàn)lash/RAM運行區(qū)域會對CoreMark產(chǎn)生什么樣滴影響？

2. CoreMark移植：前置準備

2.1 移植過程

其實，CoreMark移植到G32R501跟常見的APM32之類MCU的思路相差不大。

? 首先，下載官方CoreMark源碼；

? 然后，根據(jù)Geehy的標準庫/SDK修改工程環(huán)境、時鐘配置；

? 最后，編寫或引用標準的串口輸出（printf重定向）讓CoreMark測試完成后打印結(jié)果即可。

2.2 printf重定向

關(guān)于G32R501如何做串口打印，可參考“國內(nèi)首款M52內(nèi)核：G32R501 EVAL板卡開箱記錄”（https://bbs.21ic.com/icview-3466854-1-1.html?_dsign=08ebddb2），其中展示了 GPIO28 / GPIO29 的 UART 通道配置，以及如何重載 fputc 函數(shù)。只要能讓CoreMark結(jié)果順利“跑”到終端，就萬事OK了。

3. 跑分注意事項：G32R501內(nèi)存訪問花樣多

在CoreMark跑分時，我們往往會精確追求“運行在哪個存儲區(qū)域、主頻幾何、是否有等待周期”等等。G32R501有點特別之處就是Flash訪問路徑和可配置的內(nèi)存結(jié)構(gòu)。簡單總結(jié)如下：

(1) Flash訪問（FACC vs. CPU Cache） G32R501的CPU0和CPU1皆可通過兩條不同路徑讀Flash：

ITCM -> FACC -> Flash：針對ITCM空間訪問的加速邏輯；

CPU CACHE -> C-Bus -> busmatrix -> Flash：針對C-Bus空間訪問，每次訪問可由CPU Cache執(zhí)行加速。

這意味著，在鏈接腳本中把代碼放到不同“段”(ITCM Flash位置或C-Bus Flash位置)，MCU的訪問方式有所區(qū)別。ITCM段主要依賴FACC加速，而C-Bus段依賴CPU Cache加速。

這意味著，在鏈接腳本中把代碼放到不同“段”(ITCM Flash位置或C-Bus Flash位置)，MCU的訪問方式有所區(qū)別。ITCM段主要依賴FACC加速，而C-Bus段依賴CPU Cache加速。

(2) SRAM靈活分區(qū) G32R501總共有128KB的SRAM，可通過CFGSMS模塊對其分塊配置，比如可以劃分一部分SRAM作為ITCM、另一些作為DTCM，或者純粹當普通SRAM等。這樣可滿足不同應(yīng)用場景的速度或靈活性需求。

有了這些可玩要素，自然而然就想看看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

對應(yīng)把代碼映射到 C-Bus Flash

(2) g32r501_itcm_flash.sct

對應(yīng)把代碼映射到 ITCM Flash

(3) g32r501_itcm_ram.sct

對應(yīng)把代碼直接放進 ITCM RAM

需要注意的是，對于ITCM_RAM運行的核心可執(zhí)行代碼，默認情況下板卡的啟動還是在Flash里。所以需要按照下面的流程才能讓ram里面的代碼順利運行：

先用“g32r501_cbus_flash工程”擦除flash，

再啟動“g32r501_itcm_ram工程”調(diào)試，進入仿真后讓CPU以全速執(zhí)行，最后退出仿真狀態(tài)。這樣它才能真正從ITCM_RAM去運行CoreMark。

5. 首輪PK：三大場景的表現(xiàn)

先看看在未手動啟用CPU Cache的情況下，我們得到的CoreMark/MHz成績（注：CoreMark量綱還可能和實際主頻相關(guān)，這里以CoreMark/MHz為橫軸做對比）：

(1) C-Bus Flash

CoreMark/MHz 1.0 : 1.643746

這個數(shù)字不算出彩，和普通中端MCU跑分相當。

(2) ITCM Flash

CoreMark/MHz 1.0 : 3.861335

哇，翻個倍還多。說明走ITCM -> FACC方式確實給力。

(3) ITCM RAM

CoreMark/MHz 1.0 : 4.166570

再提升了一丟丟，果然直接跑在RAM上通常會速度更快。和理論的M52內(nèi)核跑分差距不大

可以看出，C-Bus Flash的1.64左右對比ITCM Flash和ITCM RAM，差距極大。不禁讓人好奇：“C-Bus不是也有CPU Cache加速嗎？為何比ITCM Flash慢這么多呢？”別急，我們還沒手動打開CPU Cache呢，它應(yīng)該是默認沒啟動。

6. 再進階：開啟CPU Cache 后的驚喜

既然C-Bus Flash可以配合CPU Cache，那我們就再來一試。只需要在代碼里調(diào)用以下兩行即可：

// 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，翻了兩倍多，這才是真正領(lǐng)略到了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”的現(xiàn)象——它本身有另一條加速通道 FACC 做后臺支持。所以一旦給C-Bus運輸線上再加個CPU Cache的“加速捷徑”，差距就一下子被抹平甚至反超！

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

G32R501在不同內(nèi)存訪問配置下，CoreMark/MHz可穩(wěn)定落在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架構(gòu)，并擁有自研“紫電數(shù)學(xué)指令擴展”與Arm Helium(MVE)矢量擴展，三重硬件“Buff”。CoreMark作為純整數(shù)基準，本身并未包含大量DSP或矢量化測試。而在實際應(yīng)用中，如果啟用紫電擴展與Helium指令調(diào)度更多DSP或矢量運算，尤其是像電機矢量控制、濾波、FFT這類場景，性能提升空間會更大。

對于G32R501的CoreMark測試數(shù)據(jù)你還滿意么？歡迎在評論區(qū)留言一起討論吧。

注：文章作者在原帖中提供了代碼文件，有需要請至原文21ic論壇

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