2026年FPGA校招，手撕Verilog实现AXI4-Stream实时JPEG-LS无损压缩，预测和残差编码流水线怎么设计才能不丢帧且满足1080P60？

先说你最关心的流水线级数。6级流水做1080P60是够的，关键不是级数多少，是每一级做的事不能有组合逻辑太长。MED预测器3拍：第一拍拿当前像素和左、上、左上三个邻居，第二拍算预测值，第三拍做残差和符号修正。这里容易踩的坑是第一拍拿像素的时候，你的行缓冲读地址和写地址要错开一个周期，否则读出来的邻居数据是错的。行缓冲深度设成图像宽度加2就够了，用双端口BRAM，一个端口写当前行，一个端口读上一行和上上行。

接下来Golomb-Rice编码那3拍：第一拍根据残差查k值，第二拍做编码，第三拍打包成AXI4-Stream的tdata输出。重点在k值查找这一拍，如果你用查表法，BRAM读延迟会占用一个周期，所以查k值那拍里别做别的运算。预测器第三拍输出残差给编码器第一拍，中间不需要额外插拍，因为残差是组合逻辑直接传递的，只要你的时钟约束能满足1080P60的148.5MHz，这个直连没问题。

面试官真正想看的是你对行缓冲和流水线握手信号的处理。建议你写Verilog伪代码时，把每一级的valid和ready画清楚，尤其是行缓冲读地址跨越行边界时的处理。简单做法是每帧开始前清空行缓冲，第一行和第一列用固定预测值，这样边界条件好写。如果面试官追问行缓冲能不能复用，你就说双端口BRAM读写地址冲突可以通过乒乓操作或用独立写指针解决，1080P60带宽下双端口足够。

你现在的阶段是先搭一个单帧的仿真环境，用MATLAB或Python生成测试向量，验证MED和编码器是否匹配。别一上来就想全帧不丢帧，先把单像素路径调通。你用的开发板或仿真工具是什么？如果有具体型号，我可以帮你算一下BRAM和LUT的余量。

我建议你把重心放在行缓冲的地址生成上。MED需要同时拿到左、上、左上三个像素，左像素从当前行寄存器拿，上像素从行缓冲读端口拿，左上像素从行缓冲的上一周期读结果拿。行缓冲用双端口BRAM，写地址追着读地址跑，延迟一周期写入当前像素。这样三拍里第一拍就能同时拿到三个邻居，不会因为BRAM读延迟多等一拍。剩下的预测和编码按标准做法分5到6级流水，时钟频率148.5MHz肯定能跑。面试官要是问你行缓冲深度怎么算，你就说宽度加2是为了存第一列和最后一列的边界数据，实际用BRAM时深度取2的幂次方，多出来的地址不用管。你准备用哪家的FPGA做验证？不同厂商的BRAM读延迟策略不一样，会影响你的流水线设计。

你问的预测器输出和编码器之间要不要插一拍，我的建议是：不要硬插，而是让预测器的第三拍（残差修正）直接用组合逻辑把残差送给编码器的第一拍（k值查找）。因为残差只是一个减法结果，没有时序元件，组合路径短，148.5MHz下不会成为瓶颈。真正需要小心的是行缓冲的读写时序：双端口BRAM的一个端口写当前行像素，另一个端口读上一行和上上行的像素，读地址要比写地址提前一个周期，否则读出来的上像素其实是当前行的数据。我见过有人把行缓冲深度设成图像宽度，但第一列和最后一列的边界情况会读到乱数据，所以深度要设成宽度+2，多余的两个位置存边界填充值。另外k值查找如果用BRAM查表，读延迟会占用一个周期，那这一拍里就只做查表，别把编码运算塞进来。编码那两拍可以合并成一级流水吗？可以，但组合逻辑会变长，1080P60下不一定稳，建议还是拆开。你准备用Xilinx还是Altera的片子？这两家BRAM的读延迟策略不同，Xilinx默认输出寄存器可选，Altera有些器件读延迟是固定的，会影响你流水线的对齐方式。

我觉得你卡在预测器和编码器之间，本质是没想清楚数据流是推着走的，不是等一拍再走。预测器第三拍输出残差，编码器第一拍拿k值，这两件事可以在同一个时钟沿完成：残差组合逻辑进k值查找的输入寄存器，k值查找的结果（无论是查表还是计算）在下一拍被编码逻辑使用。这样中间不需要额外流水级。行缓冲那边，注意写地址比读地址慢一拍，我当时做的时候用了一个计数器分别生成读地址和写地址，读地址提前一个周期输出到BRAM端口，写地址则延迟一个周期跟上。另外面试官可能会问边界像素怎么处理，你直接说第一列和最后一列复制边界值，存到行缓冲的额外两个单元里就行。不用说得太细，但逻辑要自洽。你目前是用仿真验证还是已经上板测过时序了？

你纠结预测器输出和编码器之间要不要插一拍，其实把问题想复杂了。残差从预测器第三拍出来是组合逻辑，直接连到编码器第一拍的k值查找输入寄存器，中间不需要额外流水级。真正要小心的是行缓冲的读写错位：写地址要比读地址慢一拍，否则你读到的上像素实际上是当前行的新数据。我见过有人把行缓冲深度设成图像宽度，结果边界像素读到乱值，改成宽度+2就好了，多出来的两个位置存第一列和最后一列的复制值。另外k值查找如果用BRAM查表，读延迟会吃掉一个周期，那这一拍里就只做查表，别把编码运算塞进来。编码那两拍可以合并成一级吗？可以，但组合逻辑会变长，1080P60下不一定稳，建议还是保持分开。你目前是用仿真验证还是已经上板测过时序了？

我的建议是，先别急着画流水线，把行缓冲的地址生成逻辑理清楚，后面自然就通了。MED需要同时拿到左、上、左上三个像素，左像素从当前行寄存器拿，上像素从行缓冲读端口拿，左上像素从行缓冲的上一周期读结果拿。行缓冲用双端口BRAM，写地址追着读地址跑，延迟一周期写入当前像素。这样三拍里第一拍就能同时拿到三个邻居，不会因为BRAM读延迟多等一拍。剩下的预测和编码按标准做法分5到6级流水，时钟频率148.5MHz肯定能跑。面试官要是问你行缓冲深度怎么算，你就说宽度加2是为了存第一列和最后一列的边界数据，实际用BRAM时深度取2的幂次方，多出来的地址不用管。你准备用哪家的FPGA做验证？不同厂商的BRAM读延迟策略不一样，会影响你的流水线设计。另外校招手撕时，面试官更看重你能否说清楚数据流怎么推的，而不是纠结具体时序。你可以先画一个三拍的数据流图：第一拍邻居像素进寄存器，第二拍算预测值，第三拍出残差。然后解释残差直接喂给编码器的第一拍，中间没有气泡。这样逻辑自洽，面试官一般不会深究具体组合延迟。

面试官让你手撕JPEG-LS，重点其实不在你写了多少行代码，而是你能不能把数据流的节奏说清楚。1080P60下像素时钟148.5MHz，6级流水足够了，但行缓冲的地址生成才是最容易翻车的地方。写地址要比读地址慢一拍，否则读到的上像素是当前行的新数据。我建议你用仿真先跑一个1920×2的小图，把边界像素的读值打印出来看看，比纠结预测器和编码器之间插不插拍更有用。你准备用Vivado还是Quartus做综合？不同工具对BRAM读延迟的默认设置不一样。

说个很多人踩过的坑：行缓冲深度设成图像宽度+2，但存边界填充值的时候，第一列和最后一列的复制逻辑别漏了。MED需要左、上、左上三个邻居，左上像素是从行缓冲读端口上一周期的结果拿的，所以你的读操作必须比写操作提前一个周期启动。我画过一份简单的数据流图：第一拍读当前像素并同时拿到三个邻居，第二拍算预测值，第三拍做残差修正并组合逻辑输出给编码器。编码器那边，k值查找如果用BRAM查表，读延迟会吃掉一个周期，那这一拍里就只做查表，别把编码运算塞进来。整体6级下来，组合路径最长的是预测器的减法器，148.5MHz没问题。你目前是用Modelsim仿真还是直接在FPGA上跑ILA抓信号？

校招手撕这类模块，面试官更想看你有没有工程直觉，而不是背流水线级数。给你个具体路径：先把行缓冲的地址生成单独写一个模块仿真，这是整个系统的瓶颈。用双端口BRAM，写地址追着读地址跑，延迟一周期写入当前像素。读地址从0走到图像宽度+1，写地址从1走到图像宽度+2，这样边界像素的复制值就自然存进去了。MED预测器分三拍：第一拍从行缓冲读上像素和上上像素，同时从当前行寄存器拿左像素，组合逻辑算出左上像素（上一拍读到的上像素）；第二拍用三个邻居算预测值；第三拍做残差和符号修正。注意第三拍输出的残差是组合逻辑，直接连到编码器第一拍的k值查找输入寄存器，中间不需要额外流水级。编码器也分三拍：第一拍查k值（如果查表就用BRAM，读延迟占一拍，这一拍里只做查表），第二拍做Golomb-Rice编码，第三拍打包成AXI4-Stream的tdata和tlast。整体6级流水，从像素输入到压缩码流输出延迟大约6个时钟周期，1080P60下每行有1920个有效像素，行消隐期足够做流水线复位。还有一个容易被忽视的点：k值更新是逐像素的，但Golomb-Rice编码的上下文模型在硬件里通常简化成固定k值或者按块更新，面试官可能会追问你这个取舍。你打算用固定k值还是自适应k值？这会直接影响编码拍里的组合逻辑复杂度。另外建议你手撕前先画一张时序图，把读地址、写地址、三个邻居的波形画清楚，面试时直接拿出来讲比念代码有说服力。你现在有实际跑过仿真吗？还是只在纸上推演？

面试官其实就想看你有没有把行缓冲读写地址的错位想明白。预测器第三拍残差用组合逻辑直连编码器第一拍k值查找寄存器就行，别多插一拍。你卡在中间插拍，可能是被网上那些通用流水线模板带偏了。先拿仿真跑个1920×2的小图，把边界像素打印出来看看，比纠结级数有用。