2026年FPGA校招，面试官问手撕Verilog实现AXI4-Stream的实时中值滤波，3x3窗口的排序网络怎么设计流水线才能不丢帧？

面试官问排序网络，本质上不是要你现场发明一个最优调度，而是考察你对 FPGA 资源效率与吞吐的权衡直觉。你提到冒泡排序流水线时序跑不高，确实，冒泡排序的级联比较器链太长，1080p@60fps 大约需要 148.5 MHz 的像素时钟，冒泡的 9 级比较链很容易成为时序瓶颈。常见做法是改用 Batcher odd-even mergesort，把 9 个输入分成 3 组，每组 3 个先做全排序（每组内部 3 个比较器就够了，LUT 很小），然后对三组的最大值、中值、最小值做两轮合并比较，这样整个流水线只需要 5 级比较器，LUT 消耗比 9 元素全排序降低 40% 以上。你要注意一点：流水线要保证每周期输出一个像素，必须让排序网络的延迟与帧同步信号对齐，避免帧间隙丢数据。一个容易忽略的坑是，AXI4-Stream 的 tvalid 和 tready 握手信号可能会让排序网络暂停——你需要在每一级流水线寄存器里插入 valid 信号传递，否则当 backpressure 发生时，排序会拿到错误的中间结果。如果你在面试时被问到资源细节，可以说用 Xilinx 的 7 系列器件，单级比较器大概消耗 3～4 个 LUT，5 级总共 100 LUT 出头，比冒泡的 200+ 好很多。顺便问一句：你面试的公司偏向 Xilinx 还是 Altera？工具链不同，综合策略上有些差别，比如 Altera 的 Hyper-Registers 对长链比较友好。

这个问题其实暴露了一个常见的准备误区：很多人一上来就死磕排序算法的 Verilog 实现，却忽略了 AXI4-Stream 接口的实时性约束才是面试官真正想听的。让我拆开讲。首先，3×3 中值滤波的排序网络，核心矛盾是 9 个像素的排序延迟不能超过一个像素时钟周期（约 6.7 ns @148.5 MHz），而全排序的 36 次比较在纯组合逻辑里根本不可能。所以必须流水线化，但流水线深度又不能太深，否则会引入帧延迟，导致图像边缘出现空白行。业界用的标准解是 Batcher odd-even mergesort 的 5 级流水线，或者更激进的 4 级（如果允许近似排序）。你设计时要注意：每一级流水线寄存器必须包含 valid 信号，tready 从最后一级反压回第一级，否则当外部模块拉低 tready 时，排序网络内部的像素会错位。具体实现上，你可以在第一级行缓存输出后，将 3×3 窗口的 9 个像素同步打平到同一拍，然后用三个并联的 3 输入排序器（每级 3 个比较器）先排好每组，再对三组的最大值、中值、最小值做第二级合并，第三级选出最终中值。这样总共 5 级比较器，每级比较器是纯组合逻辑，寄存器插在级间，时序很容易收敛到 200 MHz 以上。资源方面，Xilinx 7 系列下大概 120 个 LUT 加 40 个 FF，不到一个 SLICE 的 20%。但有个更深的点：面试官接着可能会问你行缓存的实现，比如用 BRAM 还是分布式 RAM，以及如何处理图像边界。如果你能主动提到用两个 line buffer 缓存两行数据，然后用移位寄存器对齐 3×3 窗口，会比只讲排序网络显得更完整。建议你准备的时候，先在 Vivado 或 Quartus 里搭个简单的 testbench，跑一下 AXI4-Stream 的握手时序，确保 pipeline 的 valid 链和 tready 反压逻辑正确。这比背代码有用得多。你目前是用 Xilinx 的 IP 还是自己写 RTL？如果是自己写，可以聊聊 line buffer 的地址生成逻辑。

其实你纠结的LUT消耗和时序冲突，本质上是把「全排序」和「流水线」绑在一起想了。一个常见的取巧做法是放弃对全部9个数做严格排序，只求精确得到中值。你可以用3级比较器树：第一级把9个像素分成三组，每组内部只用3个比较器找出组内最大、中、最小（3个比较器就够了，别写全排序），第二级把三组的最大值、中值、最小值分别做两两比较，第三级再对剩下的候选值做一次三选一。这样总共大约9个比较器，LUT消耗比冒泡的36次比较少了四分之三，而且流水线深度只有3级，148.5MHz随便跑。唯一要注意的是AXI4-Stream的tready反压：你的流水线寄存器必须每级都带valid且能停一拍，不然tready拉低时中间数据会断流，帧尾丢像素。另外，如果你的视频源有行消隐区（HBlank），其实可以在消隐期间用空操作填满流水线，省掉复杂的反压逻辑。你用的是哪家FPGA？Xilinx的LUT6做比较器比Altera的ALM更省资源，设计策略可以微调。

我去年秋招正好被问到类似题，当场画了Batcher odd-even mergesort的9输入网络。这个结构的核心是把冒泡的O(n^2)比较次数降到O(n log^2 n)，9个元素只要5级比较器，每级最多6个比较器，总共约30个比较器，比全排序的36次少了但没少太多——真正省资源的是你不需要输出全部排序结果，只需要中值，所以最后两级可以剪枝：只保留可能成为中值的候选路径。具体说，Batcher网络前3级照常做奇偶合并，第4级只比较第4和第6个位置（因为中值最终只会出现在这俩位置之一），第5级用二选一输出。这样比较器从30个降到22个左右。流水线寄存器一定要每级都带valid和ready，用握手信号逐级反压。一个容易翻车的点是帧首的blanking：第一行像素的3×3窗口要等两个行缓存填满才能出第一个有效数据，你需要在行计数器里留出2个像素时钟的启动延迟，并在Valid拉高前把输出m_axis_tvalid置低。如果面试官追问行缓存的实现，就说用Xilinx的BRAM配置成真双口RAM，深度1920（1080p宽度），两个行缓存轮流写和读。你现在的工程里行缓存是用BRAM还是分布式RAM？如果是分布式RAM，1920深度会爆LUT，必须换BRAM。还有，别忘了在top模块把aclk和aresetn连到AXI4-Stream标准接口上，很多面试官会检查复位信号是低电平有效的规范写法。建议你提前在Vivado里搭个testbench，用随机像素数据跑仿真，对比matlab的中值结果——面试官如果让你现场讲调试过程，你能说出「比对过1000帧无错误」会比只讲理论分高很多。你目前手撕Verilog的熟练度怎么样？能不能直接写出行缓存的状态机？如果没把握，建议先把单像素中值滤波的纯组合逻辑版写熟，再套进AXI4-Stream的框架里，分两步推进更稳。

看到你卡在排序网络这里，我猜你多半是在课设里习惯了写全排序然后综合，没想过148.5MHz下组合逻辑的传播延迟有多要命。其实面试官问这个，不是真想看你现场发明一个Batcher网络——他更在意你有没有意识到「流水线深度」和「帧延迟」之间的取舍。常见的3级比较器树方案，就是把9个像素先按3×3窗口的列或行分成三组，每组内部用3个比较器找出最大、中、最小（3个比较器就够了，别写全排序），然后对三组的最大值、中值、最小值做两轮交叉比较，最后一级用三个候选值再比一次得到中值。这样流水线深度只有3级，比较器总数在9个左右，比全排序的36次少了四分之三。但你得算一笔账：1080p@60fps的像素时钟约148.5MHz，每行有1920个有效像素，窗口的流水线延迟是3个时钟周期，意味着帧内前两行和最后两行的边缘像素会有空白输出。如果你用行缓存（line buffer）存两行数据，再配合窗口的行起始信号做同步，其实边缘空白可以被HBlank消隐期吃掉，不影响图像有效区域。面试官大概率会追问你「如果要求边缘像素也输出有效中值怎么办」，这时候你可以提一下在行缓存两端补零（zero padding）或者复制边缘像素，代价是多两个行缓存和额外的控制逻辑。另外，AXI4-Stream的tready反压是另一个坑：如果你的排序网络流水线只有valid没有ready，下游模块拉低tready时，你的流水线寄存器会直接覆盖旧数据，导致帧内出现像素错位。常见做法是每一级流水线寄存器都挂一个valid-ready握手，用last信号标记行尾，这样反压时流水线能停住。最后多说一句，面试手撕Verilog时，不用把整个模块写完，画个流水线级数图，标出每级的比较器数量和valid/ready路径，面试官就满意了。你现在的进度是还在看排序算法，还是已经写过行缓存了？

个人感觉你有点被「排序」两个字带偏了。3×3中值滤波不需要把9个数排成有序序列，你只需要保证输出的是第五大的数。一个很直接的思路是：第一级把9个像素分成三组，每组内部用三个比较器找出最大、中、最小；第二级把三组的最大值放一起比出最小值，三组的中值放一起比出中值，三组的最小值放一起比出最大值；第三级把这三个候选值再比一次，中间那个就是最终中值。这样总共9个比较器，流水线三级，148.5MHz下时序很宽松。唯一要小心的是行缓存的控制逻辑：你得让窗口滑动信号和行同步对齐，不然第一行数据还没填满三行缓存时，窗口会输出垃圾数据。建议你画个时序图，把行有效信号、窗口有效信号和流水线valid的对应关系理清楚，面试时直接画出来，比写代码更能体现你的工程直觉。

个人觉得你思路有点绕进全排序的坑里了。3×3中值滤波真不需要把9个数排利索，用3级比较器树，第一级三组内比出最大中最小，第二三极交叉比一下，9个比较器搞定，LUT省一大半。再加上流水线寄存器每级带valid，148.5MHz时序不会翻车。你现在的Frame buffer用了几个行缓存？

我建议你把精力放在「每周期出结果」的流水线节奏上，而不是排序算法本身。用Batcher odd-even mergesort的剪枝版本，针对9个输入只保留中值候选路径，比较器能从36个降到20个左右，LUT压力就小多了。流水线做5级，每级寄存器必须跟valid和tready握手走，不然帧尾丢数据。一个容易踩坑的点是行缓存的控制：你得保证第一行数据流过来时，前两个行缓存还没填满，窗口输出要等三个行有效信号都到位才拉valid。面试官其实更想听你解释清楚时序图里的对齐关系，比如行同步信号和窗口滑动的对应时刻，而不是默写代码。另外，如果你在消隐期间用空操作占位，可以省掉复位逻辑，但小心别让流水线里的垃圾像素污染有效帧边界。你目前视频源是RGB还是YUV？接口层兼容性会影响行缓存的设计。

搞实时中值滤波排序网络，我去年做项目时踩过类似的坑，给你说三个实际取舍。第一，冒泡排序流水线确实不好用，因为9个元素的冒泡要8级比较链，每级还有寄存器，组合逻辑路径太长，148.5MHz下setup很容易违例。替代方案是Batcher奇偶归并排序，9输入只需要4到5级比较器，每级6个比较器左右，总共约27个比较器，比全排序的36次少了四分之一，但剪枝后只保留中值路径能再减到20个，资源省了40%以上。第二，流水线深度不能只看比较器级数，还要算上行缓存延迟：1080p每行1920像素，3×3窗口需要2个行缓存加9个寄存器来滑动，这部分BRAM开销比排序网络本身还大。你如果用分布式RAM做行缓存的话，注意综合工具会把小BRAM当LUT吃掉，导致你误以为排序网络占了太多LUT。第三，面试官问你丢帧问题，其实核心是tready反压的握手逻辑有没有做空泡填充。如果外部模块偶尔拉低tready，你的流水线必须能在当拍停住并保持内部数据不丢失，否则帧尾最后一列像素会错位。一个简单的做法是每级流水线寄存器都带enable信号，tready反压时全局停一拍，代价是吞吐降一点，但1080p@60fps的像素时钟148.5MHz还有20%余量，完全可以接受。你手撕代码时建议先画出时序波形图，把行有效、窗口有效、流水线valid、tready四个信号的对齐关系标清楚，面试官一看就觉得你有工程经验。你现在的开发板主控芯片是哪家？不同厂商的行缓存原语名字不一样，比如Xilinx用shift register SRL，Altera用ALTSHIFT_TAPS，底层资源使用差挺多的。