2. R-Car硬件平台选型与配置

R-Car Gen3 家族中，H3、M3、V3 是最常被放在同一张选型表里比较的三档 SoC。它们共享 Cortex-A57/A53 大小核架构、IMP-X5 图像识别引擎、H.264/H.265 编解码单元和一套相近的外设控制器，但 CPU 核数、GPU 算力、内存带宽、显示通道数和 PCIe/SATA 资源存在明显阶梯差异。选型的第一步不是看主频，而是先确认产品需要几路摄像头输入、几路显示输出、是否需要独立 GPU 渲染、是否要跑多路 AI 推理，再反推 SoC 档位。

H3 / M3 / V3 的定位差异

R-Car H3 面向高端座舱与域控制器，典型配置为 4×Cortex-A57 + 4×Cortex-A53，GPU 为 PowerVR GX6650，支持 3 路以上显示输出和 8 路以上摄像头输入，内存位宽 128bit LPDDR4，适合多屏互动、环视加 DMS 融合、以及需要较强 GPU 渲染的场景。R-Car M3 定位中端，通常为 2×A57 + 4×A53，GPU 为 GX6250，显示与摄像头通道数略少，适合单屏仪表加中控、或中等规模 ADAS 前视方案。R-Car V3M/V3H 则把算力重心放在视觉流水线，CPU 核数少（多为 2×A53 或 4×A53），但集成 ISP、图像畸变校正、光流和 CNN 加速，适合前视摄像头、环视和低成本感知节点。

选型时可用一张“资源需求—档位匹配”表快速判断：若需要 4 路以上 1080p 显示、独立 GPU 渲染 3D 车模、同时跑 4 路以上 AI 模型，优先 H3；若只需 2 路显示、1～2 路 AI 模型，M3 足够；若核心任务是摄像头图像处理与轻量推理，且对 GPU 渲染要求低，V3 系列更合适。注意 V3 系列部分型号不带 GPU，若 UI 需要 OpenGL ES 渲染，必须提前确认。

SoC 核心模块与内存、存储配置

R-Car Gen3 的 SoC 内部可划分为几个关键域：CPU 域（A57/A53 集群与 L2/L3 缓存）、GPU 域、视频编解码域（VSP/VPU）、图像识别域（IMP-X5）、显示域（DU）、摄像头输入域（VIN/CSI-2）、以及安全域（ICUM、HSM）。这些域通过内部总线互联，内存带宽是共享资源。H3 的 128bit LPDDR4 在 3200Mbps 下理论带宽约 51.2GB/s，M3 若为 64bit 则约 25.6GB/s，V3 更低。多路 4K 解码加 GPU 渲染时，带宽很容易成为瓶颈，因此内存位宽和频率必须与显示、摄像头路数一起核算。

内存配置上，量产板通常采用 LPDDR4 或 LPDDR4X，容量从 2GB 到 8GB。座舱域建议 4GB 起步，若跑多路 AI 和 3D 渲染建议 8GB。存储方面，eMMC 5.1 是主流启动与根文件系统载体，容量 16GB～64GB；若需要高可靠日志或地图数据，可加 UFS 2.1 或 NVMe（通过 PCIe）。启动顺序一般由 MD 引脚和 BootROM 决定，常见为 eMMC → QSPI → SD 卡。QSPI 通常放 bootloader 和紧急恢复镜像，eMMC 放系统与数据分区。

接口资源分配的实际做法

接口分配不是“有就用”，而是要在设备树和引脚复用层面做冲突检查。以 H3 为例，VIN 通道与 CSI-2 输入共享引脚，若同时使用 4 路 CSI-2 摄像头，需要确认 VIN 通道数量、I2C 控制总线地址是否冲突、以及每路摄像头的复位和时钟引脚是否独立。显示侧，DU 输出到 LVDS 和 HDMI 时，要确认像素时钟、色彩格式和 EDID 读取通道。PCIe 控制器通常用于连接 Wi-Fi/BT 模块或 NVMe，若同时使用两个 PCIe 设备，需确认 lane 分配和参考时钟来源。

一个常见的量产配置示例：H3 板卡使用 4GB LPDDR4、32GB eMMC、QSPI 16MB；VIN 分配 4 路 CSI-2 接环视摄像头，1 路接 DMS；DU 输出 2 路 LVDS 给仪表和中控，1 路 HDMI 给后排娱乐；PCIe ×1 接 Wi-Fi 6 模块，USB 3.0 接行车记录仪；CAN-FD 两路接车身与动力。该配置在设备树中需分别声明 vin0～vin4、du0～du2、pcie0、usb0、can0/can1 的引脚组和时钟，避免复用冲突。

内存与存储的配置还要考虑启动可靠性和量产烧录。eMMC 的 boot 分区通常存放 bootloader，QSPI 存放紧急恢复镜像，两者互为备份。若使用 UFS 或 NVMe，需确认 BootROM 是否支持从该介质启动，否则仍需保留 eMMC 或 QSPI 作为启动介质。LPDDR4 的容量和频率需与 SoC 的 DDR 控制器匹配，并在硬件设计阶段完成信号完整性仿真，量产前通过 memtest 和长时间压力测试验证稳定性。

接口资源分配完成后，应在设备树中形成明确的“资源—控制器—引脚—时钟”映射表，并在 Bring-up 阶段逐项验证：摄像头能否出图、显示能否点亮、PCIe 能否枚举、CAN 能否收发。只有这些基础资源全部确认无误，后续的 AI 模型部署和功能开发才有稳定的硬件基础。