英伟达DriveAGX Thor DevKit平台分析，瞄准舱驾一体

与Orin一样，英伟达也在本月初推出了DriveAGX Thor DevKit平台。

图片来源：英伟达

当然，有些大厂在2024年初就拿到了DriveAGX Thor DevKit平台。

除了完善的软件支持外，还有一系列外围元件厂家支持。

DriveAGX Thor DevKit的盒子大小和Orin基本没差别，高和宽略大了0.3厘米，重量多了0.6公斤。内存容量还是64GB，不过Jetson AGX Thor Developer Kit和T5000是128GB，大模型时代，应该还是128GB比较合适，应该还有128GB版本；存储方面，不再使用Orin那老旧的64GB的eMMC，改用UFS，64 MB NOR Boot Flash和8 MB NOR Secure Key Flash或许还会沿用，Jetson AGX Thor Developer Kit则使用更先进更大容量的1 TB NVMe M.2 Key，显然英伟达对具身智能领域更关注，认为其市场更大。

软件SKU分两种，一种是实验室内机台测试用的SKU10，一种是在样车上开发用的SKU12。

DriveAGX Orin DevKit的背板，差别很大。最大的不同是显示方面，Orin只有一个DP显示输出，Thor多了两组4接口GMSL3显示输出，最多可以连接8块屏幕，加上DP接口，可以连接9块屏幕，显然这是为座舱考虑的。

其次是以太网方面，低端的仅仅支持100M的泰科的MATEnet连接器全部取消，RJ45接口的两个千兆和万兆连接器也全部取消，以太网连接器全部换成罗森伯格的H-MTD 连接器，这是一个360°全屏蔽差分连接器系统。该系统结合了高性能数据传输(最高可至20 GHz或28 Gbps)和高强度小体积的汽车级塑壳。

再有就是PCIe上方两个4线同轴接口，英伟达暂时未透露是做何用途，推测是各种射频、无线接口，包括收音的AM/FM、DAB，蓝牙和WiFi，4G/5G，GPS，都是为座舱领域准备的。摄像头输入方面，Thor支持最多20个摄像头输入，比Orin多4个，连接器也从MATE-AX换成了四Fakra接口，并且也全部升级到GMSL2/3。不要小瞧了看似技术含量不高的连接器，其价格比绝大多数供电类芯片还要昂贵，利润也跟芯片差不多。

显示输出方面使用两颗ADI的加串行芯片，一片是MAX96851，另一片是MAX96861，两者都是GMSL3产品，比较先进。都是4 lane的DP输出，支持菊花链，支持DP音频。MAX96851支持4路MST，支持非对称显示，MAX96861支持2路MST，不支持非对称显示。

图片来源：ADI

MAX96861支持DSC压缩，MAX96851不支持。

摄像头方面，英伟达使用5片ADI的解串器芯片，分别是3片MAX96724，1片MAX96712，1片MAX96792，其中MAX96712是早期产品，传输采用像素模式，主要做360环视，一般支持4个200万像素。MAX96724是升级产品，传输采用隧道模式，隧道(tunnel)模式主要应用于车载 ADAS 系统中，其对数据完整性和安全性有着极强的要求。来自 MIPI 接口的各种数据不是在串行器处解包，而是以 GMSL2 协议分割、封装成更小的数据包再从串行器发出。这使得解串器可以验证视频源端的原始 CRC 协议，从而保证串行器输入和解串器输出处的数据相同。其带宽效率更高，满足对于数据完整性有极高要求的应用。在隧道模式下，由于整个 CSI-2数据包结构会被原样转发而不做修改，因此链路两端必须保持一致的原始 PHY 类型（D-PHY 或 C-PHY）。这可能会构成一个难点，尤其是在合并多个超出 D-PHY 限制的视频流时。不过， MAX96724能够在隧道模式下实现 D-PHY 到 C-PHY 的转换，同时保持数据完整性。目前ADAS的侧视基本都是MAX96724，市场占有率超过90%。

MAX96792是ADI旗舰级产品，属于GMSL3，前向传输速率12Gbps。

MAX96792最高支持1500万像素，主要做前视双800万像素输入。

以太网方面，英伟达目前没有透露以太网物理层和交换机的型号。从接口推测，有20个以太网接口，最高支持万兆级端口，但不可能都是万兆级，按一半算至少要有10个万兆级端口，显然须要两片以太网交换机，因此目前车规级以太网交换机最高支持6路万兆级端口，这样的芯片屈指可数，一是博通的BCM8958X系列，二是已经被英飞凌收购的Marvell的Q6223，Q6223的总交换带宽高达90Gbps，博通的BCM8958X是55Gbps，上一代的Orin也是选用的Marvell的产品，大概率英伟达会选择两片Q6223。

Q6223是12路以太网交换机，支持TSN核心协议，包括802.1AS-2020， 802.1Qat / Qav / Qbu / Qbv / Qci / Qcr，和 802.1CB。

最后是MCU，Orin使用了英飞凌的TC397，Thor改用瑞萨的U2A16，之所以改用U2A16，主要原因推测是U2A16对虚拟机支持度更高，更适合跨域应用，也就是ZCU。

ECU的软件来自多个利益相关者方，包括OEM（应用层），Tier-1（中间件和集成），Tier-2（芯片厂家的抽象层MCAL）和第三方（如Autosar BSW、OS、安全固件）。这一组利益相关者的软件集成到一个ECU之内在今天已经成为一项重要的工程任务。很难想象同样的方法将扩展到未来的ZCU。原因有多个，谁来负责集成来自多个供应商的应用层？当ECU发生故障时，谁负责？如何在多应用的ECU系统中确保系统安全隔离？各方如何保护知识产权？谁来执行根本原因分析和调试？最后，需要大量的努力来重新测试整个ECU，即使当一个小的软件组件发生变化时。

解决这些挑战的一个办法是基于Hypervisor的软件概念，将一个物理ECU扩展为多个虚拟ECU。用AUTOSAR的话说，这里的每个虚拟ECU是一个独立的ECU，有自己的EcuExtract，通过COM和虚拟网络与其他虚拟ECU进行通信。这种解决方案允许每个虚拟ECU通过松耦合的方式结合到一个物理ECU中。每个虚拟机（VM）可以单独编译和链接，并有自己的运行时环境（RTE）。一个RTE配置的变化并不会引起整个系统的软件被重新构建。此外，这些虚拟机有完全的对处理器硬件访问权。而且，对一个虚拟机的改变不一定需要对整个系统进行重新测试，一个虚拟机可以独立于整个系统重新启动，这有助于最大限度地减少同一ECU上其他不相关功能的停机时间。

博世旗下ETAS的Hypervisor RTA-HVR支持Renesas RH 850/U2x，以满足严格的汽车功能安全和信息安全要求。RTA-HVR使用瑞萨RH 850/U2x系列的硬件虚拟化功能来创建多个虚拟机。每个虚拟机都有一个或多个虚拟CPU核、一段内存空间和一组外设。

每个VM是一个独立的可编译和可刷新的ECU软件，可以由第三方构建并交付。RTA-HVR支持Autosar Classic平台，并灵活地将物理CPU核分配给虚拟机。如果一个虚拟机对一个或多个CPU核有唯一的访问权，那么虚拟机之间就没有调度开销。如果多个虚拟机共享一个CPU核，可以应用静态配置的轮流调度或由RH 850/U2x后台中断驱动的动态预约式调度。

RTA-HVR使用MPU和保护概念在虚拟机之间提供空间隔离，为每个虚拟机划分内存和外设空间。此外，RTA-HVR提供了一种称为虚拟设备扩展（VDE）的机制，允许ECU集成商为ZCU定制虚拟和物理外设之间的绑定。VDE提供了一种在虚拟机之间共享外设的安全方式，例如，当需要一个外设的虚拟机数量超过硬件中的物理外设数量时。这里的典型例子是以太网控制器、硬件安全模块和看门狗，或带有额外CAN通道的扩展。

虽然英伟达竭力向舱驾一体靠拢，但安卓系统不是英伟达的强项，大部分厂家还是将英伟达定位于智能驾驶。未来，舱驾一体主要应该还是中低端市场，中高端市场还是舱驾分离。

免责说明：本文观点和数据仅供参考，和实际情况可能存在偏差。本文不构成投资建议，文中所有观点、数据仅代表笔者立场，不具有任何指导、投资和决策意见。