软件定义汽车-NXP S32G在域控应用的思考

一、汽车芯片是软件定义汽车的基石

智能化、网联化、电动化和共享化是近几年及未来汽车行业发展趋势，汽车已渐渐摆脱单纯代步工具的角色，而给用户带去更丰富的体验、参与和乐趣。而出色用户体验的实现重度依赖软件。目前整车厂、供应商和新势力无不希望自己能在这条由软件驱动的新价值链上把握住主动权。

这样的趋势和变化，将会给汽车E/E架构和软件带来巨大的挑战和革新。

软件方面：整车功能越来越复杂，软件定义汽车的时代，汽车软件代码量、复杂度和安全性要求都在快速增长。据NXP预测，2015-2025年汽车中代码量有望呈指数级增长，其年均复合增速约为21%。

架构方面

汽车E/E架构之前一直遵循着“一个功能一个盒子”的分布式架构模式，在这样的汽车电子电气架构形式下，每增加一个功能，就需要增加相应的控制器，进一步增加系统的复杂性，而目前OEM为了整合软件、简化整车线束及降低成本逐渐开始走域控Domain Control、区域控制Zone Control的道路。

E/E架构最终的目标是中央计算机架构，中央计算机由异构的多核处理器构成，例如ARM Cortex-A 架构, ARM Cortex-M架构、GPU等。所有传感器都是自带处理能力的智能传感器，中央计算机与传感器的交互及控制都通过网关这一桥梁建立联系。

俗话说得好：好马配好鞍，虽然我们基于软件的整车功能越来越丰富，但如何保证相应的软件安全、高效、可靠的正常运行呢？毫无疑问必须依靠越来越强大的硬件，而硬件的核心就是汽车芯片。

二、NXP域控芯片—S32G

在当前智能化和网联化的趋势下，针对域控、网联的应用各大芯片供应商都有相应的产品支持。本文将着重探讨目前业内广受关注的NXP域控芯片——S32G系列。

1、NXP S32系列

NXP在2017年发布了S32系列产品组合，针对汽车上不同的应用场景，覆盖了车身，雷达，网关，底盘动力等不同应用，向主机厂和Tier1提供丰富的产品支持。

S32系列各个产品共用多个IP核，使得在不同ECU之间例如域控制器(Domain)，区域控制器(Zonal)，以及终端节点(Node)可以共用软件，包括基础BSP和信息安全及功能安全的相关开发设计成果。

在当前域控火热的背景下，作为S32家族目前NXP主推产品之一，S32G主要应对如下目标应用：

中央网关：需要对确定性网络通信和其它处理任务负载进行加速，并需要为新兴无线服务提供嵌入式安全
服务型网关：需要高性能应用处理，并提供隔离功能，以快速部署新的安全服务
域控制器：需要高性能实时和应用处理，以支持 ECU 整合、网络协议转换和本地域控制
安全协处理器：需要 ASIL D 功能安全处理以及网络连接和 PCI Express®，以便与其他组件和中央大容量存储器共享数据
中央车控单元：新电子电气架构趋势下，服务型网关上融合了越来越多的功能(例如VCU, BCM等)

通常基于S32G的服务型网关或中央车控单元的基本系统框图如下，外围电路需要搭配专用PMIC芯片VR5510，CAN和以太网收发芯片，以及必要的存储芯片等。

S32G处理器采用成熟可靠的汽车领域专业技术设计和制造，配有嵌入式硬件安全引擎(HSE)，可满足开发人员寻求的高性能、安全性、安全保障和可靠性要求。

S32G汽车网络处理器结合了ASIL D等级安全性、高性能实时和应用处理，以及网络加速功能，具有如下主要特性：

S32G目前主要是G2家族产品，在G2家族产品序列下同样也根据不同的成本要求和应用场景，提供不同的产品支持。

三、S32G2产品的主要特征及应用

1、多核异构满足复杂软件功能需求

目前因为整车软件功能越来越复杂，再加上主机厂将多个控制器的功能整合到一个控制器的需求，越来越需要多核支持。

多核的需求还有如下几个因素

并行计算的需求：例如某些功能的输出计算需要多个输入要素在相同时间片内执行并在同一时刻输入到该功能模块。

相同时间片内多个任务的串行计算需求：例如多个功能需要在相同的时间内被串行执行。

系统响应能力的需求：例如对于那些对时间要求特别高的中断处理需要单独在一个核上运行，而周期性任务则放到另外一个核上运行，从而提高整个系统的响应能力。

此外，在同一控制器我们可能部署对实时性要求很高的嵌入式应用，例如Powertrain域的控制，也有可能部署对实时性要求不太高的应用，如车机交互，这些软件可能依赖不同的运行环境，可能是RTOS，也有可能是Linux、QNX，这时在多核需求的基础上还需要异构核的支持，分别运行依赖不同操作系统的软件。

而S32G2最多支持四个采用Arm Neon™ 技术的Arm®Cortex®-A53内核，带可选的两两锁步功能，用于处理高算力的应用和服务。还有3个Arm Cortex-M7全锁步内核，用于处理实时应用。

我们知道ARM Cortex内核系列提供了非常广泛的具有可扩展性的性能选项，设计人员可在多种选项中选择最适合自身应用的内核而非千篇一律采用同一方案，Cortex系列主要分为三类：

Cortex-A：面向性能密集型系统的应用处理器内核，A系列类似于CPU，可运行Linux、QNX系统等。
Cortex-R：面向实时性的高性能内核
Cortex-M：面向各种嵌入式应用的微控制器内核

因此总结下来ARM Cortex-A在需要Linux或其他复杂操作系统的应用中得到广泛部署，而Cortex-R和Cortex-M都是面向实时性要求的嵌入式应用。

S32G MCU采用了三个400MHz的Arm Cortex-M7内核，M7的首要使命就是高性能，号称达到了前所未有的水平，同时还要维持该系列一贯的超小面积、超低功耗。架构上，M7具备六级、顺序、双发射超标量流水线，拥有单精度、双精度浮点单元、指令和数据缓存、分支预测、SIMD支持、紧耦合内存(TCM)。指令和数据缓存、分支预测、TCM都是以往M系列上没有的。MCU经常不考虑缓存，有时候甚至将闪存作为唯一的内存接口。通过加入高性能的指令和数据缓存(最大均为64KB)，M7开始向典型的高性能处理器设计靠拢。TCM之前也只在A、R系列上存在，可以用来扩展M7的有效缓存，最大容量16MB，是MCU物理内存映射的一部分。

S32G虽然实时处理核并未采用Cortex-R，但在同样测试环境下，实测S32G的M7核 (400Mhz, 1300 DMIPS)在SRAM里运行，性能约为R5F核 (1GHz, 2000 DMIPS) 在DDR运行的3到5倍。

另外NXP S32G系列采用了4个1 Ghz Cortex-A53内核。由于 M、A两大系列往往是共存协作的，因此这种组合实现了双剑合璧，可基于该芯片实现复杂的软件功能开发，例如让Arm Cortex-M7作为MCU做对实时性要求更高的控制，例如动力域的Classic Autosar应用，而Cortex-A53由于高的主频和处理能力则主要用于算法的运行，例如跑信息娱乐或ADAS域基于QNX的Adaptive Autosar应用。

S32G SoC片上系统提供了XRDC硬件资源隔离机制，从硬件上保证M7核上的实时应用和A53核上的性能应用，既能有效合作，又能完全硬件隔离，保证整个系统的高可靠性。

S32G作为一款异构多核处理器，除了使用高配主核外，还在很多模块低配小核的配置。S32G的A核，M核，LLCE，PFE，HSE五个模块都内置处理器，意味着都可以两两之间互相通信互相配合完成各种功能，实现分布式的功能实现。例如LLCE内置了4个200MHz的Cortex M0+核，类似传统的CAN网关MCU。

另外S32G2 Arm®Cortex®-A53核带可选的两两锁步功能，用于处理高算力的应用和服务。还有3个Arm Cortex-M7全锁步核，用于处理实时应用。这样可保证一些功能安全的要求，实现高诊断覆盖度。

2、通讯加速模块助力SOA的网关应用

伴随着汽车智能化、网联化、共享化的趋势，终端用户对车辆功能的预期也悄然发生着改变，汽车在实现高等级自动驾驶/辅助驾驶功能的同时，也更趋向于提升用户体验，例如满足快速的功能更新和升级，可以提供个性化、人性化、差异化的功能与服务等。面向服务的软件架构(Service-Oriented Architecture)正为未来的车辆软件服务提供良好的解决方案。

基于信号的通讯仅支持发送和接收模式，支持的数据类型简单且可扩展性差，适用于有限大小数据交互的应用场景。而诸如自动驾驶等先进应用场景加入后，大量数据的动态交互必须采用面向服务的通讯方式以提高通讯效率降低负载，在该种方式下，接收者作为客户端，只需要查找、订阅服务等待接收信息即可，而发送者作为服务提供者只需要给订阅者提供服务和信息即可，因基于SOA的通讯支持请求/响应模式，可扩展性强且支持复杂数据的传输。SOA的应用要基于以太网，而在通讯方面，S32G有丰富的通讯接口，有20个CAN接口，4个千兆以太网接口和2个PCIe 3.0接口，为不管是网关还是域控等各种应用场景的支持提供了灵活性。

S32G与NXP相关Switch及Transceiver产品配合使用可大大提高扩展性：

在网关应用中，其数据吞吐量是非常大的，网络加速是S32G的关键特性之一。如果没有它，千兆以太网处理满载时将消耗ARM核心90%的处理能力。启用加速器后，这一性能下降到可用性能的0.2%左右，使得CPU可以自由处理一系列其他任务。这主要得益于NXP的低延迟通信引擎 (LLCE)和数据包转发引擎（PFE）

2.1 低延迟通信引擎 (LLCE)

S32G的低延迟通信引擎 (LLCE) 主要负责CAN、LIN 和 FlexRay 的通讯。LLCE 在校验和认证帧的过程中offload 主核的负载，并可基于片上的硬件安全模块 (HSE)处理帧的加密、解密过程，LLCE旨在提供：

• 通信接口的低延迟处理
• 为所有接口相关任务offload主机内核
• 安全相关任务可直接向HSE模块进行数据获取和传输

LLCE是一个完全可编程的引擎，其固件支持：

1、为所有通信接口相关任务Offload主CPU负载，例如减少主机内核上的中断负载和高级软件过滤
2、向主机内核提供灵活的控制和数据接口
3、为过滤和确定消息优先级提供硬件加速，为低延迟要求的网关转发应用场景提供了保障

固件通过 AUTOSAR MCAL 集成到 AUTOSAR ® 通信堆栈中，NXP 提供CAN\_LLCE、LIN\_LLCE和FR\_LLCE的驱动程序。用于 LLCE 的 AUTOSAR 驱动程序与标准通信的 CAN/LIN/FR 驱动程序并行运行。NXP LLCE 固件支持用户创建的高级扩展，例如：

• 使用 HSE 服务进行 CAN 帧身份验证
• CAN 到 CAN 路由
• CAN 到以太网和以太网到 CAN 路由

LLCE处理的通讯接口如下：

• 16 个 CAN 接口，支持 CAN2.0 和 CAN FD（灵活数据速率）（5 Mbps）
• 4 个 LIN 接口，每个接口均能达到 20 Kbps
• 1 个 FlexRay 接口 (20 Mbps)

2.2 数据包转发引擎(PFE)

PFE 可大幅降低主机内核对以太网数据包的处理负载，比通过纯软件的处理方式具有更高的性能和更低的功耗。PFE 具有 2 Gbit/s 的数据包转发速度且几乎不会对主机内核带去负载。

PFE 是一个基于固件的模块。在使用 PFE 之前需要加载固件。PFE 内核在主机内核初始化期间启动。初始化完成后，PFE 进入正常模式并准备好全面运行。PFE 基于可编程数据包处理引擎 (PE)。实现了快速路径、慢速路径架构。可完全offload主机内核的快速路径数据包。慢速路径数据包（例如控制数据包）可进行主机内核上的数据包处理。另外PFE的分类模块分类并执行报头修改任务，例如网络地址转换（NAT）。NXP 提供主机接口驱动PFE。

2.3 总结

因此S32G用加速器来完成CAN和以太网路由通信，大大释放了M核和A核的算力，通过加速器之间配合，即可完成CAN-to-CAN, CAN-to-Eth, Eth-to-CAN, Eth-to-Eth的路由转发功能。随着通信带宽和路数增加，加速器可以承担更多处理任务，而不影响A核和M核上的应用软件的执行。使用加速器之后，网关所需算力，按照实际车厂项目经验，约为0.5个M7核，即650 DMIPS。

3、HSE助力信息和通讯安全

安全在每个领域都是一个永恒的话题，汽车也不例外，最近几年汽车安全也越来越受到用户及开发人员的重视。在智能网联和自动驾驶相关功能引入到汽车领域之前，功能安全一直是重中之重。因此，功能安全方法和过程也是汽车行业标准和发展的关键部分。如今，随着各种智能网联汽车和自动驾驶汽车的出现，汽车连接性功能、车辆维护和交通安全信息共享等变得越来越普及，同时也增加了不同动机的黑客攻击车辆的可能性，从而给汽车网络安全带来了新的风险。

开发人员关注和考虑整车E/E架构、硬件以及软件等方面的可靠和安全，比如硬件的EMC和随机故障、软件功能设计及控制器内部和外部的通讯安全等等。每个安全要素作为系统目标的重要组成部分只为保证整车的可靠性和安全性，从而保护用户的人身安全。

而NXP S23G则提供了硬件安全引擎(HSE)，用于安全启动和加速安全服务。Hse作为一个安全子系统旨在运行具有严格保密性或真实性要求的应用程序安全功能，具有诸如秘钥管理、内存检查、加解密、随机数服务等功能：

HSE 固件可满足广泛的汽车安全要求和用例（AUTOSAR ® SecOC、SSL/TLS、IPsec等等）。

这些服务通过灵活且可配置的通信接口进行访问，该接口允许同步、异步请求，这些通用安全 API允许用户将 HSE 子系统集成到不同的安全堆栈中。

4、完整的芯片级ASIL-D功能安全

在车载中央网关向中央车控(HPC或者CCU)演进过程中，越来越多的功能会被融合进来，例如VCU和BMS等高功能安全的模块，这对处理器提出了更高的要求。另外在ADAS/AD应用中，传统使用独立MCU来实现”安全岛”功能，却受限于相对较低的算力。而S32G异构处理器在提供高性能处理能力的同时，也提供芯片级的高等级功能安全，满足以上提到的应用场景。

4.1S32G功能安全特性

与业内其他SOC产品提供的片内”安全岛”的做法不同，S32G提供了整个SOC层面的功能安全实现，并且以SEooC方式来独立模块化设计, 以M7\_0为安全主核。

硬件资源除了三对锁步M7核、可配置锁步的A53核以及基本的FCCU、BIST、WDG、时钟比较器之外，还包括更多资源，例如ASIL-D的总线、XRDC访问保护、Memory分区及保护、锁步中断控制器、锁步并带ECC的DMA、错误注入管理和Reset生产管理等多个安全模块。

4.2功能安全软件SAF

为方便开发功能安全应用软件开发，NXP为S32G开发了功能安全软件框架(Safety Software Framework, SAF)，可通过配置软件生成代码，方便集成到AUTOSAR或者non-AUTOSAR应用中。

SAF包含了多个功能模块，包括基础驱动程序(Safety Peripheral Drivers, SPD)，以及更多的中间件模块例如Safety Boot, Mode Selector, Error Management, Square Check等，方便快速开发功能安全应用软件。

4.3设计ASIL-D系统

NXP同时提供了ASIL-D的电源芯片VR5510与S32G配合，实现板级ASIL-D的安全目标。

5、片上SRAM的优势

S32G2的片上8MB SRAM，并且以64Byte交织(interleaved)的方式连接。400MHz x 128bit，带流水线功能，实现最大的吞吐率。S32G3提供最大20MB SRAM，进一步提升了实时核多域融合的集成度。

5.1SRAM带来性能提升

高性能运算芯片都会加大片上的高速SRAM来提高执行效率，例如Tesla自动驾驶FSD芯片带了32MB的SRAM，Google的TPU带了24MB的SRAM。得益于片上8MB SRAM，S32G2的实时核M7的性能也得到了极大提升。

实测对比400MHz的M7核和1GHz的R5F核，在Cache中运行测试代码对比两个核的性能，CoreMark值分别为1650/M7 vs. 2020/ R5F。而在实际运行环境中，由于M7运行在片上SRAM，而R5F运行在DDR中，M7运行各种测试样例的用时，比R5F大大的缩短，体现了片上SRAM在实际应用中带来的性能提升。

5.2SRAM实现快速启动和快速唤醒

在传统网关应用以及新一代中央车控应用中，CAN和以太网的快速启动/快速唤醒是一个必备的功能。各个OEM车厂要求未必一致，但是常规会要求CAN唤醒在100ms之内，即短时间内唤醒处理器执行软件，并将收到的CAN报文路由送到另外的ECU。现今以太网唤醒也类似要求，区域控制器(ZCU或者VIU)未来通过实时以太网跟中央车控CCU相连，需要短时间内将以太网数据送给CCU并执行相应的动作。通常，实现休眠后快速唤醒的几个必要条件如下：

a. 需要是快速中断响应的MCU核
b.需要运行实时代码或实时操作系统，例如AUTOSAR CP
c.需要唤醒后有立即可执行代码的物理空间，例如SRAM或者Flash。

过去常规MCU可以执行代码在片上Flash Memory，因此能较好的满足休眠唤醒的时间要求。而部分SOC因为唤醒后，需要在DDR Memory上执行代码，而通常DDR因为是需要训练参数，因此往往有较长的建立时间而不满足休眠唤醒要求。(如果DDR休眠不掉电而处于自刷新状态，则会存在颗粒寿命大大缩短的问题)。

S32G2自带的8MB SRAM可以将AUTOSAR CP的全部软件运行在SRAM中(S32G3提供20MB SRAM)，可以将硬件初始化时间控制在32毫秒左右即可跳转到用户的bootloader代码，最终实现快速唤醒的功能。

6、用S32G2/G3实现兼容设计

2021年12月，NXP发布了四款S32G3系列器件，进一步扩展S32G汽车网络处理器系列。和原先的S32G2系列相比，新推出的S32G3产品软件和引脚兼容性，方便平台化设计，并且S32G3的算力、片上SRAM和网络带宽都得到了极大提升，从而可以融合更多功能到中央车控单元，并进一步支持智能软件定义汽车。

四、总结

性能方面：S32G处理器提供了符合ASIL D要求的MCU和MPU处理器，特定应用的网络硬件加速以支持复杂环境下的实时性要求；
信息安全：S32G包含高性能的硬件安全加速以及用于可信密钥管理的PKI支持；
功能安全：S32G提供ASIL D要求的处理器，包含支持同步模式（lock-step）的ARM Cotex-M7微控制器，以及多个ARM Cortex-A53应用处理内核的lock-step clusters功能。

S32G作为NXP S32系列的最新产品，可助力汽车行业向高性能、基于域的车辆架构落地，并降低软件复杂性提高信息和功能安全。