2026年FPGA大赛省赛前两周，队伍卡在"图像灰度+边缘检测"流水线级数分配上，是砍掉中值滤波还是把Sobel拆成两拍？

先说结论：两周这个时间点，我倾向拆Sobel而不是砍中值滤波。原因不是中值滤波更高级，而是砍掉它之后你整条链路的图像质量会掉一档，评委看演示效果时边缘检测的毛刺和噪点会非常明显，而拆流水线是纯时序问题，风险可控。

先把因果理清楚。你综合后差0.6ns，这个数其实不算大，通常意味着关键路径只比约束多了一点点裕量，而不是架构性崩盘。常见原因是Sobel那一级的组合逻辑太厚：3×3窗口取出来后要做9次乘加、再求平方根或绝对值、再比较阈值，全塞在一个时钟周期里。拆两拍是最直接的办法，第一拍做卷积乘加，第二拍做幅值计算和阈值判断。中间插一级寄存器，代价是一个时钟周期的延迟，对实时视频流几乎无影响。

真正要担心的行缓存错位，其实和拆不拆流水线关系不大。行缓存错位一般来自三个地方：一是3×3窗口的移位寄存器深度算错，二是行缓存读写使能跨时钟域没对齐，三是灰度转Sobel之间位宽或valid信号没跟着流水打拍。你拆流水线时，只要把valid、href、vsync这些控制信号和像素数据一起打拍，窗口对齐就不会因为多一拍而错。换句话说，拆流水线只是把数据延后一拍，控制信号同步延后就行，不是重新设计窗口。

我建议的排查顺序是：先确认违例路径到底在哪一级。跑report_timing，看起点终点是不是落在Sobel的乘加或比较器上。如果是，优先在Sobel内部插寄存器，而不是动中值滤波。如果违例出现在中值滤波的排序网络，那才考虑中值滤波本身拆不拆。

具体做法上，中值滤波的3×3排序网络其实也很深，常见做法是拆成两级：第一级做行内三值排序，第二级做列向中值。这样既保功能又降深度。如果时间实在紧，可以先把Sobel拆两拍，综合看违例消没消，没消再动中值。

两周时间，别追求一次到位。先改一处、综合一次、看时序报告，再决定下一步。你们现在综合用的时钟约束是多少？如果约束本身是100MHz而实际像素时钟只有几十兆，那可能还有放松约束的空间。

先别急着砍模块，把0.6ns这个数字放回上下文里看。0.6ns的setup违例，通常不代表架构崩了，而是关键路径上多挂了一两级组合逻辑、或者某级寄存器被综合工具retiming后挤到了一起。你现在这条链路是灰度、中值、Sobel三段，问题大概率出在Sobel那一级，因为3×3窗口出来之后要做9次乘加、再算幅值、再比阈值，这些全堆在一个时钟周期里是典型的厚组合逻辑。中值滤波虽然也有3×3排序，但它是纯比较器网络，没有乘法器，路径往往比Sobel短。所以从时序角度看，砍中值未必真能救回那0.6ns；就算救回来了，你演示时的画面会明显变脏，边缘检测对噪声很敏感，评委一眼就能看出毛刺。

那拆Sobel会不会引入行缓存错位？这里要把两件事分开：行缓存错位属于功能/数据对齐问题，流水线拆分属于时序问题。你插一级寄存器，只是把原本同一拍算完的9次乘加和后续幅值计算分到两拍，数据本身没有错位，错位只可能来自你窗口生成时行缓存深度算错、或者移位寄存器边界没对齐。换句话说，拆流水线不会凭空制造错位，它只是把原本就存在的对齐bug暴露得更明显。所以拆之前，先在testbench里把Sobel输入窗口的像素值打印出来，确认3×3窗口和参考模型一致，这一步做完了再动流水线，风险就完全可控。

具体怎么拆，个人建议在9次乘加之后插寄存器。第一拍：行缓存取出3×3窗口，做乘加得到gx、gy的中间结果；第二拍：算幅值、比阈值、输出。代价是延迟多一拍，对实时视频流几乎没影响，省赛演示根本看不出来。如果拆一拍还不够，可以把gx和gy的乘加也分开，但一般0.6ns拆一拍就够了。另外检查一下你的时钟约束是不是给得太紧，比如明明跑100MHz却按150MHz约束，那0.6ns可能根本不用管。

两周时间，最小可行路径是：先确认约束真实、再拆Sobel一拍、再跑综合看违例是否消失。中值滤波先留着，它是你画质的基本盘。你们现在综合用的时钟频率和约束具体是多少？这个数直接决定0.6ns值不值得大动。

我的做法是拆Sobel，别砍中值。0.6ns多半是Sobel那级组合逻辑太厚，插一级寄存器分成卷积拍和幅值阈值拍，延迟多一拍对视频流无所谓。行缓存错位是窗口对齐的问题，跟拆不拆流水线没关系，拆之前先用仿真把3×3窗口打出来核对一遍就稳了。中值滤波是画质底线，砍了演示效果会很难看，评委对噪点很敏感。

我换个角度说吧。你先别急着在砍中值和拆Sobel之间二选一，先确认那0.6ns到底落在哪条路径上。打开Vivado的report_timing_summary，看slack为负的那条path的Source和Destination分别是谁。如果起点是灰度那级的输出寄存器、终点是Sobel输出的比较器，那基本坐实是Sobel那拍太厚；如果违例路径根本不在图像主链上，比如是某个计数器或者状态机跟像素时钟的跨域交互，那你砍中值、拆Sobel都是白折腾，改半天也没用。这个确认动作半小时内能做完，性价比比直接动架构高得多。

确认是Sobel之后，我的建议是拆两拍，但拆的位置有讲究。常见做法不是随便在中间插一级，而是把3×3窗口出来后的9次乘加放在第一拍，把幅值计算（绝对值相加或平方和开方）加阈值判断放在第二拍。这样第一拍是规整的乘加树，综合工具容易做DSP映射和retiming；第二拍是纯比较和加减，路径短。插一级寄存器只多一拍延迟，对OV5640的像素流来说完全无感。

关于你担心的行缓存错位，其实要分清：行缓存本身属于窗口对齐，跟流水线级数没直接关系。真正会错位的是你插寄存器后，窗口有效信号、行有效信号、帧有效信号没有跟着一起打拍。所以拆的时候，凡是跟数据同步走的valid、href、vsync这些控制信号，都要跟着延迟同样的拍数，用同一组移位寄存器串起来。这一步做对了就不会错位。

替代做法也有：如果两周实在紧，可以先把Sobel的阈值判断挪到后一拍做异步比较，或者干脆把平方和开方换成绝对值相加（很多比赛演示够用），先把时序救回来，功能上几乎看不出差别。这比砍中值划算，中值砍了噪点会直接暴露在边缘图上，评委演示时画面会很脏。

你们现在跑的是多少MHz的像素时钟，Sobel那级综合出来大概多少级LUT？