软件定义汽车(第七集)高性能计算单元架构.docVIP

软件定义汽车(第七集)高性能计算单元架构 1.?高性能计算单元 中央计算单元，其实就是一台经过特殊设计的专用计算机，其中最核心的是主芯片，一般会采用一颗或多颗高性能的SOC。SOC是System on Chip的缩写，就是在单块芯片上集成多个微处理器、模拟IP核、数字IP核和存储器等部件，比如CPU、GPU、DSP、ISP、Codec、NPU、Modem等模块。 在传统PC时代，各个核心芯片都是以独立的方式存在，比如英特尔和AMD的CPU、NVIDIA的GPU等，到了移动互联网时代，由于体积功耗方面的要求，主芯片都会进行高度的集成，除了大家熟知的CPU和GPU，通常还包含了音频、多媒体、显示、安全、通信、AI计算等子单元。 soc.jpeg 这些单元，在一套总线系统的连接下，构成了一个系统。大家所熟知的各种手机SOC芯片，如苹果的A系列、高通的骁龙系列、华为的麒麟系列，或者各类的AI SOC芯片，车载领域的各种SOC芯片，都逃不出以上范式。 虽然都是同一范式，但是由于使用的场景不同，各个芯片的侧重点不太一样： 娱乐系统芯片，其实和消费电子几乎一模一样，关注音频、视频、显示、图像等、Modem等。 自动驾驶芯片，注重高性能计算，一般配备有强大的NPU、GPU、DSP等。 网关芯片，主要特点是外设接口较多，有的也会集成swtich。 高性能计算单元.png 上一篇中，为大家介绍了传统ECU芯片的架构，其计算资源相对有限，结构也比较简单，一般NVM和SRAM都集成在了芯片内部，大小在KB级别，处理器一般采用Cortex-M内核。高性能的SOC其计算资源和外设都更加丰富，一般会集成多个Cortex-A内核，其存储单元采用外挂的形式，大小在GB级别。 一般的应用场景中，集成一个主芯片就能够满足计算资源的需求，但是自动驾驶对算力有着更高的要求，有时候 于安全的考虑，也需要同时集成多个主芯片，其结构一般如下图所示： cc-architecture.png 多个芯片在需要在PCIe Switch的连接下共同组成一个计算单元，如果以后发展成可动态拓展的形式（类似于刀片机），该结构依然适用，以下是采用两个Xavier芯片组成的一个高性能计算单元的示意图： xavier.png 2.??中央计算单元上的软件架构 高性能计算单元上是需要运行操作系统的，如果完全用裸机程序去控制，几乎无法完成。从下到上，依次可分为以下几个部分，硬件驱动层，操作系统内核，分布式中间件，并行计算中间件，应用及服务。 硬件驱动层(BSP) 在嵌入式软件开发当中，软件工程师经常要直接和硬件进行交互，但是在高性能计算单元上，由于有富操作系统的存在，这部分工作一般由BSP工程师完成。 BSP（Board Support Package）板级支持包，是介于硬件和操作系统中驱动层程序之间的一层，一般认为它属于操作系统一部分，主要是实现对操作系统的支持，为上层的驱动程序提供访问硬件设备寄存器的函数包，不同的操作系统对应于不同形式的BSP，尽管实现的功能一样，可是写法和接口定义是完全不同的，BSP的编程过程大多数是在某一个成型的BSP模板上进行修改，芯片厂商一般会基于其开发板，提供一个可运行的软件基线，开发厂商基于该基线进行修改。 BSP的调试工作是和硬件强相关的，目前普遍会选择由硬件Tier1做掉这部分工作，由于本身的技术壁垒不高，所以有余力的玩家选择自己做也完全不是什么问题。 操作系统内核 在软件定义汽车1-3合集中，我对操作系统的概念做过辨析，为了避免歧义，这里我直接称操作系统内核，很多玩家所谓的做自己的操作系统，其实都只是内核之上的中间件。这部分不是主机厂该做的事情，用QNX、Vxworks、Linux、FreeRTOS等，或者以后的鸿蒙微内核即可。虽然这种不直接面向C端用户的操作系统对应用生态的要求不高，但是对于开发者生态的要求还是挺高的。使用这些操作系统的时候，有几个因素至关重要： POSIX兼容性 工具链 POSIX是一个操作系统的接口标准，如果一个操作系统对于POSIX兼容性好，那么开源世界中的很多软件模块是可以复用的。举一个例子，cocos2dx 是一个开源的游戏引擎，支持windows、Linux、Mac等系统，不支持QNX系统，但是由于QNX系统良好的兼容了POSIX，我们只花了很少的功夫就把其移植到了QNX上，虽然cocos2dx依赖了好几十个开源的软件库，但调用的都是标准的POSIX接口，所以也都能非常方便的进行移植。有些网关开发中会使用FreeRTOS，其也有专门的拓展库来支持POSIX调用。 举一个反面的例子，Halide是一个专用的图像处理引擎，其构建是基于LLVM编译器框架的，由于QNX官方支持的编译器是基于GNU GCC的，我曾经尝试过要把Halide移