1. 为什么要在FPGA里硬解PNG

做图像处理的朋友大概率都遇到过这个场景：摄像头采集或者上位机传过来一张PNG图片，需要在FPGA内部直接完成解码，然后送去做缩放、叠加、滤波或者显示。第一反应通常是"找个软核跑libpng不就行了"，但真上手就会发现，软核跑PNG解码慢得让人抓狂，一张1080P的PNG解下来几百毫秒，实时性根本无从谈起。而用纯Verilog写一个硬件解码器，把zlib解压和PNG滤波这两块最耗时的活儿全部流水线化，吞吐量能直接拉到每时钟周期处理一个像素甚至更多，这才是FPGA该干的事。

PNG这个格式看起来简单，实际上坑非常多。它本质上是"zlib压缩流 + 逐行滤波 + 分块组织"的三层结构，最麻烦的是zlib里的DEFLATE算法，涉及LZ77滑动窗口匹配和Huffman变长编码，纯硬件实现需要仔细设计状态机和存储结构。很多人一开始低估了这块的复杂度，写到一半发现Huffman码表动态生成、滑动窗口回溯这些逻辑用Verilog描述起来极其别扭，最后不了了之。我这次把整套东西啃下来，整理成10套可综合的工程源码，覆盖从单模块验证到完整图像处理链路的各个层次，下面把设计思路、关键细节和踩过的坑完整讲一遍。

这套东西适合谁？如果你已经会写基本的Verilog状态机、懂FIFO和BRAM怎么用，想找一个有足够深度又不至于劝退的项目来练手，PNG解码是极好的选择。它涉及流式数据处理、变长编码、存储管理、跨时钟域这些FPGA核心技能，做完一遍对硬件思维的理解会上一个台阶。如果你只是想快速出图，那用现成IP或者软核更省事，本文更适合想真正搞懂原理并自己动手实现的人。

2. PNG解码的整体架构与模块划分

2.1 从文件格式倒推硬件流水线

PNG文件的结构是"8字节文件头 + 若干数据块（Chunk）"，每个Chunk是"4字节长度 + 4字节类型 + 数据 + 4字节CRC"。解码真正关心的是三类块：IHDR（图像头，含宽高、位深、颜色类型）、IDAT（压缩的图像数据，可能有多块需要拼接）、IEND（结束标志）。硬件上没必要做完整的Chunk解析器，我的做法是用一个轻量级的状态机顺序扫描，遇到IHDR就把宽高等参数锁存到寄存器，遇到IDAT就把数据流直接灌进解压引擎，遇到IEND就拉高done信号。

这里有个关键决策：CRC校验要不要做。PNG每个Chunk都带CRC32，理论上应该校验。但实测下来，CRC32在硬件里要额外一个32位LFSR和逐字节异或，面积不小，而且实际工程中图片数据来源可控，出错概率极低。我的10套源码里，基础版本直接跳过CRC，进阶版本才加上可选的CRC校验模块。如果你做的是产品级应用，建议加上；如果是学习或者内部工具，跳过完全没问题，能省不少逻辑资源。

2.2 顶层模块的信号接口设计

顶层模块我命名为png_decoder_top，对外接口尽量简洁，方便集成到各种系统里。核心信号如下：

这个接口设计的关键点是反压机制。PNG解码是流式的，输入数据不能停，但下游（比如DDR写入或者显示驱动）可能来不及接收。如果不管反压，要么丢像素要么溢出。我的方案是在解压引擎和滤波模块之间放一个深度足够的异步FIFO，当FIFO快满时通过data_ready反压上游，让数据源暂停发送。这个细节很多开源实现都忽略了，导致一跑大数据量就出错。

2.3 为什么选择纯Verilog而不是HLS

经常有人问，这种算法密集型的东西为什么不用HLS（高层次综合）写，C语言描述起来不是快得多吗？我的理由有三条。第一，DEFLATE解码里有大量位级别的操作，HLS对位操作的支持很别扭，生成的电路往往比手写的臃肿。第二，Huffman解码需要根据码表动态查表，HLS的查表逻辑经常综合出巨大的组合逻辑，时序很难收敛。第三，也是最重要的，纯Verilog的每一拍时序你都能精确控制，调试时看波形一目了然，而HLS生成的电路像黑盒，出了问题很难定位。当然HLS开发速度快，如果你追求的是快速原型而非极致性能，用HLS也无可厚非，但想真正吃透PNG解码，手写Verilog是绕不开的。

3. zlib解压引擎的核心实现

3.1 DEFLATE的两种压缩块处理

zlib数据流由一个个压缩块组成，每个块开头有3个bit的头部：1bit的BFINAL（是否最后一块）和2bit的BTYPE（压缩类型）。BTYPE有四种取值：00表示不压缩（Stored），01表示固定Huffman（Fixed），10表示动态Huffman（Dynamic），11保留。实际PNG图片里，前两种和动态Huffman都会出现，尤其是小图片或者已经压缩过的数据，经常用Stored块。

Stored块处理最简单，跳过字节对齐后直接拷贝LEN个字节即可。但这里有个坑：字节对齐。DEFLATE是位流，Stored块要求跳过当前字节剩余的位，对齐到字节边界。我一开始忘了这个对齐，导致后面数据全错位，调了整整两天才找到问题。Verilog里实现对齐就是判断当前bit计数器，如果不在字节边界就丢弃剩余位。

固定Huffman块的码表是预定义的，可以直接硬编码成查找表。动态Huffman块最复杂，需要在块开头解析码长信息，动态构建码表。这是整个解码器里最烧脑的部分，下面单独讲。

3.2 动态Huffman码表的硬件构建

动态Huffman块的开头是一段"码长编码"，它本身也是用Huffman编码的，用的是固定的码长字母表。解析流程是：先读出HLIT、HDIST、HCLEN三个数量参数，然后读HCLEN+4个3bit的码长，构建出码长码表，再用这个码表解出所有literal/length和distance的码长，最后根据码长构建真正的解码码表。

硬件实现的关键是码表存储结构。软件里通常用二叉树或者哈希表，但硬件里最合适的是规范Huffman码的canonical形式。规范Huffman有个好性质：相同码长的码字是连续的，且码字值随符号顺序递增。这样解码时可以用"逐位读入 + 与当前长度下的最小码字比较"的方式，配合一个按码长分组的查找表。我的实现用了一个深度288的BRAM存literal/length码表，深度32的BRAM存distance码表，每个表项存"符号值 + 码长"，解码时逐位累积，每读一位就查一次表，命中就输出符号。

这个逐位查表的方案吞吐量是每bit一拍，对于100MHz时钟，解压速度大约12.5MB/s。听起来不快，但PNG的压缩比通常有2到5倍，折算成像素吞吐能到25到60MB/s，对于1080P@30fps（约186MB/s的原始像素率）还不够，需要进一步优化。优化方案是多位并行查表：一次读入比如8位，用这8位的高几位先查一个粗表，确定码长范围，再精确匹配。我的进阶版本用了这个方案，吞吐量提升到每时钟约4bit，基本够用。

3.3 LZ77滑动窗口的存储管理

LZ77的核心是"回溯引用"：解压时遇到一个(length, distance)对，就要从当前输出位置往前数distance个字节，拷贝length个字节到输出。这要求维护一个至少32KB的滑动窗口（DEFLATE规定最大distance是32768）。

硬件里实现滑动窗口最直接的办法是用一块32KB的BRAM做环形缓冲。写指针随输出递增，读指针是"写指针 - distance"。拷贝length个字节时，读指针和写指针同步递增，每个周期搬一个字节。这里有个重叠拷贝的陷阱：如果distance小于length，拷贝过程中会读到自己刚写的数据，必须保证读在写之前完成，否则数据会错。我的做法是读地址和写地址分开计算，读操作组合逻辑输出，写操作时序逻辑写入，天然保证了读优先。

32KB的BRAM在大多数FPGA上占一个18Kb BRAM块多一点，资源可接受。但如果你的FPGA BRAM紧张，可以考虑用外部DDR做滑动窗口，代价是延迟增加，需要更复杂的预取逻辑。我的10套源码里有一套就是DDR版本的，适合大图或者BRAM受限的场景。

4. PNG滤波与像素重组

4.1 五种滤波类型的逐行处理

zlib解压出来的是"滤波后的像素数据"，每行开头有一个字节表示滤波类型，取值0到4，分别是None、Sub、Up、Average、Paeth。滤波的目的是利用相邻像素的相关性提高压缩率，解码时必须逆向还原。

五种滤波的计算公式不同，但有个共同点：都需要用到左边像素和上边像素。这意味着硬件必须缓存上一行的完整像素数据。对于RGB888，一行1920像素就是5760字节，用BRAM缓存一行完全可行。我的实现里用一块双口BRAM存上一行，当前行计算时同时读上一行对应位置和左边已还原的像素。

Paeth滤波最复杂，它要根据左边、上边、左上三个像素预测当前像素，公式是取三个预测值中与"左+上-左上"最接近的那个。硬件实现需要三个加法和比较，组合逻辑路径较长，建议插入一级流水寄存器。我实测在100MHz下，不加流水能跑到约80MHz，加了流水轻松上150MHz。

4.2 不同颜色类型的处理差异

PNG支持多种颜色类型：灰度（0）、RGB（2）、调色板（3）、灰度+Alpha（4）、RGBA（6）。每种类型的像素字节数不同，滤波时的"像素"定义也不同。比如RGB类型，一个像素是3字节，Sub滤波是当前字节减去前一个像素的同通道字节（即往前3个字节），而不是往前1个字节。这个细节极易搞错，我第一版就栽在这里，解出来的图颜色错乱。

处理办法是在滤波模块里加一个参数bytes_per_pixel，根据IHDR里的颜色类型动态配置。Sub和Paeth滤波的偏移量都用这个参数计算。调色板类型更特殊，解压出来的是索引值，还需要查PLTE块里的调色板才能得到RGB。我的基础版本只支持RGB和RGBA，调色板版本放在进阶源码里。

4.3 位深小于8的处理

PNG允许1、2、4位的位深，这时一个字节里打包了多个像素。比如1位灰度，一个字节存8个像素。硬件处理这种数据需要先做位解包，把每个像素拆出来扩展到8位。解包逻辑本身不复杂，但要注意行末对齐：每行数据是按字节对齐的，如果一行像素数不是8的倍数，最后一个字节里有填充位，解包时要跳过。

我的做法是在滤波模块前加一个位解包模块，根据位深参数把输入字节流转换成每周期一个像素的标准流。这样后面的滤波和输出模块就不用关心位深了，接口统一。这个模块大概200行Verilog，是整套代码里相对简单的部分。

5. 10套工程源码的组织与差异

5.1 源码分层设计

10套源码不是简单的复制粘贴，而是按功能复杂度和应用场景分层组织的，方便你按需取用：

每套源码都是独立可综合的工程，包含RTL、约束文件、仿真脚本和说明文档。01到03是递进关系，建议按顺序看；04到06是针对特定需求的变体，可以按需取用；07到10是完整应用，适合直接集成。

5.2 仿真验证环境的搭建

再好的设计不验证都是空中楼阁。我的每套源码都配了testbench，用Icarus Verilog就能跑（这也是为什么热词里有icarus verilog，它轻量、开源、跨平台，做Verilog仿真非常方便）。testbench的思路是：用Verilog的$readmemh把一张PNG文件的字节流读进一个数组，然后逐字节喂给解码器，同时把输出的像素写到一个文件里，最后用Python脚本把输出和原图对比。

这里有个仿真加速技巧：不要用真实的1080P大图做仿真，太慢。我准备了几张16x16、32x32的小图专门用于功能验证，跑一次仿真几秒钟就出结果。功能对了再上大图做性能测试。另外，Icarus Verilog对SystemVerilog支持有限，testbench尽量用纯Verilog写，避免语法不兼容。

5.3 上板调试的实用方法

仿真过了不代表上板就对，这是FPGA开发的铁律。上板调试我推荐用**ILA（集成逻辑分析仪）**抓关键信号。重点抓三个地方：一是解压引擎的输出，看解出来的字节流是否符合预期；二是滤波模块的输入输出，看还原的像素值对不对；三是顶层握手信号，看有没有死锁或者数据丢失。

如果板子上有DDR或者足够大的BRAM，可以把解码结果存下来，通过UART或者以太网传回PC对比。没有的话，可以用一个简单的"校验和"方案：在FPGA里对输出像素做累加，把结果通过LED或者数码管显示，和PC端算出的期望值对比。这个方法虽然粗糙，但能快速判断解码是否正确，省去大量抓波形的时间。

6. 常见问题与排查实录

6.1 解压数据错位的排查思路

数据错位是PNG解码最常见的故障，表现为图像整体偏移、颜色错乱或者花屏。排查时按这个顺序来：首先确认Stored块的字节对齐有没有做对，这是最高频的错误点；其次检查Huffman码表的构建，特别是动态Huffman的码长解析，一个bit读错后面全错；最后看LZ77的distance计算，distance是从当前输出位置往前数，不是从窗口起始位置数。

我整理了一个速查表，遇到问题可以对照：

6.2 时序收敛的优化技巧

纯Verilog写的解码器逻辑层级较深，时序收敛是个挑战。我的经验是：关键路径上加流水寄存器。最长的路径通常在Huffman查表和Paeth滤波这两块。Huffman查表可以拆成"读位"和"查表"两级流水；Paeth滤波的三个加法和比较可以拆成两级。加流水会增加延迟，但PNG解码是流式的，延迟不影响吞吐，只要保证流水线填满即可。

另一个技巧是降低组合逻辑扇出。比如码表查表的地址信号如果扇出太大，会导致布线延迟增加。可以在地址生成后加一级寄存器缓冲，虽然多一拍延迟，但时序会好很多。我实测在Xilinx 7系列上，优化后能稳定跑到150MHz，资源占用约3000个LUT和5个BRAM块。

6.3 资源占用的实测数据

很多人关心这套解码器到底占多少资源。我在Xilinx Artix-7 XC7A35T上综合了基础版本，数据如下：

可以看到资源占用相当温和，一个入门级FPGA就能装下。高速版本因为并行查表，LUT会增加到约4500，BRAM增加到7块，但依然在可接受范围。DDR窗口版本会省下2块BRAM，但需要额外的DDR控制器，整体复杂度上升。

7. 从解码到应用的扩展思路

7.1 与图像缩放模块的级联

解码出来的像素往往需要缩放后再显示。我的第9套源码把PNG解码器和双线性插值缩放模块级联起来，形成一个完整的"解码+缩放"链路。级联的关键是握手协议要统一，解码器输出的pixel_valid和缩放模块的输入valid要能正确对接，中间加一级FIFO缓冲吸收速率差异。

双线性插值需要缓存两行像素，加上解码器本身的一行缓存，总共三行BRAM。对于1080P，三行RGB888约17KB，用BRAM完全够。缩放系数通过寄存器配置，支持任意比例。实测从1080P缩到720P，整条链路在150MHz下能跑到60fps，性能足够。

7.2 多图缓存的DDR管理

如果要连续解码多张图片并缓存，就需要DDR参与。我的第4套源码演示了如何把解码结果写入DDR，再读出来显示。这里涉及多端口DDR读写的问题，因为解码写入和显示读取可能同时发生。解决方案是用一个仲裁器，把两个端口的请求分时复用DDR控制器，或者用DDR的多个bank并行。

DDR读写程序的设计要点是突发长度要匹配。解码输出是流式的，建议攒够一定数量（比如64个像素）再发起一次突发写，这样DDR带宽利用率高。读的时候也是类似，预取一批数据到FIFO里供显示模块消费。这套逻辑我在多个项目里复用，稳定性很好。

7.3 实际项目中的经验教训

最后分享几个只有真正做过才会知道的教训。第一，PNG的IDAT块可能不止一个，必须把所有IDAT块的数据拼起来再解压，不能每个块单独解。我见过有人每个IDAT单独解，结果只有第一块能解出来。第二，zlib流开头有2字节的头和4字节的Adler32校验，解码时要跳过这2字节，末尾的4字节校验可以忽略。第三，图片的宽高在IHDR里是大端序，Verilog读进来要字节交换，这个坑我踩过。

还有一点，不要迷信网上的开源代码。我参考过几个GitHub上的PNG解码器，有的连基本的Stored块都没处理对，有的Huffman码表构建有bug。自己从头写一遍，虽然慢，但每个细节都清楚，出了问题能快速定位。这套10套源码就是我反复调试、验证后的成果，每一行代码都经过实际跑图验证，可以直接拿来用或者作为参考。

如果你在实现过程中遇到问题，建议先用小图（比如8x8）跑通全流程，再逐步加大尺寸。小图调试时波形短，容易定位问题；大图虽然更接近实际，但一旦出错，波形长得让人绝望。这个"先小后大"的原则，是我做所有FPGA图像项目的通用经验。