2026年FPGA校招，手撕Verilog实现AXI4-Stream实时中值滤波，3x3窗口排序网络怎么设计最省资源？

其实3×3窗口就9个数，用双调排序的Batcher网络比奇偶交换更规整，三级比较器加一级寄存器打拍，组合逻辑路径短，时序好收敛。关键点是：第一级做(0,1)(2,3)(4,5)(6,7)四对并行比较，第二级把第一级的输出按奇偶索引交叉比较，第三级再做一次奇偶交换，最后取中间值。这样总共12个比较器，比冒泡的36个少三分之二。不过注意AXI-Stream的ready/valid握手信号要跟排序流水线配合好，不然数据流会断。你可以先搭一个纯组合逻辑的排序核，再用两级寄存器把握手信号对齐到排序结果输出时刻。资源对比的话，我实习时做过，7系列器件上冒泡要80个LUT左右，奇偶交换大概50，双调还能再省5个。追问一句：你面试时遇到的是要求纯组合还是允许拍数？

面试官嫌冒泡资源大，本质是在考察你对排序网络数据流和比较器复用的理解。这里有个很多人忽略的点：3×3窗口其实只需要排序出第5个值，没必要把9个数完全排好序。你可以用'淘汰法'——先并行比出最大值和最小值，剩下的7个再比一轮，这样只用两级比较就能锁定中值。具体做法：第一级用3个比较器找出每行的中值，第二级对这三个中值排序取中间那个。但注意这种方法只在窗口内数值分布较均匀时才保证正确，如果三行中值恰好都是偏大或偏小，结果会偏差。所以稳妥做法还是全排序，但别用冒泡。我推荐一个省资源的变种：把9个数分成三组，每组三个用全加器网络排序（三输入冒泡只用3个比较器），然后对三个中值再排一次，总共12个比较器，比双调网络的12个一样但布线更短。另外提醒一点，AXI-Stream接口的tready信号要跟你的流水线反压配合好，如果排序网络是组合逻辑，你需要在输出端加一个valid延迟匹配的寄存器，不然tready拉低时中间值会乱跳。你目前是在准备提前批还是正式批？不同阶段面试官对代码完整度的容忍度不一样，提前批他可能更看重你思路的灵活性，正式批就会抠握手时序了。

冒泡在3×3窗口里确实太奢侈了，9个数全排完得36个比较器，实际你只要第5大。试试双调排序，三级比较器加一级寄存器打拍，大概12个比较器就能搞定，LUT能省一半。面试官听到你说Batcher网络应该就满意了。追问：你用的器件是7系列还是UltraScale？时序约束松紧差挺多的。

其实面试官嫌冒泡大，核心是想看你懂不懂'排序网络'和'数据流'的关系。3×3窗口就9个数，用奇偶交换网络（Odd-Even Transposition）三级就能排完：第一级平行比四对，第二级交叉比，第三级再比一次，最后取中间那个。总共12个比较器，组合逻辑深度只有三级，时序好收敛。对比冒泡的36个比较器和大概九级比较链，LUT省40%以上是保守估计。代码实现上我建议你画个流水线框图再写，先把每级比较器的输入输出标清楚，然后按AXI-Stream的ready/valid握手信号做打拍对齐。一个常见坑是tready反压时数据没停住，排序网络里多拍数据错位。解决方法是在第一级比较器前加一个拍深的FIFO或者用寄存器组做stall控制。你如果还有富余LUT，甚至可以把排序网络做成参数化的，面试官会觉得你考虑到了复用性。

我去年校招也遇到过类似问题，当时用的双调排序网络，面试官追问了一句'为什么不用奇偶交换'——所以你得准备两个方案的取舍理由。双调排序（Batcher's odd-even merge）在9输入时也是三级比较器，但它的比较拓扑更规整，综合后布线长度更均衡，对时序收敛有利，尤其你的AXI-Stream时钟跑得高（比如200MHz以上）时优势明显。但代价是中间寄存器打拍数比奇偶交换多一拍（四级vs三级），latency稍大。资源上两者差不多，都是12个比较器，LUT数在7系列上大概45～55。一个实操小技巧：写代码时把每个比较器实例化成单独的module，比如comp2(in0,in1,out_min,out_max)，这样综合工具更容易做retiming。另外注意AXI-Stream的tuser信号如果你也需要做中值滤波的伴随数据（比如像素坐标），得设计一个同样深度的延迟链和排序结果对齐，这一步容易忘。整体来说，别死磕资源最省，面试官更看重你能否在'资源、时序、latency'三个维度上做权衡，并能清晰解释你的选择。个人建议你课后用Vivado或Vivado Simulator搭个简单testbench，对比两种网络在同一个时钟约束下的WNS和LUT用量，面试时直接贴波形图或资源报告，比背模板有用十倍。追问一句：你面试时要求纯组合逻辑实现还是允许用流水线？这个决定你能不能省掉那一级打拍寄存器。

面试官嫌冒泡资源大，其实是在等你提排序网络。3×3窗口就9个数，用奇偶交换网络三级比较器就能排完，第一级比四对，第二级交叉比，第三级再比一次，中间那个数就是中值。总共12个比较器，比冒泡的36个省三分之二。代码上建议先画流水线框图，把每级输入输出标清楚，再按AXI-Stream的ready/valid握手信号做打拍对齐。一个常见坑是tready反压时数据没停住，排序网络里多拍数据错位——解决方法是在第一级前加一个拍深的FIFO或者用寄存器组做stall控制。追问一句：你面试时器件是7系列还是UltraScale？时序约束松紧差别挺大的。

其实面试官更想听的可能是你懂不懂'只取中值，不用全排'这个思路。3×3窗口9个数，你只需要第5大的数，完全没必要像冒泡那样把整个序列捋顺。一个经典省资源做法是淘汰法：第一级用3个比较器并行找出每行的中值，然后对这三个中值再取中值——这样总共只用6个比较器，三级组合逻辑深度，比奇偶交换的12个还省一半。但面试官大概率会追问你的正确性边界：如果这三行的中值恰好都偏大或偏小，比如窗口里有一行全是高值、另一行全是低值，那三个行的中值并不能代表全局中值，结果会出错。所以稳妥做法还是全排序，但别用冒泡。我推荐一个折中方案：把9个数分成三组，每组三个用全加器网络排序（三输入冒泡只用3个比较器），得到三个中值后再排一次取中间，总共12个比较器，和奇偶交换一样，但布线更短、时序更好。资源上，我在实习时试过，7系列器件上冒泡要80个LUT左右，奇偶交换大概50，淘汰法能压到35，但正确性保证不了。面试遇到这种题，你先抛出淘汰法展现思路灵活，再补一句'但如果严格要中值正确，我还是用双调排序网络'，面试官会觉得你既懂取舍又有工程判断。另外注意AXI-Stream的tready反压处理，排序网络每级寄存器必须跟valid/ready同步打拍，否则数据流错位你会debug到怀疑人生。

提一个很多人忽略的角度：排序网络的资源消耗不光看比较器数量，还得看综合后LUT的复用程度。冒泡排序虽然比较器多，但它的比较器结构高度对称，综合工具容易做资源共享，有时候实际LUT消耗只比奇偶交换多20%而不是理论上的60%。相反，奇偶交换网络虽然比较器少，但交叉连接不规则，布线长度不均，如果时钟跑得高比如200MHz以上，时序收敛反而比冒泡更费劲。我去年校招做类似题时，用双调排序网络做了个折中：三级比较器拓扑规整，综合后布线均衡，时序余量比奇偶交换多0.3ns左右，LUT消耗比冒泡少35%。代码上有个实操窍门：把每个比较器实例化成单独的module，比如comp2(in0,in1,out_min,out_max)，并加上( keep = "true" )防止综合工具优化合并，这样retiming更容易。另外，如果面试官让你手撕代码，别一上来就写排序网络，先画个8拍流水线示意图：第一级比较，第二级寄存器对齐，第三、四级做握手信号同步，最后两拍输出中值。等把数据流图画清楚再写Verilog，面试官会觉得你思路清晰。追问一句：你当时面试要求写纯组合逻辑还是允许时序流水？这会影响你选方案时的latency取舍。

其实面试官追问资源消耗，大概率不是真要你背数字，而是想听你意识到冒泡排序在3×3窗口里属于过度排序——9个数只需要第5大的，你却把整个序列捋顺了。一个很直接的替代方案是奇偶交换网络（Odd-Even Transposition Network），它用三级比较器就能完成全排序：第一级并行比(0,1)(2,3)(4,5)(6,7)四对，第二级交叉比(1,2)(3,4)(5,6)，第三级再比一次(0,1)(2,3)(4,5)(6,7)，最后取中间那个数。总共12个比较器，组合逻辑深度只有三级，比冒泡的36个比较器加九级比较链省资源得多。实际LUT消耗在7系列器件上大概从80降到50左右，时序余量也能多出0.2ns。不过有个小坑：奇偶交换的交叉连接路径长度不一致，如果时钟跑到250MHz以上，综合工具可能因为布线不均匀导致建立时间违例。我自己在校招做题时遇到过，后来换成双调排序（Batcher's odd-even merge）解决了——它的比较拓扑更规整，综合后走线长度均衡，且同样12个比较器。代码上建议把每个比较器写成单独的module并加上keep属性，防止综合工具过度优化导致retiming困难。你现在的时钟频率大概设多少？如果低于200MHz，用奇偶交换就够。

我推荐直接上双调排序网络（Batcher's odd-even merge），原因不只是资源省，更在于它和AXI-Stream握手信号的配合更自然。3×3窗口就是9个数，用双调排序只需要三级比较器加一级寄存器打拍，总共12个比较器，LUT大概45到55，比奇偶交换网络还少5到10个。核心拓扑是：第一级并行比(0,1)(2,3)(4,5)(6,7)；第二级把索引分成奇偶两组交叉比较，比如compare(1,2)和compare(3,4)和compare(5,6)；第三级再做一次奇偶交换，最后取中间索引4的值。这样每级比较器之间的连线长度基本一致，综合工具不需要大量插入缓冲器来修时序，在200MHz以上时钟下建保时间余量通常比奇偶交换多0.3ns左右。你问为什么冒泡被面试官嫌大，最根本的原因是冒泡的排序链深度随输入数线性增长——9个输入要排完需要8级比较，组合逻辑路径太长，要么频率上不去，要么插入大量寄存器增加latency。而排序网络是固定深度，三级打完收工。实际代码实现时有个容易被忽视的点：AXI-Stream的tready信号反压时，排序网络里的多拍数据必须同步停住。我的做法是在第一级比较器前加一个拍深的寄存器组作stall控制，tready拉低时所有比较器输入保持当前值，同时把valid也锁住。这样后续流水线不会因为数据错位算出错误的中值。追问一句：你面试时面试官有没有给具体时钟频率约束？如果有，双调排序在低频优势不明显，但高频场景下这个取舍很关键。