多摄像头远程采集实战：Crosslink-NX与GMSL2架构详解

1. 为什么多摄像头远程采集场景会用到Crosslink-NX和GMSL2

做过多路视觉采集的朋友应该都有体会：摄像头一多，问题就不是"拧螺丝"那么简单了。PCB走线长度、EMI辐射、接口带宽、帧同步、线束成本、连接器可靠性，每一项都能把项目拖进泥潭。尤其是在车载环视、自动驾驶域控、工业检测设备这类需要把多个摄像头信号汇聚到一颗主处理SoC的场景里，方案选型往往直接决定整个项目的成败。

我第一次接触Crosslink-NX，是被它的MIPI D-PHY通道数量吸引的。Lattice这颗芯片最多支持多少路MIPI RX/TX，熟悉FPGA的人应该心里有数——在同类低功耗FPGA里，它的MIPI接口资源算是相当能打的一档。单颗Crosslink-NX可以同时接收多路MIPI CSI-2摄像头信号，然后做数据聚合，再通过MIPI TX口输出给主SoC。这样主处理器只需要用一个CSI口就能拿到多路摄像头数据，省掉的不只是接口资源，还有主芯片侧的软件复杂度。

但这里有个工程上的现实问题：摄像头模组和主处理器之间往往不是近在咫尺。典型场景比如卡车牵引挂车、工程机械臂末端视觉、智能座舱的驾驶员监控摄像头，传感器常常要放在好几米甚至十几米外。MIPI CSI-2的传输距离大家都懂，PCB上走个十几厘米都费劲，线缆一长就是一场噩梦。这时候就必须引入串行传输方案。GMSL2就是目前业界用得最多的高速串行链路标准之一，单条同轴电缆或者屏蔽双绞线就能把MIPI信号、I2C控制信号、GPIO甚至供电全部打在一起，传输距离做到10米以上非常轻松。

这个连载第15篇我想专门把"多摄像头采集、聚合和GMSL2远程传输"这条链路完整拆一遍。前半部分讲清楚Crosslink-NX在系统里到底负责哪几件事，后半部分给出一个可参考的架构设计思路和几个容易被忽略的工程细节。这篇的内容适合正在选型或者已经在做多路视觉采集方案的硬件工程师、FPGA逻辑工程师，以及被"摄像头信号传不远"折磨过的系统集成人员。

2. GMSL2链路的底层机制与选型逻辑

2.1 GMSL2到底是什么，它解决的核心痛点

GMSL2全称是Gigabit Multimedia Serial Link，第二代版本，由Maxim（现在并入ADI）主推。它本质上是一条高速串行链路，专门为车规级视频传输设计。第一代GMSL跑的是并行LVDS或者MIPI信号转换，第二代GMSL2直接把MIPI CSI-2协议封装进高速串行数据流里，同时还能在反向通道上传I2C控制信号。

如果对GMSL2没什么概念，可以把它想象成一条"视频+控制+供电"的三合一高速公路。正向通道承载视频数据，反向通道是低速控制通道，跑I2C，用来配置摄像头寄存器或者读取传感器状态，PoC供电则直接在线上叠加直流电源，给远端摄像头模组供电。这样远端节点只需要一根同轴电缆接到中心节点，不需要单独拉电源线、控制线和数据线，线束成本和连接器数量直线下降。

在GMSL2的方案里，远端摄像头模组一般会配一颗串行器（Serializer），中心节点配一颗解串器（Deserializer）。串行器把MIPI CSI-2的差分数据线转换成一个高速串行流，通过同轴线传给解串器，解串器再把串行流还原成MIPI CSI-2送给后端的采集芯片，也就是Crosslink-NX这类FPGA。链路是双向的，但工作模式非对称：视频走正向，控制走反向，带宽分配非常合理。

2.2 3Gbps链路带宽和UBW字对齐机制

GMSL2单条链路的有效带宽是3Gbps，这个带宽到底能装下多少路视频，是必须细算的问题。以一颗800万像素的传感器跑30fps为例，RAW10格式的裸数据量大约是 800万10bit30 = 2.4Gbps，再算上MIPI协议的包头包尾开销，实际上已经把3Gbps链路顶到接近极限了。所以GMSL2典型用法是每路摄像头占用一条独立链路，每条链路只承载一路视频流。

但如果摄像头分辨率低一些，比如200万像素的RAW8格式跑30fps，裸数据量大约为 200万830 = 480Mbps，这时候一条3Gbps的链路上其实是可以塞下多路视频流的。具体能不能塞，取决于配套解串器是否支持视频流聚合，以及前端FPGA如何做多路流的时分复用。这个点后面会展开说。

GMSL2还有一个值得注意的底层机制叫UBW，即Universal Background Word。简单理解，它是一种特殊的链路控制字，用来对齐和标记数据流。串行器在空闲的时候持续发送UBW，解串器靠识别UBW来建立帧同步。调试GMSL2链路的时候如果发现视频流时断时续，多半就是UBW检测出了问题，比如线缆屏蔽层接地不好、连接器松动、PoC供电纹波过大。这几个方向优先排查，比盲目改寄存器高效得多。

2.3 为什么选GMSL2而不是MIPI直接延长或A-PHY

刚接触远程摄像头方案的人常会问一个问题：既然Crosslink-NX能采集MIPI信号，为什么不直接用MIPI线把摄像头拉远一点，非要多花两颗芯片做串行和解串？

这个问题的答案在现场工程里非常明确。MIPI CSI-2是源同步差分接口，信号质量严重依赖线缆阻抗和PCB走线长度，一般超过30厘米就开始出现眼图闭合的风险。就算用很好的屏蔽线硬拉到1米，EMI表现也会很差，更过不了车规级的辐射发射测试。GMSL2把高速信号转成单端同轴传输，线缆本身的寄生参数影响小得多，传输距离和抗干扰能力完全是另一个量级。

GMSL2的竞争替代方案主要是A-PHY和FPD-Link。FPD-Link是TI自家的串行链路体系，在车载领域也有大量装机。A-PHY则是标准组织推动的物理层规范，口号是更开放的生态。三者在功能上高度相似，选了哪家基本就等于定了对应厂商的串行器/解串器芯片生态。对很多团队来说，选择GMSL2的理由并不复杂：ADI的解串器能和Crosslink-NX直接对接的参考设计最多，资料齐全，MIPI输出侧的兼容性问题少。做产品选型不要太迷信参数表，周围能抄的作业多不多，才是真正的隐性成本。

3. 硬件系统框架：摄像头端到主处理器的完整数据路径

3.1 Crosslink-NX在系统中的三个角色

把一套GMSL2多摄像头采集系统拆开看，Crosslink-NX不是一个被动的"中转站"，而是承担了三个关键角色：MIPI接收、数据聚合、以及GMSL2解串器侧的协议适配。

最典型的架构是这样的：多路摄像头模组各自带一颗GMSL2串行器，通过同轴电缆连到中心板。中心板上有对应数量的GMSL2解串器，把远端传来的串行信号还原成MIPI CSI-2，每个解串器的MIPI输出接到Crosslink-NX的MIPI RX lane上。Crosslink-NX在内部完成多路视频流的接收、对齐、交织或者拼接，最后从MIPI TX口输出一路聚合后的CSI-2流给主SoC。

这个过程里有几个容易踩坑的点。第一是MIPI lane的分配：每个解串器的MIPI输出是4 lane还是2 lane，取决于摄像头分辨率和带宽需求，而Crosslink-NX的MIPI RX端口的lane数量是固定的，分配不好就会导致某些端口带宽不够。第二是时钟域：每个解串器的输出像素时钟来自各自的远端传感器，即使两个摄像头型号一样，像素时钟也不可能完全同频，必须靠FPGA内部做跨时钟域处理。第三是数据交织格式：聚合输出可以做成virtual channel方式，在一条CSI-2流里用VC区分不同摄像头，也可以做成视频拼接方式，把多路图拼成一整幅大图。这两种方式对应的FPGA内部逻辑完全不同。

3.2 摄像头模组端设计：串行器和PoC供电

摄像头端的硬件设计相对简单，但简简单单三颗芯片（Sensor、串行器、电源）里也藏着不少讲究。以ADI的MAX96717为例，常见搭配是一颗MIPI CSI-2接口的传感器，传感器输出4 lane MIPI接到MAX96717的输入侧，MAX96717把信号转成GMSL2单线串行输出。MAX96717还能通过I2C给传感器供控制通道，链路由中心侧的MAX96712或者MAX96714统一管理。

PoC供电的电路设计是很多团队第一次做GMSL2板卡时最容易踩坑的地方。PoC的意思是Power over Coax，视频信号和直流电源共用一根同轴线。接收端往同轴线注入直流电压，发送端从同轴线提取直流电压给自己和传感器供电。问题在于：同轴线上既要走几V的直流电源，又要走最高3Gbps的高速信号，电源和信号之间的隔离就全靠PoC电感和电容网络。这个网络的截止频率、谐振点、寄生参数都会影响最终的眼图质量。电感选得太大，电源纹波抑制好但高速信号被衰减；选得太小，信号是好走了，但电源噪声直接串进链路。这块电路设计建议直接参考ADI的评估板原理图，不要自己凭空发挥。

3.3 中心板端设计：解串器和Crosslink-NX的连接

中心端的硬件设计思路是把多路GMSL2链路先解串成MIPI，再汇入Crosslink-NX。以4路摄像头为例，可以使用两颗MAX96712，每颗支持4路GMSL2输入或者2路输入加2路输出。MAX96712的输出侧可以通过配置把多路输入流复用成一路MIPI输出，也可以让每路输入独立对应一路MIPI输出。采用哪种方式，要看Crosslink-NX的资源占用和系统复杂度。

从我的实际经验来看，推荐的方式是让每路解串器输出独立的MIPI接口，接到Crosslink-NX的不同RX端口上。这样做的好处是每个RX端口的MIPI lane可以独立配置，时序约束也简单清晰，逻辑设计上不用去解析解串器内部的复用格式。因为不同传感器的时序参数不可能完全一样，在Crosslink-NX内部做对齐，远比依赖解串器的复用机制更可控。

Crosslink-NX和主SoC之间的连接，常见方案是MIPI CSI-2输出。如果主SoC支持CSI-2接收，直接接4 lane就能得到聚合后的视频流。部分场景下也会用到并行接口或者PCIe，但MIPI输出是绝大多数情况下的最优解，因为不用额外加桥接芯片，软件侧只需要按标准的CSI-2设备驱动来枚举摄像头个数。

4. FPGA内部逻辑设计：从MIPI接收对齐到数据聚合

4.1 多路MIPI RX通道的独立初始化和Lane映射

Crosslink-NX内部对MIPI接口的支持，依赖的是它的硬核MIPI D-PHY IP和可编程的Byte-to-Pixel逻辑。每一个RX端口可以独立配置为1/2/4 lane模式，lane的极性也可以交换，这样PCB布线的时候可以灵活调整走线方向，不用强制差分对一一对应。

逻辑设计的第一步是初始化每一路MIPI RX。MIPI协议规定接收端要先检测LP状态，接收端的初始化时序是：等待LP-00状态，进入HS模式，接收端通过解析SoT开始接收数据包。这些过程在Lattice的MIPI RX IP中已经封装好了，但使用的时候必须仔细确认每一路MIPI RX的时钟使能时序。多路视频流接入后，每一路的HS时钟完全独立，FPGA需要为每个RX端口分配独立的时钟域。

Lane映射是另一个坑。部分解串器输出的MIPI lane顺序可能是固定的，而Crosslink-NX的RX端口如果做了lane交换配置，双方必须有明确的映射约定。最好的做法是在设计文档里画一张表格，把每颗解串器输出、FPGA引脚、RX通道lane顺序全部列出来，避免layout阶段一改再改导致逻辑映射对不上。

4.2 行缓冲与数据交织策略

多路视频流进入FPGA后，第一步是转换成16bit或者24bit的像素数据。对于常见的RAW8传感器，8bit像素就够了。RAW10或者RAW12就需要把像素拼成16bit的word，这会带来一个对齐问题：RAW10的一行像素个数乘以10bit，不一定能整除16，所以每一行的行尾会有空bit填充。Crosslink-NX的MIPI RX IP提供了一组sideband信号，用来标记行有效和数据有效，逻辑层要基于这些信号做数据切割。

聚合的方式我有两个推荐。第一种是VC整合：把每一路视频流当作一个独立的Virtual Channel，在输出MIPI流的时候，给每个通道配置不同的VC号。这种方式实现简单，主SoC可以直接通过CSI-2的VC号区分摄像头，非常适合cameralink类的采集卡或者部分ISP。第二种是行交织：把多路视频流的同一行数据拼接到同一个输出行里。这种方式适合需要做双目立体视觉的场景，左右目图像可以做到逐行对齐，减少后续畸变校正和立体匹配的计算压力。

两种方式各有适用场景，我自己做过的方案里，VC整合为主，因为它的逻辑开销最小，主控软件也最容易适配。行交织方式的带宽利用率更高，但逻辑复杂度明显上升，一句话总结：除非你的算法明确要求逐行对齐，否则优先选VC方式。

4.3 速率计算与FIFO深度规划

FPGA逻辑设计里最容易被低估的是FIFO深度规划。多路摄像头数据汇聚到一路MIPI输出，输出带宽必须大于所有输入带宽之和，这个道理大家都懂，但实际做起来还是有细节。因为输出MIPI接口的lane数和工作频率是固定的，而各路输入的数据到达时间是随机的，突然有多路数据同时到达输出端口，瞬时带宽需求可能超过输出端口能力，这时候就需要FIFO来吸收突发流量。

FIFO深度的计算思路是这样的：以单路1080p30 RAW10为例，像素时钟大约为74.25MHz，有效数据带宽为 1920108030*10bit ≈ 622Mbps。4路加起来约2.5Gbps，如果输出MIPI采用4 lane，每lane 1.5Gbps，总带宽为6Gbps，看起来冗余很大。但实际上MIPI输出的数据是"突发的"，一行数据到达后必须在特定时间内送完，逻辑里还会插入消隐期，所以FIFO深度不能只看平均带宽。常用做法是把输入数据的行时间作为基准，计算最坏情况下多路行数据重叠时的数据量，然后乘以一个1.5到2的裕量系数。

以我的经验，每路FIFO深度至少要做到1.5个标准行数据量，即 192010bit1.5 ≈ 28.8Kbit，选个32Kbit的FIFO就够了。不要在这个地方省资源，FIFO溢出导致的行丢失，比任何算法问题都难排查。

5. 多摄像头同步：为什么必须做，以及GMSL2链路上的实现路径

5.1 帧同步和曝光同步的区别

"多摄像头同步"这个说法太笼统，工程上必须拆成两个问题来看：帧同步和曝光同步。

帧同步的意思是所有摄像头在同一个时刻开始传输一帧画面。如果帧不同步，不同的摄像头图像会存在时间偏移，在拼接、融合或者测距算法里会产生严重的伪影。比如车上的环视系统，如果四个摄像头采集时间不一致，车身周围的物体在移动时，拼接出来的全景图就会有撕裂感。

曝光同步则更进一步，要求所有摄像头不仅同时开始读帧，还要求同时开始曝光。因为曝光发生在传感器内部，即使帧同步命令发得再准，如果曝光时序不同，实际采到的画面仍然有时间差。对于高速运动场景，比如车辆在高速上行驶时拍摄路面标线，曝光时间差几毫秒就会造成数厘米的定位误差。

GMSL2方案对同步的支持相对友好，原因在于GMSL2的反向控制通道是共享的，可以通过解串器向所有远程串行器广播同步信号。硬件上需要做的是在Crosslink-NX里生成一个同步脉冲，通过I2C或者GPIO的方式输出到每一路解串器的同步接口，然后解串器把同步信号通过GMSL2链路的专用通道送给远端传感器。

5.2 基于GPIO的硬件触发方案

我自己在项目里用得最多的方案是FPGA输出多路同步GPIO，分别接到每颗解串器的同步输入引脚，解串器通过GMSL2反向通道把对应的触发命令发给串行器。部分传感器也支持直接用PWM或者外部触发引脚，这时候可以把FPGA的同步脉冲直接接到传感器侧的触发脚。

同步精度的关键是脉冲宽度和传播延迟的一致性。不同链路的长短、解串器配置差异会导致同步脉冲到达传感器的时刻不完全一致，好在GMSL2方案的这个偏差通常在微秒量级，远小于绝大多数视觉算法的需求。如果对同步要求极高，可以在Crosslink-NX内部做一个延迟校准逻辑，通过细粒度延时单元把每路的触发时刻对齐到纳秒级。

这个逻辑其实不难，难的是同步信号的回读确认。建议在FPGA里设计一个简单的计数器，记录每路摄像头帧起始信号和同步脉冲的间隔，用来验证同步是否真正生效。很多摄像头输出帧信号时会有不确定性，只有实测间隔基本恒定，才能放心把同步方案交付。

5.3 主SoC侧的软件配合

硬件同步只完成了一半，主SoC侧的软件也必须配合。聚合后的MIPI流通过VC区分摄像头，但VC本身不携带时间戳信息。如果主控平台支持CSI-2的frame start/end事件响应，软件可以通过中断来记录每一帧到达的时间，然后做后处理对齐。

如果主控的ISP不支持多通道时间戳，那软件层就很难保证多路图像的同步了。这时候可以在Crosslink-NX里插入帧ID信息，比如在每帧的有效数据里嵌入一个递增计数器，软件在接收端解析帧ID，丢弃ID不连续的帧。这个方法虽然增加了一点带宽开销，但能让同步问题变成可检测、可恢复的，比盲目相信硬件同步可靠得多。

6. 实测调试经验：链路建立、图像质量与故障排查

6.1 从寄存器初始化到跑通视频流的调试顺序

我调试GMSL2加Crosslink-NX这套系统的时候，习惯按照固定的顺序走，这个顺序帮我省掉了大量无效排查时间。

第一步是确认GMSL2链路物理层已经建立。上电后先读解串器的lock状态寄存器，如果link没有lock，后面的MIPI信号根本无从谈起。常见的lock失败原因包括：线缆接触不良、PoC供电异常、远端串行器没有正常上电。先排除物理层，不要急着调寄存器。

第二步是让解串器的MIPI输出恢复。lock之后，解串器会根据输入视频流的时序，在输出端恢复MIPI信号。这时候可以用示波器探一下MIPI的时钟通道，看有没有周期性的HS时钟。如果时钟出来了但数据口没有信号，多半是解串器的lane映射配置和Crosslink-NX的RX端口不匹配。

第三步是配置Crosslink-NX的MIPI RX IP。跑通的第一步不是直接做聚合，而是把每一路RX先单独接出来，用最原始的frame counter逻辑验证每一路都能正确收到行场信号。每路单独验证通过后，再打开聚合逻辑。一次只增加一个变量，出了问题就能立刻定位。

6.2 常见图像异常与根因分析

结合自己做过的几个项目，我把最常见的图像异常整理成一张表，调试的时候可以直接对照：

表格里的每一条我都实际遇到过。特别是"串扰"这一条，看上去像是硬件问题，其实常常是FPGA内部对不同通道的sideband信号处理不一致导致的。MIPI RX IP输出的行有效信号是脉冲式的，如果逻辑里用了同一个行计数器去控制多路数据写入，只要有一路的行时序提前一点，后续数据就会错位，表现为某个通道的图像里混入了另一个通道的内容。

6.3 眼图测试和信号完整性验证

GMSL2链路不像并行总线，可以逐根信号线去量。调试高速串行链路最有效的验证手段是同轴传输线上的眼图测试。用眼图可以直接看到信号余量是否足够，判断链路上的噪声、反射和PoC网络的影响。

眼图测试的步骤不复杂：在解串器输入端预留一个测试点，用有足够带宽的示波器接上，探头设置在交流耦合模式，触发方式选为恢复时钟，就能看到眼图。最理想的情况是眼图睁得越开越好，裕量至少要有20%以上，否则温度和老化变化后很容易出现误码。

还要关注PoC网络的谐振影响。同轴线上的电源注入点如果不匹配，会导致在特定频点上反射加剧，眼图上会看到一个明显的"闭合"痕迹。处理办法是调整PoC电感的感值或者增加阻尼电阻，抑制谐振峰。这部分调试没有捷径，只能靠扫频的方式找到问题频点，再针对性地调整器件参数。

7. 带宽评估和帧率规划：一套可以照着算的公式

做多摄像头方案，前期评估阶段最常被问的问题就是"这个方案能跑多少路摄像头、多少分辨率、多少帧率"。这个问题不能凭感觉回答，我习惯用一套固定公式来算。

第一步估算每路摄像头的数据率：像素总数 × 位深 × 帧率。比如400万像素的RAW10传感器跑30fps，数据率为 400万 × 10bit × 30 = 1.2Gbps。第二步加MIPI开销：MIPI CSI-2协议每4KB数据大约有13%的包头包尾开销，实际每路数据率乘以1.15。第三步看GMSL2链路带宽上限3Gbps，可以判断这个传感器能轻松跑满帧率，甚至可以跑60fps。第四步看Crosslink-NX的输出带宽，以4 lane、每lane 1.5Gbps计算，总输出带宽是6Gbps。

还是以4路400万像素RAW10为例，4路总数据率为4.8Gbps（含开销），6Gbps的输出带宽是够用的。但如果换成800万像素传感器，单路裸数据率就到了2.4Gbps，加开销后约2.76Gbps，GMSL2链路已经接近极限，4路总和约为11Gbps，远超Crosslink-NX的MIPI输出带宽。这种情况下就不能做单纯聚合了，要塞进6Gbps带宽，只能降低传感器帧率、裁剪ROI、或者改用RAW8输入，让数据率减半。

还有一个常见误区：只看总带宽够不够，没有计算MIPI输出接口的瞬时带宽。MIPI输出是高速差分信号，即使在消隐期间也会发送LP状态，实际有效数据率比额定值要低。如果你的设计是让4路1080p60的数据全部经过一个4 lane MIPI输出，瞬时带宽在每行起始时会有明显的尖峰，FIFO深度稍有不足就会丢数据。所以带宽规划的时候除了算平均速率，一定要考虑突发特性，把FIFO资源和输出时序安排好。

8. Crosslink-NX的资源利用与低功耗特性

选Crosslink-NX的原因除了MIPI接口资源丰富，还在于它的功耗控制。做过多路视觉的人都清楚，一颗功耗动辄几瓦的FPGA放在车载系统里，散热和电源设计都会非常痛苦。Crosslink-NX的标称功耗在低功耗FPGA里是比较出色的，我实测下来做4路1080p RAW10的采集聚合，整颗FPGA的功耗在毫瓦到瓦级别的区间里，具体数值取决于逻辑利用率和翻转率。

Crosslink-NX的架构里有一个特点值得关注：它自带片上闪存配置，上电启动不需要外挂SPI Flash，对系统BOM成本和启动可靠性都有好处。它支持多引导镜像，可以在运行中切换配置，对于需要在线升级固件的设备来说非常方便。

资源利用方面，MIPI D-PHY的硬核IP不消耗可编程逻辑资源，这是Crosslink-NX的优势。真正消耗逻辑的是数据通路处理，包括行缓冲、格式转换、跨时钟域逻辑和聚合状态机。一个4路1080p的方案，大约会用到几万个查找表和寄存器，具体数量取决于你做的处理复杂度。如果只是单纯做数据聚合和VC转发，资源冗余还很大，可以留一部分给后续的图像预处理功能，比如坏点校正、黑电平校准或者简单的色彩空间转换。

我自己习惯把Crosslink-NX定位为"图像链路管家"，而不是"图像处理引擎"。它擅长的是把所有摄像头数据有效地接入、整理、转发，把后端主SoC从繁重的接口适配里解放出来。如果想在FPGA里做复杂的ISP算法，Crosslink-NX的资源规模不一定够，那不如选更大型的FPGA。选型的时候先想清楚分工，再挑芯片，这个顺序不能反。

9. 部署中的环境适应性与可靠性设计

车载和工业环境里，GMSL2方案的可靠性往往比功能更重要。高温、振动、电磁干扰、线缆弯折，任何一个因素都可能让原本跑得好好的链路突然掉链子。硬件设计上要特别关注解串器和Crosslink-NX的供电质量。GMSL2解串器对电源纹波比较敏感，建议电源走单独的LDO，避免和其他数字器件共用一个开关电源，尤其是PoC馈电那一路，输出纹波尽量压在20mV以内。

连接器和座子的选型同样重要，GMSL2的实际载流量和机械可靠性，完全取决于选择什么样的FAKRA或者HSD连接器。车规级的FAKRA连接器价格不便宜，但和现场掉线带来的返工成本比，这点钱花得值。线缆方面，优先选用屏蔽层覆盖率高的同轴线，别为了省成本用普通的视频线，高速信号的衰减特性差异非常大。

软件层面，除了默认的链路检测机制，建议在系统里加一个"链路巡检"任务，定时读取解串器的lock状态和误码计数。GMSL2的误码计数器是一个非常有价值的诊断信息，正常情况下长期运行误码率应该为0，如果误码率缓慢增长，说明链路余量正在下降，大概率是连接器氧化或者线缆疲劳，提早预警比故障发生后再排查省心得多。

这里还有一点要特别提醒：GMSL2链路在某些车规平台的EMI测试中容易暴露问题，尤其是线缆长度较长的时候。常见对策包括在同轴线靠近连接器的地方加磁环、优化PoC电源网络的环路面积、以及调整FPGA输出端的压摆率控制寄存器。这些方案都不复杂，但在设计阶段留好位置，比测试阶段再改结构舒服太多。