2. R-Car硬件架构与AI加速单元

R-Car V3H 与 V4H 属于瑞萨面向 ADAS/自动驾驶的 R-Car V 系列 SoC，其设计目标不是“通用高性能计算”，而是把摄像头输入、图像预处理、深度学习推理、后处理与安全输出压缩在一条低延迟、可预测的流水线里。理解这套硬件，关键不是记住某个核的主频，而是看清“谁负责什么、数据怎么走、瓶颈通常出现在哪里”。

一、异构计算资源的分工

R-Car V3H/V4H 内部是典型的异构架构，主要计算资源可以按职责划分：

• CPU（Cortex-A 系列 + 锁步 Cortex-R 系列）：A 核运行 Linux/QNX 等富操作系统，负责调度、网络、诊断、应用逻辑；R 核运行实时操作系统，承担安全监控、看门狗、功能安全路径。CPU 不擅长高吞吐卷积，但负责“决策与协调”。
• GPU（PowerVR 系列）：主要用于图形渲染、部分通用并行计算和可视化，也可承担少量非卷积算子，但功耗与实时性不如专用 NPU。
• NPU / CNN 加速器（如 V3H 的 CNN-IP、V4H 的 CNN 加速单元）：这是推理的主力，针对卷积、池化、激活等算子做定点（INT8/INT16）流水化，能效比远高于 CPU/GPU。
• ISP（图像信号处理器）：直接接收 MIPI CSI-2 摄像头原始 Bayer 数据，完成去马赛克、白平衡、降噪、色调映射、畸变校正等，输出 YUV/RGB 给下游。
• DSP / 视觉加速器（如 IMP-X5、图像处理单元）：承担光流、特征点、立体匹配、传统 CV 算子等，常与 NPU 形成“传统视觉 + 深度学习”互补。

这种分工意味着：一个典型感知任务会被拆成“ISP 预处理 → DSP/视觉加速器做几何与特征 → NPU 做检测/分割 → CPU 做后处理与融合”。任何一段过慢，整条链路都会被拖住。

二、内存与总线结构

V3H/V4H 采用统一外部内存（LPDDR4/LPDDR4X），各计算单元通过片上互连访问。理解总线要抓住三点：

• 带宽是共享资源：ISP 写回、NPU 读权重/特征图、GPU 取纹理、CPU 访问数据都走同一内存控制器。多路摄像头同时工作时，带宽竞争会直接抬高推理延迟。
• 局部缓存决定效率：NPU 内部有片上 SRAM/缓存，用于暂存特征图和权重。若模型分块（tiling）不合理，会频繁回读外部内存，算力利用率骤降。
• 数据搬运本身有成本：从 ISP 输出到 NPU 输入，若经过多次格式转换（如 YUV→RGB→NCHW），会额外消耗带宽与 CPU 时间。工程上应尽量让 ISP 直接输出推理所需的格式与分辨率。

三、面向推理的算力特性

评估 V3H/V4H 的推理能力，不能只看 TOPS 标称值，要结合以下特性：

• 定点优先：NPU 对 INT8 有最高吞吐，INT16 次之，FP16/FP32 往往由 GPU 或 CPU 承担且效率低。因此模型量化是部署前的必要步骤。
• 算子支持有边界：卷积、深度可分离卷积、池化、常见激活支持好；自定义算子、动态 shape、复杂控制流可能回退到 CPU，造成性能断崖。
• 批处理与分辨率敏感：NPU 对 batch 和输入分辨率敏感。增大分辨率会同时增加计算量和内存占用，需在精度与延迟间权衡。
• 实时性与确定性：车载场景要求稳定帧率与可预测延迟，因此要避免频繁的动态内存分配和 CPU 与 NPU 之间的同步等待。

下面这张图把 V3H/V4H 的主要单元、数据流向与共享内存/总线关系放在一起，便于对照理解“谁产生数据、谁消费数据、瓶颈可能在哪”。

四、工程上的算力评估与调优方向

在实际项目中，建议按以下顺序定位问题：先确认 ISP 输出格式与分辨率是否与模型输入匹配，避免无谓的缩放与色彩转换；再检查模型是否已量化到 INT8，并确认所有算子都被 NPU 支持；然后观察多路摄像头并发时的带宽占用，必要时降低非关键路的分辨率或帧率；最后才考虑调整模型结构或更换 SoC 型号。

需要强调的是，V3H 与 V4H 的定位不同：V3H 更适合中等算力、成本敏感的 ADAS 前视/环视方案；V4H 面向更高算力、多传感器融合的域控制器场景。选型时应以“目标模型在目标分辨率下的实测延迟与功耗”为准，而不是单纯比较 TOPS 数字。