2. EyeQ硬件与软件栈概览

Mobileye EyeQ 系列是典型的车规级视觉 SoC，其设计目标不是追求通用算力峰值，而是在极低功耗、极小封装和严格功能安全约束下，稳定承载多路摄像头输入与深度神经网络推理。理解 EyeQ 的硬件与软件栈，是后续讨论车道线检测、可行驶区分割等感知任务部署方式的前提。本节从芯片架构、计算资源约束、图像输入链路、感知任务部署方式四个层面展开，并落到车道线与可行驶区功能在嵌入式平台上的工程约束。

一、EyeQ 系列芯片架构与代际特征

EyeQ 采用异构多核架构，而非单一 CPU 或 GPU 方案。以 EyeQ4 为例，其内部通常包含多个 MIPS 系列 CPU 核负责控制流与任务调度，多个 VMP（Vector Microcode Processor）负责向量化图像预处理与特征计算，以及专用的深度神经网络加速器（如 PMA、PMA2 等）承担卷积、池化等算子。EyeQ5 进一步引入更通用的加速单元与更高带宽的内存子系统，EyeQ6 系列则强化了多芯片级联与更高分辨率输入能力。代际演进的核心逻辑是：在功耗基本可控的前提下，提升每瓦可用的 MAC 吞吐与内存带宽。

这种异构结构决定了软件栈必须显式地把任务映射到合适的计算单元。CPU 适合分支密集、控制复杂的逻辑；VMP 适合像素级、规则化的图像运算；专用加速器适合结构固定的卷积网络。若把本应放在加速器上的卷积强行放到 CPU 上，实时性会迅速崩塌。

二、计算资源约束的实际含义

EyeQ 的算力约束不能只看 TOPS 数字。真正决定车道线与可行驶区能否稳定运行的是三个量：每帧可用的 MAC 预算、可用内存带宽、以及可接受的端到端延迟。假设某前视摄像头输出 1280×960、30 fps，若车道线分割网络在 1/4 分辨率（320×240）上推理，单帧约 7.7 万像素；若网络在该分辨率下需要约 1.2 GMAC，则 30 fps 对应约 36 GMAC/s 的持续吞吐。这只是一个示例量级，实际值取决于网络结构、量化方式和加速器利用率，但它说明：模型规模必须与芯片持续吞吐匹配，而不是与峰值算力匹配。

带宽同样关键。多路摄像头同时输入时，ISP 输出、LDC 校正、网络输入张量、中间特征图和最终输出都会占用内存带宽。工程上常见的做法是让预处理尽量在 VMP 上完成并直接写入加速器可读的紧凑格式，减少 CPU 参与的数据搬运；同时把车道线与可行驶区网络共享同一份浅层特征，避免重复计算。

三、图像输入链路与感知任务部署方式

典型链路为：摄像头经 MIPI CSI-2 进入 EyeQ，ISP 完成去马赛克、自动曝光与降噪，LDC 模块按标定参数做畸变校正，输出 YUV 或 RAW 帧到帧缓冲。感知任务从帧缓冲取图，经 VMP 做归一化、缩放、ROI 裁剪后送入 DNN 加速器。车道线检测通常输出像素级或锚点级结果，再经 CPU 上的曲线拟合与跟踪滤波；可行驶区分割输出逐像素类别，经后处理得到边界与置信度。

部署方式上，Mobileye 的软件栈通常以“网络图 + 算子库”的形式组织：每个感知网络被编译为加速器可执行的指令序列，CPU 负责任务调度、时间戳对齐和结果融合。开发者需要关注的是输入张量布局、量化尺度、以及每帧的调度优先级，而不是直接写 CUDA 式代码。

四、工程约束下的实践要点

在嵌入式平台上做车道线与可行驶区，建议遵循以下可执行原则：第一，先确定延迟预算，再反推模型复杂度，而不是先选大模型再压缩；第二，输入分辨率与 ROI 要按最远有效检测距离设计，例如要求 60 m 处仍能分辨车道线，则需根据相机焦距与像素角分辨率核算最小像素宽度；第三，量化校准集必须覆盖夜间、逆光、雨雾等场景，否则 INT8 量化后置信度分布会偏移；第四，后处理中的曲线拟合与形态学操作要放在 CPU 上并限制迭代次数，避免拖累帧率。