2026年FPGA校招，手撕Verilog实现AXI4-Stream的实时Canny边缘检测，非极大值抑制的流水线怎么设计才能满足1080P60？

先说说流水线级数。1080P60的像素时钟大约148.5MHz，非极大值抑制（NMS）通常要读三个行缓冲才能拿到3×3窗口，再加上梯度方向量化判断，我见过比较稳的做法是5级流水：读窗、算方向索引、查表映射、比较抑制、写回。BRAM消耗主要看行缓冲，RGB转灰后每个像素8bit，1080行宽大概需要3个BRAM18K（实际用2.5个左右，但一般按3个算）。边界像素的处理，常见做法是补零或者复制边缘值，面试官很可能会问你怎么保证边界不丢帧——建议说用valid信号掩掉无效输出。你目前有试过用Vivado的HLS还是纯手写RTL？纯手写的话建议先画好时序图再编码。

关于NMS的8邻域比较，面试官真正想考察的不是你能不能写出代码，而是你对数据流和延迟的敏感度。说几个常见的坑。第一，梯度方向量化。Canny原始论文把方向分成0、45、90、135四个区间，但在FPGA上你要注意梯度幅值来自Sobel算子，Gx和Gy的符号位决定了方向象限，实际工程里常用查表法把atan2近似掉，或者直接用比较器判断Gx和Gy的大小关系来映射方向。第二，流水线延迟。3×3窗口需要两行延迟加一列，如果每级流水再插入寄存器，从输入到输出会有十几拍的延迟。这对于AXI4-Stream的tready/tvalid握手来说不是问题，但你要确保后级模块能接受这个延迟，否则会造成反压。面试官可能会追问：如果帧率要求1080P60，但你的NMS模块需要等待梯度幅值模块的结果，你怎么避免帧内停顿？答案一般是加FIFO做深度匹配，或者用valid链式传递。第三，BRAM的实际消耗。行缓冲可以用分布式RAM或者BRAM。1080列宽，8bit梯度幅值+2bit方向（其实方向可以复用Gx/Gy的符号位，不用额外存），两个BRAM18K刚好能缓存两行，第三个行用寄存器打拍即可。但面试官很可能接着问：如果换成4K分辨率，你的BRAM够不够？这时候你要会算带宽——4K60需要约600MHz的像素时钟，FPGA跑不到，所以实际会降帧或者用多像素并行。建议你准备一个表格：不同分辨率下需要的行缓冲深度、BRAM个数、时钟频率，面试时直接甩出来很加分。你目前对AXI4-Stream的ready/valid时序控制熟悉吗？如果不太熟，建议先写一个简单的stream FIFO练手。

你提到的边界像素处理是个容易被低估的点。很多教程直接说补零，但在实时视频流里，补零意味着你要在每行开头和结尾插入额外的时钟周期，这会破坏流式传输的连续性。实际工程中更常见的做法是：在NMS模块内部对窗口坐标做判断，如果当前像素在边界（比如行索引小于1或大于1079，列索引小于1或大于1919），就直接把抑制结果置为0，不参与比较。这样做的好处是不需要额外插入空周期，坏处是边界一圈的像素会被强制置零，但1080P下边界只占千分之一，视觉上基本看不出。面试官如果追问这个细节，说明他想看你有没有工程经验而非理论完美。另外，NMS的流水线还有一个隐藏问题：梯度幅值比较时，你需要同时用到当前像素和邻域像素的幅值，如果邻域像素的幅值还没算好（比如因为Sobel的流水线延迟不同），就会造成数据错拍。解决办法是把Sobel模块和NMS模块的流水线深度对齐，或者用寄存器把当前像素的幅值打拍到和邻域同时到达。建议你画一个时序图，标出每个像素从进入Sobel到离开NMS需要多少拍，这样面试官问起来你就能对着图讲。顺便问一句，你打算用哪个FPGA型号做验证？不同系列的BRAM容量和布局会影响你的行缓冲方案。

个人感觉你最好提前画一张时序图，把Sobel输出、梯度方向计算、NMS比较这三级的延迟对齐想清楚。常见做法是Sobel算完Gx和Gy，同时算方向索引（用比较器判断Gx和Gy的绝对值大小和符号），然后查一个预置的4方向映射表。NMS的3×3窗口需要两行行缓冲加一列寄存器，每个像素进来时窗口已经准备好，你只需要根据方向索引从窗口里取出当前像素正前方和正后方的两个邻域值做比较。边界像素的处理我建议用valid信号掩掉——窗口坐标小于1或大于1918时直接让输出valid拉低，这样不会丢帧也不会插入气泡。BRAM方面1080P每行需要1920个8bit像素，行缓冲用两个BRAM18K就够了（一个存偶数行一个存奇数行），但为了时序方便很多人会多用半个BRAM做冗余。你目前有定下来是用HLS还是纯RTL写吗？HLS在NMS这种规则逻辑上其实也能过时序，但面试官一般更想看纯RTL。

给你说个我当年踩过的坑吧。梯度方向量化那里，如果你直接用除法或者atan去算角度，综合出来的LUT会爆掉，而且延迟很大。正确做法是把Sobel算出的Gx和Gy分别取绝对值，然后比较大小和符号位，用组合逻辑映射到0°、45°、90°、135°四个区间。比如|Gx|远大于|Gy|且Gx为正，那就是0°方向，比较左右邻域。这个映射表用case语句写，综合出来就是几个比较器和MUX，资源很少。另一个容易被忽略的点是流水线深度对帧率的影响。1080P60的像素时钟是148.5MHz，如果你的NMS模块有5级流水，加上Sobel的3级，总共8级延迟，这个延迟在AXI4-Stream下完全可以用tready/tvalid握手掩盖掉。但要注意行缓冲的写使能必须和Sobel的输出valid对齐，否则窗口数据会错位。我记得之前见过有人用异步FIFO做行缓冲，结果边界条件没处理好，每帧最后一行会多出一个像素的偏移。建议你用同步BRAM加计数器的方式做行缓冲，把写地址和读地址错开两行，这样实现起来最稳。面试官追问边界处理时，你还可以提一句：如果要求严格不补零，可以在NMS模块内部加一个坐标比较器，当像素坐标在边界一圈时直接输出原梯度幅值不抑制，代价是多几个比较器。你目前Sobel模块的流水线级数定了吗？如果前面级数不同，NMS的窗口对齐也要跟着调。

面试官问这个其实就是想看你对流水线延迟和握手信号的理解。1080P60下148.5MHz，NMS的3×3窗口用两行行缓冲加一列寄存器就够了，方向量化别用atan，用比较器判Gx和Gy的绝对值大小映射到四个区间。边界像素直接让valid拉低，别补零，不然帧率会掉。你手撕的时候记得把tready/tvalid的backpressure画清楚。

个人感觉你先把梯度方向量化这块理清，面试官追这个的概率最大。Sobel出来的Gx和Gy是带符号的，你直接算atan2那是给软件写的，FPGA上都是用比较器把绝对值大小和符号位组合成2bit方向索引，然后查一个预置的4方向映射表。NMS的流水线我建议分五级：第一级读窗口数据，第二级算方向索引，第三级查表得到比较方向，第四级从窗口里取出正前方和正后方两个邻域值做幅值比较，第五级输出抑制结果。行缓冲用两个BRAM18K够存1080行，但为了时序余量我会再加半个做冗余。边界像素的处理你直接在NMS模块内部判断坐标，小于1或大于1918时输出置零，这样不破坏流式传输。你目前有试过在Vivado里跑过时序分析吗？

说个很多教程没提的坑：梯度幅值比较时的数据对齐。Sobel模块算Gx和Gy通常有3级流水，NMS又要等窗口准备好，如果两个模块之间的valid信号没对齐，你拿到的邻域像素幅值可能是上一拍的，比较结果全错。解决办法是在Sobel输出端加一个延时匹配的FIFO，或者把NMS的流水线深度和Sobel对齐——比如Sobel是3级，那NMS的窗口读取也延迟3拍，确保每个像素的梯度幅值和它的方向索引同时到达。BRAM消耗你可以算一笔账：1080P每行1920个8bit像素，行缓冲用双口BRAM，一个18K的BRAM能存2048×8，所以两个BRAM刚好存两行，第三个BRAM用来存第三行或者做冗余。面试官如果问你「为什么不用单口BRAM」，你就说因为需要同时读两行数据，双口可以在一个时钟周期内读出不同行的像素，否则要倍频或者插气泡。另外边界像素的处理我建议你画个状态机，当行计数器小于1或大于1078时，直接把NMS输出mask掉，这样不会引入多余周期。你目前有想好边界是补零还是用valid掩掉吗？这两个选型会影响后续的降噪模块设计。

我建议你先别急着写代码，而是把梯度方向的量化方式想透——这是整个NMS流水线最容易出岔子的地方。面试官如果追问，八成会从这里切入。Canny原始论文把方向分成0、45、90、135四个区间，但FPGA上直接用atan2算角度是不现实的，资源开销大且延迟不可控。常见做法是用比较器判断Gx和Gy的绝对值大小和符号位，组合成一个2bit的方向索引，然后查一个预置的4方向映射表。比如|Gx|远大于|Gy|且Gx为正，那就是0°方向，比较左右邻域；如果|Gx|和|Gy|差不多且Gx为正、Gy为正，那就是45°方向，比较右上和左下。这个映射表用case语句写，综合出来就是几个比较器和MUX，资源很少。但有个隐藏坑：Sobel模块算Gx和Gy通常有3级流水，NMS的窗口读取也有延迟，如果你在方向量化时直接用Sobel输出的Gx和Gy，而窗口里的邻域像素幅值还没对齐，那比较结果就是错的。解决办法是在Sobel输出端加一个延时匹配的FIFO，或者把NMS的窗口读取也延迟同样的拍数——比如Sobel是3级，那NMS的窗口读取也延迟3拍，确保每个像素的梯度幅值和它的方向索引同时到达。BRAM消耗方面，1080P每行1920个8bit像素，行缓冲用双口BRAM，一个18K的BRAM能存2048×8，所以两个BRAM刚好存两行，第三个BRAM用来存第三行或者做冗余。面试官如果问你为什么不用单口BRAM，你就说因为需要同时读两行数据，双口可以在一个时钟周期内读出不同行的像素，否则要倍频或者插入等待周期，时序会变差。你目前有定下来是用HLS还是纯RTL写吗？HLS在NMS这种强时序要求的模块上容易出问题，建议纯手写。

边界像素处理其实没那么多弯弯绕。1080P下，边界一圈的像素只占总像素的千分之一左右，视觉上几乎看不出。你直接在NMS模块内部判断窗口坐标，如果当前像素的行列索引小于1或大于边界值（比如行>1078、列>1918），就让输出valid拉低，抑制结果置零。这样不破坏流式传输，也不需要额外补零周期。面试官如果追问为什么不补零，你就说补零要在每行开头和结尾插入时钟周期，会破坏AXI4-Stream的连续握手，而且补零会影响边界附近的梯度幅值计算，反而可能引入伪边缘。实际工程里大多数人都用valid掩掉，简单可靠。