PNG 这种格式在 PC 端属于随手就能打开的东西但一旦把它搬到 FPGA 里事情就完全不是一回事了。PNG 用的是 DEFLATE 无损压缩里面套着 LZ77 和 Huffman 两层编码还要处理 zlib 头、Adler-32 校验、逐行滤波反变换、可能的隔行扫描最后才是 RGB 像素输出。整套流程对纯硬件逻辑来说难点不在算力够不够而在数据流怎么控、状态机怎么切、BRAM 怎么省。我这次做的就是一个纯 Verilog 的 PNG 解码工程不依赖任何软核、不调用厂商 IP 里的图像库从文件头解析到像素输出全部用 RTL 写死并且整理了 10 套可综合、可上板的工程源码覆盖从仿真验证到实际显示的完整链路。这篇就把我在这个项目里踩过的坑、做过的取舍、以及每一块逻辑为什么这么设计尽量讲透适合正在做 FPGA 图像处理、想把压缩格式解码搬进硬件、或者单纯想找一个有含金量的 Verilog 实战项目练手的人参考。1. 为什么要在 FPGA 里硬解 PNG而不是先转成 BMP很多人第一反应是既然 PNG 解码这么麻烦为什么不提前在 PC 上把图片转成 BMP 或者原始 RGB 数据直接烧进 ROM 或者从 SD 卡读这个思路在图片固定不变的场景下确实成立但只要你的应用里图片是动态的、来源是网络的、或者存储空间紧张这个前提就崩了。1.1 存储带宽和容量的现实账先算一笔账。一张 1920×1080 的 24 位真彩色图片原始像素数据是 1920×1080×3 6,220,800 字节差不多 6MB。如果转成 BMP还要加上文件头基本就是这个量级。而同样一张图存成 PNG根据内容复杂度通常在 500KB 到 2MB 之间压缩比普遍在 3:1 到 10:1。对于用 SPI Flash 或者小容量 SD 卡做图库的设备来说这个差距直接决定了你能存 20 张图还是 100 张图。再看带宽。如果图片要从外部存储实时读进来显示BMP 方案下每帧要搬运 6MB按 60fps 算就是 360MB/s这个带宽对大多数中低端 FPGA 的外部存储接口来说是吃不消的。PNG 压缩后每帧可能只有 1MB 左右带宽压力直接降到六分之一。解码虽然要消耗逻辑资源但换来的存储和带宽收益是实打实的。1.2 纯 Verilog 解码的边界在哪需要说清楚的是纯 RTL 解 PNG 不是没有代价。DEFLATE 解码里的 Huffman 译码需要变长码字匹配LZ77 需要维护 32KB 的滑动窗口字典这两块是资源消耗的大头。我的做法是Huffman 译码用查表加逐位比较的混合结构滑动窗口用片上 BRAM 实现不占用外部存储。这样一套下来在中端 FPGA 上大概占用 3000 到 6000 个 LUT、若干块 BRAM具体数字取决于你支持的色深和是否支持隔行扫描。提示如果你的图库是固定的、容量也不紧张老老实实转 BMP 存 ROM 是最省事的选择。纯 Verilog 解 PNG 的价值在于动态图源和存储受限这两个场景不要为了炫技而炫技。1.3 这套工程适合谁我把 10 套工程按难度和场景做了分层有只做仿真、跑通单张图片解码的入门版有接 SD 卡、从文件系统读 PNG 再解码显示的完整版也有接以太网、把网络传来的 PNG 流实时解码的进阶版。如果你刚学完 Verilog 语法想找一个能真正锻炼状态机和数据流控制的项目从入门版开始最合适。如果你已经在做图像处理需要把压缩图源接入现有管线可以直接看进阶版的接口设计。2. PNG 文件结构拆解解码器要盯住哪几个块写解码器之前必须把 PNG 的文件组织方式吃透。PNG 是块结构每个块有固定的格式解码器本质上就是按顺序读块、识别块类型、对特定块做处理。搞不清块结构后面状态机根本没法写。2.1 文件签名和块的基本格式PNG 文件开头是 8 个固定字节的签名89 50 4E 47 0D 0A 1A 0A。这 8 个字节的作用是让解码器快速判断这是不是 PNG同时也能检测文件在传输中是否被文本模式损坏因为里面有换行符和 EOF 字符。解码器第一步就是比对这 8 个字节不匹配直接报错退出。签名之后就是一个个块。每个块的结构是固定的四段字段长度说明Length4 字节数据段长度不含类型和 CRCType4 字节块类型ASCII 字符Data变长块的实际数据CRC4 字节对 Type 和 Data 的校验这里有个容易踩的坑Length 字段是大端序Big-Endian也就是高位字节在前。Verilog 里读进来如果直接按小端拼长度就全错了。我在第一版里就栽在这解码器一直读到错误的块边界仿真波形上看数据全是乱的查了半天才发现是字节序问题。2.2 关键块类型和处理优先级PNG 的块分两类关键块Critical和辅助块Ancillary。关键块是解码必须的辅助块可以跳过。解码器要重点处理的是这几个IHDR图像头必须第一个出现。里面包含宽度、高度、位深、颜色类型、压缩方法、滤波方法、隔行方法。这几个参数决定了后面所有解码逻辑的分支走向。PLTE调色板只有索引色颜色类型 3才需要。里面是 RGB 三元组列表。IDAT图像数据可能有一个或多个。多个 IDAT 块的数据要按顺序拼接起来形成一个完整的 zlib 压缩流。这是解码的核心输入。IEND图像结束标志读到它就可以停止解析。tRNS透明度信息处理带透明通道的图片时需要。gAMA、cHRM、sRGB色彩相关辅助块纯显示场景可以忽略。我的解码器状态机就是围绕这几个块设计的先等 IHDR拿到图像参数后配置后续模块然后循环读块遇到 IDAT 就把数据送进 zlib 解码通道遇到 IEND 就收尾。2.3 IHDR 里的参数怎么影响硬件设计IHDR 里的几个字段直接决定硬件资源分配必须提前想清楚支持范围位深支持 1、2、4、8、16 位。位深越小一个字节里塞的像素越多解包逻辑越复杂。我建议第一版只支持 8 位跑通后再扩展。颜色类型0 是灰度2 是真彩色3 是索引色4 是灰度加透明6 是真彩加透明。真彩色类型 2最直观每个像素 3 字节适合入门。隔行方法0 是非隔行1 是 Adam7 隔行。隔行扫描把图像分成 7 个 pass每个 pass 只传部分行显示时要做行重排。这个逻辑很绕建议第一版只支持非隔行。注意很多 PNG 图片默认是隔行扫描的如果你只支持非隔行测试时一定要用工具确认图片的隔行标志否则解码出来会是花的。我一般用 Python 的 Pillow 库读一下img.info就能看到。3. zlib 与 DEFLATE 解码整个工程最硬的一块骨头IDAT 块拼起来之后得到的是一个标准的 zlib 流。zlib 流的结构是2 字节头 DEFLATE 压缩数据 4 字节 Adler-32 校验。DEFLATE 数据内部又是 Huffman 编码和 LZ77 的混合。这一块是整个解码器里逻辑最复杂、最容易出错的部分我把它单独拆成一个模块输入是压缩字节流输出是解压后的滤波数据。3.1 zlib 头部的两个字节别小看zlib 头是两个字节第一个字节的低 4 位是压缩方法CMPNG 里固定是 8表示 DEFLATE。第一个字节的高 4 位是窗口大小CINFO表示 LZ77 滑动窗口的大小通常是 7对应 32KB 窗口。第二个字节是标志位最低位 FCHECK 要满足一个校验条件把头两个字节当成 16 位大端整数要能被 31 整除。硬件里这个校验可以做也可以跳过因为实际图片基本都是合法的。但如果你想做健壮的解码器建议加上逻辑不复杂就是一个模 31 的余数判断。我第一版跳过了后来遇到一个损坏的文件解码器直接跑飞加了校验之后至少能优雅报错。3.2 DEFLATE 的三种块类型DEFLATE 数据是按块组织的每个块开头有 3 位头信息1 位 BFINAL 表示是不是最后一块2 位 BTYPE 表示块类型。BTYPE 有三种00不压缩存储。数据直接按字节跟在头后面长度由 LEN 和 NLEN 两个字段给出。这种块最好处理直接搬运。01固定 Huffman 编码。码表是预先定义好的不用动态生成译码逻辑简单。10动态 Huffman 编码。码表在块开头动态给出要先解析码表再译码。这是最复杂的一种也是实际压缩里最常用的。我的实现里三种都支持了但调试顺序是先跑通 00再跑 01最后啃 10。这个顺序很重要因为 00 和 01 能帮你验证后面的 LZ77 和输出逻辑把问题隔离在 Huffman 译码这一块。3.3 Huffman 译码的硬件实现思路Huffman 码是变长码译码的核心是逐位读入边读边匹配码表。软件里用二叉树或者查表都行硬件里我用了两级查表加逐位回退的方案。具体做法是先读固定位数比如 9 位去查一张主表如果主表里命中的码字长度不超过 9 位直接输出符号如果命中一个需要更多位的标记就再读若干位查副表。这样大多数短码字一次查表就能出结果只有长码字才需要二次查表兼顾了速度和资源。动态 Huffman 的码表解析是另一个难点。块开头会给出码长序列用游程编码压缩过比如连续多个相同码长用 16、17、18 这几个特殊符号表示。硬件里要先解出完整的码长数组再根据码长生成规范 Huffman 码表。这一步我用了一个小状态机把码长数组存在 BRAM 里然后按规范算法逐符号计算码字。提示规范 Huffman 码表的生成有个固定套路——先统计每个码长的符号个数算出每个码长的起始码字然后按符号顺序分配。这个算法在 RFC 1951 里有详细描述硬件实现时建议先把软件版本写对再逐行翻译成 Verilog不要直接上手写 RTL。3.4 LZ77 滑动窗口的 BRAM 实现LZ77 的核心是一个 32KB 的滑动窗口。译码时遇到字面量就直接输出该字节并写入窗口遇到长度-距离对就从窗口里回退 distance 个位置复制 length 个字节输出同时把这些字节也写入窗口。32KB 用 BRAM 实现写地址是一个循环递增的指针读地址是当前写指针减去 distance。这里有个细节复制长度可能超过 distance也就是复制的数据里包含刚刚写进去的内容这叫重叠复制。硬件里必须一个字节一个字节地复制不能并行搬否则会读到还没写入的数据。我一开始想用突发读来提高吞吐结果重叠复制场景直接出错后来改成逐字节状态机才稳定。窗口大小 32KB 对应 BRAM 深度 32768、位宽 8这个配置在中端 FPGA 上一般能放下。如果你的器件 BRAM 紧张可以考虑把窗口缩小但要注意 zlib 头里的 CINFO 字段会声明窗口大小缩小窗口可能导致某些图片解不了。4. 滤波反变换与像素重组从滤波字节到真实像素DEFLATE 解压出来的数据还不是像素而是滤波后的扫描行数据。PNG 在压缩前对每一行做了滤波目的是提高压缩率。解码时必须把滤波逆向还原才能得到真实像素值。这一步逻辑不算特别复杂但边界条件多容易出错。4.1 五种滤波类型和它们的意图每一行的开头有一个字节表示滤波类型取值 0 到 40 None不滤波直接就是原始数据。1 Sub当前字节减去左边像素的对应字节。2 Up当前字节减去上一行同位置字节。3 Average当前字节减去左边和上边像素的平均值。4 Paeth当前字节减去一个基于左、上、左上三个像素的预测值。滤波的目的是让相邻像素的差值变小这样 Huffman 编码时更容易出现重复的小数值压缩率更高。解码时就是反过来把预测值加回去。4.2 逐字节还原的状态机设计滤波还原必须逐字节进行因为每个字节的还原都依赖左边和上边的已还原值。硬件里我用了一个行缓冲保存上一行还原后的像素当前行还原时同时访问左边像素当前行缓冲和上边像素上一行缓冲。对于真彩色图片每个像素有 R、G、B 三个字节滤波是按字节做的不是按像素做的。也就是说Sub 滤波时R 减的是左边像素的 RG 减的是左边像素的 G以此类推。这个细节如果搞错颜色会整体偏移。我在调试时用了一张纯色渐变图一眼就能看出颜色对不对比用复杂图片调试快得多。Paeth 滤波的预测函数稍微绕一点它要在左、上、左上三个值里选一个最接近的。具体算法是计算三个预测值然后选差值绝对值最小的那个。硬件里就是几个加减和比较逻辑不复杂但要小心有符号数的处理。4.3 位深小于 8 时的解包如果图片位深是 1、2、4一个字节里会打包多个像素。比如位深 4 时一个字节里有两个像素高 4 位是第一个低 4 位是第二个。解包时要按位深提取然后根据颜色类型决定是查调色板还是直接当灰度值。索引色图片还要查 PLTE 调色板把索引值转成 RGB。调色板最多 256 项每项 3 字节用一块小 BRAM 存就行。查表逻辑很简单但要注意调色板可能不足 256 项越界索引要处理。注意位深和颜色类型的组合是有限制的。比如颜色类型 2真彩色只允许位深 8 或 16颜色类型 3索引色只允许位深 1、2、4、8。解码器在 IHDR 阶段就要校验这些组合不合法的直接报错不要硬着头皮往下解。5. 10 套工程源码的分层设计与选型逻辑标题里说的10 套工程源码不是简单复制粘贴改改参数而是按不同应用场景和技术难度做了分层。每一套解决一个具体问题接口和资源占用都不一样。下面说说这个分层是怎么想的以及每套适合什么场景。5.1 从仿真验证到上板显示的递进第一层是纯仿真工程不涉及任何外部接口输入是一段预先把 PNG 文件转成的十六进制文本通过 testbench 喂给解码器输出像素写到文件里再用脚本转成图片对比。这一层的价值是让你在没有硬件的情况下把解码逻辑调通波形看得清清楚楚。第二层是接 ROM 的工程把一张小尺寸 PNG 的字节流烧进片上 ROM解码后直接送 VGA 或者 HDMI 显示。这一层引入了时序约束和显示接口但图源是固定的适合验证解码器在真实时钟下的行为。第三层是接 SD 卡的工程通过 SPI 读 SD 卡上的 PNG 文件经过文件系统解析后送解码器。这一层引入了存储接口和文件系统复杂度上了一个台阶但也是最接近实际产品的形态。第四层是接以太网的工程把网络传来的 PNG 数据流实时解码。这一层对数据流的缓冲和背压处理要求最高因为网络速率和显示速率不匹配必须有足够的 FIFO 做缓冲。5.2 资源占用和器件选型的对应关系不同层次的工程对 FPGA 资源的要求差别很大。我整理了一个大致的对应关系工程层次主要资源消耗建议器件档次典型 LUT 占用纯仿真无任意3000-5000ROM 显示解码器 显示接口入门级4000-6000SD 卡解码器 SPI 文件系统中端6000-9000以太网解码器 MAC 大容量 FIFO中高端8000-12000这个数字是粗略估计实际占用跟你的图片尺寸、色深、是否支持隔行都有关系。我的建议是先用仿真工程确认逻辑正确再根据你的实际器件资源决定上哪一层。5.3 接口设计的统一与差异为了让 10 套工程能共用同一个解码核心我把解码器做成了一个标准接口的模块输入是字节流加有效信号输出是像素加行列坐标加有效信号。上层的差异全部封装在数据源适配这一层里——ROM 版就是从 ROM 读SD 卡版就是从 SPI 读以太网版就是从 FIFO 读。这样解码核心只写一遍改数据源就行。这个设计的好处是调试时可以把问题隔离如果仿真工程能出正确图片说明解码核心没问题上板出问题就一定是数据源或者时序的问题。我实际调试时就是靠这个分层把大部分问题都定位在了数据源侧省了很多时间。6. 调试 PNG 解码器的实战排查链路PNG 解码器出错时现象往往是图片花了或者完全没输出但原因可能藏在任何一个环节。我总结了一套从后往前的排查方法能快速定位问题在哪一层。6.1 先确认压缩流本身是否完整第一步不是看解码器而是确认你喂进去的压缩数据是不是完整的。PNG 的 IDAT 可能有多个块必须按顺序全部拼接。我遇到过一次SD 卡读取时只读了第一个 IDAT 块后面的没读结果解压到一半数据就没了输出自然是残缺的。验证方法很简单在 PC 上用 Python 把 IDAT 数据提取出来手动做 zlib 解压看能不能成功。如果 PC 上都解不了硬件肯定也不行。这一步能排除掉文件本身和数据搬运的问题。6.2 用固定 Huffman 块做隔离测试如果压缩流没问题但解码结果不对下一步是用固定 HuffmanBTYPE01的图片做测试。固定 Huffman 的码表是预定义的不涉及动态码表解析能把问题范围缩小到 Huffman 译码和 LZ77 这两块。我一般会构造一张特别简单的图比如 8×8 的纯色图这种图压缩后数据量很小波形上能一眼看完整个解码过程。如果纯色图能解对再换渐变图最后换真实照片。这个从简到繁的顺序能帮你快速定位是哪类数据触发了 bug。6.3 逐行对比滤波还原结果如果 Huffman 和 LZ77 都对了但像素颜色不对问题多半在滤波还原。这时候可以把解压后的滤波数据 dump 出来在 PC 上用 Python 手动做滤波还原和硬件输出逐行对比。对比时重点看每一行的第一个像素。因为滤波还原是从左到右、从上到下进行的第一个像素只依赖滤波类型不依赖左边像素是最容易验证的。如果第一个像素对了后面的错了那多半是行缓冲的读写地址有问题。提示调试滤波还原时把每一行的滤波类型也 dump 出来对照着看。有时候是滤波类型字节被当成了像素数据导致整行偏移一个字节这种错误在波形上很明显但如果不看滤波类型就容易忽略。6.4 时序和跨时钟域的坑上板之后如果仿真对、实际不对八成是时序或者跨时钟域的问题。解码器的数据源比如 SD 卡 SPI和显示接口往往在不同时钟域FIFO 的读写指针同步没做好就会出现偶发的数据错位。我的经验是所有跨时钟域的信号都用两级触发器同步FIFO 用厂商提供的异步 FIFO IP不要自己手写。手写异步 FIFO 在仿真里可能看不出问题上板后随着温度和电压变化亚稳态就会冒出来。这个坑我在早期项目里踩过后来一律用 IP省心很多。7. 工程源码的使用方式和二次开发建议拿到 10 套源码之后怎么用、怎么改直接决定了你能不能把它变成自己的东西。这里说说我的建议。7.1 先跑仿真再上板不要跳步很多人拿到源码第一件事就是上板结果板子不亮就开始怀疑代码。正确的顺序是先用仿真工程跑通确认输出图片和原图一致再上最简单的 ROM 显示工程确认时序没问题最后才上 SD 卡或者以太网工程。每一步都确认无误再往下走出问题时才能快速定位。仿真工程里我提供了 testbench 和对比脚本跑完之后会自动生成解码后的图片和原图做像素级对比。这个脚本能帮你省掉大量肉眼比对的时间。7.2 按需裁剪功能来省资源如果你的应用不需要隔行扫描、不需要 16 位色深、不需要透明度完全可以把这些逻辑裁掉。解码器里这些功能都是独立的分支裁掉之后资源占用能降不少。我建议先保留全部功能跑通确认没问题后再逐项裁剪每裁一项就重新验证一次确保没裁错。裁剪时要注意 IHDR 的校验逻辑也要同步改否则遇到不支持的图片格式解码器可能进入未定义状态。我的做法是不支持的特性直接在 IHDR 阶段报错输出一个错误标志让上层决定怎么处理。7.3 扩展方向从单张解码到图库管理这套工程目前是解一张图的形态。如果你要做图库可以在外面套一层管理逻辑维护一个图片索引表根据索引从存储里读出对应的 PNG 数据送进解码器。索引表可以存在 Flash 的固定位置启动时读进 BRAM。再进一步如果要做图片切换动画可以在解码器前面加一个双缓冲一张图在显示的同时另一张图在后台解码解完之后切换。这样切换时不会闪屏。双缓冲的切换逻辑要注意时序切换点最好选在帧消隐期避免撕裂。我在实际项目里还遇到过一个需求图片需要缩放显示。这个可以在解码输出后接一个缩放模块用双线性插值把像素重采样到目标尺寸。缩放模块和解码器之间用一个 FIFO 解耦因为两者的吞吐率不一定匹配。这部分逻辑我在另一套工程里有实现思路和这里的数据流控制是一致的。最后分享一个我在调试时养成的小习惯每次改完代码先跑仿真对比脚本确认输出图片的 MD5 和原图一致再上板。这个习惯帮我挡掉了至少一半的低级错误尤其是改地址计算或者状态机跳转的时候肉眼很难发现的问题MD5 一比对就露馅了。