2. NVIDIA DRIVE硬件架构与传感器接口
在上一节中我们已经明确：多摄像头与多传感器同步的核心难点，并不只是“让时间戳对齐”，而是要让所有传感器在同一套硬件时钟域、同一套触发链路和同一套数据通路下工作。要做到这一点，必须先理解 NVIDIA DRIVE 平台的硬件架构，以及摄像头、LiDAR、Radar、IMU、GNSS 这些传感器究竟通过什么物理接口接入计算平台。本节围绕 DRIVE AGX/Orin 计算平台、摄像头串行器与解串器链路、GMSL/FPD-Link 接口，以及 LiDAR/Radar/IMU/GNSS 的接入方式展开。
一、DRIVE AGX/Orin 计算平台的基本构成
NVIDIA DRIVE AGX 是面向自动驾驶的车载计算平台系列，Orin 是其中广泛使用的一代 SoC。以 DRIVE AGX Orin 为例，其核心并不是一颗“通用 CPU”，而是由多个计算单元协同工作的异构架构：CPU 集群负责通用逻辑与调度，GPU 负责深度神经网络推理与图像处理，深度学习加速器 DLA 承担固定网络的高能效推理，可编程视觉加速器 PVA 处理传统视觉与图像预处理任务，此外还有专门的 ISP（图像信号处理器）用于摄像头原始数据的去马赛克、降噪、色彩校正等处理。
对同步系统而言，比算力更关键的是平台上的时间与触发资源。DRIVE AGX Orin 内部维护一个高精度系统时钟，通常以 PTP（精确时间协议）硬件时间戳或 SoC 内部计时器为基准。所有传感器采集到的时间戳，最终都要能映射到这个统一时钟域。平台还提供多路通用输入输出（GPIO）、PWM 输出、外部触发输入以及同步信号接口，用于向摄像头、LiDAR 等设备发送帧同步（FSYNC）或曝光触发信号。换句话说，Orin 不只是“接收数据”，它还要“发出节拍”。
在数据接入侧，DRIVE AGX Orin 通常通过 MIPI CSI-2 接口接收来自解串器（Deserializer）的图像数据。CSI-2 是 SoC 侧的图像输入标准，而车外长距离传输则依赖 GMSL 或 FPD-Link。理解“串行器—线缆—解串器—CSI-2—SoC”这条链路，是理解摄像头同步的基础。
二、摄像头串行器与解串器链路
车载摄像头通常由图像传感器（Image Sensor）、串行器（Serializer）和同轴线缆组成。图像传感器输出的是并行或 MIPI 信号，串行器把它转换成适合长距离同轴电缆传输的高速串行信号。到了计算平台一侧，解串器（Deserializer）再把串行信号还原为 MIPI CSI-2，送入 Orin 的 CSI 接口。常见的串行器/解串器芯片来自 Maxim（现属 Analog Devices）的 GMSL 系列和 TI 的 FPD-Link 系列。
这条链路对同步的意义在于：触发信号和时钟信息必须能够穿过串行器与解串器。许多串行器支持“反向通道”（Back Channel），解串器可以通过同轴线缆向摄像头端发送控制命令和同步脉冲。例如，Orin 侧产生一个 30 Hz 的帧同步信号，经解串器编码后通过反向通道传到串行器，串行器再触发图像传感器开始曝光。这样，多颗摄像头就能在同一时刻开始曝光，而不是各自按内部晶振自由运行。
实际工程中，一个解串器往往有 4 路或 8 路输入，可以同时连接多颗摄像头。例如 Maxim MAX9296 是常见的双路 GMSL2 解串器，MAX9295 是配套串行器。假设我们使用 4 颗 1920×1080、30 fps 的摄像头，每颗通过 GMSL2 接入一片 MAX9296，两片解串器再通过 MIPI CSI-2 接入 Orin。此时，同步设计需要确认：两片解串器是否共享同一个外部参考时钟？触发信号是分别发送还是级联发送？如果两片解串器各自使用独立晶振，即使都收到 30 Hz 触发，帧起始时刻仍可能存在微秒级漂移。
三、GMSL 与 FPD-Link 接口对比
GMSL（Gigabit Multimedia Serial Link）和 FPD-Link 都是车载高速串行链路标准，目标相似，但在速率、反向通道能力、芯片生态和配置方式上存在差异。GMSL2 常见速率可达 3 Gbps 或 6 Gbps，支持同轴或屏蔽双绞线，反向通道可用于 I2C 控制、GPIO 传输和同步脉冲。FPD-Link III 同样支持同轴供电（PoC）和双向通信，在 TI 生态中与 DS90UB 系列解串器配合广泛。
选择哪一种，往往取决于摄像头模组、线缆长度、EMC 要求和平台已有驱动支持。对同步系统来说，关键不是“哪个更快”，而是：该链路是否支持确定性触发传输、是否支持多路解串器共享时钟、是否能在驱动层读取到硬件时间戳。如果链路只传图像不传触发，那么同步就只能依赖软件时间戳，精度会明显下降。
四、LiDAR、Radar、IMU、GNSS 的接入方式
与摄像头不同，LiDAR、Radar、IMU 和 GNSS 的接入方式更加多样，但它们最终都要汇入同一个时间基准。
LiDAR 通常通过以太网接入，部分机械式或早期型号使用串口。以太网 LiDAR 一般支持 PTP（IEEE 1588）或 gPTP，可以与 Orin 的 PTP 硬件时钟同步。如果 LiDAR 支持 PTP，那么它的每个点云帧都可以带上与 Orin 同一时间域的时间戳；如果不支持，则需要 Orin 通过 PPS 或外部触发向 LiDAR 发送同步信号，并在驱动层记录到达时间。实际配置中，常见做法是让 Orin 作为 PTP 主时钟，LiDAR 作为从时钟，同时用 PPS 做秒对齐。
Radar 多通过 CAN FD 或以太网接入。CAN 帧本身带有时间戳，但 CAN 控制器的时间戳精度取决于控制器时钟。若 Radar 支持以太网，则优先走 PTP；若只支持 CAN，则需要在 Orin 侧用 CAN 控制器的时间戳寄存器记录接收时刻，并与系统时钟做偏移校准。Radar 的帧率通常低于摄像头，例如 20 Hz，因此同步重点在于“帧起始时刻对齐”，而不是逐点对齐。
IMU 通常通过 SPI 或 UART 接入，采样率可达 100 Hz 甚至 1 kHz。IMU 的同步难点在于：它往往没有外部触发输入，只能自由运行。此时，Orin 需要在读取 IMU 数据时，同时读取系统时钟，形成“采样时刻—系统时间”的映射。如果 IMU 支持数据就绪中断（DRDY），可以用 GPIO 捕获中断时刻，提高时间戳精度。
GNSS 则通过 UART 输出 NMEA 语句，同时提供 PPS 秒脉冲。PPS 是 GNSS 接入中最有价值的同步资源：它每秒产生一个上升沿，精度可达纳秒级。Orin 可以用 GPIO 捕获 PPS 上升沿，将系统时钟与 UTC 秒对齐。这样，即使 GNSS 的 NMEA 语句有延迟，PPS 仍能提供高精度秒边界。实际系统中，常把 PPS 作为全局时间基准，再通过 PTP 分发给 LiDAR 和摄像头。
五、同步设计的检查要点
综合来看，DRIVE AGX Orin 的传感器接入并不是“插上线就能同步”。在硬件架构层面，需要确认以下几点：第一，所有摄像头是否共享同一个参考时钟，或者至少共享同一个触发源；第二，解串器是否支持反向通道触发，触发延迟是否可测；第三，LiDAR 和 Radar 是否支持 PTP 或 PPS，若不支持，是否有替代的硬件触发；第四，IMU 和 GNSS 的时间戳如何映射到 Orin 系统时钟；第五，Orin 的 PTP 硬件时钟是否已启用，并与 GNSS PPS 完成对齐。
这些检查点直接决定了后续软件同步层的精度上限。如果硬件链路本身存在独立晶振、触发延迟不可控或时间戳不可读，那么再复杂的软件算法也只能做“事后估计”，而无法实现确定性同步。因此，理解本节所述的硬件架构与接口，是后续进行时间同步配置、驱动调试和误差分析的前提。