ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

GMSL2与CrossLink-NX:跨距离多摄像头视频聚合方案解析

GMSL2与CrossLink-NX:跨距离多摄像头视频聚合方案解析 1. 为什么跨距离多摄像头时代GMSL2和CrossLink-NX总被放在一起提做过多摄像头车载项目或者机器人感知项目的人应该都对“线束问题”有切肤之痛。摄像头数量不是最难的最难的是把分布在车头、车尾、后视镜外壳、机械臂关节、AGV底盘上的多路视频稳定可靠地汇总到一块主控板上。MIPI CSI-2天生是为板级短距离传输设计的PCB走线超过二三十厘米就得开始小心布局一旦经过连接器、FPC排线再拉到两米开外信号完整性基本没法保证。这时候行业里普遍采用GMSL2这种串行传输技术摄像头端通过一颗串行器把MIPI数据转成高速差分信号走一根同轴线或者双绞线轻轻松松传输十几米。GMSL2真正吸引人的地方不只是距离而是它把一根线用到了极致。视频信号向下传I2C控制信号通过反向通道向上传同时还能通过同一条同轴线给远端摄像头供电也就是PoC。我最早调试这类系统时远端摄像头模组只接一根同轴线视频出来、寄存器配置进去、电源也进去整个模组不需要单独拉电源线和控制线这种体验对结构设计、线束成本和整车EMC来说都是非常大的进步。不过GMSL2解决的是“单路视频远程搬运”的问题它本身不处理多路汇聚。项目一旦超过两路摄像头主控SoC的MIPI端口数量、每端口lane数就会变成瓶颈。比如你只有一颗带两个4-lane CSI端口的SoC却要接四路1080p视频直接接就没法接。这时候就需要有一颗专门的视频桥接芯片把多路输入整理成主控更容易接受的单路输出这就是CrossLink-NX在整套方案中存在的价值。它本质上是可编程的视频聚合和桥接器件配置足够灵活适合处理“多路进、少路出”或者“少路进、多路出”这类不对称的视频路由需求。1.1 GMSL2解决的是“线怎么拉”的问题不是“数据怎么整理”的问题GMSL2全称是Gigabit Multimedia Serial Link第二代的串行链路技术单条链路的有效数据速率可以到3Gbps部分器件支持6Gbps。它把MIPI CSI-2、I2C、GPIO、供电全部打包进一根同轴线里。摄像头传感器出来的MIPI信号先喂给串行器串行器做并串转换后输出一对差分信号远端的解串器再把这对差分信号恢复成MIPI CSI-2信号交给主控。整个过程中数据格式基本没有变化只是换了物理传输介质。但是它不负责“几路视频怎么合并”。四路摄像头经过四根同轴线拉回主控端之后得到的仍然会是四路独立的MIPI信号、四套独立的时基、四个可能相同的虚拟通道编号。主控要么有足够多的CSI端口分别接入要么得靠中间加一颗聚合芯片。GMSL2链路本身并不具备把多路流合并成一路的能力。1.2 CrossLink-NX在整套方案里的角色聚合、重定时、重映射CrossLink-NX是莱迪思的一款28nm FD-SOI工艺FPGA专门面向嵌入式视觉应用。它的核心优势在于有四个硬核MIPI D-PHY每个D-PHY支持四条数据lane并且每个PHY都可以独立配置成发送或者接收。这就非常适合做视频路由中转几路CSI-2输入进来经过内部逻辑处理再从另外的PHY送出去。它和通用FPGA最大的差别是D-PHY物理层是硬核的不需要自己写高速SerDes也不用在FPGA逻辑里做MIPI物理层协议直接把CSI-2数据包从PHY搬运到内部逻辑即可。这大大降低了设计门槛。对于多路摄像头系统CrossLink-NX可以做三件事一是聚合把多路输入流打包成单路CSI-2输出靠虚拟通道VC ID区分不同摄像头二是分裂把一路输入复制或者分发到多个输出比如一个画面同时送显示和编码器三是重定时由于多路摄像头时序可能不同步CrossLink-NX可以用内部FIFO缓存和PLL重新建立统一输出时基。这三件事在车载环视、驾驶员监控、机器人多目感知、医疗内窥镜等场景里都非常常用。2. 一套完整方案4路远端摄像头、1路聚合MIPI输出到SoC接下来分享一套我实际做过的参考方案框架。场景设定是这样的一套域控制器主板上有一颗主机SoCSoC只留了一个4-lane MIPI CSI-2接口给外部摄像头但我们需要接入四路1080p30的远端摄像头例如环视加DMS的组合。四颗摄像头分别安装在车辆四个角落离域控有3到8米的距离。显然不能用MIPI直接拉线必须走GMSL2。这套方案的完整链路拓扑可以分成三段来描述。第一段在摄像头模组端传感器输出MIPI CSI-2接口通常配置成2-lane或者4-lane速率视分辨率而定传感器旁边放一颗GMSL2串行器常见的比如MAX96717把MIPI信号转成GMSL2串行信号另外还需要给传感器和串行器供电同时设计PoC注入网络让电源从同轴线远端送过来。第二段在同轴线束每颗摄像头对应一根同轴线比如50欧姆的FAKRA或者HFM连接器同轴线传输GMSL2差分信号同时承载PoC电源和反向I2C控制通道。第三段在域控内部四根同轴线进入四通道解串器例如MAX96724解串器把GMSL2链路恢复成MIPI CSI-2信号输出。注意MAX96724的输出可能是两个MIPI端口每个端口四条lane分别承载两路视频流。然后解串器输出接到CrossLink-NXCrossLink-NX把四个逻辑视频流重新映射到一路4-lane CSI-2输出最终接到主控SoC的MIPI CSI-2端口。2.1 远端传感器加串行器的“摄像头模组”怎么搭远端摄像头模组设计的关键点在于传感器输出MIPI串行器输入MIPI两边必须匹配lane数量、数据速率和时钟模式。以1920×108030fps 8bit YUV422为例有效像素数据率大约是995Mbps。加上MIPI包头、行消隐和帧消隐实际链路速率通常在1.1到1.2Gbps左右。如果用4-lane传输每lane速率约300Mbps余量很充足。有些传感器为了节省功耗会把YUV422数据拆成2-lane输出那每lane速率会翻倍到约600Mbps只要在串行器支持范围内也可以但对PCB走线要求会稍微高一些。我习惯上能用4-lane就用4-lane速率低一些信号完整性和EMC表现都会好很多。传感器输出的MIPI时钟模式也要和串行器对齐。大部分车规传感器支持连续时钟和非连续时钟两种模式。GMSL2方案里我建议把传感器配置成连续时钟模式因为串行器内部的PLL锁定更稳定解串器端的恢复也更容易。串行器选型上MAX96717、TI的DS90UB953这类单路串行器都很常见。它们一般从MIPI收数据输出给同轴线缆同时通过反向通道接收I2C指令用来配置远端传感器寄存器。远端模组的启动顺序一般是先给传感器和串行器上电然后主机通过反向I2C访问串行器配置它的MIPI输入参数、GMSL2串行输出速率、时钟模式和视频管道使能寄存器最后配置传感器输出格式并启动视频流。2.2 中央域控里的解串和聚合顺序四路GMSL2同轴线进到域控之后先到解串器。解串器MAX96724这类器件支持四路独立GMSL2输入输出端提供两个MIPI CSI-2端口每个端口四条lane可以通过寄存器配置把哪几路GMSL2输入映射到哪个MIPI输出端口。这里有一个重要的设计决策四路视频从解串器出来之后是直接送给SoC还是经过CrossLink-NX如果SoC有两个空闲的4-lane CSI-2端口完全可以不经过CrossLink-NX解串器两个端口各接一路CSI-2每路包含两路VC。但现实项目里SoC的CSI端口往往很紧张多个摄像头模组、一个显示器、一个行车记录器都在抢资源。因此只在SoC留了一个CSI端口的情况下就必须在解串器和SoC之间插入CrossLink-NX做最后的汇聚。CrossLink-NX有四个可配置的D-PHY这个方案里我们用其中两个作为输入接收解串器的两个MIPI CSI-2输出端口再用一个作为输出向SoC发送聚合后的单路MIPI CSI-2信号。剩下第四个PHY可以规划成预留接口比如后续接一块显示屏或者做一路视频转发给其他芯片。2.3 带宽预算每一段链路都不应该“算着刚好够”做多摄像头系统最忌讳的是只算有效像素率不算MIPI协议开销和GMSL2串行开销。我把这套方案的带宽简单列一下方便大家照着估算自己的项目。以1920×108030fps YUV422 8bit计算有效像素数据率1920×1080×2字节×30fps124,416,000字节/秒约995MbpsMIPI CSI-2包开销和消隐大约额外10%到15%实际MIPI链路率约1.1到1.2Gbps单颗摄像头到串行器4-lane每lane约300Mbps完全没问题单条GMSL2链路承载单路视频MAX96717这类串行器下行3Gbps余量很大CrossLink-NX输入侧两个D-PHY端口每个端口接收约2.4Gbps两路视频两条lane就能承载但我们用四lane输入每lane仅约600MbpsCrossLink-NX输出侧四路视频共约4.4到4.8Gbps走单路4-lane CSI-2每lane约1.1到1.2Gbps这个速率在CrossLink-NX和SoC的MIPI接收端都还在可接受范围内但已经是这整套链路里压力最大的部分如果用的是720p30 YUV422有效像素率只有约442Mbps四路加一起也不到2Gbps整个系统的余量就非常充裕。带宽计算要盯住CrossLink-NX输出到SoC这一段这是最容易成为瓶颈的地方。2.4 CrossLink-NX的PHY端口分配逻辑CrossLink-NX一共四个D-PHY物理接口每个接口支持四条数据lane独立配置TX或RX。在做系统规划时第一步就是数清楚有几个输入流、几个输出流然后分配PHY。这套方案里PHY0接收解串器端口A的CSI-2信号包含两路视频流VC ID为0和1PHY1接收解串器端口B的CSI-2信号包含两路视频流VC ID为2和3PHY2作为输出把四个逻辑流聚合后发送到SoCPHY3预留可以后续做第二路输出PHY分配背后的原则是输入输出方向确定后不要轻易改因为CrossLink-NX的D-PHY在配置成输入还是输出时端接电阻、偏置电压、ESD结构和PLL工作模式都不太一样。虽然没有明确限制不能在运行中切换但从稳定性和时序收敛角度考虑最好上电前就确定好方向。3. 远端摄像头节点的信号完整性设计很多项目第一次点不亮问题都出在远端摄像头模组。传感器到串行器这一小段MIPI虽然距离短但因为高速、高频、信号幅度小反而需要精细设计。3.1 传感器到串行器的MIPI布线传感器和GMSL2串行器之间的距离理论上越近越好。实际项目中我通常控制在10mm以内并且把MIPI差分对走在同一层保持阻抗85到100欧姆。每对差分线之间要做包地或者拉开间距避免串扰。MIPI D-PHY的信号共模电压典型值200mV差分摆幅约200到300mV。这么小的摆幅对参考平面非常敏感。如果板子层叠里有切割、过孔断参考的情况信号质量会明显劣化。所以传感器和串行器如果必须跨层走线过孔旁边一定要加回流地过孔并且差分对的等长补偿要做在靠近接收端的位置。另外传感器的MIPI时钟对和数据对之间也要做等长匹配。我当时做等长时预留的误差控制在±5mil以内如果没有这个条件至少做到时钟比数据短一点点让数据先到、时钟后到接收端采样更稳。3.2 PoC供电网络布局PoC供电是GMSL2设计里最容易被低估的一环。远端摄像头没有本地电源全靠同轴线缆里的供电叠加因此需要做电源和高速信号的分离。设计上在串行器的同轴输出端放置一个电感或者磁珠让直流电源通过它叠加上去同时阻止高频GMSL2信号进入电源路径。这个电感的选型很关键。它需要有足够高的自谐振频率通常选择几百nH到1uH左右的高频电感直流电阻要低避免远端模组电压跌落。我踩过的一个坑是用了直流电阻偏大的电感远端摄像头在80度高温下持续工作传感器供电电压跌到规格下限以下出现偶发重启。后来换了DCR更小的电感问题才消失。在解串器端同样要有PoC分离网络把同轴线上的直流电源分离出来经过稳压器给远端模组供电。整个PoC网络的滤波特性是可以通过网络分析仪测S参数的重点是保证GMSL2工作频段内的插入损耗和回波损耗达标。如果手头没有网络分析仪至少用示波器看眼图确认链路没有因为PoC网络引入明显反射。3.3 同轴线束和连接器选型同轴线本身建议用50欧姆特性阻抗连接器选择FAKRA、HFM或者HSD这类车规级别的不能随手拿一根普通视频线代替。GMSL2工作在数GHz频段线缆的弯折半径、端子压接工艺、屏蔽层覆盖率都会直接影响传输距离和误码率。线束长度方面GMSL2标称支持15米以上但我实测下来超过10米后链路余量会变得有限。如果你需要更长的距离要么降低GMSL2速率档位比如从3Gbps降到1.5Gbps要么选用支持更高输出摆幅的串行器。总之不建议按照标称最大值来设计留出20%到30%的链路余量更稳妥。4. CrossLink-NX内实现多流聚合的逻辑设计CrossLink-NX的精髓在FPGA逻辑设计。虽然是FPGA但它提供的MIPI IP已经帮你把D-PHY物理层和链路层处理好你主要操心的是数据流怎么组织。4.1 CSI-2输入接收从PHY到AXI Stream在莱迪思Radiant软件的Clarity Designer工具里可以直接生成CSI-2接收IP。这个IP的作用是把MIPI D-PHY物理层收到的串行数据转换成并行像素数据并且解析出帧起始、帧结束、行起始、行结束等包信息输出接口通常是AXI4-Stream形式。我在这个方案里生成两个CSI-2 RX IP分别挂在PHY0和PHY1上。每个IP配置成4-lane数据类型为YUV422 8bit。IP的输出是像素字节流和对应的包同步信号。多路视频流在这个阶段还是混合在同一个AXI Stream里的IP会通过识别包头里的Virtual Channel字段来区分不同摄像头。需要注意的是CSI-2 RX IP本身不做VC分流或者重映射这些需要在用户逻辑里完成。所以我在每个RX IP后端都加了一个VC分拣模块把AXI Stream按VC ID拆成多路独立的小流分别送入后面的FIFO。这套做法看起来多了一步但逻辑清晰也方便排查问题。4.2 异步时钟域和FIFO设计四路远端摄像头虽然在同一个系统里但它们的像素时钟不一定完全同频。即使四个传感器用同一个参考时钟芯片经过不同的线缆长度、不同板卡上的PLL之后到达CrossLink-NX时的实际时钟仍然会有微小偏差。这种偏差短期内不容易发现但长时间运行后FIFO迟早会溢出或者下溢。我的处理方式是在CrossLink-NX内部为每一路视频流分配一个独立的异步FIFO。写入侧时钟是各自输入MIPI恢复出来的像素时钟读出侧统一使用CrossLink-NX内部PLL生成的一个输出像素时钟。这样四路视频流在CrossLink-NX内部就完成了时钟域对齐输出出去的数据节奏完全一致。FIFO深度的确定要考虑输入和输出之间的频率偏差以及帧消隐时间长度。假设输入像素时钟是74.25MHz输出也是74.25MHz但实际偏差可能在正负200ppm以内。那么每一帧1080p30的传输时间里读写指针的漂移大约是帧时间乘以频率偏差也就是约33.3ms乘以200ppm约6.6微秒。按照每像素两个字节、像素时钟74.25MHz计算一个帧周期内的累积差异大约不到1KB。所以配置成4KB深度已经足够。不过为了保险我一般直接给每路配8KBCrossLink-NX内部有2.4Mbit的嵌入式RAM足够分配。4.3 Virtual Channel重映射与输出打包CrossLink-NX做聚合时最核心的一个动作是VC重映射。因为四路远端摄像头最初从传感器出来时VC ID可能默认都是0。如果不做修改四路数据都标成VC0SoC端会完全分不清哪路是哪路。正确的做法是在输出之前把四路流的VC ID分别改成0、1、2、3。这个操作在逻辑上很简单直接改写CSI-2包头里的VC字段即可因为CSI-2包头本身就是协议规定的固定结构。CrossLink-NX的CSI-2发送IP提供了接口可以在发送时显式指定每个数据包的VC ID。我在实现时做了一个VC重映射表用寄存器控制。这样将来如果摄像头数量变化、或者想调整VC的分配顺序不需要改逻辑直接通过I2C或者SPI改写寄存器就行。对固件调试阶段来说非常方便不用每次都重新综合工程。输出侧的CSI-2 TX IP配置成4-lane数据速率根据总带宽计算设定。这里注意一点输出帧消隐时间需要合理设置既不能太短导致数据堆积也不能太长导致SoC接收端FIFO欠载。我一般参考SoC的MIPI接收端建议值来设置通常保持和输入视频相同的行消隐比例即可。4.4 交叉开关逻辑和旁路模式CrossLink-NX除了做聚合我还习惯在内部做一个旁路开关逻辑。用途是调试时可以把某一路输入直接旁路输出不经过FIFO和VC重映射方便单独验证每一路信号的完好性。这在整机联调时非常管用可以快速定位是链路问题还是CrossLink-NX内逻辑问题。旁路模式下CSI-2 RX IP的数据不进入FIFO而是直接接回CSI-2 TX IP。这样相当于CrossLink-NX变成一根短线路。我先验证四路输入信号本身是好的再打开聚合路径这样后续定位问题会容易很多。5. 解串器输出、SoC对接和反向I2C配置5.1 解串器的MIPI输出怎么接到CrossLink-NX解串器MAX96724输出端通常可以提供两个MIPI CSI-2端口每个端口四条lane。我需要规划这两组端口到CrossLink-NX的接线方向和距离。如果解串器和CrossLink-NX在同一块PCB上直接走板内差分线距离控制在1到2英寸以内即可。解串器的MIPI输出速率需要和CrossLink-NX的输入速率匹配。具体做法是先确定每个视频流的实际数据率以及每个输出端口要承载几路视频流然后算出每条lane的速率通过解串器寄存器配置输出时钟分频比。解串器输出端还有一个比较重要的参数是连续时钟还是非连续时钟。如果解串器支持在无数据时停止时钟可以开启非连续时钟降低功耗但CrossLink-NX的RX IP必须配置成对应的模式。我在项目里为了省事统一用连续时钟。5.2 主机SoC侧的VC ID和ISP配置四路视频流最终从CrossLink-NX输出到SoC的4-lane MIPI CSI-2接口。SoC端的ISP需要配置成接收四路虚拟通道。例如海思平台、NVIDIA平台或者地平线平台通常都支持单端口多VC接收关键是把每个VC对应的分图像素格式、分辨率、数据流类型都配置正确。这里容易出问题的是SoC的ISP对VC数量的限制。部分SoC虽然接口支持4-lane但ISP只支持两个VC通道这时候就要调整方案把四路视频按照VC 0和1合并成两路来提高兼容性或者改成分时复用传输。实际项目里我遇到过SoC端ISP固件限制的情况最后是改由CrossLink-NX输出的CSI-2头里把四路VC合并成两个VC组每组内包含两路视频定时切片才绕过了限制。这个扩展性说明CrossLink-NX在硬件调试阶段确实能给系统留出调整余地。5.3 反向I2C通路怎么建立GMSL2系统的传感器寄存器配置是通过主机SoC侧发起的I2C访问经过解串器、同轴线反向通道、远端串行器最后到达传感器。这样主机就能像直接访问本地设备一样读写远端摄像头传感器寄存器。但这个I2C转发链路有个常见坑多颗传感器的I2C从机地址可能完全相同比如四颗IMX系列传感器默认地址都是0x34。如果解串器不做地址重映射四个从机地址冲突I2C总线会乱套。解决方法是让解串器给每个GMSL2链路分配不同的本地别名地址然后建立一张地址映射表。主机访问本地地址A时解串器根据映射表把它转发到链路1上的传感器访问本地地址B时则转到链路2上的传感器。CrossLink-NX在系统中可以扮演I2C主机的角色承担上电时的传感器自动初始化任务。我在设计里让CrossLink-NX在上电后自动写出每个远端传感器的配置序列SoC起来后直接就能拿到正常出图的视频流减少了SoC端软件的复杂度。6. 硬件实测中的典型故障和调优记录最后分享几个这套方案实测过程中遇到的典型问题。这些问题单看都很简单但不当场踩一遍下次还是会犯。6.1 解串器LOCK信号经常拉起又断开最早跑通GMSL2链路时解串器的LOCK信号并不稳定表现为周期性的锁定丢失。用示波器量同轴线上的GMSL2差分信号眼图张力还可以但细看数据速率和串行器配置的速率不一致。原因是我把串行器配成了3Gbps档位但解串器侧还按1.5Gbps速率配置去接收。两边速率不匹配锁定当然不稳定。改好配置后LOCK立即恢复稳定。这类问题在单独调串行器、单独调解串器的时候都不容易暴露因为串行器端的配置寄存器只影响发送解串器端的寄存器只影响接收两边分开调都“看着正常”一旦对接就露馅。建议上电调试时先确认GMSL2链路速率等级一致再查其他参数。6.2 输出MIPI出现偶发CRC错误CrossLink-NX输出到SoC的MIPI信号在长时间运行后出现偶发性CRC错误。这种错误最难查因为不是每次开机都有。后来在示波器上观察输出差分信号发现数据lane的驱动强度设置偏强导致过冲和振铃在SoC接收端采样点附近引入了不确定性。把CrossLink-NX输出D-PHY的驱动强度下调一档之后CRC错误完全消失。MIPI D-PHY的驱动强度和转换速率不能凭感觉设一定要根据PCB走线长度和接收端能力来匹配。走线短、负载轻驱动强度可以降下来反而更稳。6.3 PoC电源噪声导致远端传感器花屏有一个项目出现远端摄像头偶发花屏最后定位是PoC电源噪声超标。远端模组的稳压器输入端噪声过大导致传感器模拟电源纹波超过规格影响了CMOS图像传感器的模拟输出。处理办法是加强PoC网络的高频滤波把靠近串行器端的滤波电容从单颗100nF改成100pF、1nF、100nF的组合同时调整了PoC电感的选型让电源噪声和目标频段隔离更彻底。这个案例验证了PoC供电网络不能用“差不多”的心态去设计NOR管性能差异在高速链路里会直接被放大。6.4 多摄像头帧同步不只是硬件同步信号的问题这套方案虽然支持所有摄像头通过GMSL2反向通道接收同一个帧同步触发信号但实际运行一段时间后仍然会出现帧错位。排查后发现问题出在传感器端的帧同步信号使能配置和曝光时序不匹配光把触发信号送过去还不够传感器的曝光模式、帧长配置都必须一致。这需要上层和传感器寄存器配置协同处理。如果你做的是双目立体视觉这类强帧同步要求的应用建议在系统层面加一个硬件时间戳校验以CrossLink-NX内部计数器为基准把每一帧的到达时间记录下来主机侧根据时间戳做帧对齐而不是完全依赖硬件同步信号。6.5 量产一致性和老化测试建议量产阶段要留意的是不同批次连接器和线束的阻抗差异。GMSL2链路对连接器压接工艺很敏感建议产线每批次抽几台设备做完整的老化测试至少连续跑几个小时4K视频或者多路1080p视频同时监控解串器的LOCK状态和误码计数。这套方案在测试中曾经出现过个别设备在温度升高后链路误码增加的情况追根溯源是串行器的供电去耦电容容值偏低高温下ESR变大电源噪声升高。这类问题只有在高温老化环境下才会暴露所以量产前的老化规范不能省。最后一条个人经验多摄像头加GMSL2加CrossLink-NX这套组合前期架构设计一定要想清楚输入路数、输出路数和SoC端口约束。CrossLink-NX虽然灵活但四个PHY的方向一旦定下来后面调整空间有限。先画好PHY分配图算清楚每一段的带宽再动手画原理图整体进度反而是最快的。
返回列表