2026年想在秋招前把「FPGA做CNN加速」项目写进简历，只有两个月，该选YOLOv5-tiny还是自己搭一个3层卷积+池化的最小可跑通版本？

先说结论：两个月选3层卷积+池化的最小可跑通版本，而且这个选择本身就应该是你面试时能讲清楚的一个决策。

原因很直接。YOLOv5-tiny看着唬人，但你真正要花时间的地方不是卷积本身，而是量化工具链、DDR带宽规划、前后处理对齐、mAP验证这一整套工程链路。两个月里光把量化后的精度调回来就可能吃掉一半时间，最后你手里是一个跑起来但讲不清的模型，面试官一问「卷积阵列怎么复用」「行缓存怎么处理边界」你就卡住了。而最小版本虽然模型小，但加速器的核心问题一个都不少：数据流怎么走、行缓存怎么设计、乘加阵列怎么复用、定点量化的误差从哪来、吞吐率怎么估。

具体路线可以这样排。前两周把3层卷积的定点版本用Python或C先跑通，确定每层的输入输出尺寸、量化位宽、定点缩放因子，这是你后面硬件设计的参照。第三到第五周做RTL：先做单层卷积的行缓存加乘加阵列，跑通仿真，再串成3层加池化。第六周上板，用UART或VGA把结果送出来验证。第七到八周补吞吐率估算、资源占用报告，整理成能讲的项目文档。

面试官会不会觉得玩具？关键不在模型大小，而在你能不能把设计取舍讲明白。你要能回答：为什么选这个位宽、行缓存深度怎么定的、乘加阵列为什么这么排、吞吐率瓶颈在哪、如果换更大的模型哪里会先崩。这些答得出来，3层卷积比一个跑不通的YOLO强得多。反过来，如果你能把3层版本做扎实，再花一周把YOLO-tiny的一个卷积层替换进去做扩展演示，那就是加分项。

要提醒的是，别把时间平均分给「学工具链」和「做设计」。工具链够用就行，主线是数据流和阵列复用。你现在手上有开发板吗，是哪块？这会影响行缓存和上板验证的具体做法。

换个角度看这事：面试官问你项目，真正想听的不是「我部署了YOLO」，而是「我知道一个卷积加速器的瓶颈在哪、我怎么绕过去的」。所以你的目标不是模型规模，而是让自己有话说。

三层卷积加池化，恰好能覆盖加速器最核心的几个问题。你可以先定一个具体的尺寸，比如输入32×32、三层3×3卷积、通道数从3到16到32，配最大池化。然后按这个尺寸去算：每层需要多少次乘加、行缓存要存几行、乘加阵列开多大、理论吞吐率是多少。算完之后你会发现，瓶颈往往卡在带宽和阵列利用率上，而不是算力本身。这些数字就是你面试时的底气。

YOLO-tiny可以作为最后一周的扩展，把其中一层换成YOLO的卷积配置，看看你的设计怎么改。这样你既有一个能跑通的最小系统，又有一个「我知道往大模型扩展要动哪里」的故事。

你现在是打算用现成的开发板还是自己画板？这会影响你怎么安排上板验证的时间。

两个月做三层卷积+池化，这个选择本身就是简历上最值钱的一段话。我按因果链给你捋一遍。

先说为什么不是YOLOv5-tiny。你的时间不是被卷积吃掉的，是被外围链路吃掉的：量化工具链调精度、DDR带宽规划、前后处理对齐、mAP验证。这几样里任何一项卡住，都可能吃掉你一半时间，而它们恰好是最难在面试里讲出深度的部分——你只会说「我按教程跑通了」。面试官追问一句「量化后的误差主要来自哪一层」，教程不会告诉你答案。

再看三层卷积为什么不是玩具。一个卷积加速器的核心问题，跟模型大小基本无关：数据怎么从外部搬进来、行缓存要开几行才能复用、乘加阵列怎么排布和调度、吞吐率受限于算力还是带宽、定点量化的误差怎么传播。你把输入定成32×32、通道3到16到32、三层3×3卷积配最大池化，然后老老实实手算：每层多少乘加、行缓存存几行、阵列开多大、理论吞吐多少、实际能跑到几成。这一套算完，你对加速器的理解就已经超过大多数「跑通YOLO」的同学了。

路线可以这么排。前两周先用Python或C把定点版本跑通，确定每层的输入输出尺寸、量化位宽、缩放因子，这是后面RTL的参照系。第三到第五周做RTL，先做单层、单通道，再扩到多通道，行缓存和乘加阵列一起搭，边搭边写testbench对比软件结果。第六周做整体集成和上板，哪怕只跑到几十兆时钟也算成功。最后留一周专门做「讲清楚」这件事：把每层的周期数、带宽占用、阵列利用率整理成一张表。

YOLO-tiny放在最后当扩展，把其中一层换成YOLO的卷积配置，看看你的设计要动哪里。这样你手里既有一个真跑通的系统，又有一个「我知道往大模型扩要改什么」的故事。

顺带说一句，你之前做过UART和VGA，说明你有基本的时序和状态机手感，这个项目正好把那些能力接上。你现在打算用现成开发板还是自己画板？这个会直接影响你前两周的时间分配。

先别把「玩具」这个词往自己项目上贴。面试官判断一个加速器项目有没有料，看的从来不是模型多少层，而是你能不能把一条数据通路讲圆。3层卷积+池化的最小版本，恰好能把数据流、行缓存、乘加阵列复用、吞吐率估算这几个核心问题全暴露出来，而这些跟模型大小几乎无关。

给你一个可落地的排法：前三周用Python或C把定点版本跑通，把每层输入输出尺寸、量化位宽、缩放因子定死，这是你后面RTL的黄金参照；第四到第七周做RTL，先做单层卷积，跑通再复制成流水；剩下时间做仿真和上板，能出波形和图就收工。

风险在哪要说清楚：最小版本最大的坑是「讲不出瓶颈」。很多人做完只知道乘加阵列多大，不知道带宽和阵列利用率哪个先到顶。补救办法是手算一遍——每层多少次乘加、行缓存开几行、理论吞吐率多少、实际卡在哪。这几个数算出来，面试就有了支点。

YOLO-tiny别一上来啃，留到最后当扩展：把其中一层换成YOLO的卷积配置，看看你的设计要改哪里，这就够讲一个「我知道往大模型扩要动什么」的故事了。

你现在是打算用现成开发板，还是自己画板子？这会影响你上板那两周的排期。

我按一条主线给你推：两个月里，你的稀缺资源不是算力也不是代码量，而是「能被追问的深度」。

YOLOv5-tiny的诱惑在于名字响，但真正吃掉时间的不是卷积，是它外围那一整条链路——量化工具链调精度、DDR带宽规划、前后处理对齐、mAP验证。这四样里任何一项卡住，都可能耗掉你一半时间，而且它们恰恰最难在面试里讲出层次，你大概率只能说「我按教程跑通了」。面试官追问一句「量化后的误差主要来自哪一层」，教程不会给你答案。

反过来，3层卷积的逻辑是：模型小，但加速器的核心矛盾一个不少。数据怎么从外部搬进来、行缓存要开几行才能复用、乘加阵列怎么排布调度、吞吐率到底受限于算力还是带宽、定点量化误差怎么逐层传播——这些问题的答案跟网络有3层还是30层没关系。你把它定成输入32×32、通道3到16到32、三层3×3配最大池化，然后老老实实手算每层乘加数、行缓存行数、阵列规模、理论吞吐。算完你会发现瓶颈常常卡在带宽和阵列利用率上，而不是算力本身。这些数字就是你面试时的底气。

时间分配上，前两周用Python或C把定点版本跑通，确定每层尺寸、位宽、缩放因子，作为硬件设计的参照；第三到第五周做RTL，先单层再流水；剩下时间仿真上板。YOLO-tiny放最后一周当扩展，把一层换成YOLO的卷积配置，看你设计要动哪里。

这样你手里既有能跑通的最小系统，又有一个「我知道往大扩要改什么」的故事。你目前RTL写到什么程度了，是只会写状态机，还是已经碰过流水线？

先说个容易被忽略的点：面试官判断项目含金量，其实看的是你有没有踩过坑、能不能说出取舍，而不是网络有多少层。三层卷积加池化听着简单，但如果你把它做成定点版本，从数据流、行缓存、乘加阵列到吞吐率估算全走一遍，能聊的东西比一个跑通的YOLO demo多得多。

具体可以这样切：第一到第三周，用Python或C把定点推理先跑通，把每层的输入输出尺寸、量化位宽、缩放因子都定死，这份结果就是你后面RTL的黄金参照，仿真对不上时全靠它。第四到第七周做RTL，别一上来就写完整流水线，先把单层卷积跑通，再加池化，再串成三层。最后两周上板、抓波形、算资源占用。

风险也得说清楚。最小版本最大的坑不是做不出来，而是做完只会说「我实现了三层卷积」，讲不出瓶颈在哪。补救办法是手算几个数：每层多少次乘加、行缓存要开几行、理论吞吐率多少、实际卡在算力还是带宽。这几个数一出来，面试就有了支点。

YOLO-tiny可以放到最后一周当扩展，把其中一层换成YOLO的卷积配置，看看设计怎么改，这样你既有一个能跑通的最小系统，又有一个「往大模型扩展要动哪里」的故事。你现在开发板是现成的还是准备自己画？

先给结论：两个月做三层卷积加池化的定点版本，别碰YOLO-tiny。理由不是难度，是时间去哪了。YOLO这类部署，真正吃时间的是量化工具链调精度、DDR带宽规划、前后处理对齐这几块，任何一环卡住都能耗掉你三四周，而且这些东西面试时你很难讲出层次，只会说按教程跑通了。三层卷积虽然小，但加速器的核心矛盾一个不少：数据怎么从外部搬、行缓存开几行、乘加阵列怎么复用、吞吐率受算力还是带宽限制。你可以定个具体尺寸，比如输入32×32、通道3到16到32、三层3×3配最大池化，然后把每层乘加次数、行缓存行数、理论吞吐率都手算一遍。这几个数摆出来，面试官不会觉得是玩具。你现在板子定了吗，还是准备先用仿真跑通？

两个月的话，我建议直接做3层卷积+池化+定点量化，别犹豫。原因很现实：你之前只碰过UART和VGA，说明你还没建立完整的数据流设计直觉，而YOLO-tiny的坑主要在量化工具链和DDR带宽这些外围工程上，这些东西卡住你的时候你连个能对照的黄金参考都没有。3层卷积虽然小，但数据怎么搬、行缓存开几行、乘加阵列怎么复用、吞吐率卡在算力还是带宽上，这些核心矛盾一个不少。你可以定个具体尺寸，比如32×32输入、3到16到32通道、3×3卷积配最大池化，然后把每层乘加次数和行缓存行数手算一遍。这几个数字摆出来，面试官就知道你不是在跑教程。你现在板子定了吗，还是打算先用仿真跑通？

换个角度说，面试官看项目其实不看模型多大，看你能不能说清楚取舍。3层卷积这个选择本身就是个可以讲的故事：为什么不做YOLO、为什么选这个尺寸、瓶颈卡在哪。我建议你按里程碑排：前两周用Python或C把定点版本跑通，把每层输入输出尺寸、量化位宽、缩放因子定死，这份结果是你后面RTL的黄金参照，仿真对不上时全靠它；第三到第六周做RTL，先写单层卷积跑通，再加池化，最后串成三层，别一上来就写完整流水线；最后两周上板、抓波形、算资源占用和吞吐率。风险在于很多人做完只会说「我实现了三层卷积」，讲不出瓶颈在哪。补救办法就是手算几个数：每层多少次乘加、行缓存要开几行、理论吞吐率多少、实际卡在带宽还是阵列利用率上。YOLO-tiny可以放到最后一周做个扩展，把其中一层的卷积配置换成YOLO的，看看你的设计要改哪里，这样你既有一个能跑通的最小系统，又有一个知道往大模型扩展要动哪里的故事。你现在更缺的是RTL经验还是上板调试经验？