2026年FPGA校招简历上写「基于Zynq的AI加速器」但只会跑通demo，面试官追问吞吐率怎么算该怎么补？

先说个残酷但省时间的判断：如果最后两个月你只是把开源工程再跑一遍，简历上「基于Zynq的AI加速器」这句大概率会被问穿。面试官不一定要求你真流片，但要求你对自己写的东西有第一手数字。补的方向不是把CNN理论重学一遍，而是把这个项目的三个数字吃透：峰值算力、实测吞吐、资源占用。

峰值算力的公式其实就一句话：峰值GOPS = MAC单元数 × 2 × 时钟频率（单位对到GHz就是G）。一个MAC每周期做一次乘加，乘加算两次运算，所以乘2。比如你PL端例化了64个乘法器、跑200MHz，那就是64×2×0.2 = 25.6 GOPS。注意这是理论上限，实际受数据供给、流水线气泡、DDR带宽拖累，能到三成就算不错。

实测吞吐率要落到具体任务上：用帧率×每帧运算量。比如跑一张224×224的图，模型总运算量是0.3 GMAC，那每帧就是0.6 GOP；如果实测30帧每秒，吞吐就是18 GOPS。这里最容易翻车的是单位混用，MAC和OP、GMAC和GOP别搞反，面试官一听就知道你算没算过。

资源这块建议做一张小表：DSP用了多少、BRAM多少、LUT多少，再对比综合报告里理论能用的数量，算出占用率。同时准备一句话解释为什么是这个数，比如卷积并行度决定了DSP数量，行缓存决定了BRAM。

风险提示：如果你连自己工程的并行度参数都说不清，别硬撑，可以在简历上加「复现并分析」这类限定词，把重点放在你改了什么、测了什么。面试官更在意你有没有量化意识，而不是你造了个多牛的芯片。你现在的工程大概是什么模型、什么分辨率，这决定了每帧运算量怎么估，先把这个数拿出来吧。

这个问题我特别理解，因为校招面试官问吞吐率，从来不是考你背公式，而是想验证你到底有没有亲手碰过这个工程。我按一条主线帮你捋：从「跑通demo」到「讲清楚一个加速器」，中间差的其实是数据流这条链。

你先得能画出数据流图。输入特征图从DDR进来，经过行缓存、滑窗、乘加阵列、累加、激活、量化，最后写回。画出来之后，每个环节的并行度就自然浮现了：一行同时算几个像素，一个周期几个通道并行，流水线有几级。这些数字直接决定你的MAC数。很多人卡在说不清并行度，本质是没画过这张图。

有了并行度和频率，峰值算力就出来了。但面试官紧接着会问实测，这时候你要能说清测试方法：是用PL端计数器统计周期数，还是用PS端计时跑固定帧数取平均。两种方法误差来源不同，前者不含DDR搬运，后者含，你要能解释差异。吞吐率=帧率×每帧运算量，每帧运算量按模型乘加总数算，别拿峰值去反推。

再往深一层，是资源与理论的对比表。DSP占用对应乘法器数量，BRAM对应行缓存和权重缓存，这两项和你的并行度、分块策略强相关。做这张表的意义在于，面试官问「为什么DSP用超了」，你能答出是并行度太高还是位宽没压。

取舍上，最后两个月别贪多。挑一个卷积层，把它的数据流、并行度、DSP/BRAM占用、实测帧率完整走一遍，形成一套自洽的数字，比泛泛了解整个CNN有用得多。常见误区是只记结论不记推导，面试官一追问「这个数怎么来的」就露馅。

如果时间实在紧，宁可把简历改成「复现并完成性能分析」，也别硬扛「加速器设计」。诚实加上量化，反而是加分项。你这个开源工程是哪个模型、跑在什么分辨率上，先确定这个，每帧运算量才好估。

先说一个容易被忽略的风险：面试官问吞吐率，往往不是要你背公式，而是想确认你对自己项目有没有第一手数字。所以最后两个月的补法，不是重学CNN，而是把三个数吃透。峰值算力就一句：MAC数×2×频率。比如你例化64个乘法器、跑200MHz，那就是64×2×0.2=25.6 GOPS，乘2是因为一次乘加算两次运算。注意这是理论上限，实际能到三成已经不错，受数据供给、流水线气泡、DDR带宽拖累。

实测吞吐率落到具体任务：帧率×每帧运算量。比如跑224×224的图，模型总运算量0.3 GMAC，那每帧就是0.6 GOP，跑到50帧就是30 GOPS。测试方法要能说清：是用PL端计数器统计周期数，还是PS端计时跑固定帧数取平均，两者误差来源不同，前者不含DDR搬运，后者含。

再准备一张表，把DSP、BRAM、LUT的实测占用和理论估算列出来，差在哪要能解释。数据流图也得能画：输入从DDR进来，经行缓存、滑窗、乘加阵列、累加、激活、量化写回，每个环节的并行度直接决定MAC数。

替代做法也有：如果实在算不清实测，就老实说这是跑通的开源工程，你做了哪些改动和验证，别硬编数字。面试官最怕的是你报一个自己都解释不了的数。你现在PL端例化了多少MAC、跑多高频率，这两个数定了吗？

先别急着背公式，我更想让你先把一件事想明白：面试官追问吞吐率，其实是在验证你有没有真正「拥有」这个项目。只会跑 demo 的典型症状就是，被问一句数字就卡壳，然后开始含糊其辞，这比直接说『这块我还没细算』更伤。所以最后两个月的补法，核心不是把 CNN 理论重学一遍，而是围绕你这个工程建立一套自洽的数字链条。

这条链条的起点是数据流图。你得能白板上画出：特征图怎么从 DDR 搬进来，经过行缓存、滑窗、乘加阵列、累加、激活、量化，再写回。画出来之后，并行度自然就浮出来了——一行同时算几个像素、一个周期并行几个通道、流水线切了几级。这些数字直接决定你的 MAC 数量，而 MAC 数就是峰值算力的分子。峰值算力的公式一句话：MAC 数 × 2 × 频率。乘 2 是因为一次乘加算两次运算。比如例化 64 个乘法器、跑 200MHz，就是 64×2×0.2=25.6 GOPS。但你要主动补一句：这是理论上限，实际受数据供给、流水线气泡和 DDR 带宽拖累，能到三成就算不错。

然后是实测吞吐率，公式是帧率 × 每帧运算量。这里的关键是你能说清测试方法：是用 PL 端计数器统计周期数，还是 PS 端计时跑固定帧数取平均。前者不含 DDR 搬运，后者含，误差来源完全不同，面试官很可能顺着这条线追问。

再准备一张表，把 DSP、BRAM、LUT 的实测占用和理论估算列在一起，能解释差在哪。做到这三点，你这个项目就从『跑通过』变成了『我算过、我测过』。你这个工程大概是什么并行度配置，方便的话说下，我帮你看看数字链哪里最容易被问穿。

如果只能补一件事，我建议你先把并行度这条线捋清楚，因为它同时决定了峰值算力和资源占用，是两个高频追问的交汇点。

具体做法：对着你的开源工程，找到卷积阵列那部分代码，数清楚一个周期内到底例化了多少个乘法器，这就是 MAC 数。再确认时钟频率，峰值算力就是 MAC 数 × 2 × 频率，单位对上 GHz 就行。很多人背得出公式，却说不出自己工程里的 MAC 数，一问就露馅。

接着往数据流上游走一步：这些乘法器的输入从哪来？行缓存深度够不够？滑窗有没有产生流水线气泡？把这些想通，你就能解释为什么实测吞吐率只有峰值的三成左右，而不是干巴巴报一个数。实测那一侧，帧率 × 每帧运算量，测试方法要么 PL 计数器要么 PS 计时，两种口径的差异也要能说。

最后补一张 DSP/BRAM 实测占用和理论值的对比表，能解释差额来源。这三块凑齐，项目就立得住。

我换个角度说，因为前几批大概都在讲公式，你多半已经背下来了。真正让你两个月后能站住的，不是记住峰值算力等于MAC数乘2乘频率，而是你能不能用这条公式反推出自己工程里的瓶颈在哪。面试官追问吞吐率，本质是想看你有没有把「数字」和「设计决策」连起来。

你先做一件事：打开你的工程，找到卷积阵列那部分，数清楚一个周期里到底例化了多少个乘法器。这个数就是MAC数。别嫌笨，很多人说不出来。数完再确认时钟频率，峰值算力就出来了。但注意，这只是理论上限，面试官接下来一定会问实测为什么差那么多，这时候你要能往上游走一步。

上游是什么？是数据供给。你的行缓存有多深，滑窗有没有产生气泡，DDR搬一块特征图要多少周期，这些决定了乘法器大部分时间是在等数据。常见情况是实测吞吐只有峰值的三成左右，如果你能说清楚「差的那七成里，有多少是因为行缓存深度不够导致流水线断流，有多少是因为DDR带宽吃满」，那你这个项目就从跑demo变成了你真懂。

实测那一侧，帧率乘每帧运算量，这个口径要固定。测的时候是用PL端计数器统计周期数，还是PS端跑固定帧数取平均，两种结果不一样，前者不含DDR搬运，后者含。你得说清楚自己用的是哪种，误差从哪来。

最后准备一张表，把DSP、BRAM、LUT的实测占用和理论估算列在一起，差额能解释就解释，解释不了就说这块还没细究。面试官不怕你有没搞懂的地方，怕的是你含糊其辞。

你现在的工程跑在什么频率、卷积阵列例化了多少乘法器，这两个数你手头有吗？

建议你先别背公式，先回工程里数一个数：PL 里一个周期到底例化了多少个乘法器，再确认跑多少 MHz。MAC 数乘 2 乘频率就是峰值，实测那边用帧率乘每帧运算量。数不出来，简历那句就悬。你现在手上有这个工程的源码吗？

别急着背公式，先做一件更省时间的事：把工程里的乘法器数量数出来，再确认时钟频率。MAC数×2×频率就是峰值，实测拿帧率×每帧运算量。数不出来，简历这句就真站不住。你手上有源码吗？

先把流片和跑通分开看：面试官问吞吐率，八成是想验证你知不知道瓶颈在哪。你只要能在白板上画出数据流，标出并行度，说一句峰值等于MAC数乘2乘频率、实测掉在三成左右，基本就稳了。你工程里卷积阵列一个周期例化几个乘法器？

先别背公式，去数一个数：PL 里一个周期例化了几个乘法器。这个数就是 MAC 数，乘 2 再乘频率就是峰值算力。乘 2 是因为一次乘加算两次运算。比如 64 个乘法器、200MHz，就是 64×2×0.2=25.6 GOPS。数不出来就说明简历那句确实悬。实测那边用帧率乘每帧运算量，别报个孤零零的 GOPS。你工程里卷积阵列那部分代码还能找到吗？