JPEG-LS图像压缩算法的FPGA实现（一）：从算法原理到硬件架构的映射

1. 为什么要在FPGA上实现JPEG-LS？从算法优势到硬件加速的必然

如果你做过图像处理相关的项目，尤其是对实时性要求高的，比如医疗影像、工业检测或者无人机图传，肯定对“压缩”和“加速”这两个词又爱又恨。爱的是它们能节省宝贵的带宽和存储空间，恨的是软件算法跑在CPU上，速度常常跟不上。我自己就踩过这个坑，当时做一个在线检测系统，用软件跑无损压缩，帧率死活上不去，成了整个系统的瓶颈。

后来我把目光投向了硬件加速，FPGA自然是首选。在众多无损/近无损压缩算法里，为什么偏偏是JPEG-LS？这得从它的“出身”说起。JPEG-LS（ISO/ITU-T的正式编号是ISO/IEC 14495-1）的设计初衷就是为了简单高效。它不像JPEG那样搞复杂的离散余弦变换（DCT），也不像JPEG 2000那样用计算量巨大的小波变换和算术编码。JPEG-LS的核心是LOCO-I（Low Complexity Lossless Compression for Images）算法，它的“武器库”里主要是基于上下文的预测、一个简单的自适应修正，以及最后那一步非常硬件友好的Golomb-Rice编码。

这种简洁性，对于硬件工程师来说，简直是天赐良缘。算法步骤清晰，数据依赖关系相对明确（虽然也有坑，后面会讲），这意味着我们可以把它相对直接地“翻译”成硬件电路。在FPGA上，我们可以把算法的不同步骤拆解成独立的硬件模块，让它们并行工作，形成一条高效的流水线。想象一下，软件是单线程的，必须按顺序一步步算；而在FPGA里，我们可以让“梯度计算”、“预测”、“编码”这几个车间同时开工，处理图像中不同位置的像素，吞吐量自然就上去了。实测下来，一旦流水线灌满，处理速度相比高性能CPU的纯软件实现，提升一个数量级是很常见的事情。

所以，选择在FPGA上实现JPEG-LS，不是一个“能不能”的问题，而是一个“太合适了”的选择。它完美契合了那些对图像保真度要求极高（不能有任何视觉损失或误差必须严格控制）、同时又对处理速度和功耗非常敏感的嵌入式视觉应用场景。

2. 庖丁解牛：JPEG-LS核心算法步骤的硬件视角解读

看算法论文是一回事，把它变成电路图是另一回事。我们得像个翻译官，把C语言或者MATLAB描述的算法，翻译成硬件能听懂的语言：数据流、控制信号和时序。JPEG-LS的编码流程，我们可以把它拆解成几个关键的操作车间。下面，我就结合自己画了无数遍的模块框图，带你走一遍这个“翻译”过程。

2.1 上下文建模：给每个像素“贴标签”

这是整个算法的第一步，也是最关键的一步，因为它决定了后续所有操作的“环境”。软件里可能就是一个数组查询或者哈希计算，硬件里我们得实实在在地算出来。

第一步，计算梯度。算法会看当前待编码像素X周围几个已经处理完的像素（通常是左邻a、上邻b、左上邻c和右上邻d的重建值）。计算三个方向的梯度：D1 = Rd - Rb,D2 = Rb - Rc,D3 = Rc - Ra。注意，这里用的是重建值，不是原始值。在无损模式下，重建值就等于原始值，所以这一步很简单。但在近无损模式下，由于引入了量化，重建值和原始值有细微差别，这意味着计算梯度时必须等待前一个像素完成“反量化与重建”模块的输出。这里就埋下了第一个时序挑战的伏笔：数据依赖。硬件上，我们需要一个专门的梯度计算单元，它本质上就是几个减法器。为了提速，我们可以让这三个减法并行执行。

第二步，量化梯度。算出来的梯度值是连续的整数，范围可能很大。为了减少后续查找表（LUT）的规模，我们需要把它们“归类”。算法通过一组与量化参数Near相关的阈值（T1, T2, T3）将每个梯度值映射到-2， -1， 0， 1， 2这几个离散的等级。这个操作在硬件里对应一个比较器组。我们可以为每个梯度值设计一个逻辑电路，将其与阈值比较，输出对应的量化等级。

第三步，生成上下文索引Q。拿到三个量化后的梯度等级（q1, q2, q3），通过一个公式Q = (q1 * 9 + q2) * 5 + q3把它们组合成一个唯一的索引值。这个索引Q的范围是-365到365。这个计算就是乘法和加法，一个简单的算术逻辑单元（ALU）就能搞定。这个Q值，就是当前像素的“身份证”，后续所有操作——用哪个预测偏差C、更新哪组参数——都靠它来寻址。

硬件设计小贴士：这个索引Q有正负，但后续寻址存储器（如RAM）时地址必须是正的。我们需要一个简单的映射电路，将Q映射到0~730的连续地址空间。同时，由于Q的计算依赖于梯度量化，而梯度量化依赖于梯度计算，这一串操作构成了一个小的组合逻辑链。在FPGA里，我们需要关注这条链的延迟，确保它在一个时钟周期内能稳定完成，否则会成为时序瓶颈。

2.2 预测与修正：猜猜下一个像素值

知道了上下文环境（Q），接下来就要预测当前像素X的值了。JPEG-LS采用了一种叫“边缘检测预测”的简单但有效的方法。

边缘检测预测：它观察a（左）、b（上）、c（左上）三个重建值，然后做一个判断：如果c是a和b之间的最大值，那就预测X是a和b中较小的那个；如果c是最小值，就预测X是a和b中较大的那个；如果c既不最大也不最小，那就预测a + b - c。这个逻辑在硬件里就是一个比较器网络和一个选择器（MUX）。我们可以并行比较a, b, c的大小关系，然后用比较结果作为选择信号，从三个候选值（a, b, a+b-c）中挑出一个作为初步预测值Px。

自适应预测修正：光靠邻居猜还不够准。算法为每个上下文Q都维护了一个“预测偏差”值C[Q]。这个值记录了历史上在这个上下文环境下，预测平均偏大了还是偏小了。我们用初步预测值Px减去这个偏差C[Q]（注意符号处理），得到最终的修正预测值Px_corrected。硬件上，这需要一次减法操作。关键点在于，C[Q]的值存储在一个RAM里，我们需要用上下文索引Q作为地址，去读出这个值。这里产生了关键的“读取-计算”路径。

2.3 残差计算与处理：准备“打包”的数据

得到修正预测值后，就能计算残差了：Errval = X - Px_corrected。这就是原始像素和最终预测值的差值。在无损模式下，这个Errval就是我们要编码的对象。

但在近无损模式下，为了进一步压缩，允许有一点误差。这里会多两步：

1. 量化：Errval = floor((Errval + Near) / (2*Near + 1))。这相当于把残差除以一个步长，取整。硬件上是一个乘加和移位操作。
2. 模减（Modulo Reduction）：这是为了把残差值的范围折叠到更小的对称区间，方便后续的Golomb编码。它的逻辑是：如果残差太大（超过正半区间），就减去最大值；如果太小（低于负半区间），就加上最大值。这个操作在硬件里体现为几个比较器和一个条件加法器/减法器。虽然描述起来有点绕，但用硬件描述语言（如Verilog）写出来，就是一个if-else控制的数据选择通路。

2.4 参数更新：让算法“学习”起来

JPEG-LS是自适应的，意味着它会根据编码过程中的统计信息不断调整自己。这就是通过更新四组与上下文Q相关的参数实现的：A[Q],B[Q],C[Q],N[Q]。

• N[Q]：计数器，记录这个上下文出现了多少次。
• A[Q]：累计残差绝对值，用于估计Golomb编码的参数k。
• B[Q]：累计残差（带符号），用于调整C[Q]。
• C[Q]：就是我们前面用到的预测偏差。

每编码完一个像素，就要根据当前的残差Errval和Near参数，更新A,B,N，然后根据B和N的新值，决定是给C加1、减1还是不变。这是整个算法中最“麻烦”的一步，也是硬件设计最大的挑战所在。

为什么？因为它构成了一个紧密的反馈环路。要更新C[Q]，需要先读出旧的B[Q]和N[Q]，计算，然后写回新的B[Q]和N[Q]，同时根据计算结果更新C[Q]。而下一个像素，如果碰巧是相同的上下文Q，它需要立刻用到更新后的C[Q]来做预测修正。在高速流水线中，我们期望每个时钟周期处理一个像素。但如果读写C[Q]需要多个周期（比如RAM的读延迟是2个周期），那么当下一个像素到来时，它需要的C[Q]可能还没更新好，流水线就必须停滞（Stall），这是性能杀手。

2.5 Golomb-Rice编码：最后的“打包”

经过前面处理，残差Errval变成了一个非负整数（通过一个简单的映射：MErrval = 2 * abs(Errval) - sign(Errval)）。Golomb-Rice编码是应对几何分布数据的利器，它用很短的码字表示小数字，用长的码字表示大数字。

编码过程非常规整，特别适合硬件：

1. 确定参数k：根据A[Q]和N[Q]的值，通过比较A[Q]和N[Q]的倍数关系，动态确定k值。硬件上可以用一个查找表（LUT）或一个小的状态机来实现。
2. 拆分与拼接：将待编码数MErrval看成两部分：低k位，和高位（MErrval >> k）。编码结果就是：用一元码表示高位（高位是多少，就输出多少个0，最后跟一个1作为终止符），后面直接跟上低k位的二进制表示。 例如，MErrval=13,k=2。13的二进制是1101。低2位是01，高位是13>>2=3。一元码表示3就是0001。所以最终码流是0001（一元码）拼接01（低k位）=000101。

硬件上，这需要一个桶形移位器来取低位，一个前导零计算逻辑（或计数器）来生成一元码，最后是一个并串转换器把生成的比特流输出。这一步是纯组合逻辑，可以做得很快，并且可以独立成一个编码模块。

3. 从算法到架构：关键硬件模块的映射与设计思路

理解了算法步骤，我们就可以动手规划硬件模块了。我们的目标是把上面的“操作车间”连成一条高效的流水线。下面这张表概括了从算法步骤到硬件模块的映射关系：

这里我重点讲两个最核心、也最具挑战的模块设计思路。

预测引擎的设计：这个模块的输入是邻居像素的重建值（Ra, Rb, Rc）和从RAM读出的C[Q]值。输出是修正后的预测值Px_corrected。为了提高速度，我们必须让“边缘检测”和“读取C[Q]”并行进行。也就是说，在计算边缘检测逻辑的同时，地址Q已经产生，并立刻发起对RAM中C[Q]的读请求。RAM通常有1-2个时钟周期的读延迟。我们可以通过流水线寄存器把边缘检测的结果暂存一下，等待C[Q]数据到来，然后在下一个周期完成减法修正。这样，预测操作本身可以设计成2-3级流水线，吞吐率仍然能达到每周期一个像素。

参数更新逻辑与反馈环路的破解：这是设计的重中之重。传统的串行思路是：像素N用完C[Q]后，更新A,B,N，再根据新B和N更新C，然后像素N+1才能用新的C。这直接限制了时钟频率。 我的实战经验是，必须打破这个串行依赖。一个行之有效的策略是多路并行前向预测。具体来说：

1. 复制多组参数：我们不再只维护一套A,B,C,N数组。我们可以维护多套（例如4套），每套对应流水线中的一个不同阶段。
2. 流水线化更新：像素在流水线中移动。当它进入“参数更新”阶段时，它使用的是上一套（比如第(stage-1) mod 4套）参数计算出的C值进行预测。然后，它在本阶段更新的是当前套（第stage mod 4套）参数。
3. 延迟匹配：通过精心设计流水线深度和参数套数，确保当一个像素到达需要C值的预测阶段时，它所对应的那套参数的C值已经被更早的像素更新完毕并稳定可用。

这相当于把一条拥堵的单车道，改成了多条交替通行的车道。虽然增加了存储资源（多套参数存储器），但彻底解决了读写冲突，实现了真正的每周期处理一个像素的吞吐率。在Verilog实现时，这通常体现为一个多级流水线，每一级都有自己对应的参数存储器地址生成和写入逻辑，并通过一个精心设计的“上下文索引路由网络”来保证每个像素访问正确的参数版本。

4. FPGA实现中的核心挑战与应对策略

把算法框图变成可综合的RTL代码，路上还有几个大坑等着我们。这里分享几个我踩过的坑和填坑方法。

挑战一：存储器访问冲突与带宽JPEG-LS需要频繁访问多组上下文参数（A,B,C,N）。这些参数通常存储在FPGA的块RAM（BRAM）中。如果每个像素每个时钟周期都要对这四个数组进行读和写，对BRAM的端口数量要求极高。一个双端口BRAM同一时钟周期只能进行一读一写或两读。解决方案是：

• 资源复用与时分复用：将A、B、N（更新逻辑相关）和C（预测使用）合理分组，分配到不同的BRAM中。对于更新逻辑，可以错开读写相位，比如在时钟上升沿读，下降沿写（如果BRAM支持）。
• 使用分布式RAM或寄存器堆：对于规模不大的上下文索引范围（如近无损模式Near值较小时），可以考虑用查找表（LUT）构成的分布式RAM甚至直接用寄存器来实现，虽然资源消耗大，但访问延迟极低（1个周期），且端口多。
• 增加流水线级数：如果实在无法在一个周期完成所有存储操作，就坦然地增加流水线级数，用 latency 来换取 throughput。只要整体流水线是平衡的，吞吐率依然可以很高。

挑战二：条件操作与控制流算法中有大量的if-else判断，比如模减操作、参数C的更新逻辑（if(B<= -N) ... else if(B>0)...）。在硬件中，这些不能直接翻译成软件式的顺序判断，因为会引入优先级逻辑，延长关键路径。我们应该将其转化为并行的数据通路。 例如，对于模减，我们可以同时计算Errval + RANGE和Errval - RANGE，然后根据Errval的范围，用一个多路选择器（MUX）同时选择正确的输出。同样，对于C的更新，我们可以并行计算C-1，C,C+1三个候选值，然后根据B和N的比较结果生成的选择信号，一次选出最终值。这种方式虽然多用了一些比较器和加法器，但所有计算同时进行，最终结果通过MUX快速选出，大大提高了时序性能。

挑战三：可变长编码的输出缓冲Golomb-Rice编码输出的是变长比特流。而我们的流水线每个周期都产生一个像素的编码结果，这些结果的比特长度各不相同。如果直接输出，会造成下游模块（如FIFO或对外接口）的数据节奏混乱。我们必须设计一个缓冲对齐单元。 通常的做法是使用一个较大的移位寄存器作为缓冲池。每个周期，编码器将产生的变长码字和其长度信息送入这个缓冲池。缓冲池内部有一个指针，负责将码字拼接到一起。同时，一个状态机负责监视缓冲池中积累的比特数，一旦达到或超过一个固定的输出位宽（比如32位或64位），就将其作为一个整字输出，并更新指针。这个单元需要仔细处理边界情况，比如码字跨两个输出周期的情况。

注意：在初始设计时，可以先实现无损模式，避开近无损模式中的量化/反量化模块，以及由此带来的更复杂的数据依赖。待核心流水线稳定后，再将其作为扩展功能加入。

纸上得来终觉浅，绝知此事要躬行。这篇主要是在架构层面捋清了从JPEG-LS算法到FPGA硬件模块的映射关系，并重点分析了那些让软件工程师皱眉、却让硬件工程师兴奋的挑战点，特别是那个绕不开的参数更新反馈环路。把这些思路想明白，画好模块框图，定义清楚接口和时序，接下来动手写Verilog代码就会顺畅很多。在下一篇里，我会深入到RTL层面，分享具体模块的Verilog实现代码、仿真测试方法，以及如何优化时序和面积，让这个压缩引擎在芯片里真正飞跑起来。