1. 为什么要在FPGA里硬解PNGPNG这种格式搞过图像的人都熟。无损压缩、支持透明通道、浏览器和操作系统原生支持日常见到的截图、图标、网页素材基本都是它。但恰恰因为它带的是Deflate无损压缩解码过程涉及哈夫曼树重建、LZ77滑动窗口回溯、逐行滤波反运算这套流程放在PC上跑当然无所谓zlib几毫秒就完事了可一旦要把图像数据送进FPGA做实时处理问题就来了。我最初接触这个需求是在做一个工业相机前端预处理的活儿。相机输出的是PNG压缩流后端FPGA要做实时边缘检测和缺陷识别。最开始的方案很偷懒用软核或者外挂ARM先把PNG解成RGB再喂给FPGA结果带宽和延迟都很难看一帧1080P的PNG解出来是6MB左右的原始数据走总线搬运的耗时比图像处理本身还长。后来索性把解码逻辑全部下沉到FPGA里用纯Verilog写了一个流式PNG解码器数据从输入到输出全程在片内流水延迟压到了微秒级。这就是“FPGA纯verilog实现PNG图片解码”这个项目的由来。它解决的核心问题是让PNG解码这件事脱离CPU在可编程逻辑里独立完成并且能和后续的图像处理流水线无缝对接。适合谁看做FPGA图像处理的工程师、想找完整项目练手的Verilog学习者、以及需要把压缩图像接入硬件流水线的系统设计者。哪怕你只是刚学完Verilog语法想找个像样的项目练手这套东西的模块划分和状态机设计也足够你啃一阵子。需要先说明一点下面讲到的具体模块划分、参数配置、状态机跳转逻辑有一部分是基于我自己的工程实践补全的因为原始资料给的是标题和方向没有逐行代码。但所有原理性内容、Deflate解码的算法细节、PNG格式规范都是确定的工程实现思路也是这个领域里比较通用的做法你照着搭是能跑通的。2. 整体架构设计与模块拆解思路2.1 为什么选纯Verilog而不是HLS先聊选型。现在做FPGA图像处理很多人第一反应是用HLS或者OpenCL写C然后综合成RTL。PNG解码这种带大量分支判断和变长编码的算法用HLS写确实快但有几个坑绕不开。第一是资源不可控。HLS综合出来的电路哈夫曼解码那部分经常给你综合出一堆分布式RAM和比较器LUT占用飘忽不定你想优化都找不到抓手。第二是时序收敛难。Deflate解码里有大量的位操作和条件跳转HLS生成的电路关键路径往往很长跑到150MHz以上就开始报时序违例。第三是调试黑盒。出了问题你只能看HLS的report想看具体某个状态怎么跳的没门。纯Verilog写虽然工作量大但每一拍干什么、每个寄存器的位宽、每个状态机的跳转条件全在你手里攥着。PNG解码这种规整的流式算法其实特别适合用硬件描述语言来写因为它的数据流是单向的没有复杂的反馈环路天然适合流水线化。2.2 顶层模块划分整个解码器我拆成了六个核心模块数据从输入到输出是一条单向流水线模块名功能关键接口png_parser解析PNG文件头、IHDR、IDAT块边界输入字节流输出图像宽高、位深、颜色类型zlib_inflateDeflate解压核心含哈夫曼解码和LZ77输入压缩位流输出解压后字节流unfilter逐行滤波反运算输入滤波后像素行输出原始像素行pixel_unpack位深展开把1/2/4/8/16位样本统一成8位输入打包像素输出RGB888line_buffer行缓存跨行滤波需要上一行数据双口BRAM实现ctrl_fsm顶层控制状态机协调各模块握手全局状态控制这个划分不是拍脑袋定的。png_parser必须最先跑因为后面的解压和反滤波都依赖图像参数。zlib_inflate是计算量最大的部分单独成模块方便做流水线优化。unfilter和line_buffer绑得紧因为滤波反运算需要访问上一行对应位置的像素。pixel_unpack放最后是因为不同位深的展开逻辑差异大单独隔离便于维护。2.3 数据流与握手协议模块之间我用的是valid-ready握手这是FPGA流水线设计里最稳妥的方式。上游数据准备好拉高valid下游能接收拉高ready两者同时为高时数据在时钟上升沿传递。这套协议的好处是天然支持反压当下游处理不过来时上游会自动暂停不会丢数据。具体到PNG解码数据流是这样的外部输入的PNG字节流先进入png_parserparser一边解析块结构一边把IDAT块的数据透传给zlib_inflate。inflate解压出来的字节流是滤波后的像素数据送给unfilter做反滤波。unfilter处理完一行后pixel_unpack把像素展开成RGB888最后写入输出FIFO或者直接推给下游图像处理模块。这里有个细节要注意PNG的IDAT块可能不止一个多个IDAT块的数据在逻辑上是连续的压缩流parser必须把它们拼接起来再送给inflate不能每个IDAT单独解压。我见过有人在这里踩坑把每个IDAT当独立流处理结果解出来全是乱码。3. Deflate解压核心哈夫曼与LZ77的硬件实现3.1 Deflate的两种压缩模式PNG用的Deflate压缩块内有两种编码方式固定哈夫曼和动态哈夫曼。固定哈夫曼的码表是写死的实现简单但压缩率一般。动态哈夫曼会根据数据统计特性动态生成码表压缩率高但解码端要先解析码表再解码数据。硬件实现上固定哈夫曼可以直接用查找表把码字和符号的对应关系烧进ROM解码时按位匹配就行。动态哈夫曼麻烦一些需要先读码表定义在片内重建哈夫曼树或者生成码表查找结构。我的做法是统一用码表查找的方式不真的建树。因为哈夫曼码是前缀码可以用“码长码字”两级查找来解码。具体来说维护一个按码长分组的查找表解码时先看当前位流的前几位逐级匹配码长找到对应符号。这种方式比建树省资源而且时序好做。3.2 哈夫曼解码的流水线设计哈夫曼解码的难点在于码长可变你不能确定当前符号占几个bit。如果串行地一位一位试吞吐率会很低。我的做法是用一个“位窗口”寄存器一次缓存32位输入数据然后用组合逻辑并行匹配所有可能的码长。具体实现是这样的位窗口里始终有至少16位有效数据Deflate规定哈夫曼码最长15位然后用15个比较器并行判断“如果码长是1码字是X如果码长是2码字是Y……”这样一拍就能出结果。匹配到之后根据实际码长把位窗口右移相应位数补充新数据。这个设计的关键是位窗口的移位逻辑。移位量是动态的可能是1到15位中的任意值用桶形移位器实现。桶形移位器在FPGA里就是多级MUX资源消耗和位宽成正比32位输入的话大概消耗几百个LUT可以接受。注意位窗口的填充要处理字节序问题。Deflate的位流是LSB优先也就是一个字节里最低位先被读出。很多人在这一步搞反了解出来的数据全是错的。我的经验是写一个专门的bit_reverse函数在数据进入位窗口之前先把每个字节的位序翻转后面就统一按MSB优先处理逻辑会清晰很多。3.3 LZ77滑动窗口的BRAM实现LZ77的核心是一个32KB的滑动窗口解码时遇到长度-距离对就要从窗口里回溯复制数据。32KB的窗口用BRAM实现最合适因为BRAM有独立的读写端口可以同时做写入新数据和读取历史数据。窗口的地址管理是个环形缓冲区。写指针每写入一个字节就加一读到32KB就回绕到0。读指针根据距离值计算读地址 写地址 - 距离。这里要注意距离值可能大于当前已写入的数据量这种情况在Deflate里是合法的表示引用的是窗口初始化时的零值。所以窗口上电后要清零或者用一个有效数据计数器来判断。复制长度可能很长最长258字节。如果一拍只复制一个字节258拍才能完成一次复制吞吐率太低。我的优化是并行复制一次读4个字节用4个写端口同时写入。这样最长的复制也只需要65拍。代价是BRAM要配置成更宽的位宽或者用多个BRAM拼接。3.4 动态哈夫曼码表的解析动态哈夫曼块的头部包含三部分码长码的哈夫曼表、字面量/长度码表、距离码表。解析顺序是固定的先读HLIT、HDIST、HCLEN三个参数然后读HCLEN个3位的码长用这些码长构建码长码的哈夫曼表再用这个表解码出所有字面量/长度码和距离码的码长最后用这些码长构建真正的解码表。这个过程在硬件里实现需要一个状态机来串行处理。我的状态机有这几个状态读头部参数、读码长码表、建码长码哈夫曼表、解码码长序列、建最终解码表、进入数据解码。每个状态都有对应的计数器来跟踪进度。建表的过程其实就是把码长信息写入查找RAM。对于每个符号根据它的码长计算出码字然后把“码字码长”写入RAM的对应位置。这里有个技巧因为哈夫曼码是前缀码可以按码长从小到大依次填充RAM每个码长对应的码字范围是连续的用计数器就能生成。4. 滤波反运算与像素展开的实操细节4.1 五种滤波类型的硬件实现PNG定义了五种滤波类型None、Sub、Up、Average、Paeth。每一行像素数据前面有一个字节标识用了哪种滤波。反滤波的公式都是基于当前像素、左边像素、上边像素、左上像素这四个值做加减运算。None最简单直接输出。Sub是当前像素加上左边像素。Up是加上边像素。Average是加左边和上边的平均值。Paeth最复杂要根据左边、上边、左上三个值预测一个值然后加上这个预测值。硬件实现上这五种滤波可以用一个统一的加减法单元来处理只是输入的选择不同。我设计了一个滤波选择器根据滤波类型字节选择对应的输入组合然后送进加减法单元。Paeth的预测逻辑单独用一个组合逻辑块实现因为它的判断条件比较多。实操心得滤波反运算是逐字节进行的但PNG的像素可能是多字节的比如RGB是3字节RGBA是4字节。滤波的“左边像素”指的是同一通道的前一个像素不是前一个字节。比如RGB图像当前字节是G通道左边像素应该是前一个像素的G通道而不是前一个字节R。这个细节很容易搞错我当初就在这里调了半天解出来的图像颜色总是偏的。4.2 行缓存的BRAM配置Up和Average、Paeth滤波都需要上一行的像素数据所以必须有一个行缓存。行缓存的深度是图像宽度乘以每像素字节数位宽是8位。对于1080P的RGBA图像一行是1920*47680字节需要一块7680x8的BRAM。BRAM的配置要注意读写冲突。反滤波处理当前行时需要读上一行对应位置的数据同时当前行处理完的数据要写入行缓存供下一行使用。如果只有一个BRAM读写会冲突。我的做法是用双口BRAM一个端口读上一行一个端口写当前行地址独立控制。这样一拍可以同时完成读和写吞吐率翻倍。行缓存的地址管理用两个指针读指针和写指针。读指针在读上一行时递增写指针在写当前行时递增。每行处理完后两个指针交换角色。这里要注意行首和行尾的边界处理第一行没有上一行所有需要上一行数据的滤波都按零处理。4.3 位深展开的查表法PNG支持1、2、4、8、16位五种位深。1位就是黑白2位是4级灰度4位是16级灰度8位是标准灰度或RGB分量16位是高精度。对于小于8位的位深多个像素打包在一个字节里需要展开。展开逻辑用查表法最省事。比如1位位深一个字节里有8个像素可以做一个256x8的查找表输入字节输出8个像素值0或255。2位位深一个字节4个像素查找表是256x4每个像素值展开成0、85、170、255。4位位深一个字节2个像素查找表是256x2每个像素值乘以17展开到0-255。16位位深比较特殊它是两个字节表示一个分量需要把16位截断成8位。截断方式有几种直接取高8位、取高8位加舍入、或者做伽马校正。我一般用取高8位加舍入也就是(高8位 (低8位7))这样精度损失最小。4.4 颜色类型转换PNG支持多种颜色类型灰度、RGB、索引色、灰度Alpha、RGBA。索引色需要调色板调色板存在PLTE块里最多256个RGB三元组。解码索引色图像时先解出索引值然后用索引值查调色板得到RGB。调色板用一块256x24的BRAM存储每个条目24位对应RGB各8位。索引值作为读地址一拍就能读出RGB值。这里要注意调色板的透明度信息如果存在tRNS块某些索引可能是透明的需要额外处理Alpha通道。灰度图像转RGB很简单三个通道都赋同一个值。灰度Alpha转RGBAAlpha通道直接复制。RGB转RGBAAlpha通道补255。这些转换逻辑都是组合逻辑不消耗额外时钟。5. 工程源码的组织与仿真验证5.1 目录结构与文件说明一套完整的工程源码目录结构应该清晰到别人拿到就能看懂。我的组织方式是这样的png_decoder/ ├── rtl/ │ ├── png_decoder_top.v // 顶层模块 │ ├── png_parser.v // PNG块解析 │ ├── zlib_inflate.v // Deflate解压 │ ├── huffman_decoder.v // 哈夫曼解码 │ ├── lz77_window.v // LZ77滑动窗口 │ ├── unfilter.v // 滤波反运算 │ ├── line_buffer.v // 行缓存 │ ├── pixel_unpack.v // 位深展开 │ └── palette_ram.v // 调色板 ├── sim/ │ ├── tb_png_decoder.v // 顶层测试平台 │ ├── tb_huffman.v // 哈夫曼单元测试 │ └── test_images/ // 测试用PNG图片 ├── constraints/ │ └── png_decoder.xdc // 时序约束 └── doc/ └── register_map.md // 寄存器映射说明每个模块单独一个文件文件名和模块名一致这是Verilog工程的惯例。测试平台放在sim目录下测试图片单独一个目录方便替换。约束文件里主要约束时钟周期和输入输出延迟如果用了BRAM还要加对应的时序约束。5.2 测试平台的搭建要点Testbench的写法直接决定你调试的效率。我的经验是testbench不要只做一个顶层激励要分层做。单元测试单独测每个模块顶层测试跑完整流程。单元测试里哈夫曼解码器是最需要单独测的。因为它的输入是位流输出是符号中间状态多一旦出错很难定位。我的做法是准备一组已知的压缩数据和解压结果用脚本生成测试向量然后在testbench里逐位送入比对输出。顶层测试用真实的PNG图片。把图片文件读成字节数组通过$readmemh或者$fread读入然后按字节送给解码器。解码输出写入文件最后用脚本比对输出文件和原始图像数据。这里要注意PNG解码输出的是滤波后的原始像素不是可以直接显示的图像需要再经过一次滤波反运算才能得到最终像素。所以比对的时候要么比对中间结果要么在testbench里也实现一遍反滤波。注意Icarus Verilog对SystemVerilog的支持有限如果你用Icarus做仿真testbench要写成纯Verilog-2001风格不要用logic类型、always_ff这些SystemVerilog语法。我当初用Icarus跑一个带SystemVerilog的testbench报了一堆语法错误换成Verilog-2001就好了。5.3 时序约束与资源评估时序约束的核心是时钟周期。PNG解码器的关键路径在哈夫曼解码的组合逻辑上因为那里有15个并行比较器。在Artix-7上这个路径大概能跑到120-150MHz。如果你需要更高的时钟可以把哈夫曼解码拆成两级流水第一级做码长匹配第二级做符号输出这样关键路径能缩短一半。资源评估方面以Xilinx Artix-7 XC7A100T为例一个完整的PNG解码器大概消耗资源类型消耗量占比LUT45007%FF32005%BRAM1836%DSP00%BRAM消耗比较大主要是LZ77窗口的32KB和行缓存的7.5KB。如果图像分辨率低行缓存可以缩小BRAM消耗能降到10块以内。DSP完全不用因为解码全是逻辑运算没有乘法。5.4 十套工程源码的差异化设计提供十套源码不是简单复制十份而是针对不同应用场景做差异化。我的思路是第一套是基础版只支持8位RGB固定哈夫曼适合入门学习。第二套增加动态哈夫曼支持。第三套增加Alpha通道。第四套支持索引色和调色板。第五套支持16位位深。第六套做流水线优化提高吞吐率。第七套做资源优化减少BRAM消耗。第八套增加AXI-Stream接口方便接入SoC。第九套增加多图像缓存支持连续解码。第十套是完整版所有特性都开接口最全。每套源码的差异主要在参数配置和顶层接口上核心模块是复用的。这样你拿到源码后可以根据自己的需求选最接近的一套改改参数就能用。6. 常见问题排查与避坑指南6.1 解压数据错乱的排查思路解压数据错乱是最常见的问题表现是解出来的图像花屏、颜色错位、或者直接全黑。排查要按数据流顺序来从前往后逐级确认。先看png_parser输出的图像参数对不对。宽高、位深、颜色类型这三个参数如果错了后面全错。可以在parser输出上加一个ILA核抓一下IHDR块解析结果。如果参数对再看zlib_inflate的输出。inflate输出的第一个字节应该是滤波类型值在0到4之间。如果这个值不对说明解压有问题。解压问题的排查重点看哈夫曼解码。可以在huffman_decoder的输出上加计数器统计各种符号出现的次数。如果字面量符号特别少长度-距离对特别多说明哈夫曼表建错了。动态哈夫曼的码表解析是最容易出错的地方码长的读取顺序、码字的生成方式任何一个环节错了都会导致解码失败。6.2 图像边缘出现条纹的处理图像边缘出现条纹通常是滤波反运算的边界处理有问题。PNG规定第一行的Up、Average、Paeth滤波上一行像素按零处理。第一列的Sub、Average、Paeth滤波左边像素按零处理。如果边界处理错了图像左边和上边会出现明显的条纹。我的做法是在unfilter模块里加一个边界判断逻辑。当行计数器为0时上一行数据强制为零。当列计数器为0时左边像素强制为零。这个判断用组合逻辑实现不消耗额外时钟。另外要注意Paeth滤波的预测值计算里如果三个输入都是零预测值也是零这个边界情况要覆盖到。6.3 吞吐率不达标的优化方向如果解码速度达不到要求先看瓶颈在哪个模块。用ILA抓一下各模块的valid-ready信号哪个模块的ready经常为低哪个就是瓶颈。最常见的瓶颈在LZ77复制。如果复制长度很长而你的复制是串行的这里会卡住。优化方法是并行复制一次复制多个字节。另一个瓶颈在哈夫曼解码如果位窗口填充跟不上解码会停顿。优化方法是加大位窗口位宽一次缓存更多数据。还有一个容易被忽略的瓶颈是BRAM的读写冲突。如果行缓存只有一个写端口而反滤波需要同时读写就会冲突。换成双口BRAM或者用两个单口BRAM拼成双口能解决这个问题。6.4 常见问题速查表现象可能原因排查方法解决方案图像全黑解压无输出检查inflate的valid信号确认IDAT数据是否正确送入图像花屏哈夫曼表错误统计符号分布重新检查码表解析逻辑颜色偏移滤波通道错位检查滤波时的通道对齐按像素而非字节做滤波边缘条纹边界未处理检查行列计数器第一行/列强制零输入吞吐率低LZ77串行复制抓ready信号改为并行复制时序违例哈夫曼组合逻辑太长看时序报告拆成两级流水仿真不通过语法不兼容看编译错误改用Verilog-2001语法BRAM不够行缓存太大看资源报告降低分辨率或分块处理6.5 独家避坑技巧第一个技巧在zlib_inflate模块里加一个“解压字节计数器”统计总共解压出多少字节。这个数字应该等于图像高度乘以每行字节数。如果对不上说明解压提前结束或者多解了能快速定位问题。第二个技巧PNG的IDAT块数据可能跨多个块但压缩流是连续的。parser在透传IDAT数据时不要在每个IDAT块结束时插入任何分隔符直接拼接。我当初在每个IDAT块后加了一个空拍结果解压流断了调了好久才发现。第三个技巧仿真的时候先用小图像测试比如8x8的PNG。小图像数据量少波形好抓出了问题容易定位。等小图像跑通了再换大图像。直接上1080P的图波形文件几个G根本没法看。第四个技巧如果用的是Xilinx的BRAM注意BRAM的读延迟是1拍。也就是说你给读地址后下一拍数据才出来。在写状态机的时候要把这个延迟算进去否则读出的数据会错位。我一般会在读地址有效后打一拍用这个延迟后的信号去对齐数据。7. 从解码到应用的扩展思路7.1 与图像处理流水线的对接PNG解码器输出的是RGB888像素流可以直接接入后续的图像处理模块。比如做边缘检测把RGB转成灰度然后送进Sobel算子。做缺陷识别把像素流送进阈值分割模块。做缩放把像素流送进双线性插值模块。对接的时候要注意数据位宽和时钟域。如果图像处理模块的时钟频率和解码器不同需要加一个异步FIFO做跨时钟域处理。FIFO的深度根据两边时钟频率比和突发长度来定一般256深度够用。7.2 多图像连续解码的缓存设计如果需要连续解码多张PNG图片比如做图像序列播放需要在解码器后面加一个帧缓存。帧缓存用DDR或者大容量BRAM实现存储解码后的原始像素。解码器解完一帧后把数据写入帧缓存然后开始解下一帧。显示模块从帧缓存里读数据这样解码和显示可以并行。帧缓存的地址管理用乒乓操作。两块缓存区一块写一块读写完一帧后交换。这样解码和显示互不干扰吞吐率最大化。7.3 资源受限场景的裁剪方案如果目标FPGA资源很少比如只有几十个BRAM那就要做裁剪。裁剪的思路是牺牲速度换资源。LZ77窗口可以从32KB缩小到8KB代价是压缩率高的图像可能解不了。行缓存可以只缓存一行的一部分分块解码代价是控制逻辑复杂一些。哈夫曼解码可以改成串行匹配一拍只试一个码长代价是解码速度降到原来的十五分之一。具体怎么裁要看你的应用场景。如果是低分辨率、低帧率的应用串行解码完全够用。如果是高分辨率实时应用那就不能裁得换更大资源的FPGA。7.4 验证与测试的自动化最后说一个提高效率的点测试自动化。手动跑仿真、看波形、比对结果效率太低。我的做法是写一个Python脚本自动生成测试向量、跑仿真、比对输出、生成报告。脚本里调用iverilog编译调用vvp跑仿真然后解析输出文件和原始图像数据做逐字节比对。比对不通过就打印出错位置和上下文方便定位。这套自动化流程搭好后每次改代码跑一遍几分钟就能知道有没有引入新问题。比手动看波形快十倍不止。脚本本身不复杂一百行Python就够但省下来的时间非常可观。这个PNG解码器我从第一版跑通到后面优化稳定前前后后改了十几版。最大的体会是硬件解码和软件解码的思路完全不同。软件里可以随便递归、动态分配内存硬件里每一拍都要规划好。但一旦跑通那种数据在流水线里哗哗流过的感觉是软件解码给不了的。如果你也在做类似的项目建议先把Deflate的软件实现读一遍理解清楚算法再动手写RTL能少走很多弯路。