027、影像数据通路带宽规划——MIPI CSI-2/CPHY/DPHY的lane分配与DDR带宽预留策略在安霸CVflow上的实现上个月在调试一个8路AHD转MIPI的案子客户拿来的转接芯片标称支持4-lane MIPI我们按默认配置把8路全部塞进一条CSI口结果预览画面一到夜间噪点多的场景就出现横向撕裂抓log发现ISP的line buffer频繁underflow。查到最后根本不是ISP算力不够是MIPI的virtual channel复用没做带宽隔离加上DDR的QoS优先级没设对导致高负载下帧数据被挤到带宽洼地里。这种问题在datasheet上永远查不到只能靠对数据通路的逐段拆解来定位。先理清楚MIPI物理层的带宽天花板。DPHY在1Gbps/lane的速率下4-lane理论峰值是4Gbps但这是纯payload速率实际要扣掉LP模式切换、ECC/CRC校验、以及每帧的blanking开销。CPHY在同样3-trio配置下每个trio能跑2.28Gbps16:18编码后3-trio就是6.84Gbps看着比DPHY翻倍但CPHY的同步开销更大而且安霸平台对CPHY的支持远不如DPHY成熟——我们实测CV25上CPHY的trio间skew校准在高温下会漂移导致误码率上升最后不得不降速到1.7Gbps/trio才稳定。所以选型时别只看峰值速率要看平台对PHY的调校成熟度。lane分配的核心矛盾是多路sensor共享CSI口时每路的时序隔离靠virtual channel但物理lane是共享的。假设4-lane DPHY跑1.5Gbps/lane总带宽6Gbps接4路1080P60每路RAW10格式下数据率约1.78Gbps1920108010*60/8/1000/1000四路加起来7.12Gbps已经超了。这时候要么降帧率要么切到RAW8要么把sensor的HDR模式关掉减少数据量。我们实际做的是把其中两路降成720P60用带宽计算器反推每路的lane占用时间片确保在MIPI的帧blanking窗口内完成切换。DDR带宽预留是另一层坑。安霸CVflow的ISP前端有独立的DMA引擎但和视频编解码器、NPU共用同一个DDR控制器。默认配置下ISP的DMA优先级低于NPU一旦跑AI模型ISP的带宽就被挤占。我们用的办法是在CVflow的DDR QoS寄存器里把ISP的read channel优先级提到最高同时给MIPI RX的write channel设置一个最小带宽保证——具体做法是配置AXI的QoS仲裁权重让ISP的outstanding transaction数量从默认的8提升到16但要注意别超过DDR控制器的最大pending队列深度否则会引发反压。代码层面有个容易忽略的点MIPI的frame sync信号必须和DDR的burst对齐。我们之前用CV25的CSI-2驱动默认的burst length是16字节但sensor输出的行长度是1920像素*10bit/82400字节不是16的整数倍导致每行末尾有残包DMA要额外处理带宽浪费约3%。后来把burst length改成32字节配合行缓冲对齐到32字节边界浪费降到0.5%以内。这里踩过坑——别直接改burst length就完事要同步改DMA描述符的地址对齐否则会出页错误。安霸的CVflow SDK里有个工具叫cv_bandwidth_profiler能在跑流时实时统计每个IP核的DDR读写带宽。我们用它发现一个反直觉的现象MIPI RX的写带宽在夜间场景比白天高15%原因是sensor的HDR模式在低照度下会触发多次曝光合并每帧数据量增大。这个在规划带宽时一定要留余量我们一般按最坏场景的1.3倍预留否则冬天低温下sensor的增益拉高数据率超了就会丢帧。最后说一个关于lane mapping的细节。多路sensor接同一个CSI口时硬件上要保证每路的data lane和clock lane的物理走线等长否则高速信号的眼图会塌。我们之前有一版PCB两路sensor的lane走线差了15mil结果在1.2Gbps下误码率到了1e-6画面出现随机噪点。后来改成等长走线误码率降到1e-12以下。这个在原理图阶段就要算好别指望软件能补偿。给个经验值DPHY 4-lane 1.5Gbps下实际可用带宽约5.4Gbps扣除协议开销CPHY 3-trio 1.7Gbps/trio下约4.8Gbps。规划时按这个数算别按理论峰值。DDR带宽预留方面ISP前端DMA建议至少占DDR总带宽的20%如果同时跑NPU和编解码这个比例要提到30%。安霸平台可以在bootloader阶段就设置好QoS别等系统起来再调否则启动阶段的sensor初始化就可能丢帧。调试这类问题我的习惯是先用逻辑分析仪抓MIPI的LP/HS切换时序确认物理层没问题再上CVflow的profiler看DDR带宽分布最后才动QoS配置。顺序反了会浪费时间——很多所谓带宽不足的问题其实是PHY的时序margin不够降一档速率就全好了。 027、影像数据通路带宽规划——MIPI CSI-2/CPHY/DPHY的lane分配与DDR带宽预留策略在安霸CVflow上的实现上个月在调试一个8路AHD转MIPI的案子客户拿来的转接芯片标称支持4-lane MIPI我们按默认配置把8路全部塞进一条CSI口结果预览画面一到夜间噪点多的场景就出现横向撕裂抓log发现ISP的line buffer频繁underflow。查到最后根本不是ISP算力不够是MIPI的virtual channel复用没做带宽隔离加上DDR的QoS优先级没设对导致高负载下帧数据被挤到带宽洼地里。这种问题在datasheet上永远查不到只能靠对数据通路的逐段拆解来定位。先理清楚MIPI物理层的带宽天花板。DPHY在1Gbps/lane的速率下4-lane理论峰值是4Gbps但这是纯payload速率实际要扣掉LP模式切换、ECC/CRC校验、以及每帧的blanking开销。CPHY在同样3-trio配置下每个trio能跑2.28Gbps16:18编码后3-trio就是6.84Gbps看着比DPHY翻倍但CPHY的同步开销更大而且安霸平台对CPHY的支持远不如DPHY成熟——我们实测CV25上CPHY的trio间skew校准在高温下会漂移导致误码率上升最后不得不降速到1.7Gbps/trio才稳定。所以选型时别只看峰值速率要看平台对PHY的调校成熟度。lane分配的核心矛盾是多路sensor共享CSI口时每路的时序隔离靠virtual channel但物理lane是共享的。假设4-lane DPHY跑1.5Gbps/lane总带宽6Gbps接4路1080P60每路RAW10格式下数据率约1.78Gbps1920108010*60/8/1000/1000四路加起来7.12Gbps已经超了。这时候要么降帧率要么切到RAW8要么把sensor的HDR模式关掉减少数据量。我们实际做的是把其中两路降成720P60用带宽计算器反推每路的lane占用时间片确保在MIPI的帧blanking窗口内完成切换。DDR带宽预留是另一层坑。安霸CVflow的ISP前端有独立的DMA引擎但和视频编解码器、NPU共用同一个DDR控制器。默认配置下ISP的DMA优先级低于NPU一旦跑AI模型ISP的带宽就被挤占。我们用的办法是在CVflow的DDR QoS寄存器里把ISP的read channel优先级提到最高同时给MIPI RX的write channel设置一个最小带宽保证——具体做法是配置AXI的QoS仲裁权重让ISP的outstanding transaction数量从默认的8提升到16但要注意别超过DDR控制器的最大pending队列深度否则会引发反压。代码层面有个容易忽略的点MIPI的frame sync信号必须和DDR的burst对齐。我们之前用CV25的CSI-2驱动默认的burst length是16字节但sensor输出的行长度是1920像素*10bit/82400字节不是16的整数倍导致每行末尾有残包DMA要额外处理带宽浪费约3%。后来把burst length改成32字节配合行缓冲对齐到32字节边界浪费降到0.5%以内。这里踩过坑——别直接改burst length就完事要同步改DMA描述符的地址对齐否则会出页错误。安霸的CVflow SDK里有个工具叫cv_bandwidth_profiler能在跑流时实时统计每个IP核的DDR读写带宽。我们用它发现一个反直觉的现象MIPI RX的写带宽在夜间场景比白天高15%原因是sensor的HDR模式在低照度下会触发多次曝光合并每帧数据量增大。这个在规划带宽时一定要留余量我们一般按最坏场景的1.3倍预留否则冬天低温下sensor的增益拉高数据率超了就会丢帧。最后说一个关于lane mapping的细节。多路sensor接同一个CSI口时硬件上要保证每路的data lane和clock lane的物理走线等长否则高速信号的眼图会塌。我们之前有一版PCB两路sensor的lane走线差了15mil结果在1.2Gbps下误码率到了1e-6画面出现随机噪点。后来改成等长走线误码率降到1e-12以下。这个在原理图阶段就要算好别指望软件能补偿。给个经验值DPHY 4-lane 1.5Gbps下实际可用带宽约5.4Gbps扣除协议开销CPHY 3-trio 1.7Gbps/trio下约4.8Gbps。规划时按这个数算别按理论峰值。DDR带宽预留方面ISP前端DMA建议至少占DDR总带宽的20%如果同时跑NPU和编解码这个比例要提到30%。安霸平台可以在bootloader阶段就设置好QoS别等系统起来再调否则启动阶段的sensor初始化就可能丢帧。调试这类问题我的习惯是先用逻辑分析仪抓MIPI的LP/HS切换时序确认物理层没问题再上CVflow的profiler看DDR带宽分布最后才动QoS配置。顺序反了会浪费时间——很多所谓带宽不足的问题其实是PHY的时序margin不够降一档速率就全好了。 
