Mentor 嵌入式多核框架能消除異構硬件和軟件環境的管理復雜性，從而簡化SoC系統設計。

異構多處理對于當今的嵌入式應用來說正變得越來越重要。片上系統 (SoC) 架構，例如賽靈思的 Zynq? UltraScale+? MPSoC 提供包含四個 ARM? Cortex?-A53 內核以及兩個 ARM Cortex-R5 內核的強大異構多處理基礎架構。除了核心的計算基礎架構外，SoC 還包含一系列豐富的硬化外設 IP 和 FPGA 架構，可實現靈活的設計模式，從而幫助系統開發人員創建高性能多處理系統。

各種軟件開發模式的出現使開發人員可以充分利用 SoC（例如 Zynq MPSoC）提供的多處理功能優勢。對稱多處理 (SMP) 操作系統提供了必需的基礎架構，能夠在多處理系統中的多個同構內核之間以對稱或非對稱方式平衡應用工作負荷。不過，要想利用系統中異構處理器提供的計算帶寬，需要使用非對稱多處理 (AMP) 軟件架構。

AMP 架構通常需要在 SoC 中不同處理內核上運行的多種軟件環境（例如 Linux、實時操作系統 (RTOS) 或裸機軟件），協同工作實現最終應用的設計目標。在典型設計中，主內核上的軟件環境根據需要驅動一個遠程內核上的遠程軟件環境，用于分擔計算任務。主處理器、遠程處理器及其相關軟件環境(即它們的操作系統環境)可以是同構或者異構的。

Mentor 選用 Linux 3.4.x 內核以及更新版本中的 remoteproc 和 rpmsg API。

為有效管理不同處理器上多個操作系統的生命周期，同時提供處理器間通信 (IPC) 基礎架構以分擔計算工作負荷，需要采用經過改善的新軟件功能和方法。

Mentor Graphics 公司的 Mentor 嵌入式多核框架是一種軟件框架，能夠為 AMP 系統開發人員提供兩大重要功能：用于對遠程處理器及其相關軟件環境進行生命周期管理的 remoteproc 組件和 API；用于在 AMP 環境中的操作系統之間實現 IPC 的 rpmsg 組件和 API。該框架為用戶提供了簡化的應用級接口，從而消除了管理異構硬件和軟件環境的復雜性。

讓我們詳細了解一下如何使用這種新的開發框架來管理 AMP 系統中的異構計算。

兼容性和起源
在為 Mentor 嵌入式多核框架選擇合適的 API 時，對開放標準的兼容性以及在 Linux 社區中的應用情況是重要的考量指標。Mentor選用了 Linux 3.4.x 內核以及更新版本中的 remoteproc 和 rpmsg API。Linux remoteproc 和 rpmsg 基礎架構最初由 Texas Instruments 設計開發，并專門用于 Linux 內核。該基礎架構允許主處理器上的 Linux 操作系統管理遠程處理器上遠程軟件環境的生命周期和通信。

然而，Linux 提供的基礎架構存在一些限制。 首先，Linux rpmsg 隱式地假設 Linux 總是主操作系統，而且不支持將 Linux 作為 AMP 配置中的遠程操作系統。 此外，remoteproc 和 rpmsg API 只能從 Linux 內核空間獲得，沒有可用于其它操作系統和運行時間的等效 API 或庫。
Mentor 嵌入式多核框架是一種用 C 語言編寫的獨立庫。它能干凈地實現在 RTOS 或裸機軟件環境中使用的 remoteproc 和 rpmsg 功能，并具備與 Linux 中對應的 remoteproc 和 rpmsg 的 API 級兼容性和功能對稱性。圖 1a 顯示了 Mentor 嵌入式多核框架的軟件棧圖及其在 RTOS 或裸機環境中的使用。如圖所示，該框架經過抽象的移植層由硬件接口層和操作系統抽象(環境)層構成，讓用戶能夠方便地將框架移植到其它處理器和操作系統。

圖 1b 顯示了 Linux 內核中的 remoteproc 和 rpmsg 基礎框架。remoteproc 和 rpmsg 內核空間驅動程序為 remoteproc 平臺驅動程序和 rpmsg 用戶設備驅動程序提供服務。remoteproc 平臺驅動程序支持遠程生命周期管理；rpmsg 用戶設備驅動程序向用戶空間應用提供 IPC 服務。

除了能在 AMP 架構中實現 RTOS 和裸機環境與 Linux remoteproc/rpmsg 基礎架構的互操作外，Mentor 嵌入式多核框架還提供相應的工作流程和運行時間基礎架構，用于將 Linux 進行封裝并作為 AMP 配置中的遠程操作系統啟動。圖 2 顯示了該框架支持的各種 AMP 配置。

?

圖 1 – RTOS 和裸機環境中的 Mentor 嵌入式多核框架 (a)，以及 Linux 內核中的 remoteproc 和 rpmsg (b)

?

?

圖 2 – Mentor 多核框架支持的 AMP 配置

用例與應用
Mentor 嵌入式多核框架非常適合無監督和有監督的 AMP 架構。

無監督的 AMP (uAMP) 架構適用于不需要對參與的操作系統環境進行嚴格分離的應用。在該架構中，參與的操作系統在系統中的處理器上本地運行。如圖 3a 所示，Mentor 嵌入式多核框架提供一種簡單有效的基礎架構，其中，主（引導）處理器上的主軟件環境可以管理生命周期，并將計算任務分配給 SoC 中的其它計算資源。

有監督的非對稱多處理 (sAMP) 架構最適合需要對軟件環境和系統資源虛擬化進行隔離的應用。在 sAMP 中，參與的客戶操作系統運行在客戶虛擬機中，而客戶虛擬機由管理程序（也稱為虛擬機監視程序）進行管理和調度。管理程序為虛擬機提供隔離和虛擬化服務。Mentor 嵌入式多核框架使 sAMP 架構能夠管理 SoC 中異構計算資源的計算任務。

如圖 3b 所示，該框架有兩種應用方式：在客戶操作系統環境下，進行無監督的異構計算資源管理；在管理程序中，進行有監督的異構計算資源管理，使管理程序能夠監督客戶操作系統與遠程環境之間的交互。

?

圖 3 – Mentor 嵌入式多核框架用例，包括 uAMP (a) 和 sAMP (b) 架構

總之，Mentor 嵌入式多核框架最適合需要將計算功能按照需求分配給多處理芯片中專用內核的應用。對于功率受限的器件，該框架能夠根據需要開啟和關閉計算資源，實現最佳功率利用率。

該框架還便于將傳統的單核嵌入式系統整合到功能更強大的多處理 SoC 上。此外，該框架能夠輕松地移植針對單核芯片而開發的傳統軟件，以便與更新、更強大的多處理芯片上的增強系統功能進行互操作。

最后，該框架還有助于實現容錯型系統架構。例如，該框架能支持處理關鍵系統功能的 RTOS 環境(主機)來管理負責非關鍵系統功能的 Linux 環境。當 Linux 子系統出故障時，RTOS 可重啟故障子系統，而且不會對關鍵系統功能產生任何不利影響。

系統級考慮因素
Mentor 嵌入式多核框架 API 提供所需的軟件基礎架構，以管理 AMP 系統中的計算。然而在使用上述 API 開發應用軟件之前，設計 AMP 系統必須考慮特定的系統級考慮因素。

在初始設計階段，您需要確定 AMP 拓撲結構。該框架可在星形拓撲（單個主機管理多個遠程機）或鏈式拓撲（主機和遠程節點鏈接在一起）中使用。當您選擇合適的拓撲結構后，下一步是確定存儲器布局。應為每個參與的操作系統運行時間分配存儲區域，并為操作系統實例之間的 IPC 分配共享存儲區域。在存儲器布局最終確定后，您需要更新框架提供的、用于反映所選存儲器架構的特定平臺配置數據。

現成的操作系統通常假定其擁有整個 SoC，因此無法直接在無監督的 AMP 環境中運行，因為該環境要求合作使用共享資源，并且互斥地使用非共享資源。AMP 系統中每個參與的操作系統都要進行修改，以便通過合作方式使用共享資源。例如，遠程操作系統不應復位和重新初始化已經在主機環境中使用的共享全局中斷控制器；也不能修改共享時鐘樹或外設，以免導致沖突。這些變更通常包括對參與的操作系統內核或 BSP 源文件（或二者皆有）進行修改。

下一步是執行系統分區。必須在參與的操作系統之間對系統資源（例如存儲器和非共享 I/O 器件）進行分區，這樣，每個操作系統都只能顯示和訪問所分配的資源。為實現上述任務，您可以對提供給操作系統的平臺數據(器件和存儲器定義) 進行修改。例如，修改 Linux OS 的 Linux器件樹源文件 (DTS) 中的存儲器和器件定義；Nucleus RTOS 的平臺定義文件中的存儲器和器件定義；裸機環境中平臺專用報頭文件的存儲器和器件定義。

該框架提供相應的工作流程，用來封裝 Linux、RTOS 或裸機軟件映像以及所需的引導程序固件，從而生成 ELF 格式的遠程固件映像。

使用 REMOTEPROC 進行生命周期管理
在完成系統級設計決策以及針對參與操作系統的修改后，就可使用應用軟件的 Mentor 嵌入式多核框架。該框架提供相應的工作流程，用來封裝 Linux、RTOS 或裸機軟件映像以及所需的引導程序固件，從而生成 ELF 格式的遠程固件映像。

遠程固件 ELF 映像包含一個名為資源表的特殊區域。資源表是一個預先定義捆綁的靜態數據結構，用戶可在這里指定遠程固件所需的資源。資源表提供的一些重要定義內容包括遠程固件所需的存儲器以及遠程固件所支持的 IPC 功能。主軟件環境中的 remoteproc 組件使用資源表定義來分配資源并建立與遠程環境的通信。

框架主機使用 remoteproc_init API 初始化遠程處理器環境。在調用時，remoteproc 主機取出遠程固件映像、解碼、獲得資源表、并對其解析，以確定遠程固件的資源要求。remoteproc 根據資源表定義建立遠程固件所需的物理存儲器，并執行 rpmsg/VirtIO IPC 的特定初始化功能。

在 remoteproc 完成初始化后，可使用 remoteproc_boot API 啟動相關軟件環境中的遠程處理器。在調用時，找到固件映像以便在存儲器中適當執行，同時，遠程處理器解除復位狀態以執行該映像。remoteproc_shutdown 和 remote- proc_deinit API 允許應用關閉遠程處理器，并分別解除各類資源的初始化。(圖 5 中的偽代碼模塊給出了 remoteproc API 在主機環境中的使用實例。)

在遠程環境中，啟動和關閉 API 不適用。為了對 remoteproc 組件進行初始化和解除初始化，必須使用 remoteproc_resource_init API 和 remoteproc_resource_deinit API。如欲了解在 Linux 環境中如何使用 remoteproc，敬請參見 Linux 內核文檔。

RPMSG 和處理器間通信
一旦遠程固件啟動并在遠程處理器上運行，就可使用 rpmsg API 在主機與遠程軟件環境之間實現處理器間通信。當使用 rpmsg 時需要理解的關鍵抽象和概念如下：

? 從主機角度看，rpmsg 器件代表一個遠程處理器。
? rpmsg 通道是主機與遠程處理器(也稱為 rpmsg 設備)之間的雙向通信通道。
? rpmsg 端點是可出現在 rpmsg 通道任意一側的邏輯抽象。
? 端點提供用于在主機與遠程環境之間發送目標消息的基礎架構。
? 當創建端點時，用戶提供唯一的端點索引或允許 rpmsg 組件為端點分配一個索引。此外，用戶提供應用定義的回調，并將其與正在創建的端點關聯。
? 當收到針對給定端點索引的消息時，rpmsg 會參考所收到的數據負荷調用相關的接收回調。
? 用戶可在 rpmsg 通道的任意一側創建任意數量的端點。
? 沒有明確指向目標端點索引的消息會到達與 rpmsg 通道相關聯的默認端點。
? rpmsg 組件利用在初始化過程中注冊的、用戶提供的回調為用戶應用通知通道創建和刪除等事件。

圖 4 所示為 rpmsg 通道和端點抽象及其使用情況。rpmsg 組件與 remoteproc 協同建立并管理主機與遠程環境之間的 rpmsg 通信通道。一旦主機上的 remoteproc 啟動遠程環境，遠程環境上的 rpmsg 就會發送名稱服務公告。收到名稱服務公告后，主機會注冊已宣布的 rpmsg 器件，并建立 rpmsg 通道。通道建立后，在兩側調用由 rpmsg 通道創建的回調，通知主機和遠程應用通道已建立。

?

圖 4 – rpmsg 通道和端點抽象

?

?

圖 5 – 偽代碼給出了主機環境下關鍵 remoteproc 和 rpmsg API 的使用情況

此時，主機和遠程環境可利用分別針對分塊和不分塊傳輸請求的 rpmsg_sendxx API 和 rpmsg_trysendxx API 相互傳輸數據。當遠程環境調用 remoteproc_resource_deinit 時，由 rpmsg 通道刪除的回調向主機應用通知該事件，以平穩終止基于 rpmsg 的通信鏈路。在遠程環境無法響應的情況下，主機可選擇使用 remoteproc_shutdown API 異步地關閉遠程處理器。圖 5 中的偽代碼段給出了在主機環境中 rpmsg API 與 remoteproc API 的協同使用情況。

rpmsg 組件將 VirtIO 作為共享存儲器傳輸抽象層。VirtIO 有自己的根，可用作 lguest、KVM 和 Mentor 嵌入式管理程序中客機到主機通信的 I/O 虛擬化標準。rpmsg 驅動程序使用 VirtIO 層提供的服務與對方實現共享存儲器通信。rpmsg 驅動程序實例化一個 rpmsg VirtIO 器件，并使用 VirtQueue 接口推送和消耗其通信另一方的數據。

用于開發 AMP 系統的工具
AMP 應用軟件的開發會產生一些獨特的挑戰。系統開發人員通常不得不同時調試異構 SoC 上部署在不同處理器的不同操作系統環境。采用可感知操作系統的統一調試環境不僅能改善調試體驗，還能提高生產力。Mentor Embedded Sourcery CodeBench 工具提供可感知所有受支持操作系統環境（包括Mentor Embedded Linux 和 Nucleus RTOS)的統一 IDE。此外，Sourcery CodeBench 還支持多種調試選項，包括用于調試 Linux 內核空間、Nucleus RTOS 和裸機環境的 JTAG 調試；以及針對 Linux 用戶空間和 Nucleus RTOS 應用的 GDB 調試。

在開發 AMP 系統時，軟件特性分析工具很有用，可用來了解異構操作系統上部署的各種應用在運行時間的相互交互情況。每個操作系統實例通常使用一個獨立時鐘參考，而且給定操作系統環境中收集的任何特性分析數據都以操作系統本地的時基為基礎。Mentor Embedded Sourcery Analyzer主機工具和 Mentor 的操作系統包含內置算法，使用戶能夠以圖形方式查看和分析從統一時間參考的不同操作系統資源中收集到的跟蹤數據。該功能使用戶能夠深入了解復雜交互情況以及開發 AMP 軟件時難以發現的時序問題。

開源運行時間組件
Mentor 嵌入式多核框架與 Mentor 的開發工具和操作系統緊密集成。它支持各種不同的基于 ARM 的 SoC 和平臺。通過使用具有 Mentor 工具和操作系統的框架，用戶不必從頭設計 AMP 系統，而是只需執行“系統級考慮因素”一節中所討論的任務。用戶可利用其中一種參考配置開始 AMP 應用的開發工作，然后對系統配置進行定制化處理，以滿足不同需求。

對于 AMP 系統設計而言，亟需一種標準化的軟件框架，使開發出的 RTOS 或裸機軟件能夠與開源 Linux 社區所采用的接口進行互操作。為滿足該需求并促進在行業中的應用，Mentor Graphics 與賽靈思共同通過 OpenAMP 開源項目開放了 Mentor 嵌入式多核框架的運行時間組件源代碼，并提供針對 Zynq-7000 All Programmable SoC 的平臺支持。該項目目前由 Mentor Graphics 和賽靈思共同維護。