2026年FPGA大赛备赛，用Zynq做实时视频拼接时，多摄像头帧同步和AXI4-Stream数据对齐有哪些坑？

硬件触发同步是最稳的，但看你描述两路OV5640帧率不一致，大概率是PLL配置或者MCLK分频没对齐。先检查硬件上两个摄像头的XVCLK是不是同一个晶振出来的，如果各用各的晶振，PPM偏差积累到一定帧数就会漂。建议先在PL端做一个全局复位逻辑，所有摄像头用同一个复位信号，再用一个计数器做帧起始对齐。你提到的TUSER打时间戳在低帧率下可行，但一旦丢帧时间戳就乱，不如在VDMA的帧缓存里写一个固定Pattern作为帧头标记，读侧检测到Pattern再开始拼接。丢帧问题很可能出在AXI4-Stream的ready/valid握手时序上，检查一下FIFO深度是否足够覆盖两路的最大延迟差。你用的是VDMA还是直接Stream FIFO？

说个你可能没注意到的点：两路OV5640帧率不一样，不一定只是摄像头本身的问题，Zynq的MIPI CSI-2接收端在PL里用的参考时钟如果不同步，也会导致帧率偏差。建议你先在ILA上抓一下两路的帧同步信号，看看是帧起始时刻对不上，还是帧长不一致。如果帧长不一样，那TUSER时间戳对齐后肯定丢帧，因为一路已经读完一帧另一路还在传。一个工程上常用的土办法是：在PL里用BUFG把两路像素时钟做动态相位补偿，然后用一个深异步FIFO做弹性缓冲，深度至少两帧以上，同时用帧计数器代替时间戳——计数器溢出时两路同时复位重新对齐。别迷信现成IP核，Xilinx的Video Mixer对多路帧同步要求挺苛刻的，不如自己写一个简单的帧对齐状态机。开源方案可以搜LogiCORE IP Video Frame Buffer，但那个写回DDR再读出的延迟很大，不适合实时拼接。你现在的拼接是在PL里直接做还是通过VDMA进DDR再处理？如果是后者，丢帧很可能是DDR带宽争抢造成的，建议先确认一下AXI总线的仲裁优先级配置。

兄弟，看你描述的情况，我怀疑你踩了三个常见坑。第一个坑：误以为硬件触发同步就能解决一切。实际上两个OV5640即使共用一个SCCB总线配置，上电瞬间的初始化延迟也可能差好几帧，硬件触发只能保证帧起始沿对齐，不能保证后续帧长完全一致。第二个坑：TUSER打时间戳的思路本身没问题，但OV5640输出的MIPI数据包在CSI-2协议里，TUSER信号往往被用来标记行同步或帧同步，你再用它打时间戳就会和协议冲突。正确做法是在PL端写一个独立的Packet Analyzer模块，从像素数据流里提取每帧的Line Valid信号，然后生成自定义的帧序号插入到AXI4-Stream的TDATA高位，读侧根据帧序号做对齐，这样TUSER留给标准协议用。第三个坑：丢帧不一定是同步问题，可能是你的VDMA配置成了连续传输模式，而两路FIFO的写使能不同步导致VDMA的S2MM通道出现了Address Underflow。建议改成Non-Linear模式，手动管理写指针。另外，Zynq的PL端做实时视频拼接，一般不建议把两路数据直接拼成一个Stream，因为缓冲深度不好控制。更常见的做法是：两路各自通过VDMA写入DDR的不同地址区，然后在PS端用OpenCV或者自定义的DMA描述符链做帧级同步拼接，PL只负责MIPI解包和简单的预处理。这样虽然延迟增加一帧，但稳定性高很多。至于开源方案，Xilinx的Video Framebuffer Read/Write IP核可以配合使用，但注意它们都是基于AXI4-Stream的，如果你要用多路，必须自己写一个Arbiter来做帧级选通。最后问一句：你用的是Zynq-7000还是MPSoC？因为MPSoC的VCU有硬件拼接加速器，但只支持H.264/HEVC流。如果是7000系列，建议多看看UG934里的Video Pipeline示例。

说个工程上偷懒但管用的做法：别在TUSER上纠结时间戳，那玩意儿跟CSI-2协议冲突。你直接在PL里写个简单的帧序号插入模块，每检测到一次帧起始就在像素数据的高4位里加一，然后扔进异步FIFO。读侧看到序号连续的就放行，跳号了就把两路FIFO同时清空一次重新对齐。这个办法不需要VDMA改配置，占资源也少。丢帧多半是因为FIFO深度不够，建议至少缓存两帧深度，Zynq的BRAM管够。Vivado里有个Video Frame Buffer IP可以读，但那玩意儿对MIPI入的数据格式要求死板，不如自己写个状态机灵活。你PS端用的什么操作系统？裸奔还是Linux？Linux下中断处理时间戳延迟太大，不适合实时拼接。

兄弟你这问题我备赛时也卡了两周，说点扎心的：现成的IP核基本都不好使。Xilinx的Video Mixer要求输入帧率严格一致，两个OV5640哪怕硬件触发同步了，PLL锁相环的抖动就能让帧长差出几行像素，积累几帧后画面直接错位。正确做法分三步：第一步，在PL里给两路MIPI解包后的像素时钟各接一个MMCM做动态相位补偿，让两路时钟频率差值小于0.01%。第二步，写一个双端口异步FIFO，写侧用各自像素时钟，读侧用同一路时钟，深度至少存够两帧半——别问我为什么是两帧半，实测两帧在极端情况会溢出。第三步，在FIFO读出侧加个帧同步状态机：检测到两路同时出现帧起始时开始输出，如果某路帧结束信号先来而另一路还没结束，就把先结束那路读侧强制插入空白像素补齐，直到另一路结束。这样即使丢帧画面也只是短暂撕裂一下，不会永久错位。TUSER那个信号是给MIPI CSI-2协议层用的，你拿来打时间戳等于跟协议打架。开源方案可以看看Digilent的Zybo视频例程，但那个只做了单路显示，多路得自己改。你摄像头是用的FMC子卡还是自己画的板？子卡的话走线等长控制很重要，不等长会导致MIPI数据歪斜进而丢帧。另外问一下，你VDMA配置的是Auto还是Manual模式？Auto模式下帧计数器的复位时机很容易被忽略，踩过这个坑的人挺多的。

参加过两届大赛的老油条说句实话：实时视频拼接最容易被忽视的坑是AXI4-Stream的握手机制。你打时间戳丢帧，八成是TUSER信号在跨时钟域时没做同步处理，或者你的Slave接口把valid拉高后不等ready就撤了。建议你先把ILA挂到AXI接口上，看看TREADY和TVALID之间有没有断流。如果断流频繁，那就是FIFO反压导致丢帧，不是同步问题。摄像头帧率不一样就更好办了，把两路的数据都先写进DDR里，用PS端一个定时器中断统一调度读出，每帧读之前比较一下两路帧号，号不对就等一帧。这方法牺牲一点实时性，但代码量少，适合备赛赶时间。别搞什么硬件触发同步了，OV5640那破芯片的触发引脚响应延迟能差200多个时钟周期。你PS端用的DDR带宽够吗？两路1080p@30fps加拼接算法，Zynq-7020的带宽很紧张，建议降分辨率到720p。