2. EyeQ 软硬件架构与验证接口

EyeQ 系列是 Mobileye 面向 ADAS 与自动驾驶的 SoC 家族，从早期 EyeQ2 到 EyeQ6，其演进主线始终围绕“在有限功耗下提升视觉感知吞吐”。理解这一主线，是理解回归验证接口的前提：验证工程师面对的不是一台通用计算机，而是一套由固定功能加速器、可编程核、多路摄像头输入和确定性数据通路组成的嵌入式视觉平台。

算力与传感器配置：从 EyeQ4 到 EyeQ6

EyeQ4 是许多量产 ADAS 项目的基线平台，典型算力约 2.5 TOPS（INT8 等效，示例量级），内部集成多核 MIPS CPU、多个 VMP（Vector Microcode Processor）视觉加速器和专用 CNN 加速单元，可同时接入前视单目/三目、侧后视等多路摄像头，常见配置为 1 路前视 + 4 路环视或 3 路前视。EyeQ5 将算力提升到约 24 TOPS 量级，采用 7nm 工艺，配备 8 个 MIPS I6500-F 核与多组 VMP、PMA（Programmable Macro Array）和 CNN 加速器，支持最多 8 路以上高分辨率摄像头输入，并引入 PCIe、千兆以太网等更通用的主机接口。EyeQ6 进一步面向高阶智驾，算力与内存带宽继续提升，摄像头路数和分辨率支持更强，同时保持车规功耗与功能安全约束。

对验证而言，关键不是记住 TOPS 数字，而是理解“算力—传感器—内存带宽”三者的匹配关系。例如，当回归用例把前视分辨率从 1280×960 提升到 1920×1080、帧率从 30fps 提升到 60fps 时，输入数据率约变为原来的 2.25 倍，若同时增加一路侧视，感知模块的 VMP 与 CNN 负载会显著上升，端到端延迟可能超出实时预算。因此回归场景库中必须显式记录传感器配置，否则同一算法版本在不同配置下会得到不可比的结果。

EyeQ 软件栈与 API 分层

EyeQ 软件栈自上而下大致分为：应用层（ADAS/AD 功能）、Mobileye 感知与规控中间件、EyeQ SDK 与运行时、驱动与固件、硬件。对回归验证最直接相关的是 SDK 暴露的接口层。典型 API 包括：

• 摄像头与图像接口：用于配置输入通道、分辨率、帧率、曝光与触发模式，并获取带时间戳的帧数据。
• 感知结果接口：输出目标列表（车辆、行人、车道线、交通标志、可行驶区域等），每个目标带 ID、位置、速度、置信度和生命周期状态。
• 诊断与状态接口：读取各处理单元的运行状态、温度、负载、丢帧计数和错误码。
• 记录与回放接口：将原始帧、感知结果和内部事件按时间对齐写入日志，供离线回归复现。

这些接口在回归中的价值在于“可复现”。如果只记录最终输出而不记录输入帧与配置，一旦结果异常，就无法判断是算法问题、配置问题还是数据问题。因此工程上通常要求日志同时包含输入、配置、输出和状态四类信息。

回归验证可用的数据接口与日志格式

EyeQ 回归验证常用的数据来源有三类：实车采集的原始视频与 CAN/以太网数据、仿真注入的合成场景、以及历史回归产生的日志回放。数据接口通常以文件或流的形式提供，常见格式包括：

日志格式设计上，最重要的是时间基准统一。EyeQ 内部各处理单元可能使用不同的时钟域，回归工具需要把图像时间戳、感知输出时间戳和总线时间戳对齐到同一时间轴，通常以摄像头帧的 SOF（Start of Frame）为基准。若时间戳偏差超过半帧，目标关联就可能错位，导致误报“目标丢失”。

软硬件协同的验证视角

把上述内容放在一起看，EyeQ 回归验证的接口关系可以概括为：传感器配置决定输入数据率，软件栈 API 决定可观测的输出与状态，日志格式决定这些信息能否被离线复现和比对。下图给出这一关系的结构化表达，帮助在搭建回归链路时快速定位每一层需要采集什么、比对什么。

实际执行回归时，可以按以下顺序检查：先确认输入帧序列与基准一致，再确认感知输出在容差范围内，最后检查系统状态是否出现丢帧或延迟突增。若输入一致而输出偏差大，优先怀疑算法或配置变更；若输入本身就不一致，则先修复数据采集与回放链路。把这三类比对维度分开记录，能显著缩短问题定位时间。