概要

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

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

異構多核系統的特點主要體現在以下幾個方面：

性能提升：通過結合不同類型的處理器核心，異構多核系統能夠充分發揮各核心的優勢，實現計算性能的大幅提升。例如，高性能核心可以處理復雜的計算任務，而專用核心則可以加速特定類型的數據處理。

能效優化：異構多核系統能夠根據任務需求動態調整核心的使用，避免資源浪費和不必要的功耗。對于計算密集型任務，可以使用高性能核心；而對于數據密集型任務，則可以利用專用核心進行高效的數據處理，從而實現能效比的最大化。

靈活性：異構多核系統能夠適應多樣化的應用場景，通過靈活的任務調度和核心分配，滿足不同任務的需求。這使得系統能夠同時處理多種類型的任務，提高整體計算效率。

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

多核通信

市面目前多核異構芯片形態：

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

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

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

RPMsg-Lite介紹

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

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

創建目的

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

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

框架說明

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

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

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

核心子組件

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

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

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

應用

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

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

RPMsg-Lite 還為發送和接收操作實現無復制機制。這些方法需要在應用程序中使用時必須考慮的細節。

無復制發送機制：該機制允許發送消息，而無需將數據從應用程序緩沖區復制到共享內存中的 RPMsg/virtio 緩沖區。要執行的無復制發送步驟的順序如下：

調用rpmsg_lite_alloc_tx_buffer()函數獲取virtio緩沖區并將緩沖區指針提供給應用程序。

將要發送的數據填充到預先分配的virtio緩沖區中。確保填充的數據不超過緩沖區大小（作為rpmsg_lite_alloc_tx_buffer()大小輸出參數提供）。

調用rpmsg_lite_send_nocopy()函數將消息發送到目標端點。考慮緩存功能和virtio緩沖區對齊。

no-copy-receive機制：該機制允許讀取消息，而無需將數據從共享內存中的virtio緩沖區復制到應用程序緩沖區。要執行的無復制接收步驟的順序如下：

調用rpmsg_queue_recv_nocopy()函數獲取指向接收數據的virtio緩沖區指針。

直接從共享內存中讀取接收到的數據。

調用rpmsg_queue_nocopy_free()函數釋放virtio緩沖區并使其可用于下一次數據傳輸。

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

配置選項

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

審核編輯 黃宇