上一篇文章介紹了 MM32F5 系列 所采用的 “星辰”STAR-MC1 處理器，如果讀者還有印象的話，“星辰”處理器相較于 M3 和 M4 處理器的一個主要優勢是引入了內存子系統，包括了L1 指令和數據緩存接口和緊耦合 TCM 接口。而僅有內存子系統是不夠的，需要配合高效率的總線架構設計來實現其功能最大化。

本期，筆者就來聊聊 MM32F5270 的總線架構設計，看看 F5270 是如何通過高并行度的總線設計實現系統吞吐率的最大化。

MM32F5270 的總線架構

下圖展示了 MM32F5270 的總線架構，可以看到，系統中的處理器、存儲和外設是通過一個零延遲 AHB 總線矩陣進行互聯，這里的總線矩陣是一個多 Master 到多 Slave 的多層 AHB 總線結構。這里，把可發起讀寫訪問的一方叫做 Master，響應訪問的一方叫做 Slave。

注：AHB 屬于 Arm? AMBA? 通信接口協議的一種，是嵌入式系統中的常用接口協議之一，對于不了解 Arm? AMBA? 接口協議的讀者，可自行搜索相關資料，本文不再贅述。

總線 Master – 訪問發起者?

從上圖可以看到，MM32F5270 中包含了如下 AHB 總線 Master：

CPU – “星辰”STAR-MC1

DMA1

DMA2

USB 控制器（USB FS）

以太網控制器（ENET）

其中，“星辰”處理器占據 三個 AHB 口，分別是系統總線AHBS（system bus），代碼總線 AHBC（code bus），以及 TCM 總線 AHBT（TCM bus）。其中 AHBC 和 AHBS 是處理器發起訪問，從外部獲取數據和指令的通路，而 AHBT 是處理器以外的其它 Master（如 DMA等）訪問內部 TCM 的通路，也就是說，TCM 不僅能被 CPU 訪問，外部資源也可以將 TCM 當作普通 SRAM 訪問。

其它Master 包括 DMA、USB 和以太網。在 MM32F5270中，為提高系統并行度，配置了兩路獨立的 DMA 控制器，每個 DMA 控制器包含 8 個通道，每路 DMA 都可以無需 CPU 干預而進行 Slave 的讀寫訪問。USB 和以太網也可以做為總線 Master 直接發起對系統存儲的訪問，例如將提前放置在 SRAM 中的數據搬移到 TX FIFO 中以實現無需 CPU 干預而進行的數據通信。

總線 Slave – 訪問響應者?

MM32F5270 中包含了如下 AHB 總線 Slave：

256KB 內置 Flash 存儲器

112KB SRAM1

16KB SRAM2

QSPI – 可外擴四線 NOR Flash

FSMC – 8/16/32 位并口，可外擴 SRAM，NOR Flash，8080/6800 屏

外設 APB1 組

外設 APB2 組

32KB ITCM和 32KB DTCM – 通過 AHBT 總線訪問

為提高系統并行度，MM32F5270配備了兩路獨立的 RAM，包括 112KB 的 SRAM1 和 16KB 的 SRAM2，每個 RAM有獨立的 RAM 控制器和 Slave端口。

此外，MM32F5270 還配備了 32KB 指令 TCM RAM（ITCM）和 32KB 的數據 TCM RAM（DTCM）。這里， TCM 和 CPU 是通過 TCM 接口直連的，相當于一條快速通道，CPU 訪問 TCM 不需要經過外部總線矩陣，這也是 TCM 被稱為緊耦合存儲（Tightly-Coupled Memory，TCM）的原因。CPU 訪問 TCM 是沒有任何延遲的，因此也不需要經過緩存。同時，“星辰”處理器也預留了 AHBT 總線供 DMA 等 CPU 外部 Master 訪問 TCM。這里的 AHBT 總線掛在總線矩陣的 Slave 端，也就是說，DMA 要訪問 TCM 需要先經過總線矩陣。當 DMA 和 CPU 同時訪問 TCM 時，“星辰”處理器以 CPU 訪問為高優先級進行仲裁。需要說明的是，ITCM 支持程序執行和數據讀取，其起始地址為 0x0000_0000，DTCM 支持數據讀取，其起始地址為 0x2000_0000。

根據上述介紹可以得出，MM32F5270 里實際是配置了 4塊完全獨立的 RAM，包括 ITCM，DTCM，SRAM1 和 SRAM2，在某些應用場景下，這 4 塊 RAM 能夠同時被不同的 Master 訪問而不會產生任何的總線沖突和等待。例如，CPU 可以讀取并執行ITCM中存放的程序算法，以太網可以從 SRAM2 中讀寫數據，DMA1 可以從 DTCM中搬數據， DMA2 可以從 SRAM1中搬數據，這里的四條通路是完全獨立和并行的。

MM32F5270還包含了兩路獨立的 APB 外設組，即 APB1 和 APB2，每個外設組有獨立的 Slave 端口和AHB到 APB 的協議轉換橋。

與此同時，用戶還可以通過 FSMC 去外擴并口 NOR Flash 或者 SRAM，也可以通過 QSPI 去外擴四線式 NOR Flash。且這里的 FSMC 和 QSPI 都是直接掛在零延遲 AHB 總線矩陣上的 AHB Slave，因此其訪問通路是完全獨立的。當然，用戶也可以通過 SPI、UART等串行總線接口來擴展更多存儲空間，不過這些外設都是掛在 APB 總線上，和其它共同掛在 APB 總線的外設共享總線矩陣的 AHB Slave 端口，因此，可能會產生多余的等待周期。

需要說明的是，除了 TCM 和外設空間，從 Code bus 和 System bus 上讀取的指令和數據基本上都可以被 4KB 指令緩存和 4KB 數據緩存加速。

下表對 MM32F5270 中支持的 Flash 和 RAM 資源做一個總結：

并發網絡

前文提到的總線結構圖中，Master 和 Slave 的連接關系通過矩陣網絡上的空心圓表示，如內置 Flash 僅可以被 CPU 的 code bus 或者 DMA 訪問，而不能被其它總線 Master 訪問。

基于上述描述所能達到的效果就是，多個 Master 可以同時發起對多個Slave的訪問，如果每條路徑的發起者（Master）和響應者（Slave）都是不同的，那這些訪問是完全并行的，是不需要仲裁和等待周期的。

下圖是一個并發訪問的例子，這里，6個總線 Master 對 6 個總線 Slave 的訪問構成了 6 個獨立通路。當然，這里僅僅是一個極限情況，對于一個實際應用所能達到的并發效果，需要根據應用需求具體分析。

案例：帶顯示的音頻播放器?

為了更直觀的講解 F5270 多并發總線設計的強大，這里以一個實際應用的案例來進行展示。需要說明的是，這里的案例僅僅為了講解功能，并不做為參考設計。

這里，考慮基于 MM32F5270 制作一個帶顯示的音頻播放器，這是一種很常見的應用場景，實際產品中所包含的功能可能是多種多樣的，這里為了簡化，以如下規格要求為例：

可播放 SD 卡上的音頻文件，支持 WAV 和 MP3 格式

2.4寸屏，320x240 分辨率，GUI 交互

注：實際的產品可能有更多的功能，如更高清的顯示、USB擴展、WIFI 或藍牙聯網、視頻播放、觸控等，感興趣的讀者可以搜索下網絡上的相關產品。

基于這個要求，可以搭建一個帶顯示的音頻播放器，根據 MM32F5270 所包含的片內資源，對上述規格要求做出如下的功能分解和資源分配：

其對應的簡易系統框圖如下：

分析可知系統的主要功能可以分為三塊：

第一塊是 CPU 處理部分。

首先， CPU 所執行的主程序存放在內置 256KB Flash 中，而運行中所需要內存存放在 SRAM1 中，其數據通路如下圖中的藍色箭頭所示；

同時，CPU 需要從外部 SD 卡讀取音頻文件，這里涉及到文件系統的交互，以及 MP3 軟解碼運算，并將解碼后的音頻數據存放在 32KB DTCM 中，其數據通路如下圖中的黃色箭頭所示；

最后，CPU 需要運行 GUI 應用程序，包括從外擴 Flash 中獲取顯示數據和字庫，通過 CPU 的運算并將待顯示的圖像緩存到外擴 SRAM 中，其數據通路如下圖中的綠色箭頭所示。

第二塊是音頻播放數據流控制。

這里，通過 DMA1 來處理音頻數據流，DMA1 通過 AHBT 總線從 DTCM 中讀取解碼后的音頻數據，并寫入 I2S 的 TX FIFO 中，通過 I2S 和外部的功放通信并驅動揚聲器或耳機，其數據通路如下圖中的紅色箭頭所示。

第三塊是圖像顯示數據流控制。

這里，通過 DMA2 來處理圖像顯示數據流，DMA2 通過 FSMC 從外部 SRAM 中讀取待顯示圖像，并通過 FSMC 寫入外部 LCD 屏，實現圖像幀的周期性刷新，其數據通路如下圖的紫色箭頭所示。

基于上述分析，將所有路徑進行匯總，并刪掉非獨立路徑后（即兩條路徑有共同發起者或共同接收者），可得到下圖所示的匯總數據通路。可以看到，主程序的指令獲取和執行（藍色箭頭）、主程序數據讀寫（藍色箭頭）、音頻數據流（紅色箭頭）和GUI數據流（紫色箭頭）這四條通路是完全獨立的。假設系統運行在 120MHz，而所有訪問都采用 32 位寬，則可以計算出此時整個系統的并行吞吐率可達 15Gbps！

當然，這里僅僅是一個精簡的例子，對于實際應用，其所需功能可能會更加復雜。但重要的是，MM32F5270 的多并發總線架構為各類實際應用中的并行處理場景提供了硬件支持，使系統整體吞吐率有了大幅優化的空間。

需要補充說明的是，這個例子里面并沒有用到 SRAM2 和 ITCM 等資源，因此其可以用作其他用途，如 SRAM2 可以用作 ENET、USB 、CAN 或者 ADC的數據緩存，而ITCM 中可以存放對實時性要求較高的算法或中斷服務程序等。如果把這些功能都開發起來，則系統吞吐率是否還可以進一步提高呢？這個問題就留給感興趣的讀者來思考吧