2026年FPGA毕业设计选了「基于Zynq的实时人脸检测系统」，导师说工作量不够，要加什么模块才能稳过盲审？

先说结论：别换YOLO，也别碰视频编码。换YOLO意味着你要重新搞一遍模型量化、重新调PL端加速器的数据流，一个本科毕设的周期根本兜不住，最后大概率是模型跑不动或者精度掉得没法看。视频编码输出倒是能加一点工作量，但它和你的主线是两张皮，盲审老师一眼就能看出来是硬凑的。

比较稳的加法是往「系统闭环」上走，而不是往「算法更深」上走。你现在的框架是PL预处理+CNN加速、PS跑Linux和QT，这其实已经是个完整链路了，缺的是让它看起来像一个能用的系统。举几个例子：加一路摄像头输入的自动曝光/白平衡调节逻辑，PL端做统计、PS端做决策回写寄存器，这就是个正经的软硬件协同模块；再加个检测结果的跟踪，比如简单的IOU匹配或者卡尔曼，让框不会每帧乱跳，这个纯PS端软件就能写，工作量不小但风险低；还可以做多分辨率自适应，根据输入帧率动态调整PL端流水线的工作模式。

这些模块的共同点是不动你的核心加速器，都是在周边加功能，改坏了也能回退。盲审看的是你做了什么设计决策、怎么权衡的，不是看你的模型有多新。

你板子到手了吗，PL端现在跑到什么程度了？

先说个容易踩的坑：别把「工作量」理解成「堆功能数量」。盲审老师看的是你这条链路有没有闭环、有没有你自己做的决策，而不是你塞了几个模块进去。你这个题目本身其实不差，PL预处理加CNN加速、PS跑Linux和QT，链路是通的，问题在于看起来像「照着教程跑了一遍」。

我的建议是往「软硬件协同的闭环」上加，而不是往算法更深的方向加。比如加一路自适应曝光：PL端用直方图统计当前亮度，PS端根据统计结果回写寄存器调增益，再把这个过程用QT画出来。这个模块不难，但它天然跨了PL和PS，答辩时你能讲清楚「为什么统计放PL、决策放PS」，这就是加分点。

再比如加目标跟踪，用IOU匹配或者简易卡尔曼把人脸框稳住。纯PS端软件就能写，风险低，但视觉上效果提升很明显，演示时框不会一帧一个样。

至于你提的三个方向，我说下风险：换YOLO基本等于重做一遍量化和加速器数据流，本科周期兜不住；视频编码输出和主线是两张皮，容易被看出硬凑；多路拼接倒是可以，但要注意别把带宽撑爆，Zynq的DDR带宽在1080p多路下是紧的。

你现在的板子是哪块，PL侧还剩多少逻辑资源？这个决定了你能加多少东西。

我按一条主线来说：你导师说工作量不够，本质不是嫌你模块少，而是嫌你「没有工程取舍的痕迹」。一个毕设如果从头到尾都是「我用了什么」，没有「我为什么这么选、放弃了什么」，那在盲审眼里就是课程设计放大版。

所以加模块的正确姿势，是加那种能让你产生「取舍故事」的模块。举个例子，假设你加多分辨率自适应：输入可能是720p也可能是1080p，你让PL端先做缩放，再送进CNN。这里面立刻冒出一堆可以写进论文的东西——缩放用双线性还是最近邻，资源差多少；缩放放在预处理前还是后，对检测精度影响多大；帧率掉了多少，你怎么在QT上把帧率显示出来做对比。这些不是「我加了个模块」，而是「我做了三组实验，选了折中方案」。

再往深一层，你可以把整条链路的延迟拆开测：PL预处理多少毫秒、CNN推理多少毫秒、PS后处理和显示多少毫秒。这个测量本身就是一个模块——在PL里插时间戳计数器，在PS里读出来统计。听起来简单，但很多毕设根本没做过端到端延迟分析，你做了，论文里就有一节别人没有的内容。

关于换YOLO，我的判断是别换。人脸检测用轻量CNN已经够，换成YOLO你要重新做量化、重新对加速器的数据排布，这些工作量不是「加模块」，是「重开一局」。视频编码输出也一样，除非你的演示需要推流到手机看，否则它和检测主线没有因果关系，写进论文会显得突兀。

一句话：加能产生对比实验和取舍论证的模块，别加只是「多了一个功能」的模块。你PS端现在跑的是哪个Linux发行版，QT是直接读framebuffer还是走DRM？这个会影响你加延迟统计的难度。

先说一个判断：你导师说工作量不够，大概率不是嫌你模块少，而是嫌你整条链路里看不到「你自己做的决策」。你现在这个结构，PL预处理加CNN加速、PS跑Linux和QT，本身是通的，但给人的观感是照着教程走了一遍。盲审老师翻你的论文，最想找的是「你遇到了什么问题、你比较了哪些方案、你最后为什么选这个」。所以加模块的正确姿势，是加那种能逼你产生取舍故事的模块，而不是单纯堆功能。

沿着这条主线，我建议你加「多分辨率自适应」这一条，而不是换YOLO、也不是加视频编码。原因很直接：换YOLO意味着模型、量化、PL端加速器的数据流全要重来一遍，本科毕设的周期基本兜不住，最后很可能卡在模型跑不动或者精度掉得没法看。视频编码输出虽然能加点工作量，但它和你的主线是两张皮，盲审一眼能看出是硬凑的。

多分辨率自适应为什么值？因为摄像头输入可能是720p也可能是1080p，你先在PL端做缩放，再送进CNN。这里面立刻冒出一堆能写进论文的东西：缩放用双线性还是最近邻，资源差多少；缩放放在预处理前还是后，对检测精度影响多大；帧率掉了多少，你怎么在QT上把帧率显示出来做对比。这些不是「我加了个模块」，而是「我做了三组实验，选了折中方案」。

再往深一层，你可以把整条链路的延迟拆开测：PL预处理多少毫秒、CNN推理多少毫秒、PS后处理和显示多少毫秒。这个测量本身就是工作量，而且答辩时你能对着数据讲清楚瓶颈在哪、你怎么权衡的。老师一听就知道你是真做过，不是跑了个demo。

顺带说个配套的小模块，风险很低但加分明显：加一路检测结果跟踪，用简单的IOU匹配或者轻量卡尔曼把人脸框稳住。纯PS端软件就能写，不碰PL，但演示时框不会一帧一个样，视觉效果好很多，论文里也能写「跟踪前后框抖动对比」。

所以路线大概是：先补跟踪稳住演示效果，再做多分辨率自适应这条主线，最后把延迟拆解测出来。别贪多，把一条做透比铺三条半成品强。你现在的CNN加速器是打算自己写还是用现成的IP？这个会直接影响多分辨率那条路好不好走。