2026年FPGA大赛用国产紫光同创盘古板做实时目标跟踪，为什么算法在MATLAB里跑通、上板后框选延迟半秒，是流水线断流还是DDR带宽被抢？

先说结论：半秒延迟在紫光同创盘古这种平台上，十有八九不是单一原因，而是流水线没打满和DDR被视频通路抢带宽叠加出来的。你可以先做个粗略的判据：如果延迟跟画面内容复杂度基本无关、就是个固定的半秒，那更像是某处FIFO或者帧缓存凑了整帧的缓冲；如果延迟随场景变化、目标一多就抖，那更偏向DDR仲裁抢占。

排查顺序我建议从后往前。第一步，先把DDR这一环摘干净：把视频通路接成纯直通（不做跟踪），看从sensor到显示的总延迟是多少。如果直通就已经小半秒，那问题在采集或显示侧的缓冲深度，跟跟踪算法无关。第二步，量一下单帧从写入到读出的实际时延，别只看串口打印的帧率——帧率够不代表延迟低，很多队伍的帧率是靠多缓冲堆出来的。PDS里可以用在线逻辑分析仪抓DDR控制器的读写请求信号和仲裁状态，重点看视频通路是不是一直占着高优先级，算法通路拿不到授权。

有个容易被忽略的点：盘古板的DDR带宽是分时共享的，视频写入、视频读出、算法读写特征图、CPU访问会打架。常见做法是给视频通路设成固定优先级但在行消隐期让出，或者干脆把一帧的一小块（ROI）搬到片上RAM里处理，别每帧都全图过DDR。这是典型的空间换带宽取舍。

风险在于，很多队伍一上来就优化算法，其实瓶颈在数据搬运。你可以先写个最小测试：只搬一帧图像绕DDR跑一圈，测端到端延迟，这个基线能帮你判断到底该动算法还是动架构。你们现在跟踪模块是整帧处理还是只做ROI，这个会直接决定后面往哪个方向调。

半秒延迟，多半是缓存凑了整帧再加DDR仲裁没配好。先做直通测量：不跑算法，看sensor到显示的延迟，如果已经很大，就别怀疑流水线了，是采集/显示缓冲的问题。PDS里抓DDR仲裁和FIFO水位，比猜有用。

这个问题得往架构层面想，不然容易在细节里绕圈。

先说一个基本判断：所谓实时目标跟踪，在FPGA上真正难的不是算法本身能不能算出来，而是数据从哪来、算完往哪去、中间要不要等。MATLAB里帧率够，是因为它默认数据都在内存里躺着，随取随用；上板之后，每一帧图像都要经过sensor接口、写DDR、被算法读、结果再写回去、最后送去显示，每一个箭头都可能是等待。半秒延迟，说明这条链上至少有一处攒够了一帧甚至几帧的量才动一次。

流水线断流和DDR抢带宽，本质上是同一类问题的两种表现：一个是数据没准备好，一个是数据准备好了但通道被占。区分它们的方法很朴素——看延迟是恒定的还是抖动的。恒定半秒，通常是缓冲深度设计成整帧对齐的结果，比如你用了双缓冲甚至三缓冲，而每级又都在等垂直同步；抖动且随目标数量变化，才是仲裁层面的事。

那怎么在PDS里定位？我的经验是别一上来就抓信号，先做减法。把跟踪算法整个旁路掉，只留采集到显示的通路，测延迟。这一步是为了确认你的基线。如果基线就高，问题在接口和缓冲策略，比如DDR写入是否用了突发、读出是否被打断；如果基线正常，再逐级把算法模块加回去，每加一级测一次，哪一级把延迟从几毫秒拉到几百毫秒，就是它。

再往深一层，这其实是个工程取舍的问题。很多队伍为了图省事，让每一级都通过DDR传递数据，看着模块解耦了，实际把带宽和延迟都堆到DDR上。更稳的做法是让数据在片上流起来：像素级流水用行缓存和FIFO传，只有需要跨帧访问的中间结果才落DDR，而且尽量落小块ROI而不是整帧。这样做的代价是模块耦合变紧、调试变难，但延迟会下来一个数量级。

对第一次打国赛的队伍，我建议把这次延迟当成一次架构课：先量基线，再逐级加模块定位，最后决定哪些数据该走片上、哪些才配用DDR。这个过程比调通算法本身更有价值。你们现在每一级之间是用FIFO直连还是都过DDR，这个决定了优化的起点在哪。

先把一个容易被忽略的前提摆正：MATLAB 里的实时和 FPGA 上的实时，根本不是同一个词。MATLAB 跑通只能证明算法在数学上成立、定点化之后数值没崩，它证明不了数据在你板子上能按节拍流起来。所以你看到的半秒延迟，我倾向于先别急着归因到流水线或者 DDR 二选一，而是先判断延迟的「形状」——这是最省时间的一步。

怎么判断形状？把目标放到画面里做匀速横移，同时用秒表或者录像对比传感器实际画面和显示器输出。如果延迟基本是个固定的半秒，跟你画面里有没有目标、有几个目标几乎无关，那大概率是缓冲深度问题：某一级 FIFO 或者帧缓存是按整帧对齐设计的，双缓冲甚至三缓冲，每一级都在等垂直同步，延迟自然被堆到几百毫秒。这种延迟的特点是稳定、可预测。反过来，如果延迟会抖，目标一多、背景一花，延迟就涨，那才更偏向带宽和仲裁层面的抢占。你串口打印看到 DDR 仲裁被视频通路抢占，这只是个现象，不能直接等同于根因——视频通路本来就该占高优先级，关键是它占完之后，跟踪算法那一路还能不能拿到足够的带宽和足够低的响应延迟。

接下来往深一层想：流水线断流和 DDR 被抢，其实经常是同一件事的两面。跟踪算法如果按帧处理，就必须先把整帧写进 DDR 再读出来做处理，那它对 DDR 的访问模式就是大块突发、周期性很强。视频显示通路也是周期性大块读写。两条周期性的大流量通路撞在一起，仲裁器只要稍微偏向显示，算法那一路就得多等，等的时间累积起来就是延迟。所以真正要解决的不是「谁抢谁」，而是让两条通路的时间窗错开，或者给算法那一路留出独立的缓冲，别让它和显示去抢同一片区域。

PDS 里定位的话，我的建议是从后往前拆。第一步先做直通：不跑跟踪算法，只做 sensor 到显示的纯通路，量一下总延迟。如果直通就已经接近半秒，那算法根本不背这个锅，问题在采集和显示侧的缓冲。第二步，把跟踪算法的输入输出单独打时间戳，看单帧从写进 DDR 到读出来用了多久，别只看串口打印的帧率——帧率够不代表延迟低，很多队伍的高帧率就是靠多缓冲堆出来的假象。第三步才是看仲裁，抓 DDR 控制器的请求和授权信号，看算法那一路的请求平均要等多少个周期才被响应。

个人感觉你们现在最该做的是第一步直通测量，它能把问题范围砍掉一大半。你们现在传感器到显示这条链路，中间是不是还挂着帧缓存做缩放或者格式转换？