2026年FPGA校招简历上写「基于Zynq的CNN加速器」，面试官追问端到端吞吐量怎么算，我该怎么补量化指标？

先说结论：面试官问端到端吞吐，不是要你背一个数字，是想看你有没有从「跑通」走到「算得清」。你补指标的顺序可以这样：先算理论上限，并行度乘频率，比如一次算 16 个 MAC、跑到 200MHz，那峰值就是 3.2G MAC/s，折成 FPS 还要除以单帧的运算量。然后实测，用板上计时或者打点，测真实 FPS。关键在第三步，把实测和理论一除，看差多少，再去拆瓶颈：是 DDR 喂不上数据，还是流水线断流，还是数据搬运占了太多时间。你只要能说清「我的瓶颈在 DDR 带宽，实测只有理论的三成」，就已经比只报峰值的人强很多。面试前把优化前后的对比数据整理成一张小表，讲的时候先讲瓶颈再讲怎么优化，别一上来就报数字。你这块板子现在跑的是哪个网络，输入分辨率多大？这个会影响单帧运算量怎么估。

这个问题我拆成两层说，一层是「指标怎么记」，一层是「面试怎么讲」。

先说记指标。很多人简历上只写「实现了 CNN 加速器」，面试官一问就露馅。你至少要有四类数：第一是算力口径，并行度乘频率，比如 16 路 MAC、200MHz，峰值就是 3.2G MAC/s，这是天花板；第二是单帧运算量，拿具体网络算，卷积层的乘累加总数加全连接，得出每帧多少 MAC，两者一除就是理论 FPS；第三是实测 FPS，这个必须上板测，别拿仿真数据糊弄；第四是瓶颈证据，DDR 带宽、BRAM 带宽、DSP 利用率、流水线级数，挑一两个真正卡住你的记下来。

为什么强调「真正卡住你的」？因为新手常犯的错是把所有指标都堆上去，结果面试官问哪个是瓶颈，答不上来。你得做过对比实验，比如优化前 FPS 是 12，优化后是 30，中间你改了数据复用或者加了乒乓缓冲，那瓶颈就很清楚。没有对比，指标就是死的。

再说面试怎么讲。一句话版本可以是这样：「理论峰值是 X FPS，实测 Y FPS，差距主要来自 DDR 带宽不足，数据搬运占了总时间的 Z%，我通过加片上缓存把搬运降下来，FPS 提到 W。」注意顺序：先瓶颈，再优化，最后数字。反过来讲，面试官会觉得你在背简历。

还有个容易被忽略的点，端到端和纯加速器核的吞吐是两回事。端到端要把预处理、DMA 搬运、后处理都算进去，很多项目核里跑得飞快，一加上数据搬运就掉一半。你如果只测了核内吞吐，面试时要主动说清口径，别被追问时才补。

学习路径上，建议你先拿一个小网络，比如 LeNet 或者小型 MobileNet，把这条链路完整走一遍：算理论、测实测、找瓶颈、做一次优化、再测。走完这一轮，你对吞吐的理解就不是纸上的了。你目前项目里数据是从 DDR 直接喂给加速器，还是中间有片上缓存？这个决定了瓶颈大概率在哪。

补个容易被忽略的角度：别只盯着 FPS 这一个数，面试官真正想筛的是「你会不会定位问题」。我见过有人理论算得挺漂亮，一问实测就卡壳，因为他的加速器根本喂不满。

一个具体例子：假设你并行度 8、频率 150MHz，理论 1.2G MAC/s，单帧 300M MAC，那理论 4 FPS。实测只有 1.2 FPS。这时候别急着说「优化不够」，先算数据量：如果每帧输入加权重几百 MB，DDR 带宽假设 1GB/s，光搬数据就要零点几秒，那瓶颈根本不在计算单元，而在搬运。你把这个推理讲出来，比报十个指标都管用。

风险在于，很多人为了简历好看，把理论峰值当实测写，面试官一追问细节就崩。替代做法是老老实实标口径：理论多少、实测多少、瓶颈在哪。哪怕数字不好看，讲清因果反而加分。

另外提醒一句，DSP 利用率高不一定是好事，可能是你在硬堆并行度，结果时序跑不上去，频率掉下来，端到端反而更慢。所以指标之间要能互相解释，不能各说各话。你当时测 FPS 是用什么方式打点的，板上计时还是软件测的？

理论吞吐就是并行度乘频率，比如 16 路 MAC 跑 200MHz，峰值 3.2G MAC/s，再除以单帧 MAC 数就是理论上限 FPS。面试官更想听的是你实测多少、差在哪，比如是不是 DDR 喂不上数据。你板子上现在跑的分辨率和网络是哪个？

理论值就是并行度乘频率，比如你 16 路 MAC 跑 200MHz，峰值 3.2G MAC/s，再除以单帧 MAC 数就是上限 FPS。但面试官八成不是要这个数，是想听你实测多少、卡在哪。你板子上现在跑的是哪个网络、多少分辨率？

一句话：先给理论值（并行度乘频率再除单帧MAC），再给实测FPS，最后补一句瓶颈在哪，比如「瓶颈在DDR带宽，实测只有理论三成」。三个数摆出来，面试官就知道你不是只跑通例程。你板子上跑的是哪个网络？

先说个容易被忽略的点：面试官问吞吐量，真正想听的不是那个除法算式，而是你能不能说清「为什么实测比理论低」。理论那步谁都会算，并行度乘以频率得峰值 MAC/s，再除以单帧 MAC 数得理论 FPS，两分钟的事。分水岭在后面。

所以你的准备顺序应该反过来。先去板上测真实 FPS，别用仿真数，用计时器打点或者拿计数器数帧。拿到实测之后，做一件绝大多数学生没做的事：把端到端时间拆开。一帧的总耗时大致等于数据搬进搬出加计算加层间调度开销。你分别估一下这几块：输入特征图和权重一共多少字节，DDR 理论带宽打个对折当实际可用，除一下就知道纯搬运要多久；再看计算单元的活跃周期占比，如果算的时候经常等数据，那瓶颈就在搬运。

举个具体的推理链给你参考。假设并行度 16、跑 200MHz，峰值 3.2G MAC/s，单帧 320M MAC，理论上限 10 FPS，实测 3 FPS。别急着说优化不够。先算数据量：每帧输入加权重假设 200MB，DDR 有效带宽按 800MB/s 算，光搬就要 0.25 秒，也就是搬运本身就把上限压到 4 FPS 左右了。这时候结论很清楚：瓶颈在 DDR 带宽，不在计算阵列。你把这套推理讲出来，比报十个指标都值钱。

再说记录哪些指标。我的建议是分三层，别一股脑全写。第一层是硬指标：峰值算力、实测 FPS、单帧 MAC 数，这三个必须有。第二层是瓶颈证据：DDR 吞吐、DSP 利用率、BRAM 带宽占用，挑真正卡住你的那一两个记，不要六个都写，写多了面试官随便挑一个问你就露馅。第三层是优化前后对比：比如改数据复用之前 1.2 FPS，之后 3 FPS，中间你做了什么，为什么有效。

面试讲的时候有个小技巧：先讲瓶颈，再讲优化，最后才报数字。比如「我的瓶颈在 DDR 带宽，实测只有理论三成，后来通过输入分块复用把访存降了一半，FPS 从 1.2 提到 3」。这样面试官听到的是解决问题的能力，不是一堆数字。

还有个坑提醒一下：DSP 利用率高不一定是好事。利用率 95% 往往意味着时序紧、布线难，而且可能算力根本没喂满，是在空转。别把它当亮点硬吹。

你板子上现在跑的是哪个网络、输入分辨率多少？这个直接决定单帧 MAC 怎么估，也决定瓶颈到底在算还是在搬。

一句话：理论值等于并行度乘频率再除单帧 MAC，但别只报这个。先测真实 FPS，再补一句瓶颈在哪，比如「卡在 DDR 带宽，实测只有理论三成」，基本就稳了。你实测过没有？