2026年了，FPGA大赛用国产高云做图像处理，时序收敛总差一口气，是砍功能还是换架构？

先说结论：三周时间，砍功能和换架构都不是好选项，你要做的是「降内部数据吞吐，保外部功能外观」。1080p@60 的 Sobel 加中值，真正压死时序的不是算法本身，而是你让一整帧像素在一个时钟域里从头冲到尾。高云 GW2A 这类器件，逻辑资源和布线延迟都比较紧，跨时钟域违例和乘法器违例往往是同一个根因：数据流太宽、组合逻辑太深、时序约束没写对，工具就在那儿乱优化。

具体怎么落地？第一步别急着改 RTL，先打开综合后的时序报告和 ILA，把违例路径按 slack 从小到大排一遍，看清楚最差的那几条到底落在哪。很多人的违例其实集中在一两个跨时钟域握手信号上，比如摄像头像素时钟到处理时钟、处理时钟到显示时钟，这种加一级异步 FIFO 或两级同步器就能救回来，根本不用动 Sobel 主体。乘法器路径同理，Sobel 里的系数乘法如果被综合成通用乘法器，延迟会很难看，改成移位加加法的定系数实现，或者用 DSP 级联，往往直接省掉一大截关键路径。

第二步才是降吞吐。注意是降内部吞吐，不是降分辨率。你可以保持 1080p 输入输出，但把处理时钟提上去、或者用行缓存加流水线把一行像素拆成几拍处理，让每个时钟只算一小段。如果实在来不及，把帧率从 60 降到 30，外部看还是 1080p，评委演示时基本无感，但时序压力直接减半。这比降到 720p 体面得多。

第三步是约束。高云这边很多人只写了 create_clock 就跑了，跨时钟域路径没做 set_false_path 或 set_clock_groups，工具会把本来不该分析的路径当关键路径优化，结果越优越大。把异步 FIFO 两侧、复位同步这些真正异步的路径明确排除，工具才知道该把力气花在哪。

三周够用，但别贪。先保一条能跑通的 1080p 主链路，功能完整度确实是评委第一眼看的。你现在综合报告里违例最狠的那条路径，具体落在哪个模块上？这个信息决定先加 FIFO 还是先改乘法器。

个人感觉你们卡住的地方，大概率不是算法太重，而是流水线切得太粗。Sobel 加中值这种结构，本身很适合打成多级流水：行缓存出来之后，梯度计算、方向判断、中值排序各占一拍，寄存器打满，关键路径自然就短了。你现在综合违例集中在乘法器和跨时钟域，说明这两块要么是组合逻辑一口气算完，要么是信号在时钟域之间裸穿。

我建议的排查顺序是：先看时序报告里违例路径的起点和终点属于哪个时钟域，如果是跨域，就加异步 FIFO 或双触发器同步，顺手把 set_false_path 补上；如果确实在乘法器内部，就把定系数乘法改成移位加法，或者让工具推断 DSP 并插寄存器。做完这两步再重新综合，看违例还剩多少。

至于砍功能还是换架构，我的看法是都先别动。真正该砍的是「内部一拍算完」这个执念，而不是分辨率或算法。实在收敛不了，把帧率降到 30 是性价比最高的妥协。你们现在用的综合工具是高云自家的还是第三方？这个会影响约束写法。

先说句可能不太中听的：三周这个节点，最怕的不是功能单薄，而是你在答辩前一天板子上跑不出稳定画面。评委看完成度这话没错，但完成度不等于分辨率数字，而是一整套能演示、能复现、讲得清楚的东西。所以我的建议是先把功能锁死，再谈别的。

具体点说，你可以只降分辨率不砍算法。1080p@60 换成 720p@60，像素吞吐直接掉一半多，Sobel 和中值的主体逻辑一行都不用动，跨时钟域那边的压力也顺带小一截。演示的时候画面依然流畅，观众看不出你内部省了多少。要是还紧，就把帧率降到 30，绝大多数实时边缘检测的演示效果肉眼根本分不出来。

但降之前先做一件事：别拍脑袋改，打开综合后的时序报告，把违例路径按 slack 从小到大排，看最差的那几条到底在哪。我见过太多人是被一两个异步握手信号卡住的，摄像头像素时钟到处理时钟那一段，加个异步 FIFO 或两级同步器就回来了，Sobel 主体根本没动。乘法器路径也一样，Sobel 里那几个系数是常数，直接让工具推断 DSP 并插流水寄存器，或者干脆写成移位加法，关键路径立刻短一截。

高云这边还有个小坑：约束别写得太随意。create_clock 要覆盖到真实的输入时钟，那些确实不需要分析的跨域路径用 set_false_path 显式放掉，不然工具会在那里反复折腾，把本来能收敛的地方也搞乱。

顺带提个风险对照：换架构是收益不确定、时间确定要花；降分辨率是收益确定、代价可控。三周里前者是赌博，后者是保险。你现在的跨域和乘法器违例，八成不是架构问题，是流水线切太粗、约束没写对。手头有 ILA 的话，先把违例那几条路径抓出来看一眼再决定，别急着动 RTL。