2026年FPGA校招面经：面试官问如何用Verilog实现一个AXI4-Stream接口的实时图像中值滤波，排序网络怎么设计才能不丢帧且资源最省？

冒泡排序在3×3这种小窗口下其实资源也不是完全不能忍，但面试官明显想听你提并行比较器树。三级比较器，每级插一拍寄存器，吞吐率拉满，组合逻辑深度压到3级以内，时序比冒泡好不少。你面试时画个树结构图，再随口说句'比冒泡省约30%LUT'，基本就过了。

兄弟，你提到'不丢帧'这个点很关键，面试官其实在考察你对AXI4-Stream握手协议的理解。排序网络再省资源，如果tready/tvalid配合不好，窗口数据错位一样丢帧。我的建议是：排序核心用并行比较器树，3×3窗口9个输入，第一级做两两比较分出4组最大最小，第二级合并，第三级拿中间值。每级之间插一个寄存器打拍，这样组合逻辑深度最多3级，时钟频率能跑到200MHz以上，不会成为瓶颈。然后重点在窗口滑动部分：用两个line buffer存两行数据，配合移位寄存器生成3×3窗口，每来一个像素tvalid有效，就同时更新窗口并启动排序，排序结果在下一拍通过tdata输出，这样就能做到每时钟周期输出一个像素。资源方面，比较器树大概用50个LUT左右，比冒泡的80到90个省不少。另外注意，面试时最好主动提一句'如果是更大窗口比如5×5，我会考虑奇偶排序或者双调排序树，3×3用比较器树就够'，显得你有扩展性思考。你现在是在准备手撕代码阶段还是已经在系统调试了？如果还在写代码，建议用Vivado综合一下看看实际LUT和FF占比，面试官很吃这种数据。

其实你可以换个思路：3×3窗口排序不一定非要纯排序网络，用'取中值专用电路'也能省资源。9个数找中值本质是找第5大的数，用两两比较加累加器判断每个数大于其他数的个数，等于4的那个就是中值。这种结构用比较器加加法器，逻辑级数比树还低，但缺点是不能直接流水输出，需要额外一拍做计数。如果你项目里时钟裕量够，这个方案LUT能再省10%到15%。面试时提一句'我知道有计数型中值提取方法，但为了流水线吞吐率我优先选了比较器树'，显得你技术视野宽。你用的工具链是Vivado还是Quartus？不同综合器对比较器树优化程度有差异，Vivado会更好一点。

冒泡排序在小窗口下确实直观，但校招面试官更想看你对并行比较器树的熟悉程度。3×3窗口只用三级比较器，第一级把9个数分成3组每3个数比出最大、中、最小，第二级拿三组的最大、中、最小再比，第三级从三个候选里取中值。每级后面插一拍寄存器，组合逻辑深度就两级到三级，时钟轻松上200M。资源上比冒泡省30%到40% LUT，而且流水线吞吐率每周期出一个像素。你面试时能边画边讲这个树结构，提一句'每级插一拍避免长路径'，基本就稳了。另外你实习项目里用过Vivado的HLS吗？还是纯手写RTL？

面试官追问'不丢帧'其实是在考你对AXI4-Stream握手协议和流水线背压的理解。光排序网络省资源没用，窗口数据如果因为tready拉低而错位，中值滤波出来的像素也跟着错。我的做法是：排序核心用并行比较器树，这你已经知道了，但重点在窗口滑动模块。用两个line buffer加一个3×3移位寄存器阵列，每个像素进来时，先判断tvalid和tready是否同时有效，只有两个都拉高才更新窗口数据并启动排序，否则窗口保持上一拍的值。这样就算下游偶尔反压，也不会漏掉像素。排序结果通过一个寄存器输出，下一拍tvalid同步拉高。这样每周期输出一个像素，背压时数据不丢。你提到冒泡资源大，其实还有个坑——冒泡的组合逻辑链在9输入下可能有5到6级比较器深度，时钟频率上不去，而比较器树只有3级。面试官如果接着问'你怎么保证tready信号不会让流水线断流'，你可以说在输入加一个FIFO做弹性缓冲，深度设成一行像素数，这样行切换时也不会丢数据。你目前用的开发板是什么型号？如果板子自带DDR，还可以考虑用行缓存做乒乓操作，进一步解耦时序。

其实还有个思路你可能没想过：对于3×3窗口，中值滤波不一定要用排序网络，直接用'计数型中值提取'也能省资源。具体做法是拿9个比较器并行判断每个像素大于其他几个像素，大于次数等于4的那个数就是中值。这个结构只用比较器和加法器，没有树形比较器那么长的组合逻辑链，LUT能再省10%到15%。但代价是比树结构多打一拍才能出结果，因为计数需要额外一个时钟做累加。如果你的项目时钟裕量够，比如只跑100M，这个方案完全可行。面试时你提一句'我知道有计数型方法，但为了流水线吞吐率我优先选了比较器树'，能给面试官留下技术视野宽的印象。另外你用的工具链是Vivado还是Quartus？不同综合器对比较器树的优化程度有差异，Vivado对LUT级联的压缩做得更好，资源差距会明显一些。

面试官问排序网络怎么省资源，你提冒泡被追问资源大，其实3×3窗口有个更直接的思路叫"淘汰法"——不用把9个数排成有序序列，只要找出中值就行。具体做法是：第一级用4个比较器找出9个数里的最大值和最小值，这两个肯定不是中值，直接扔掉；剩下7个数再找一轮最大最小再扔掉，剩5个的时候再找一次中值。这么做比较器总数大概12个左右，比冒泡的36个比较器少一半多，而且组合逻辑级数只有4到5级，插一拍寄存器就能跑200M。缺点是每轮淘汰需要多一个时钟周期的控制逻辑，如果你做的是逐像素流水线，这个控制开销会破坏每周期一个像素的输出节奏，所以实际工程里并行比较器树还是主流。但面试时你把这个方案当备选提出来，能展示你对资源-时序权衡的理解。另外注意AXI4-Stream接口的tkeep信号，如果图像数据位宽不是8bit倍数，你需要用tkeep标记有效字节，否则窗口移位会错位导致丢像素——这个坑面试官经常藏在"不丢帧"里。你当前是在校招初期还是已经拿到offer在选组了？追问这个是想看看你还有多少时间深挖细节。

兄弟，冒泡在3×3下其实能忍，但面试官想听你说并行比较器树。三级比较加三级寄存器，资源省一半，时序稳稳的，画个图直接过。

你提到冒泡资源大，其实本质问题是排序网络在3×3窗口下做了过多无用功——你只需要第5大的数，却把9个数全排好了。并行比较器树的核心思路是分治+剪枝：第一级把9个数分成三组，每组3个数做全比较，每组输出最大、中、最小三个候选；第二级拿三组的最大组、中数组、最小组各自比较，得到三个候选；第三级从这三个里取中值。这个结构最妙的地方在于，每一级比较器的输出只用于下一级的输入，没有反馈路径，所以天然适合插入流水线寄存器。你如果每级后面放一个寄存器，组合逻辑深度只有2到3级LUT，时序闭着眼睛过200M。资源上大概用45到55个LUT加9个寄存器，比冒泡的80到100个LUT省40%以上。具体RTL写法上有个技巧：用generate循环生成比较器单元，不要手写9个if-else，否则代码又长又容易漏条件。另外关于不丢帧，你除了要处理tready反压，还要注意line buffer的读使能——当tvalid有效且tready有效时，line buffer才更新写入地址，否则地址保持不动，窗口数据才能和像素流严格对齐。常见的错误是直接用tvalid驱动line buffer写使能而不管tready，这样下游一拉低就把像素写丢了。面试官追问丢帧其实就是在等你说握手信号的联动。我建议你写代码前先把line buffer和移位寄存器的时序图画一下，把tvalid、tready、wr_en、shift_en的波形对齐，画完再写RTL思路会清晰很多。你目前是在学Vivado还是Quartus？不同工具对generate的综合支持有点差别，Vivado下用generate会直接展开成LUT，而Quartus有时会优化成DSP块导致资源报告不准，你写代码时留意一下综合报告里的SLICE和ALUT计数。

面试官问资源最省，很多人第一反应就是比冒泡更好的是奇偶排序或者双调排序，但3×3窗口其实有个更直接的思路叫淘汰法——不用把9个数排成有序序列，只要找出中值就行。具体做法是：第一级用4个比较器找出9个数里的最大值和最小值，这两个肯定不是中值，直接扔掉；剩下7个数再找一轮最大最小再扔掉，剩5个的时候再找一次中值。这么做比较器总数大概12个左右，比冒泡的36个比较器少一半多，而且组合逻辑级数只有4到5级，插一拍寄存器就能跑200M。缺点是每轮淘汰需要多一个时钟周期的控制逻辑，如果你做的是逐像素流水线，这个控制开销会破坏每周期一个像素的输出节奏，所以实际工程里并行比较器树还是主流。但面试时你把这个方案当备选提出来，能展示你对资源-时序权衡的理解。另外注意AXI4-Stream接口的tkeep信号，如果图像数据位宽不是8的倍数，你窗口对齐的逻辑会多一层mux，这个细节很多人会漏掉。你目前是想跑多少分辨率？1080p还是4K？这个会影响你line buffer的深度选择。

校招面试里，面试官追问'不丢帧'其实是在考你对AXI4-Stream握手协议和流水线背压的理解，排序网络省资源只是前半题。很多人光顾着优化比较器树，把窗口滑动模块写成了组合逻辑直接更新——下游tready一拉低，窗口数据就错位，中值跟着错，帧就丢了。我的做法是：排序核心用并行比较器树，这你已经知道了，但重点在窗口滑动模块的控制。用两个line buffer加一个3×3移位寄存器阵列，每个像素进来时，先判断tvalid和tready是否同时有效，只有两个都拉高才更新窗口数据并启动排序，否则窗口保持上一拍的值。排序结果通过一个寄存器输出，下一拍tvalid同步拉高。这样就算下游偶尔反压，也不会漏掉像素。资源方面，比较器树9输入三级大概用50个LUT出头，加上握手控制逻辑总共不到80个LUT，比冒泡的120个左右省了不少。还有一个常见坑：有些同学为了省那两三个LUT，把比较器树每级之间的寄存器省掉了，结果组合逻辑路径太长，时钟频率上不去，最后反而要插更多流水级才能收敛时序，得不偿失。所以面试时你能说出来'每级之间必插一拍，组合逻辑深度控制在三级以内'，就已经比大多数候选人扎实了。另外你提到实习项目里用过HLS，其实HLS综合出来的排序网络资源往往比手写RTL多20%到30%，因为它会生成通用的比较器链而不是针对3×3优化的树结构。如果你时间充裕，建议手写RTL并对比一下综合报告，面试时能拿出具体数字会更加分。

兄弟你这个问题我去年校招也遇到过，面试官问了几乎一模一样的东西。先说结论：冒泡排序在小窗口下确实直观，但资源效率低，面试官追问的意图多半是看你会不会用并行比较器树来替代。3×3窗口只有9个输入，用三级比较器树就能把中值找出来，第一级把9个数分成3组，每组3个数比出最大、中、最小，第二级拿三组的最大、中、最小再比，第三级从三个候选里取中值。每级后面插一拍寄存器，组合逻辑深度就两级到三级，时钟轻松上200M。资源上比冒泡省30%到40% LUT，而且流水线吞吐率每周期出一个像素。你面试时能边画边讲这个树结构，提一句'每级插一拍避免长路径'，基本就稳了。

然后你担心的'不丢帧'问题，其实和排序结构本身关系不大，关键在AXI4-Stream握手信号的控制。我当时的做法是：窗口滑动模块用两个line buffer加一个3×3移位寄存器阵列，每个像素进来时先判断tvalid和tready是否同时有效，只有两个都拉高才更新窗口数据并启动排序，否则窗口保持上一拍的值。排序结果通过一个寄存器输出，下一拍tvalid同步拉高。这样就算下游偶尔反压，也不会漏掉像素。面试官追问这个点，其实是在考你对握手协议和流水线背压的理解，很多人光顾着优化比较器树，把窗口滑动模块写成了组合逻辑直接更新——下游tready一拉低，窗口数据就错位，中值跟着错，帧就丢了。

另外提醒一下，你在写RTL的时候，记得把tkeep信号也考虑进去，如果图像数据位宽不是8bit对齐，比如是10bit的RAW格式，tkeep的位宽处理不当会丢像素边界。还有工具链的问题，Vivado对比较器树的LUT级联优化比Quartus好，资源差距可能有10%左右，如果你用Quartus，建议在综合属性里加一句use_dsp48或keep_hierarchy来控制资源映射。你现在是刚投简历还是已经在面试流程中了？如果还在准备阶段，建议把这个模块完整写一遍跑仿真，面试时能直接说'我在项目里验证过200M时钟下连续1万帧无丢像素'，比光讲理论有说服力得多。