2026年FPGA校招面试被问「你这个项目为什么要用FPGA而不是STM32」，怎么答才能让面试官觉得你懂架构选型？

面试官想听的不是「FPGA快」，而是你算过账。你就说：图像每帧要跑多少路并行算子、允许几毫秒延迟、STM32H7单核主频和DMA带宽撑不撑得住、功耗预算多少。只要能把「算过、比过、选过」讲出来，哪怕最后结论是STM32更合适，也比空喊并行强。你当时到底测没测过延迟？

核心就一句：别背维度，讲取舍。你说图像处理要几路并行、允许多少毫秒延迟，然后说STM32单核跑不满或功耗超标，所以选FPGA。面试官要的是你算过，不是你知道FPGA快。你当时算过帧率和延迟预算吗？

个人感觉这题最稳的答法是走一条主线：延迟确定性。你可以这么讲——项目里一帧图像要在X毫秒内出结果，STM32H7靠DMA搬数据没问题，但算子一旦串行执行，中断和调度抖动会让最坏延迟不可控；而FPGA流水线一拍一拍走，延迟基本可算、可预测。然后补一句：并行度其实不是唯一理由，确定性才是我选它的关键。这样一答，面试官会觉得你在做架构而不是选玩具。你们那套流水线的级数和时钟是多少？

我一般建议把这道题当成一次小型方案评审，而不是知识问答。你可以先给场景约束：分辨率、帧率、允许延迟、功耗预算、BOM成本、团队几个人、给多久开发。然后按这六个维度做对比，但重点讲两三个真正卡脖子的。比如延迟上，FPGA流水线可以做到固定几十个时钟周期的处理延迟，抖动很小；STM32H7即使主频高，中断响应和Cache、总线争用会带来不确定的最坏情况，实时图像里最坏延迟比平均延迟更致命。吞吐量上，FPGA天然按像素或按行并行，STM32更多靠DMA加SIMD指令硬扛，算子一复杂就掉帧。功耗和成本要诚实：FPGA芯片贵、外围电源复杂、开发周期长，如果项目只是低速、低帧率、算法还在频繁改，其实STM32更划算。开发周期这点很多人忽略，算法没定型时用FPGA反复综合布局布线很痛苦，用STM32先验证算法再考虑硬件加速是常见做法。风险也要说：选FPGA意味着要处理时序收敛、跨时钟域、DDR带宽这些坑，团队没人扛得住就是风险。最后收一句：我的结论不是FPGA一定好，而是在这个延迟预算和并行度要求下，FPGA的确定性收益大于它的成本和开发代价。如果面试官继续追问，你就把延迟预算和实测数据摆出来。你项目里最坏延迟大概是多少，有没有实测过？

别急着背六个维度，先挑一个你项目里真正说得出口的数字当锚点。比如「一帧 1080p 要在 8ms 内出结果」，然后顺着讲：STM32H7 单核算子串行跑，DMA 搬得动数据但算不过来，而且中断、Cache miss、总线争用会让最坏延迟漂到几十毫秒；FPGA 这边把 Sobel 和阈值做成流水线，从像素进到结果出一共 N 级，每级一拍，延迟基本是常数，抖动只有几个时钟。这么一对比，选 FPGA 的理由就落在「确定性」上，而不是「快」。剩下功耗和成本一句带过：FPGA 贵、外围电源麻烦，如果帧率低、算法还在改，我其实会先用 STM32 验证。面试官要的就是你算过、也认过它的代价。你当时那帧率大概多少？

我换个角度说，这题真正考的是你会不会给自己留退路。很多人一被问就死撑FPGA好，其实成熟工程师会说：先看算法稳不稳。图像处理如果只是几路固定滤波、分辨率帧率都不变，FPGA流水线确实省心；但只要算子还在调、阈值天天改，综合布局布线一轮几十分钟，迭代成本比STM32高一个量级，这时候用H7先跑通算法、测出每帧耗时和最坏情况，再决定哪部分下放到FPGA，是更聪明的路径。所以你可以这么答：我最初也用STM32H7加DMA做过原型，测下来平均能跑，但最坏帧延迟因为中断和Cache抖动超标，而我的场景对延迟上限卡得死，所以把算子并行化搬到FPGA。这样既讲了维度，也讲了风险控制和替代方案，比空谈并行度有说服力。另外补一句成本意识：FPGA芯片贵、电源轨多、PCB层数上去，BOM和开发周期都是实打实的代价，如果项目量小、对成本敏感，选型结论可能反过来。面试官听到你主动提代价，反而觉得你不是在背答案。你那个项目最后是整条链都放FPGA，还是只加速了一部分？

这个问题往深了想，其实是在问你有没有形成一套「先定约束、再比方案、最后认代价」的思维习惯，而不是记住FPGA比STM32快。我给你捋一条因果链，你顺着讲就行。第一步先立约束：分辨率、帧率、允许的最坏延迟、功耗预算、BOM成本、团队人手和开发周期，这几个数不报出来，任何选型都是空谈。第二步比延迟性质：STM32H7主频高、DMA带宽也够，但它是顺序执行加中断驱动，平均延迟好看，最坏延迟会被中断嵌套、Cache miss、总线争用拉长，而实时图像里卡死你的是最坏情况不是平均；FPGA是空间换时间，算子铺成流水线，延迟等于级数乘时钟周期，可算、可预测、抖动小。第三步比吞吐和并行：FPGA按像素或按行天然并行，STM32要么靠DMA加SIMD硬扛，算子一复杂就掉帧，要么降分辨率降帧率，这是实打实的性能天花板。第四步也是最容易被忽略的，是承认代价：FPGA芯片贵、外围电源复杂、PCB难度和层数上去，开发周期长，算法没定型时反复综合布局布线很痛苦。所以完整的答法是——我的场景延迟上限卡得死、算子结构稳定、可以接受更高的BOM，所以选FPGA；如果算法还在频繁迭代或者成本敏感，我会先用STM32H7做原型验证算法，再决定是否下放硬件加速。面试官想听的就是这个「取决于约束」的结论，而不是一句「FPGA快」。你在准备的时候，不妨把项目里那几个关键数字重新算一遍，哪怕当时没测，事后补一个估算也比含糊过去强。你手上有没有当时测的帧耗时数据？

这个问题其实可以拆成两层：一层是技术账，一层是工程账。技术账你面试时肯定要摆，但别只摆并行度。拿实时图像来说，先报约束——分辨率、帧率、允许的最坏延迟。假设 1080p、30fps、要求每帧处理延迟不超过 8ms。STM32H7 主频高、DMA 也能搬，但它是顺序执行加中断驱动，算子是串着跑的，中断嵌套、Cache miss、总线争用会把最坏延迟拉长，平均好看，最坏不可控。FPGA 把 Sobel、阈值这些算子铺成流水线，延迟等于级数乘时钟周期，比如 8 级、100MHz，那就是 80ns 量级，而且抖动只有几个时钟，可算可预测。这是延迟确定性的差异，不是单纯的快。但光讲技术账面试官会觉得你没落地。工程账才是加分项：FPGA 芯片贵、电源轨多、PCB 层数上去，BOM 和开发周期都是实打实的代价。所以我会补一句风险控制——如果算法还在调、阈值天天改，我会先用 STM32H7 跑通原型，测出每帧耗时和最坏情况，再把卡瓶颈的那部分下放到 FPGA 做加速。这样答，面试官听到的是你算过账、也认过代价，而不是背了句 FPGA 快。你那个项目当时算法定型了吗，还是边调边做？

先别急着把六个维度排成一排背出来，面试官一听就知道是模板。我更建议你挑一个自己项目里真有数的场景当锚点，比如一帧1080p要在多少毫秒内出结果。然后顺手带出一个容易被忽略的维度——风险。你可以这么说：STM32H7主频确实高，DMA也能把数据搬得飞快，但它本质是顺序执行加中断驱动，算子串着跑，中断嵌套、Cache miss、总线争用会让最坏延迟漂掉，平均帧率好看不代表每一帧都能按时出。FPGA把Sobel、阈值这些算子铺成流水线，延迟约等于级数乘时钟周期，比如8级、100MHz，那就是80ns量级，抖动只有几个时钟，可算可预测。这是确定性的差别，不是单纯的快。接着补一句风险控制：我一开始也是用H7跑原型的，因为算法没定型时改阈值只要重编译，而FPGA综合布局布线一轮几十分钟，迭代成本高一个量级。等算法稳了、延迟上限又卡得死，才把算子并行化下放。最后诚实认代价：FPGA芯片贵、电源轨多、PCB层数上去，BOM和开发周期都是实打实的。这样答下来，你既算了账，也认了代价，还留了退路。你当时那版算法定型了没，还是边调边测的？

我建议你别把这个问题当成「六个维度背诵题」，而是当成一次「我为什么这么选」的复盘。你项目是实时图像，那就有一条天然主线：确定性的延迟预算。

先给约束。假设你做的是 1080p、30fps、每帧处理延迟要求不超过 8ms。STM32H7 主频四百多兆、DMA 也能把数据搬得飞起，乍看够用。但你要意识到，H7 是顺序执行加中断驱动的：Sobel、阈值、形态学这些算子串着跑，中间任何一次中断嵌套、Cache miss、总线争用，都会让这一帧的最坏延迟往后漂。平均帧率测出来好看，不代表每一帧都按时出。而实时图像里卡死你的往往是最坏那一帧，不是平均。

FPGA 这边性质不同。你把算子铺成流水线，一行像素进来，经过 N 级处理，每级一拍，延迟约等于 N 乘时钟周期。8 级、100MHz，那就是 80ns 量级，抖动只有几个时钟，可算、可预测。这叫延迟确定性，不是单纯的快。你面试时把这句话说出来，比说十句「并行快」都有用。

但光讲这个还不够，面试官会继续问你算过功耗和成本没有。这时候你得诚实：FPGA 芯片贵、电源轨多、PCB 层数上去，BOM 和开发周期都是实打实的代价。而且算法没定型时，综合布局布线一轮几十分钟，改个阈值就要等半天，迭代成本比 H7 高一到两个数量级。所以我常建议的路径是：先用 H7 加 DMA 把算法跑通，测出每帧耗时和最坏情况，等算法稳定、延迟卡死了，再把关键算子下放到 FPGA。这样你既讲了技术账，也讲了工程账和风险控制。

面试官想听的不是「FPGA 好」，而是「你算过、也认过它的代价」。你那个项目当时测过最坏帧延迟吗？