浅析核间通讯——以NXP IPCF为例

前言C0Xednc

随着汽车电子的高速发展，电控单元的复杂性越来越高，对芯片的算力要求也迅速提高，于是，例如ARM架构这样的异构处理器的应用也更为普遍。对于多核异构处理器而言，核间通讯是一项至关重要的特性。核间通讯的性能往往能对整个处理器的性能释放起到决定性的作用。C0Xednc

本文将以NXP的IPCF为例，并简单对比一些其他方案，浅析核间通讯的设计与实现。C0Xednc

IPCF的官方网站：https://www.nxp.com/design/automotive-software-and-tools/inter-platform-communication-framework-ipcf:IPCFC0Xednc

其代码托管于https://github.com/nxp-auto-linux/ipc-shmC0Xednc

02C0Xednc

软件架构C0Xednc

C0Xednc

IPCF架构框图C0Xednc

根据IPCF架构框图，它基于硬件（NXP硬件平台），服务于应用（客户应用程序），由硬件驱动（ipc-hw）、操作系统接口（ipc-os）与功能实现（ipc-shm）这三个子模块构成。通过这一设计，核间通讯方案可以将算法实现与下层的软、硬件系统解耦，实现高度的模块化和可移植性。C0Xednc

03C0Xednc

硬件驱动（ipc-hw）C0Xednc

硬件驱动是架构中的最底层。它与硬件直接相关，负责实现对硬件的操作，例如通知（中断）和数据（内存）的操作。C0Xednc

在IPCF的架构设计中，硬件驱动全权掌管对硬件的交互，向上则面向操作系统接口与功能实现这两个子模块。C0Xednc

代码实例C0Xednc

C0Xednc

https://github.com/nxp-auto-linux/ipc-shm/tree/master/hwC0Xednc

在NXP公开的源码中可以看到，对于不同的硬件平台，它分别提供了对应的C语言实现，而头文件保持一致，确保接口的一致性。C0Xednc

粗略阅读头文件可以看到，这一模块主要提供的是对芯片中断的支持，可以完成注册、启用、禁用和触发中断等一系列操作。C0Xednc

核间通讯中断的硬件设计也是一门学问。NXP的S32系列芯片设计了若干个专用的核间通讯中断（具体数量由芯片型号决定），每个中断都有自己的一组寄存器以实现导向触发（Steering），用户可以通过寄存器配置，灵活设置每一个中断的发送核与接收核。这样可以利用有限的资源，实现业务所需的具体核心之间的通讯需求。C0Xednc

04C0Xednc

操作系统接口（ipc-os）C0Xednc

操作系统接口是架构中的中间层，但从整个系统而言，它也可以说是软件方面的最底层。它负责与操作系统交互，例如掌控程序的执行流程（中断和任务的调用）。C0Xednc

在IPCF的架构设计中，操作系统接口向下依赖于硬件驱动，向上服务于功能实现。C0Xednc

代码实例C0Xednc

C0Xednc

在NXP公开的源码中可以看到，对于不同的操作系统，它也分别提供了对应的C语言实现。在A核侧可以看到有对uio的支持，而如果拿到M核侧的源码，则可以看到对AUTOSAR、FreeRTOS等多个操作系统的支持。C0Xednc

相比硬件驱动，操作系统的接口明显更多样（毕竟硬件都是NXP自家的），但无一例外地都应当实现软件模块的各种例程在操作系统中的适当调用。C0Xednc

虽然操作系统林林总总，但这一子模块需要解决的问题无非是各类例程的调用（初始化、周期任务、中断任务）和对软件底层资源的使用（文件读写）。C0Xednc

05C0Xednc

功能实现（ipc-shm）C0Xednc

功能实现是架构中的最上层，负责提供对应用程序的软件接口，并依赖于硬件驱动和操作系统接口来实现通讯的逻辑。相比起更为直白和稳定的软硬件基础件，功能实现的自由度更大，可供发挥的空间也更多。针对具体业务设计更高效的功能实现将起到事半功倍的效果。C0Xednc

代码实例   在NXP公开的源码中，这一子模块以其传输介质的形式（shared memory）被命名为shm。它实现了几种通用的通讯算法，以共享内存与中断通知的组合，完成消息和数据的传递。 和几乎所有的消息系统一样，它将消息的访问方式分为回调与轮询两种，以满足不同时效性要求的场景。C0Xednc

而在数据算法方面，它又设计了两种形式，其中unmanaged类型是以一段连续的内存区域为消息的内容，发送方可以直接覆盖数据，因此在例如接收方处理速度较慢的情况下，可能出现丢失数据的结果，但其优点在于发送的消息不会被阻塞，保证信息的实时性。正如其官方建议的那样，此类数据处理形式适用于例如视频流传输等整块访问数据的、新数据优先的场景中。C0Xednc

而managed类型则是一种先入先出式的队列系统。首先它会将内存区域划分成固定大小的缓存块，并根据一张读写的索引表，按顺序将数据存入缓存块中，再按顺序取出使用。这一层可以当作对存储器的基本数据队列处理。为了更好地利用内存空间，它还设计了另一层消息队列，支持分布不同长度的缓存块，可以理解为将多个缓存队列并列起来，但其代价是为了保证所有队列中消息的有序性，需要另建一张总的索引表来记录所有消息的读写索引。这种方式能够严格保证消息的有序和有效，但可能出现阻塞。C0Xednc

当然，这些现成的通讯算法并不一定能完全满足业务的需求，也存在许多明显的局限性，例如自身没有数据完整性校验、轮询方式不支持单条消息的读取等等，这些都是笔者在实际应用中所发现的，旨在抛砖引玉。到了这些时候，就需要软件开发者各显神通，或是加以改进，或是另辟蹊径，只为不断提高核间通讯的可用性，以满足日益繁杂的业务需求。C0Xednc

06C0Xednc

其它方案C0Xednc

Linux RPMsg framework for STM32MP15xC0Xednc

Rpmsg是Linux内核提供的一种通用的通讯方案，在当前的汽车电子领域有相当广泛的应用。下面是STM32MP15x系列芯片的RPMsg方案的概览：C0Xednc

C0Xednc

从中可以看到，作为一种示范性的通用方案，它与NXP的IPCF也有许多异曲同工之妙。C0Xednc

我们自下而上来看，首先是SoC的硬件层。IPCC是inter-processor communication controller的缩写，负责的是核间通讯的通知（中断）收发，向上的mailbox和remote proc则相当于对硬件中断封装的驱动，这与NXP IPCF中的ipc-hw是大致对应的。MCUSRAM负责存储器的管理，其中的收发Vring及对应的缓存实现了消息队列，向上则联通Linux内核中的Virtio虚拟输入输出总线，最后是rpmsg模块，这样的结构也大致与ipc-os和ipc-shm对应。C0Xednc

TI Jacinto的IPCC0Xednc

C0Xednc

在TI的Jacinto上也有类似的基于rpmsg的核间通讯方案IPC。从设计上与上述方案都大同小异：Mailbox管理中断，VRing管理数据，向上通过rpmsg模块实现消息的收发接口。C0Xednc

07C0Xednc

结语C0Xednc

本文通过实例分析和对比，介绍了核间通讯的总体软件架构设计与各个子模块的实现。作为影响多核系统性能的重要一环，核间通讯在如今的汽车电子模块中对实时性和吞吐量都提出了越来越高的要求，在一些具体业务中，还会对安全性等方面提出额外的需求。这一切也给核间通讯开辟了更多的发展空间，同时为广大汽车人提供了更广阔的舞台。C0Xednc

参考来源 https://www.nxp.com/design/automotive-software-and-tools/inter-platform-communication-framework-ipcf:IPCF https://www.nxp.com/assets/block-diagram/en/IPCF.pdf https://github.com/nxp-auto-linux/ipc-shmhttps://wiki.stmicroelectronics.cn/stm32mpu/wiki/Linux_RPMsg_framework_overview https://docs.kernel.org/staging/rpmsg.html https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/07_02_00_06/exports/docs/pdk_jacinto_07_01_05_14/docs/userguide/jacinto/modules/ipc.htmlC0Xednc