2026年FPGA校招，海思面试官问手撕Verilog实现AXI4-Stream实时视频去雾，暗通道先验的导向滤波用行缓冲怎么设计才能满足4K60帧？

面试官问这个，本质是想看你有没有真正做过视频处理级的行缓冲设计，而不是背过论文公式。4K60帧的行时间大约16.7us，像素时钟接近600MHz，导向滤波窗口用7×7的话，行缓冲深度就是图像宽度，并行度取决于你用几个处理单元去算均值与方差。你先定好窗口大小和每行处理几个像素，再反推BRAM个数，别一上来就写代码。你用的什么器件？UltraScale+还是7系列？

我去年秋招也被问过类似导向滤波的硬件实现，说点实际工程取舍。4K60帧要求每行3840像素，RGB三通道的话，单色行缓冲深度3840就够了，但导向滤波窗口需要多行同时访问，比如7×7窗口需要同时读7行数据，所以你得用7个行缓冲，每个深度3840，宽度看数据位宽（一般10bit或12bit）。带宽瓶颈在均值滤波那一步：每像素要算窗口内所有像素的均值和方差，如果每个时钟只处理一个像素，BRAM带宽是够的，但逻辑资源会炸，因为你要同时算49个像素的和。常见做法是拆成两步，先用行缓冲做水平方向的累加和，再用列缓冲做垂直方向的累加和，这样每个时钟只要算几个加法器。时序约束上，关键是让行缓冲的读地址和写地址错开一拍，避免组合逻辑环路。你的帧率要求决定了像素时钟频率，如果器件主频跑不到600MHz，就得把数据降频展开成多像素并行，比如每时钟处理两个像素，行缓冲数目翻倍。框架上建议先写一个参数化行缓冲模块，用双端口BRAM，读使能根据行号生成，写地址连续累加。追问一句：你选的导向滤波窗口是固定7×7还是可配置的？这会直接影响行缓冲组数。

我换个角度说，面试官其实不太指望你当场写出完整的Verilog，他更想看你的推导过程。你先画时间轴：一行像素周期是3840个时钟，一帧有2160行，帧间隙大概几十行。行缓冲设计的关键是确定你要缓存几行数据，这取决于导向滤波的窗口半径，比如半径3就需要缓存6行加上当前行共7行。然后算BRAM个数：每个行缓冲用1个BRAM36K，深度2048的话存不下3840，得用两个BRAM拼接，所以7行缓冲需要14个BRAM，加上列缓冲和系数存储，总共20个左右，在Xilinx KU系列里绰绰有余。并行度方面，如果每时钟处理1个像素，行缓冲读端口只需1个，但均值滤波会变成流水线延迟；如果每时钟处理4个像素，行缓冲读端口要4个，BRAM要切分成多个Bank。我建议你先按每时钟1像素写，验证功能后再优化并行度，别一开始就追求极限。时序约束主要是set_max_delay和set_multicycle_path，针对行缓冲的读写地址路径。你目前手上有开发板能跑仿真吗？

面试官问行缓冲深度和并行度，其实是在考察你有没有从系统层面考虑过带宽匹配。4K60帧的像素时钟接近600MHz，导向滤波窗口如果是7×7，你的行缓冲深度就是图像宽度3840。但关键不是深度，而是你打算每时钟处理几个像素——如果每时钟只处理1个，BRAM带宽够但逻辑吃紧，因为你同时要算49个像素的均值；如果每时钟处理4个像素，行缓冲读端口得扩到4个，BRAM要切Bank。我建议你先把每时钟1像素的框架搭通，再考虑展开并行，别一上来就追求极限。另外，注意行缓冲的读写地址错开一拍，避免组合逻辑环路。你的FPGA具体是哪家的？

我去年在实习时也调过类似的去雾模块，说点实际工程取舍。导向滤波的行缓冲深度不是简单等于图像宽度，还要看你的数据位宽和是否做RGB三通道独立处理。如果是单色图，深度3840，位宽10bit，一个BRAM36K存不下，得用两个BRAM拼接成深度4096，这样7行缓冲要14个BRAM。但带宽瓶颈不在行缓冲，在均值滤波那步：每像素要算窗口内所有像素的和，常见做法是拆成水平和垂直两个方向的一维累加，这样每个时钟只需要几个加法器，逻辑资源从O(n^2)降到O(n)。时序约束上，跨时钟域处理要注意——如果输入是AXI4-Stream的tready/tvalid握手机制，行缓冲写侧要跟着像素时钟，读侧可能跟处理时钟同一个域，不用异步FIFO，但要保证读地址不会超过写地址。你打算用UltraScale+还是7系列？不同器件的BRAM配置有点区别。

我个人觉得，面试官问这个问题的真正意图不是让你当场写出完整的Verilog，而是想看你推导行缓冲参数的过程。你先把时间轴画清楚：4K60帧的一行像素时间是1/60/2160 ≈ 7.7微秒，但注意这个2160是有效行数，实际上帧消隐期还有几十行，所以像素时钟大概是148.5MHz左右（4K60的常用标准），而不是你直觉以为的600MHz——很多人这里算错，以为4K就是3840×2160@60Hz，像素时钟确实接近600MHz，但那是针对RGB444每像素24bit的原始带宽，AXI4-Stream视频去雾一般走的是YUV422或单通道灰度，数据量减半，时钟频率也能降下来。导向滤波用7×7窗口，行缓冲深度取图像宽度3840就够了，但并行度取决于你每时钟处理几个像素。如果每时钟1像素，BRAM带宽够用，但7行缓存同时读7个地址，BRAM是双口RAM，一个读端口只能读一个地址，所以你得用7个独立的BRAM，每个深度2048存不下3840，得用两个BRAM拼接成一个深度4096的伪双口，这样7行需要14个BRAM。时序约束上，关键是让行缓冲的写地址比读地址领先至少一个窗口半径的像素数，避免读空。你先按这个思路写个框架，把行缓冲的写使能、读使能、地址计数器理清，代码其实没几行，核心在地址控制逻辑。你目前有在ISE或Vivado上跑过时序仿真吗？如果跑过，可以看看最差路径的建立时间余量是多少。

面试官让你手撕Verilog，其实不是真要在白板上写几百行代码，而是看你推导行缓冲参数的过程。导向滤波行缓冲深度取决于窗口半径，4K60帧一行像素数3840，窗口7×7就需要缓存7行。但有个常见坑：你算的像素时钟是不是按3840x2160x60x3来算的？那是RGB原始带宽，视频去雾通常走YUV422或单通道，数据量减半，时钟能降到300MHz左右。并行度上，别一上来就想每时钟处理4个像素——BRAM带宽和逻辑资源会炸，建议先按每时钟1像素搭框架，验证功能后再逐级展开。时序约束方面，行缓冲的读地址要落后写地址一拍，避免组合逻辑环路。你目前用的是哪家的开发板？资源够不够放14个BRAM？

说实话，海思面试问导向滤波行缓冲，真正想听的不是你背公式，而是你理解带宽匹配和资源折衷的过程。我去年也面过类似岗位，说点实际工程取舍。4K60帧下，像素时钟大约148.5MHz（如果是标准视频格式），但暗通道先验需要先求最小值再做导向滤波，这两个阶段的行缓冲设计不一样。最小值滤波窗口可以复用导向滤波的行缓冲，但要注意数据位宽：如果输入是12bit灰度，行缓冲深度3840，一个BRAM36K深度2048，存不下，得用两个BRAM拼接成深度4096，这样7行就要14个BRAM。并行度方面，均值滤波那步最吃资源，常见做法是拆成水平和垂直一维累加，每个时钟只用几个加法器，逻辑从O(n^2)降到O(n)。时序约束上，AXI4-Stream的tready/tvalid握手要处理好，写侧跟着像素时钟，读侧可能跟处理时钟同一个域，但必须保证读地址不超过写地址，否则读到无效数据。你目前是在准备实习还是校招？如果时间紧，建议先跑通一个低分辨率版本，比如1080p，再往4K改，这样调试周期短很多。

行缓冲深度直接等于图像宽度3840，并行度看BRAM带宽，单像素处理先稳一手。你算过BRAM36K的深度上限吗？2048存不下3840，得用两个拼一个，所以7行实际占14个BRAM。别被600MHz吓到，视频去雾走YUV422时钟就降了。

面试官真正想听的是你推导行缓冲参数的过程，不是背公式。先算BRAM个数：7×7窗口要7行，每个BRAM36K深度2048不够存3840，两个拼一个，14个BRAM。并行度先按1像素/时钟稳一手，别一上来就4像素。