概要

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

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

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

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

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

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

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

多核通信

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

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

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

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

RPMsg-Lite介紹

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

RPMsg-Lite官方倉(cāng)庫(kù)：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)建目的

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

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

框架說(shuō)明

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

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

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

核心子組件

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

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

名稱服務(wù)子組件（可選）：該子組件是RPMsg的Linux內(nèi)核實(shí)現(xiàn)中存在的名稱服務(wù)的最小實(shí)現(xiàn)。它允許通信節(jié)點(diǎn)發(fā)送有關(guān)“命名”端點(diǎn)（即通道）創(chuàng)建或刪除的公告，并在應(yīng)用程序回調(diào)中采取任何用戶定義的操作來(lái)接收這些公告。用于接收名稱服務(wù)公告的端點(diǎn)地址被任意固定為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提供兩個(gè)移植子層，但如果計(jì)劃使用其他的RTOS，您需要實(shí)現(xiàn)其他RTOS的環(huán)境層（例如，rpmsg_env_xxxrtos.c）并將其包含在項(xiàng)目構(gòu)建中。

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

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

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

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

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

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

no-copy-receive機(jī)制：該機(jī)制允許讀取消息，而無(wú)需將數(shù)據(jù)從共享內(nèi)存中的virtio緩沖區(qū)復(fù)制到應(yīng)用程序緩沖區(qū)。要執(zhí)行的無(wú)復(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é)任在取消初始化時(shí)銷毀他創(chuàng)建的任何RPMsg-Lite對(duì)象。為此，函數(shù)rpmsg_queue_destroy()用于銷毀隊(duì)列，rpmsg_lite_destroy_ept()用于銷毀端點(diǎn)，最后，rpmsg_lite_deinit()用于取消初始化RPMsg-Lite核間通信堆棧。在取消初始化隊(duì)列之前，使用隊(duì)列取消初始化所有端點(diǎn)。否則，您將主動(dòng)使已使用的隊(duì)列句柄失效，這是不允許的。RPMsg-Lite不會(huì)在內(nèi)部檢查這一點(diǎn)，因?yàn)樗闹饕繕?biāo)是輕量級(jí)。

配置選項(xiàng)

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

審核編輯 黃宇