2026年FPGA校招笔试题：用Verilog实现一个基于AXI4-Stream的实时JPEG-LS无损压缩，预测和残差编码流水线怎么设计才能不丢数据？

预测流水线卡顿，大概率是AXI4-Stream的ready/valid握手没处理好，或者预测器内部组合逻辑路径太长。先检查一下，你的预测器是不是用了多级流水线寄存器来切分关键路径？JPEG-LS预测公式里乘除法尽量换成移位加查找表，不然时序很难跑到200MHz以上。残差编码的Golomb-Rice查表，建议把k值对应的码表和长度做成双口RAM，一个周期内并行查完。

其实你遇到的丢帧问题，根源可能不在预测器本身，而在AXI4-Stream的backpressure处理。很多校招同学只盯着算法模块，忘了把ready信号跨时钟域同步好，或者没做乒乓buffer来吸收输入抖动。JPEG-LS预测器建议拆成三级流水：第一级算局部梯度，第二级查上下文表并做预测，第三级算残差。每级之间用valid-ready握手，不要用简单的使能信号，这样上游卡住时流水线能自动反压。Golomb-Rice编码器如果用查找表，要注意k值变化时表内容需要更新，可以用一块双端口BRAM，一个口写表、一个口读表，写操作只在k值改变时发生，平时不影响读。另外，残差编码的出口最好加一个fifo，深度至少256，用来吸收编码器输出码长不一致带来的突发。你现在的设计是每周期固定输出一个像素的编码结果吗？还是按可变码长输出？这个区别很大，前者容易丢数据，后者需要额外处理位宽对齐。

从面试官角度看，这道题其实在考你对AXI4-Stream握手规则和流水线气泡的理解。预测器流水线划分，关键是把JPEG-LS里那个需要查历史像素的上下文依赖给处理好。常见做法是把预测公式拆成两个周期：第一周期算局部梯度和上下文索引，第二周期算预测值和残差。这样每个周期都能处理新像素，但要注意上下文表要用双口RAM，读旧值的同时写新值，不然会多等一拍。Golomb-Rice编码器用查找表优化时，建议把码表和码长分别存成两个ROM，k值作为地址直接查，这样比组合逻辑算快很多。你现在的设计丢帧，大概率是因为编码器输出码长不固定，导致下游模块没准备好接收，而你的流水线又没设计反压机制。可以先加个简单的手握式fifo在编码器后面，深度根据最大码长偏差来定，一般16到32就够了。另外，提醒一句：校招笔试里这种题往往不要求你写出完整可综合的代码，能画出流水线框图、讲清楚握手时序和资源估计，就已经能拿大部分分了。

丢帧问题我猜是你预测器输出和编码器之间没做弹性缓冲。JPEG-LS预测器每周期出一个残差，但Golomb-Rice编码器输出码长不固定，下游可能来不及收。最简单的办法是预测和编码之间加一个异步fifo，深度设成两倍最大码长偏差，比如64。这样编码器慢的时候fifo能存住数据，不会丢。你现在的握手信号是valid-ready直接连过去的吗？有没有考虑过ready信号在编码器内部被拉低的情况？

从工程实现角度，这道题核心在两点：一是预测器流水线的时序收敛，二是编码器输出码率抖动时的反压机制。先说预测器，JPEG-LS的预测公式涉及三个邻像素的加减法和查上下文表，组合逻辑路径很容易超过5ns。常见做法是拆成三级流水：第一拍算局部梯度（三个减法器并行出），第二拍查上下文表并算出预测值（表用双口RAM，读旧值的同时把新上下文写进去），第三拍算残差。每级之间用valid-ready握手，这样上游输入速率波动时流水线能自动反压，不会丢数据。这里有个坑：上下文表更新必须在当前像素的预测值算出之后、下一个像素查表之前完成，否则会读到脏数据。所以双口RAM的写操作要延迟一拍，在第二级结束时写，保证第三级读到的永远是上一周期的旧值。再说Golomb-Rice编码器，它的输出码长随k值和残差大小变化，可能从2比特跳到16比特。如果编码器每周期固定输出一个编码结果，下游模块必须能处理任意码长。我建议编码器后面挂一个打包器（packer），把可变长度的码字拼成固定位宽（比如32位）再发出去。打包器内部用一个移位寄存器加一个位计数器，每次收到编码结果就左移并累加计数，满了32位就输出一拍。这样AXI4-Stream输出就是固定位宽的，下游fifo深度只需要16到32就能吸收码率抖动。你现在的丢帧，大概率是编码器直接输出可变码长，下游fifo深度不够或者反压没处理好。另外，如果想在校招面试里出彩，可以提一下上下文表用BRAM实现时要注意写使能的时序，以及可以用乒乓buffer来解耦预测器和编码器的速率差异。你目前用的FPGA型号是什么？不同型号的BRAM读延迟不一样，会影响流水级数划分。

我补充一个容易忽略的点：预测器流水线里的上下文表地址计算。JPEG-LS的上下文索引是靠局部梯度量化得到的，这个量化表通常用组合逻辑查，但梯度范围是-511到511，量化成9个区间，组合逻辑做比较器链会很长。个人建议把量化表做成一个小的ROM，梯度值直接作为地址查，一个周期出结果。这样虽然多占了几个BRAM，但时序压力小很多。另外，残差编码的Golomb-Rice查找表，k值如果固定不变（比如对整张图用同一个k），那表内容可以预计算好固化在ROM里，不需要动态更新。如果k值逐行或逐块变化，才需要用双口RAM来动态写表。你现在的设计里k值是固定的还是变化的？如果是固定的，那编码器出口的fifo深度可以更小，8到16就够用。还有个小技巧：编码器输出码长可以用格雷码计数器来统计，避免频繁切换位宽导致功耗异常——虽然校招一般不考功耗，但面试官听到这个会眼前一亮。

说实话，你遇到的丢帧问题，十有八九不是算法本身算错了，而是AXI-Stream握手信号在跨时钟域或者流水线级间没处理好。JPEG-LS预测器要每周期处理一个像素，核心是把组合逻辑路径切短，但更关键的是每级流水线之间必须用valid-ready握手机制，而不是简单的使能信号。很多校招同学喜欢写一个全局valid，然后所有模块共用一个ready，这在单模块仿真里能通，一旦拼到系统里，上游某模块反压一下，整条链就断了。我个人建议你把预测器拆成三级：第一级算三个局部梯度，第二级查上下文表并计算预测值，第三级算残差。每级之间放一个寄存器加valid-ready，这样即使下游编码器输出码长波动导致反压，流水线能自动停住，不会丢数据。另外，Golomb-Rice编码器的查找表优化，我推荐用双口BRAM，一个口固定读码表和码长，另一个口只在k值改变时才写，这样平时读表不占用额外周期。注意，如果你的设计里k值对整张图是固定的，那表可以预计算好固化在ROM里，连双口RAM都省了。最后一个小提醒：编码器出口的fifo深度不要拍脑袋设成8，根据最大码长偏差来算，一般16到32比较稳妥。你现在的fifo深度设了多少？是同步还是异步fifo？

丢帧大概率是predictor和encoder之间没加fifo，或者fifo深度不够。Golomb-Rice输出码长跳变时下游来不及收，简单加个深度32的异步fifo就能解决。你先试试这个，别一开始就改流水线架构。

这道题如果你只盯着'每周期一个像素'这个目标，很容易忽略一个工程陷阱：上下文表的依赖冲突。JPEG-LS的预测需要用到当前像素左边和上边的像素值，这意味着你查表的时候，上一行同列或左边像素的上下文可能刚被更新，如果你用单端口RAM，读旧值和新值就会冲突。常见的校招解法是用双口RAM，一个口读旧值，一个口写新值，但这里有个更精细的操作：写操作必须延迟一拍，在当前像素的预测值算出来之后、下一个像素查表之前完成。如果你在第三级算残差的同时写表，那第四级读到的就是刚写进去的值，完全错误。所以流水线拆法推荐这样：第一级算梯度，第二级查表并做预测，第三级算残差，同时把新的上下文写到双口RAM里，但写使能只在这级结束时有效，保证下一级读到的永远是上一周期写好的值。另外，Golomb-Rice编码器的查找表优化，我建议你把码表和码长分别存成两个ROM，k值做地址直接查，这样比组合逻辑算移位和前缀零快很多。如果k值在编码过程中变化（比如逐块自适应），那ROM就要换成双口RAM，并且用一个状态机在k值更新时暂停一到两拍来写表。你的设计里k值变化频率如何？如果变化不频繁，完全可以用一个简单的握手信号让上游停一拍，表写完之后再恢复流水，这样比用复杂缓存省事多了。最后，关于校招笔试，这类题其实不要求你把整个JPEG-LS压缩器写完整，面试官更看重你对流水线握手、数据依赖和资源取舍的理解。能说清楚哪里会有气泡、怎么消除，比硬写几百行代码得分高。

我觉得你这个问题其实可以拆成两个相对独立的事情来看，一个是预测器流水线本身的正确性，另一个是编码器出口的反压机制。很多人一上来就想着怎么把Golomb-Rice计算逻辑塞进流水线里，结果两头都没做好。先说说预测器这块，JPEG-LS的预测核心是算三个局部梯度，然后查上下文表得到预测值。这个查表操作有个麻烦：当前像素用到的上下文，可能刚被左边或者上边的像素更新过。如果你用单端口RAM，读旧值和写新值会撞车。稳妥的做法是双端口BRAM，一个口专门读旧值，另一个口在预测值算出来之后、下一个像素查表之前写新值。具体到流水线划分，我推荐三级：第一级算梯度，第二级查表并算预测值，同时在这一级的末尾把新的上下文写进RAM，第三级算残差并输出。这样每级之间加valid-ready握手，上游反压时流水线能自动停住，不会丢数据。然后说编码器，Golomb-Rice的输出码长随残差和k值变化，可能从2比特跳到16比特，下游如果没准备好接收，你的流水线又没反压，数据就会丢。所以预测器和编码器之间必须加一个异步FIFO，深度根据你估计的最大码长偏差来定，一般32到64就够。如果k值固定不变，编码器的查找表可以直接用ROM固化，读一个周期出结果；如果k值动态变化，就用双口BRAM，一个口写表、一个口读表，写操作只在k值更新时触发。还有个容易忽略的点：编码器输出码长不固定时，不要用简单的shift register来串行化，而是用位宽拼接加计数器，每次取够一个字节就发出去，这样吞吐量稳定。你现在的设计丢帧，我猜大概率是FIFO深度不够或者握手信号没处理好。方便说一下你FIFO设的多深吗？