2026年FPGA校招，大疆面试官问手撕Verilog实现AXI4-Stream实时HDR融合，多帧曝光怎么用流水线对齐才能不丢帧？

面试官问流水线对齐，其实是在考你行级并行而不是帧级缓存。三帧不同曝光通常需要先做几何对齐，但面试场景下他更可能接受你是同一场景的三路同步流。丢帧的根源是你用了帧存：等第三帧来齐了再处理，前两帧的BRAM就一直在等，带宽浪费。常见做法是用双倍行缓冲配合FIFO做曝光域的对齐——每帧进来都按行流水，只缓存几行而不是一整帧。具体说，三路输入各自带valid/ready，用一个状态机控制写使能，在每行开始时刻对齐三个通道的行起始信号。如果曝光差异导致行有效时间不同，就靠FIFO深度来吸收抖动，深度按最大滞后行数算。BRAM占用从几Mb降到几十Kb。追问一句：你面试时写的是基于帧还是基于行的方案？如果当时说清了行对齐，他可能只是进一步考你FIFO深度怎么算。

我自己实际调过类似的HDR流水线，能理解你被说丢帧时的困惑。面试官说的丢帧，不是指数据丢失，而是指你的帧缓冲方案会导致后级模块在等待期间拉低ready，造成输入deassert。AXI4-Stream的握手机制下，一旦你hold住ready，上游源端如果背压不住就会丢数据——这不是你故意的，是协议层面必然的。所以核心解决思路是：让流水线在任何周期都能接受新数据，即每个stage的ready不能因为等待对齐而强制拉低。

具体到三帧对齐，我推荐用行列双缓冲加乒乓操作。每帧数据进来先按行写入一个深度为1.5倍行长的FIFO，三路FIFO的写使能各自独立。对齐逻辑不是等三路都满，而是检测三路中最小帧率的那个：用计数器记录每帧的行号，当三个行号都达到同一值时，同时弹出三路的第一个像素。这样FIFO里最多缓存一行半的数据，BRAM占用极低。而且因为ready始终为高（除非FIFO满），上游不会丢帧。这其实是一种异步FIFO加同步释放的思路，你可以把它写成有限状态机：IDLE、ALIGN、STREAM三个状态。

另外提醒一点，大疆的面试官可能特别关注你写的代码能不能综合。手撕时别写复杂的乘法器或除法，HDR融合的权重计算用查表+移位实现，面试官会更认可。如果你想进一步优化面积，可以尝试把三路FIFO合并成一路，用tag标记数据来源，但那样控制逻辑会变复杂。建议先跑通基础版再去抠优化。你现在已经拿到面试了吗？还是正在准备阶段？如果还在准备，建议找块带MIPI接口的FPGA板子，自己搭个三路模拟输入调一下，面试时能说出实测数据会更有说服力。

丢帧通常是因为你用了帧同步，改用行同步加FIFO就好了。BRAM省下来的关键是不存整帧，只存几行。面试官看到你写行缓存而不是帧缓存，基本就过了。追问：你当时手撕时有提到乒乓操作吗？

面试官说丢帧，其实是在提醒你：AXI4-Stream的握手机制下，只要你的模块在某个周期没有准备好接收新数据（ready拉低），上游源端就可能因为内部FIFO满而丢弃数据——这不是你故意的，是协议层强制行为。你写帧缓冲方案，等于每帧进来都要等三帧都到齐才开始处理，等待期间后级ready一直为低，上游背压不住必然丢数据。所以核心思路不是怎么缓存更大，而是让流水线在任何时钟周期都能接受新数据。具体到三帧对齐，我推荐用行缓存加乒乓FIFO。每条数据流进来后，按行写入一个深度为两倍行长的小FIFO（比如1920像素深度），三个FIFO的写使能各自独立。对齐逻辑不是等三路都满，而是用计数器记录每帧当前行号，当三个行号都达到同一值时，同时从三个FIFO读出第一个像素。这样每个FIFO里最多缓存一行半的数据，BRAM占用从几Mb降到几十Kb，而且ready信号只在FIFO快满时才拉低，大部分时间保持高电平，不会丢帧。你当时手撕时如果提到用行对齐加乒乓操作，面试官应该就不会追问丢帧问题了。另外，注意三帧曝光时间不同会导致行有效信号宽度不一样——短曝光的行有效时间短，长曝光的长，这时需要让三个FIFO的写使能都基于原始行同步信号，而不是基于有效数据数量。追问一句：你当时写的时候，是让三路的写使能同时使能，还是各自独立控制？这个细节决定了FIFO深度能不能省下来。

帧缓冲方案在校内课设够用，但面试官要的是行级流水——把BRAM从存整帧改成存几行，ready就不会被长时间拉低，丢帧自然解决。

其实面试官考的不是Verilog语法，而是你对AXI4-Stream背压机制的理解。丢帧的本质是：你用帧缓冲时，等待期间ready为低，上游源端如果内部FIFO满了就会丢弃新数据。解决方法是把帧对齐拆成行对齐：每路输入各自用一个深度为两倍行长的FIFO缓存当前行数据，然后用一个状态机检测三路行同步信号是否都到达同一行号——如果都到了，就同时从三个FIFO弹出第一个像素，从而实现逐行对齐。这样每个FIFO深度只要1.5倍行长，BRAM占用是原来的百分之一左右。另外注意曝光时间差异：短曝光帧的行有效数据量少，但行同步信号宽度不变，所以对齐时以行同步信号为准，而非有效数据个数。你当时如果画出这个状态机图，面试官应该就不会继续追问了。

面试官说丢帧，其实是在提醒你：AXI4-Stream握手下，等整帧对齐必然拉低ready，上游FIFO一满就丢。换成行对齐，每路只缓两行，用行号做同步触发，ready就能一直为高。

我去年面过类似岗位，当时也被问到丢帧问题。你写帧缓冲，本质是把三帧数据都拉进来再处理，这期间后级ready一直拉低，上游源端背压不住就会丢——这不是你模块的bug，是协议层的强制行为。面试官要的不是更大的缓存，而是流水线在任何时钟周期都能接收新数据。具体做法是把帧对齐拆成行对齐：每路输入用一个深度为两倍行长的FIFO缓存当前行，三个FIFO的写使能独立。对齐逻辑不是等三路都满，而是用三个计数器分别记录每帧当前行号，当三路行号都达到同一值时，同时从三个FIFO弹出第一个像素。这样每个FIFO最多存一行半数据，BRAM占用从几兆降到几十K。另外注意曝光差异：短曝光帧的行有效像素少，但行同步信号宽度不变，对齐要以行同步信号为准而非有效数据个数。你如果当时画出这个状态机图，他应该就不会继续追问了。追问一句：你手撕时有没有提到乒乓FIFO来掩盖写入延迟？

面试官考的是你的资源意识而非语法。帧缓冲方案在校内课设够用，但工业级HDR融合必须行级流水。建议你准备一个带行缓存加状态机的通用框架：三路输入各自写进深度为两行长的小FIFO，用行号计数器做同步触发，每检测到三路行号相等就同时读出一像素。这样BRAM占用是原方案的百分之一左右，而且ready不会被长时间拉低。如果面试官再追问丢帧，你就说把帧对齐换成行对齐，保证每个时钟周期都有握手机会。

面试官点你丢帧，其实是在问你对AXI4-Stream握手的理解——ready拉低太久，上游FIFO一满就丢数据。帧缓冲要等三帧全到，这期间ready一直低，BRAM还大。换成行对齐：每路只存两行到一个深度为两倍行长的FIFO，用行号计数器做同步，三路行号相等就同时读。这样ready几乎一直为高，BRAM占用从几兆降到几十K。手撕时画出这个状态机，他基本就不会再追问了。你当时有提到用行同步信号做触发吗？