2026年研一刚进组，导师给了块紫光同创PGL22G让我做「CNN加速器」，但实验室没人做过，我该从哪篇论文和哪个开源工程起步才不白耗半年？

先把目标收窄：半年内你要交付的不是「一个能跑ResNet的加速器」，而是一个可写进论文的、边界清晰的小系统。PGL22G这类国产中小容量FPGA，LUT和DSP都有限，硬塞大网络必然翻车。所以第一步不是找论文，是定边界：选LeNet-5或MNIST级别的小CNN，输入28×28，卷积层通道数压到个位数，全连接层做小。这个规模能塞进PGL22G，也能让你把数据流、行缓存、乘累加阵列这些核心机制走通一遍。

论文先啃两篇就够，别贪多。一篇是MIT的Eyeriss（ISCA 2016），它讲的是卷积在硬件上到底怎么复用数据，行固定、权重固定、输出固定这几种dataflow的区别，看完你就知道为什么不能无脑堆PE。另一篇找国内做FPGA CNN的综述或硕士论文，重点看它的系统框图和资源占用表，别纠结数学推导。这两篇看完，你脑子里应该有一张自己的架构草图。

开源工程方面，Xilinx的HLS例程（比如Vitis HLS里的CNN示例）可以拿来理解dataflow，但别指望直接移植到紫光同创。国产工具链的HLS成熟度和Xilinx差距不小，个人感觉手写RTL反而更可控，尤其是你本科写过状态机，时序概念是有的。建议路线：先用纯Verilog写一个单PE的卷积模块，跑通MNIST单张图推理，再逐步扩成PE阵列、加行缓存、做流水。每一步都用仿真验证，别等上板才发现问题。

至于Vitis AI，那是Xilinx DPU生态的东西，和PGL22G基本无关，直接放弃。紫光同创的PDS工具和IP核文档要花时间啃，例程少是事实，但基本原语、BRAM、DSP的用法和Xilinx是相通的，遇到问题多翻官方手册而不是搜中文博客。

半年节奏大概是：前两个月吃透Eyeriss加定架构，中间两个月写RTL跑仿真，最后两个月上板调时序、做对比实验。论文的增量点可以放在国产器件上的资源优化、或某种轻量dataflow的适配，别想着超越Eyeriss。你板子上的DDR和时钟资源具体是什么配置？这会影响你能不能做多帧流水。

最后提醒一句：导师给五个字不代表你要做五个字的事，主动把方案缩到「能做完」比硬扛「听起来大」更重要。

先说结论：别急着选论文，先选一个能跑通的端到端小系统，论文是用来解释你踩过的坑的。PGL22G这类国产中小容量FPGA，逻辑和DSP资源都不宽裕，硬塞大网络必然翻车。所以第一步是定边界，不是找论文。选MNIST或CIFAR-10级别的小CNN，输入28×28，卷积通道压到个位数，全连接做小，这个规模既能塞进板子，也能让你把行缓存、乘累加阵列、数据流这些核心机制完整走一遍。论文先啃两篇就够。一篇是Eyeriss（ISCA 2016），它讲卷积在硬件上到底怎么复用数据，权重固定、输出固定、行固定这几种dataflow的取舍，看完你就明白为什么不能无脑堆PE。另一篇找国内做FPGA CNN的硕士论文或综述，重点看它的系统框图和资源占用表，别纠结数学推导。开源工程方面，别一上来就碰Vitis AI那种面向Xilinx平台的重型工具链，国产板子适配起来会让你怀疑人生。建议找纯Verilog或HLS写的轻量CNN加速器，比如GitHub上搜FPGA CNN accelerator Verilog，挑star数中等、代码量在几千行以内、带仿真testbench和权重导出脚本的。关键是能仿真通过，再考虑上板。工具链上，紫光同创的PDS和Xilinx的Vivado差别主要在IP核和约束写法，你本科写过UART和状态机，说明时序和状态机基础是有的，缺的是数据通路设计经验。所以半年节奏可以这样排：前两个月吃透Eyeriss的dataflow概念，同时把一个小CNN的Python推理跑通并导出权重；第三到四个月照着开源工程改，先仿真对齐，再综合看资源报告；第五到六个月上板调通，把资源占用、吞吐、功耗这些数据整理成论文素材。记住，导师要的不是性能多强，而是你能把这条链路完整走通并说清楚取舍。你那块板子的具体型号和片上DSP数量确认过吗？这直接决定你能塞多大的网络。

我换个角度说，你现在最大的风险不是选错论文，而是被工具链拖死。HLS、手写RTL、Vitis AI这三条路，对PGL22G来说其实只剩一条半：手写RTL是稳的，HLS要看紫光同创对高层次综合的支持程度，很多国产工具链这块还不成熟，Vitis AI基本可以排除，那是Xilinx生态的东西。所以主思路应该是以手写RTL为主线，把CNN加速器拆成几个可独立验证的模块：行缓存、卷积PE阵列、池化、全连接、权重加载。每个模块先写testbench仿真对，再拼起来。论文方面，Eyeriss给你dataflow的框架，国内硕士论文给你工程实现的参考，两者搭配看。开源工程建议挑那种模块划分清晰、每层有单独仿真用例的，哪怕性能一般，只要你改得动、调得通，就是好起点。半年出成果的关键在于验证路径清晰，而不是性能多高。你导师对论文的期望是会议还是期刊，这个也影响你要不要做对比实验。

先说个容易踩的坑：研一进组最怕的不是没论文看，是半年过去只攒了一堆PDF和一堆跑不起来的工程。你现在有个隐性优势——实验室没人做过，意味着导师对你的预期不会卡在性能指标上，你只要交付一条能自圆其说的完整链路就够写进论文了。

所以第一步不是选论文，是选一个「能被你亲手改坏再修好」的开源工程。判断标准很简单：模块划分清楚、每层有单独仿真、代码量你别一看就绝望。找到之后先别改架构，只做一件事——把它的仿真跑出波形，逐层看数据怎么流动，尤其是行缓存和卷积PE那两块。这一步做完你对dataflow的理解会比读三篇论文都实在。

论文就啃两篇，多了是浪费。Eyeriss那篇讲数据复用和几种dataflow取舍，看完你会明白为什么不能无脑堆PE。再找一篇国内做FPGA CNN的硕士论文，重点看系统框图和资源占用表，别纠结公式推导。至于Vitis AI，那是Xilinx生态的东西，对PGL22G基本可以排除，别在这上面耗时间；HLS也要先确认紫光同创工具链支持到什么程度，很多国产工具这块还不成熟。

风险提示一句：如果三个月后你的加速器还只能跑仿真、上不了板，就要果断砍网络规模，别死磕。你现在手上的板子具体是哪个型号、配套的PDS版本装好了吗？

先说个容易被忽略的现实：你师兄师姐做通信，对你的直接帮助可能比你想的大。通信里那套「先建模、再定点仿真、最后上板」的流程，和CNN加速器其实是一回事，你可以直接借他们的验证习惯和仿真脚本框架，别自己从零造轮子。

第一步我建议先把「半年能写进论文的东西」定义清楚，不是跑通ResNet，而是：一个你自己搭出来的、能算通LeNet或MNIST级小CNN的加速器，有资源占用表、有和软件对拍的误差曲线、有几种dataflow的对比。这个边界定下来，后面所有取舍都围绕它。

论文别贪，Eyeriss那篇（ISCA 2016）必须啃，重点不是公式，是权重固定、输出固定、行固定这几种dataflow到底怎么省带宽。看完你再去翻一两篇国内FPGA CNN的硕士论文，只看系统框图和资源占用表，看别人怎么把通道数、并行度、位宽这三者配平。

开源工程的选择标准很实际：模块划分清楚、每层有独立testbench、代码量你一周能读完。别碰Vitis AI，那是Xilinx生态的东西，PGL22G的国产工具链基本走不通。HLS也先放一放，紫光同创对高层次综合的支持成熟度一般，你耗在工具bug上的时间会远超省下的RTL工作量。老老实实手写RTL，行缓存、卷积PE阵列、池化、全连接分模块验证。

风险这块提醒一句：国产工具链例程少，遇到综合报错很可能搜不到答案，建议早点混进紫光同创的官方论坛或用户群，比你自己闷头调两天强。

你现在板子到手了吗，工具链装的是哪个版本？这个直接决定你后面踩坑的类型。

如果你只想记一句话，那就是：这半年你真正要练的不是「做一个加速器」，而是「把一条数据流从软件映射到硬件、并且能解释每一步为什么这么选」。CNN加速器只是个载体，半年后能写进论文的，是你对dataflow、并行度、位宽、带宽这几件事的判断力。

顺着这条主线走，第一步该定的是规模，不是论文。PGL22G这类国产中小容量FPGA，LUT和DSP都紧张，你硬塞CIFAR-10以上的网络，综合阶段就会卡死。所以把网络压到MNIST或LeNet级别，输入28×28，卷积通道个位数，全连接做小。规模定死之后，你会发现后面所有问题都变得可回答：行缓存要多大、PE阵列摆几乘几、权重放片上还是走DDR，全都有边界了。

论文只啃两篇。Eyeriss（ISCA 2016）负责给你dataflow的思维框架，它讲清楚了为什么卷积硬件不能无脑堆PE，权重固定和输出固定各自的代价在哪。另一篇找国内做FPGA CNN的硕士论文或综述，负责给你工程参考，重点看系统框图和资源占用表，公式推导跳过。这两篇看完，你对「我的设计该长什么样」会有具体画面。

开源工程的作用是给你一个能被改坏的起点。挑那种模块清晰、每层有单独simulation的工程，先别动架构，只做一件事：把它的仿真跑出波形，逐层追数据怎么流动，尤其是行缓存和卷积PE这两块。这一步做完，你对dataflow的理解比读三篇论文都实在，因为你是看着波形理解的，不是看着公式。

工具链取舍上，手写RTL是主线。HLS能不能用，取决于紫光同创当前版本对高层次综合的支持程度，很多国产工具链这块还不成熟，你如果拿它当主力，很可能把时间全耗在工具bug上。Vitis AI直接排除，那是Xilinx的生态。

验证路径要清晰：每个模块先自己写testbench仿真对，再拼成整条链路，最后和Python或MATLAB的软件结果对拍，看误差是不是在定点化能解释的范围内。这条路径走通，论文的图和数据就都有了——资源占用表、误差曲线、不同并行度下的吞吐对比，足够支撑一篇硕士论文的核心章节。半年时间紧但不至于不够，前提是你别在选型上反复横跳。你导师有没有给具体的性能指标，还是只要「做出来能跑」就行？