中央计算平台的集中计算架构
汽车电气/电子 (EE) 架构正在由分布式ECU 和基于域的系统架构过渡到集中式分区架构的发展。在集中式分区架构中,硬件 (HW) 系统和相关软件 (SW) 系统将发生比较大的变化。新架构围绕一个集中计算模块构建,该模块执行多种应用,如ADAS/ 智能座舱,信息娱乐、底盘/车身控制和动力系统。多个应用在位于中央处理模块的各种独立硬件板上运行。在独立硬件板上运行的各种应用提供了在单个硬件板上集成和组合独立板和 SoC的额外机会。新的集中式 EE 架构逐步创造了新一代片上系统 (SoC),具有更高的集成水平、极高的性能和更多数量的应用。正是由于集中式分区计算架构使自动驾驶和智能座舱(车载娱乐系统)集成到一个soc/chiplet 成为可能。

在单芯片中实现 ADAS 和数字驾驶舱(或 IVI)功能之后,就需要同时执行ADAS应用和数字驾驶舱应用。对于集中式 EE 架构的合并应用而言,可能会有一种不同的组合,即将远程信息处理功能与 ADAS 功能合并,或与集成了不同应用的多个不同混合平台合并。
使用集中计算模块实现分区架构将影响管理合并应用的计算 SoC。运行多个应用的新一代中央计算 SoC 需要更高水平的 AI 处理、更多数量的缓存一致性,多核64位主机处理器以及更高水平的显示处理。由于实现计算SoC 需要高性能且具有复杂性,因此需要先进的半导体 FinFET 工艺。将多个功能集成到中央计算 SoC 中将降低成本并最大限度地降低复杂性.
集中计算 SoC 必须执行实时、同步的应用。由于多个实时应用同步运行,集中计算模块中使用的处理SoC必须支持类似于高性能数据中心服务器处理器的虚拟化。由于SoC 必须支持多种实时应用,因此需要针对高性能汽车处理器优化应用的软件堆栈。对应用软件进行前瞻性规划将使汽车制造商能够设计软件定义汽车 (SDV),并允许引入新的特定应用的业务模式。但是,对于面向分区中央计算的高性能SoC 而言,处理器必须包含专门的功能,才能满足运行实时应用所需的性能。
集中计算SoC的一个关键设计特征是可扩展的异构多核处理器,其中有多达 14-30个64 位应用处理器集成到 SoC 中。为了执行安全关键型 ADAS 应用以及驾驶员监测系统 (DMS) 和乘客监测系统 (OMS) 等基于 AI 的 IVI 应用所需的 AI 算法,SoC 需要额外的深度学习AI 加速器。添加生成式 AI 使 IVI 供应商能够提供自然语言数字助理,为中央计算模块增加了额外的AI 工作负载。OEM 将 AI 用于 ADAS/HAD 中的多个应用,例如路线规划、物体/场景检测、识别和基于 AI 的决策。前面提到的 ADAS/HAD 应用,如自动紧急制动、车道保持辅助和自适应巡航控制,全都基于 AI。
集中中央计算SOC,可以在ADAS和IVI共享传感器信息,车辆运行状态,驾驶状态,乘车人员状态和需求。从而实现算力共享,算力资源集中调度,提高系统的性能和稳定性,也更符合驾驶的自然状态和从而提高自动驾驶软件水平。提高用车体验,也可以大大节省成本。
中央计算平台soc 需要CPU集群,GPU/NPU/ISP/VPU/DPU/DSP/安全岛/内存/HSM/高低速接口/传感器接口等
CPU集群
高算力的NPU/GPU和可扩展的架构
车的使用寿命一般是15年左右,NPU/GPU需要保持其算力的预埋和AI架构的硬件加速可扩展。随着自动驾驶技术的不断演进,端侧对NPU的算力需求也在不停的增加,从CNN,RNN,Transformer,Occupancy,BEV到VLA/VLM,world model,算力一直在不停的增加,NPU/GPU的支持的算子和AI架构也在不停变化。需要满足VLA/world model的在L3的ADAS,需要500TOPS之上的算力
智能座舱也需要NPU算力来满足AI需求,如车载大模型与生成式AI;个性化推荐与内容生成,DMS/OMS。需要~100TOPS的算力,对GPU要求支持高分辨率多屏显示屏/高分辨率的图形渲染、3D导航,HUD.

支持多传感器数据采集处理和融合

ADAS需要使用大量,多种类的传感器进行数据融合。雷达、激光雷达、超声波和摄像头传感器等传感器的数据需要以最低的延迟持续送达SOC并进行处理。如ADAS至少需要9路高清8M像素camera sensor。而座舱需要DMS/OMS至少2路高清camera sensor。
万兆以太网
中央计算平台必须实时持续处理用于安全关键型 ADAS 应用的大量传感器数据。。数据流量和协议不得过度占用车载网络线束。以太网主要用来传递雷达/激光雷达数据和DDS通信数据。支持TSN需要根据网络策略,传输高优先级的安全关键型数据包,以确保IVI娱乐等低优先级数据不会干扰安全关数据的带宽和低时延。以太网必须支持时间同步。
SerDes/MIPI 高速接口
ADAS系统需要处理多路的高分辨率的camera sensor每个传感器的数据两大,soc必须要有丰富的serdes/MIPI等告诉接口。MIPI 联盟也开发了A-PHY 协议(15米距离),可将图像数据传送到中央计算模块。MIPI A-PHY 作为车载数据传输协议越来越受欢迎。
高带宽的DDR控制器
AI对DDR的带宽需求随着使用场景不同而不同,但是AI计算平台相比传统的计算平台,带宽需求大很多。对ADAS和IVI的单一soc其带宽需要在500GB/s之上
内存防火墙
为了使不同的子系统之间的内存隔离,防止内存访问越界,往往需要内存防火墙
高分辨率和多屏显示系统
DSP audio 系统
Timer 系统
I2C/UART/I2S/DEBUG等
高带宽QOS的NOC
缓存一致性
由于ADAS和IVI的HW集成到同一个SOC,而ADAS和IVI的应用对安全等级,实时性,latency等不相同,通常需要对HW进行虚拟化。
为什么需要虚拟化?由于在soc上需要同时运行ADAS/IVI的应用,而ADAS/IVE的安全等级,需要的资源,其优先级天然的不同。因此需要在中央计算平台上(单一SoC上)创建多个相互隔离、具备独立资源和执行环境的虚拟机,从而实现不同操作系统及应用程序的安全、可靠、高效共存与运行。虚拟化的目标是隔离,独立运行,资源共享。在虚拟化中,存在两种虚拟化范式,一是基于时间片的虚拟化,类似于一个单核CPU通过时间片轮转来同时运行多个程序。每个程序都感觉自己在独占CPU,但实际上是在快速切换。资源共享,隔离性较弱。另外一种是类似于一个多核CPU,将不同的物理核心直接分配给不同的任务或用户。每个核心都独立执行指令。资源隔离,物理分割。对中央计算平台来说,主流的做法是采用物理分割方式,往往事先根据VM对算力的要求,在Hypervisor已经配置好各VM的硬件资源,这样系统启动时VM使用自己分配好的硬件资源,而不是在runtime时进行动态的调整分配。

CPU的虚拟化
在虚拟化时往往以DSU为单位,分配给不同的VM使用。至少也是虚拟CPU和物理CPU是事先配置好的,无法做到在运行时动态调整。这样Hypervisor的软件简单高效,调度器直接从虚拟的CPU到实体的CPU,无需进行动态的调整分配。也能充分利用local的一致性,程序运行的数据不会跨DSU进行跃迁从而导致cache miss飙升,影响性能
GPU/NPU虚拟化
GPU虚拟化的核心是上下文管理与计算隔离。在目前的ADAS/IVI SOC架构中,通常是多cluster的GPU/NPU,也就和CPU的DSU类似,这些cluster的GPU/NPU有自己独立的register/独立的计算单元/独立的L2 cache。这样不同的VM分配不同的GPU/NPU cluster。不同的VM对GPU/NPU的计算运行在同的GPU cluster 上,这样系统可以同时运行ADAS/IVI 系统对NPU/GPU计算的请求,他们相互独立互,隔离,不依赖。高效地执行,并为每个VM提供独立的GPU/NPU。
Memory虚拟化
内存虚拟化的目标是让多个虚拟机同时运行在一个物理机上,每个虚拟机都认为自己独占了整个物理内存地址空间。需要完成两阶段地址转换。
Guest Virtual Address -> Guest Physical Address -> Host Physical Address
GVA:虚拟机内应用程序看到的地址。
GPA:虚拟机操作系统认为自己正在使用的“物理地址”。
HPA:真实的机器物理地址。
Hypervisor控制着GPA->HPA的映射关系,从而实现了对物理内存的控制和隔离。
ARM通过虚拟化扩展为两阶段转换提供了完整的硬件支持。

对设备的虚拟化解决方案是使用SMMU。SMMU相当于这些设备的“MMU”。它使用与CPU MMU相同的Stage 2页表。

对soc架构而已,目前有两种方式。一种方式是传统的SOC,也即各子系统通过NOC连接在一起,封装在一个soc内部。这技术含量比较高,目前主要有NVIDIA和QCOM两个玩家。另外一种方式是采用chipset,子系统是以独立的Die存在,以先进的封装方式组合在一起。后者多是基于UCIe 的多Die解决方这种方案可以为每个Die选择最佳的工艺节点和设计风格。提供了产品管理的灵活性,并缩短了上市时间。








两个头部玩家的最新芯片都还没有完全整合ADAS/IVI。NVIDIA芯片AI 算力很强,然后在座舱软件的支持比较欠缺,或许NVIDIA看暂时还看不上IVI这一块,比较即便是ADAS这块芯片业务也是可有可无。QCOM的AI 算力一直饱受诟病,算而不强,有卖座舱送ADAS的美誉。
也许不久的将来会出现一个SOC搞定中央计算平台,真正做到一芯多用。