概要

隨著科技的飛速發(fā)展，計算需求日益復(fù)雜和多樣化，傳統(tǒng)的單核處理器已難以滿足所有應(yīng)用場景的需求。在這樣的背景下，異構(gòu)多核系統(tǒng)應(yīng)運而生，成為推動計算領(lǐng)域進步的重要力量。異構(gòu)多核系統(tǒng)不僅提高了計算效率，還優(yōu)化了能耗，為眾多領(lǐng)域帶來了革命性的變革。

異構(gòu)多核系統(tǒng)是指在一個芯片上集成多種不同類型的處理器核心，這些核心可能采用不同的指令集架構(gòu)（ISA），具備不同的性能特性和功耗要求。這些核心可以是高性能的通用處理器核心，也可以是專為特定任務(wù)設(shè)計的專用核心，如圖形處理單元（GPU）、數(shù)字信號處理器（DSP）或神經(jīng)網(wǎng)絡(luò)處理器（NPU）等。

異構(gòu)多核系統(tǒng)的特點主要體現(xiàn)在以下幾個方面：

性能提升：通過結(jié)合不同類型的處理器核心，異構(gòu)多核系統(tǒng)能夠充分發(fā)揮各核心的優(yōu)勢，實現(xiàn)計算性能的大幅提升。例如，高性能核心可以處理復(fù)雜的計算任務(wù)，而專用核心則可以加速特定類型的數(shù)據(jù)處理。

能效優(yōu)化：異構(gòu)多核系統(tǒng)能夠根據(jù)任務(wù)需求動態(tài)調(diào)整核心的使用，避免資源浪費和不必要的功耗。對于計算密集型任務(wù)，可以使用高性能核心；而對于數(shù)據(jù)密集型任務(wù)，則可以利用專用核心進行高效的數(shù)據(jù)處理，從而實現(xiàn)能效比的最大化。

靈活性：異構(gòu)多核系統(tǒng)能夠適應(yīng)多樣化的應(yīng)用場景，通過靈活的任務(wù)調(diào)度和核心分配，滿足不同任務(wù)的需求。這使得系統(tǒng)能夠同時處理多種類型的任務(wù)，提高整體計算效率。

并行處理：不同類型的核心可以并行工作，實現(xiàn)任務(wù)級別的并行處理。這種并行性可以進一步提高系統(tǒng)的整體性能，縮短計算時間。

多核通信

市面目前多核異構(gòu)芯片形態(tài)：

由于異構(gòu)多核系統(tǒng)中集成了多種不同類型的處理器核心，這些核心之間需要進行高效的數(shù)據(jù)通信和協(xié)同工作，以確保整體系統(tǒng)的性能和穩(wěn)定性。因此，通信機制在異構(gòu)多核系統(tǒng)中扮演著至關(guān)重要的角色。為了確保核心間的順暢通信，異構(gòu)多核系統(tǒng)采用了多種通信協(xié)議和接口技術(shù)，如共享內(nèi)存、消息傳遞接口（MPI）、高級可擴展接口（AEI）等。這些通信機制使得不同核心之間能夠快速地傳輸數(shù)據(jù)、共享資源和協(xié)同執(zhí)行任務(wù)，從而實現(xiàn)整體系統(tǒng)的高效運行。

異構(gòu)多處理系統(tǒng)中往往會形成主-從（Master-Remote）結(jié)構(gòu)。主核上的系統(tǒng)先啟動，并負責(zé)準(zhǔn)備好運行環(huán)境，然后根據(jù)需要或者一定規(guī)則啟動從核并對其進行管理。主-從核心上的系統(tǒng)都準(zhǔn)備好之后，他們之間就通過 IPC（Inter Processor Communication）方式進行通信，而 RPMsg 就是 IPC 中的一種。RPMsg，全稱 Remote Processor Messaging，它定義了異構(gòu)多核處理系統(tǒng)（AMP，Asymmetric Multiprocessing）中核與核之間進行通信時所使用的標(biāo)準(zhǔn)二進制接口。

常見的多核通信框架：OpenAMP, RPMsg，rpmsg-lite等，本片文章的主角是：rpmsg-lite

RPMsg-Lite介紹

RPMsg-Lite組件，它是遠程處理器消息傳遞 (RPMsg) 協(xié)議的輕量級實現(xiàn)。RPMsg 協(xié)議定義了一個標(biāo)準(zhǔn)化的二進制接口，用于在異構(gòu)多核系統(tǒng)中的多個核之間進行通信。與開放非對稱多處理 (OpenAMP) 框架(https://github.com/OpenAMP/open-amp)的 RPMsg 實現(xiàn)相比，RPMsg-Lite 減少了代碼大小、簡化了 API 并改進了模塊化。在較小的基于 Cortex-M0+ 的系統(tǒng)上，建議使用 RPMsg-Lite。RPMsg-Lite 是由 NXP Semiconductors 開發(fā)的開源組件，并在 BSD 兼容許可下發(fā)布。

RPMsg-Lite官方倉庫：https://github.com/nxp-mcuxpresso/rpmsg-lite

RPMsg-Lite官方文檔：https://nxp-mcuxpresso.github.io/rpmsg-lite

RPMsg-Lite源碼目錄：

.
├──common
│└──llist.c
├──include
│├──environment
││└──rt-thread
││└──rpmsg_env_specific.h
│├──llist.h
│├──platform
││└──RK3568
││├──rpmsg_config.h
││└──rpmsg_platform.h
│├──rpmsg_compiler.h
│├──rpmsg_default_config.h
│├──rpmsg_env.h
│├──rpmsg_lite.h
│├──rpmsg_ns.h
│├──rpmsg_queue.h
│├──virtio_ring.h
│└──virtqueue.h
├──rpmsg_lite
│├──porting
││├──environment
│││└──rpmsg_env_threadx.c
││└──platform
││└──RK3568
││└──rpmsg_platform.c
│├──rpmsg_lite.c
│├──rpmsg_ns.c
│└──rpmsg_queue.c
└──virtio
└──virtqueue.c

創(chuàng)建目的

開發(fā)RPMsg-Lite的原因有多種：①是需要與RPMsg協(xié)議兼容的通信組件占用空間小；②是OpenAMP RPMsg實現(xiàn)的廣泛API的簡化。RPMsg協(xié)議沒有記錄，其唯一定義是由Linux內(nèi)核和舊版OpenAMP實現(xiàn)給出的。這已經(jīng)隨著基于無鎖共享內(nèi)存的多核通信協(xié)議的出現(xiàn)而改變，它是一個標(biāo)準(zhǔn)化協(xié)議，允許多種不同的實現(xiàn)共存并且仍然相互兼容。

基于小型MC 的系統(tǒng)通常不實現(xiàn)動態(tài)內(nèi)存分配。RPMsg-Lite中靜態(tài)API的創(chuàng)建進一步減少了資源使用。動態(tài)分配不僅會額外增加5KB的代碼大小，而且通信速度會變慢且確定性較差，這是動態(tài)內(nèi)存引入的一個特性。下表顯示了OpenAMP RPMsg實現(xiàn)和新RPMsg-Lite實現(xiàn)之間的一些粗略比較數(shù)據(jù)：

框架說明

RPMsg-Lite的實現(xiàn)可以分為三個子組件。核心組件位于rpmsg_lite.c中。其中rpmsg_ns.c和rpmsg_queue.c是可選的，兩個可選組件用于實現(xiàn)阻塞接收API（在rpmsg_queue.c中和動態(tài)“命名”端點創(chuàng)建和刪除公告服務(wù)（在rpmsg_ns.c中）。

實際的“媒體訪問”層在virtqueue.c中實現(xiàn)，它是與 OpenAMP 實現(xiàn)共享的少數(shù)文件之一。該層主要定義了共享內(nèi)存模型，內(nèi)部定義了vring或者virtqueue等用到的組件。

移植層分為兩個子層：環(huán)境層和平臺層。第一個子層將針對每個環(huán)境單獨實現(xiàn)。（裸機環(huán)境已經(jīng)存在并在rpmsg_env_bm.c中實現(xiàn)，FreeRTOS 環(huán)境在rpmsg_env_freertos.c等中實現(xiàn)）只有與所使用的環(huán)境匹配的源文件才會包含在目標(biāo)應(yīng)用程序項目中。第二個子層在rpmsg_platform.c中實現(xiàn)，主要定義中斷啟用、禁用和觸發(fā)的低級函數(shù)。情況如下圖描述：

核心子組件

該子組件實現(xiàn)了阻塞發(fā)送 API 和基于回調(diào)的接收 API。RPMsg 協(xié)議是傳輸層的一部分。這是通過使用所謂的端點來實現(xiàn)的。每個端點可以分配不同的接收回調(diào)函數(shù)。然而，需要注意的是，在當(dāng)前的設(shè)計中，回調(diào)是在中斷環(huán)境中執(zhí)行的。因此，不鼓勵在回調(diào)中執(zhí)行某些操作（例如內(nèi)存分配）。下圖顯示了 RPMsg 在類 ISO/OSI 分層模型中的作用：

隊列子組件（可選）：該子組件是可選的，需要在環(huán)境移植層中實現(xiàn)env_*_queue()函數(shù)。它使用阻塞接收API，這在RTOS環(huán)境中很常見。它支持復(fù)制和非復(fù)制阻塞接收功能。

名稱服務(wù)子組件（可選）：該子組件是RPMsg的Linux內(nèi)核實現(xiàn)中存在的名稱服務(wù)的最小實現(xiàn)。它允許通信節(jié)點發(fā)送有關(guān)“命名”端點（即通道）創(chuàng)建或刪除的公告，并在應(yīng)用程序回調(diào)中采取任何用戶定義的操作來接收這些公告。用于接收名稱服務(wù)公告的端點地址被任意固定為53(0x35)。

應(yīng)用

應(yīng)用程序應(yīng)將 /rpmsg_lite/lib/include 目錄放入包含路徑，并在應(yīng)用程序中包含rpmsg_lite.h頭文件，或者選擇包含rpmsg_queue.h和/或rpmsg_ns.h文件。RPMsg-Lite提供兩個移植子層，但如果計劃使用其他的RTOS，您需要實現(xiàn)其他RTOS的環(huán)境層（例如，rpmsg_env_xxxrtos.c）并將其包含在項目構(gòu)建中。

堆棧的初始化是通過調(diào)用主端的rpmsg_lite_master_init()和遠程端的rpmsg_lite_remote_init()來完成的。該初始化函數(shù)必須在任何RPMsg-Lite API調(diào)用之前調(diào)用。在init之后，需要創(chuàng)建一個通信端點，否則通信是不可能的。通過調(diào)用rpmsg_lite_create_ept()函數(shù)來完成?？梢赃x擇接受最后一個參數(shù)，在該參數(shù)中創(chuàng)建端點的內(nèi)部上下文，以防RL_USE_STATIC_API選項設(shè)置為1。如果不是，堆棧將在內(nèi)部調(diào)用env_alloc()為其分配動態(tài)內(nèi)存。如果要使用基于回調(diào)的接收，則使用用戶定義的回調(diào)數(shù)據(jù)指針將ISR回調(diào)注冊到每個新端點。如果需要阻塞接收（在 RTOS 環(huán)境的情況下），則必須在調(diào)用rpmsg_lite_create_ept()之前調(diào)用rpmsg_queue_create()函數(shù)。隊列句柄作為回調(diào)數(shù)據(jù)參數(shù)傳遞給端點創(chuàng)建函數(shù)，并且回調(diào)函數(shù)設(shè)置為rpmsg_queue_rx_cb()。然后可以使用 rpmsg_queue_receive() 函數(shù)在隊列對象上偵聽傳入消息。rpmsg_lite_send()函數(shù)用于向?qū)Ψ桨l(fā)送消息。

RPMsg-Lite 還為發(fā)送和接收操作實現(xiàn)無復(fù)制機制。這些方法需要在應(yīng)用程序中使用時必須考慮的細節(jié)。

無復(fù)制發(fā)送機制：該機制允許發(fā)送消息，而無需將數(shù)據(jù)從應(yīng)用程序緩沖區(qū)復(fù)制到共享內(nèi)存中的 RPMsg/virtio 緩沖區(qū)。要執(zhí)行的無復(fù)制發(fā)送步驟的順序如下：

調(diào)用rpmsg_lite_alloc_tx_buffer()函數(shù)獲取virtio緩沖區(qū)并將緩沖區(qū)指針提供給應(yīng)用程序。

將要發(fā)送的數(shù)據(jù)填充到預(yù)先分配的virtio緩沖區(qū)中。確保填充的數(shù)據(jù)不超過緩沖區(qū)大?。ㄗ鳛閞pmsg_lite_alloc_tx_buffer()大小輸出參數(shù)提供）。

調(diào)用rpmsg_lite_send_nocopy()函數(shù)將消息發(fā)送到目標(biāo)端點?？紤]緩存功能和virtio緩沖區(qū)對齊。

no-copy-receive機制：該機制允許讀取消息，而無需將數(shù)據(jù)從共享內(nèi)存中的virtio緩沖區(qū)復(fù)制到應(yīng)用程序緩沖區(qū)。要執(zhí)行的無復(fù)制接收步驟的順序如下：

調(diào)用rpmsg_queue_recv_nocopy()函數(shù)獲取指向接收數(shù)據(jù)的virtio緩沖區(qū)指針。

直接從共享內(nèi)存中讀取接收到的數(shù)據(jù)。

調(diào)用rpmsg_queue_nocopy_free()函數(shù)釋放virtio緩沖區(qū)并使其可用于下一次數(shù)據(jù)傳輸。

用戶有責(zé)任在取消初始化時銷毀他創(chuàng)建的任何RPMsg-Lite對象。為此，函數(shù)rpmsg_queue_destroy()用于銷毀隊列，rpmsg_lite_destroy_ept()用于銷毀端點，最后，rpmsg_lite_deinit()用于取消初始化RPMsg-Lite核間通信堆棧。在取消初始化隊列之前，使用隊列取消初始化所有端點。否則，您將主動使已使用的隊列句柄失效，這是不允許的。RPMsg-Lite不會在內(nèi)部檢查這一點，因為它的主要目標(biāo)是輕量級。

配置選項

RPMsg-Lite可以在編譯時進行配置。默認配置在rpmsg_default_config.h頭文件中定義。用戶可以通過包含具有自定義設(shè)置的rpmsg_config.h文件來自定義此配置。下表總結(jié)了所有可能的 RPMsg-Lite 配置選項。

審核編輯 黃宇