HEVC解碼器：核心模塊與仿真指南)
簡介這是一份基于 Verilog 的 H.265/HEVC 解碼器 FPGA 工程源碼面向 Zynq7035 平臺構建適用于 FPGA 開發(fā)者、視頻編解碼研究人員及有硬件基礎的嵌入式學習者。項目在 Zynq7035 上完成驗證實現(xiàn)熵解碼、語法解析、運動補償、去塊效應濾波、逆變換和圖像重構等核心流程可作為 HEVC 硬件解碼器設計參照。壓縮包共 146 個文件約 4.62MB其中以 33 個 .v 和 19 個 .sv 源碼文件為主另含 9 個 sample 測試示例、4 個 .265 碼流文件以及工程配置、Makefile 和輔助腳本方便進行仿真、綜合與上板調(diào)試。目前已有 298 人瀏覽學習。通過這套資源可以獲得完整模塊級 Verilog 源碼、測試序列和 Zynq 工程結構結合配套文章能快速掌握 H.265 解碼的硬件實現(xiàn)方法、模塊劃分與軟硬件協(xié)同設計技巧。1. FPGA 上讀 HEVC 碼流這個 Verilog 解碼器到底能做什么如果你以為在 FPGA 上解 H.265 就是把.h265文件丟給仿真器、等波形出來就完事那第一次跑這個h265_decoder項目時大概率會翻車——跑了幾萬個周期波形窗口里一片 XYUV 輸出全是花屏。這套基于 Verilog 的 HEVC 解碼器源碼本質(zhì)是把 H.265 從「NAL 層解析」到「SAO 重建」的完整鏈路搬進了硬件描述語言面向的是想在自己的 FPGA 板卡上實現(xiàn)視頻硬解、或者想搞懂 CABAC 和 CTU 劃分到底怎么走時序的開發(fā)者。它適合兩類人一類是拿它當學習藍本對照協(xié)議看熵解碼和幀間預測的硬件實現(xiàn)另一類是直接拿它做二次開發(fā)裁剪模塊、換分辨率、掛到自己的圖像處理流水線上。這篇文章會從模塊骨架、核心代碼、仿真運行到踩坑點全部拆開講。2. 整體設計與技術骨架NAL 解析、CTU 流水與參考幀管理的分層這個解碼器的頂層設計不算復雜但分層很清晰。拿到一段 H.265 裸流硬件上要干的事和軟件解碼器是同一套邏輯先做 NAL 單元解析把 SPS、PPS、SEI、Slice 數(shù)據(jù)分開再進熵解碼層用 CABAC 解出語法元素然后按 CTUCoding Tree Unit為單位做四叉樹劃分逐個塊走幀內(nèi)預測或幀間預測、反變換、重建最后過一遍環(huán)路濾波去塊濾波 DBF 和樣點自適應補償 SAO把重建幀寫進參考幀緩沖區(qū)供后續(xù)幀做運動補償時讀取。2.1 五層流水架構從碼流到像素的硬件劃分整個工程按數(shù)據(jù)流方向分成五層每一層對應 RTL 目錄下的一個子模塊集合。第一層是nal_parser負責起始碼檢測、NAL header 解析和字節(jié)流到語法元素的位寬對齊第二層是cabac包含上下文模型初始化、bin 解碼狀態(tài)機和去量化后的語法元素分發(fā)第三層是ctu_tree負責 CTU 的四叉樹遞歸劃分和預測模式解析第四層是intra_pred、inter_pred、transform三個并行塊分別處理幀內(nèi)預測、運動補償和反 DCT/DST 變換第五層是loop_filter和dpb完成濾波并管理參考幀讀寫。這種分層的好處是每一級的接口都收斂在語法元素和像素塊上調(diào)試時可以單獨給某一級喂激勵。比如你只想驗證 CABAC 解碼是否正確就不需要把整個解碼器跑起來直接構造一個 slice 段的上下文初始化值觀察bin_out和參考軟件解碼器的輸出對比即可。實際工程里nal_parser和cabac之間還插了一個小的 FIFO用來吸收 NAL 層輸出的字節(jié)流速率波動避免 CABAC 模塊因為碼流暫時不足而進入不必要的 stall 狀態(tài)。2.2 目錄結構與模塊職責拿到源碼先看哪里打開源碼包主要的目錄結構大致是這樣h265_decoder/ ├── rtl/ │ ├── nal_parser/ │ │ ├── start_code_detect.v │ │ ├── nal_header.v │ │ └── emulation_prevention.v │ ├── cabac/ │ │ ├── cabac_engine.v │ │ ├── ctx_model_init.v │ │ └── cabac_bin_decode.v │ ├── ctu_tree/ │ │ ├── ctu_quadtree.v │ │ ├── split_flag_parser.v │ │ └── pred_mode_parser.v │ ├── intra_pred/ │ ├── inter_pred/ │ │ ├── motion_comp.v │ │ └── ref_fetch.v │ ├── transform/ │ │ ├── inverse_transform.v │ │ └── dequant.v │ ├── loop_filter/ │ │ ├── deblock.v │ │ └── sao.v │ └── dpb/ │ ├── ref_frame_mgr.v │ └── frame_buffer.v ├── sim/ │ ├── tb_top.v │ ├── stimulus/ │ ├── scripts/ │ │ ├── sim.do │ │ └── filelist.f │ └── ref_model/ ├── fpga/ │ ├── vivado/ │ └── constraints/ └── tools/ └── yuv_check/建議拿到代碼先看兩個文件sim/scripts/filelist.f和rtl/cabac/cabac_engine.v。前者告訴你整個工程的編譯順序后者是整個解碼器最容易卡住的地方。filelist.f里每一行的路徑順序不是隨意的——ctx_model_init.v必須在cabac_bin_decode.v之前編譯因為后者例化了前者的輸出作為上下文初始值ref_frame_mgr.v必須在motion_comp.v之前因為運動補償模塊調(diào)用參考幀管理器輸出的讀端口。如果你用 Vivado 的 add sources 自動導入而忽略了編譯順序跑到仿真階段大概率會報一堆Unknown module或者端口不匹配的錯誤。3. 核心模塊逐個拆解從 CABAC 到 SAO 的時序邏輯實現(xiàn)這一章是重點。我不會把全部代碼貼出來只挑四個最值得讀的核心模塊講清它們的端口含義和時序關系CABAC 熵解碼、CTU 四叉樹劃分、參考幀管理、環(huán)路濾波。這四個模塊分別對應了 HEVC 解碼器里最容易出問題、也最影響性能的四個環(huán)節(jié)。3.1 CABAC 熵解碼讓 bin 流變成語法元素的有限狀態(tài)機CABAC 在 FPGA 上實現(xiàn)時軟件里那種「while 循環(huán)讀位」的寫法完全不可綜合硬件必須把它拆成狀態(tài)機。模塊對外暴露的接口很簡潔上游解析出ctx_idx和bin_valid模塊內(nèi)部根據(jù)當前range和offset判斷下一個 bin 是 0 還是 1然后更新上下文狀態(tài)。下面是一段簡化的狀態(tài)機骨架// cabac_bin_decode.v 簡化版狀態(tài)機 module cabac_bin_decode ( input wire clk, input wire rst_n, input wire bin_valid, // 上層請求解碼一個 bin input wire [5:0] ctx_idx, // 上下文模型索引6bit 可覆蓋 64 狀態(tài) output reg bin_out, // 解碼出的 bin 值 output reg bin_ready // bin 解碼完成可接收下一個請求 ); localparam S_IDLE 2d0; localparam S_DECODE 2d1; localparam S_RENORMAL 2d2; reg [1:0] state, next_state; reg [8:0] range_q; // 當前區(qū)間的量化值HEVC 中始終保持在 [256, 510] reg [8:0] offset; // 當前碼流偏移值 reg [6:0] ctx_state; // 上下文狀態(tài)值共 64 個狀態(tài) // 狀態(tài)轉移每個 bin 至少占用 3 個時鐘周期 always (posedge clk or negedge rst_n) begin if (!rst_n) state S_IDLE; else state next_state; end always (*) begin next_state state; case (state) S_IDLE: if (bin_valid) next_state S_DECODE; S_DECODE: next_state S_RENORMAL; S_RENORMAL: next_state S_IDLE; default: next_state S_IDLE; endcase end // range 更新與判決核心公式 LUT 化 // 實際代碼中range_q 會根據(jù) ctx_state 查 64x2 的表 // 然后與 offset 比較offset range_q * prob 時 bin1 always (posedge clk or negedge rst_n) begin if (!rst_n) begin bin_out 1b0; bin_ready 1b0; end else begin bin_ready (state S_RENORMAL); case (state) S_DECODE: begin // 比較 offset 與 range 的量化乘積決定 bin 值 if (offset range_q) bin_out 1b1; else bin_out 1b0; end endcase end end endmodule這段代碼只保留了狀態(tài)機框架真正的決策邏輯在S_DECODE狀態(tài)里。range_q是當前編碼區(qū)間的高 9 位量化值HEVC 標準規(guī)定它始終不小于 256offset是碼流中已經(jīng)讀入的偏移量。判決原理是如果offset大于等于range_q * 上下文概率則 bin 為 1否則為 0。工程里常用查表代替乘法把ctx_state和range_q拼成地址輸出是該狀態(tài)下的兩個子區(qū)間邊界。ctx_idx這個參數(shù)很關鍵它決定了上下文模型的選擇。HEVC 里有幾百個上下文模型覆蓋不同類型語法元素ctx_model_init.v就是根據(jù) SPS/PPS 和 slice 類型生成這些初始值的。你在修改這個模塊時最常做的事就是調(diào)整上下文查表的位寬或初始值——如果你發(fā)現(xiàn)解碼出的split_flag總是錯先查ctx_idx是否映射到了正確的上下文模型區(qū)間。3.2 CTU 四叉樹劃分用狀態(tài)機代替遞歸的塊遍歷HEVC 的 CTU 最大是 64x64可遞歸劃分到 8x8每一層都有一個split_flag決定是否繼續(xù)分。軟件里用遞歸函數(shù)很容易寫但 Verilog 不能遞歸調(diào)用模塊所以工程里用了一個「深度計數(shù)器 待處理塊隊列」的思路// ctu_quadtree.v 四叉樹遍歷狀態(tài)機簡化 module ctu_quadtree ( input wire clk, input wire rst_n, input wire [5:0] ctu_x, ctu_y, // CTU 坐標0~63 input wire start, input wire split_flag_in, // 當前層的 split_flag output reg [5:0] block_x, block_y, // 當前正在處理的子塊坐標 output reg [1:0] cur_depth, // 當前劃分深度 output reg ctu_done ); reg [5:0] block_stack [0:15]; // 待處理的子塊棧 reg [3:0] stack_ptr; reg [1:0] depth_stack [0:15]; always (posedge clk or negedge rst_n) begin if (!rst_n) begin stack_ptr 4d0; ctu_done 1b0; end else if (start) begin block_stack[0] {ctu_x, ctu_y}; depth_stack[0] 2d0; stack_ptr 4d1; ctu_done 1b0; end else if (stack_ptr ! 4d0 split_flag_in) begin // 有 split_flag 且深度未到 3則把四個子塊壓棧 if (cur_depth 3) begin block_stack[stack_ptr] {block_x, block_y}; block_stack[stack_ptr1] {block_x, block_y 32d16}; // ... 實際按當前深度計算子塊偏移 stack_ptr stack_ptr 4d3; end end else if (stack_ptr ! 4d0) begin // 無 split_flag處理完當前塊后出棧 stack_ptr stack_ptr - 4d1; {block_x, block_y} block_stack[stack_ptr - 4d1]; cur_depth depth_stack[stack_ptr - 4d1]; if (stack_ptr 4d1) ctu_done 1b1; end end endmodule這段代碼的要點在于棧頂?shù)膕plit_flag決定當前塊是否繼續(xù)劃分而cur_depth限制了最大遞歸深度為 364x64 到 8x8 正好三次二分。實際工程里不僅需要split_flag還要解析pred_mode幀內(nèi)/幀間和part_mode對稱/非對稱劃分這些都掛在同一個狀態(tài)機上只是把待解析的信息一起壓棧。為什么不用遞歸語法因為綜合工具無法把遞歸展開成電路而顯式?？梢?。你在二次開發(fā)時如果想支持更大的 CTU比如 128x128下一代標準的方向只需要把MAX_DEPTH加 1、把坐標位寬從 6bit 擴到 7bit棧深度從 16 增到 32其他邏輯幾乎不用動。這也是這個模塊設計得比較干凈的地方。3.3 參考幀管理乒乓緩沖與 DPB 讀寫的地址映射參考幀管理是 HEVC 解碼器里最繞的部分不是算法難而是地址映射搞錯會導致花屏且極難排查。工程里采用經(jīng)典的乒乓緩沖策略兩塊幀緩存當前幀寫一塊參考幀從另一塊讀// 雙緩沖切換核心邏輯 wire [3:0] ref_read_idx ref_buf_sel ? BUF_B_ID : BUF_A_ID; wire [3:0] cur_write_idx ref_buf_sel ? BUF_A_ID : BUF_B_ID; // 運動補償讀取參考像素按塊坐標計算幀內(nèi)偏移 // 以 16x16 塊為例 wire [15:0] ref_base_addr ref_read_idx * FRAME_SIZE (mv_y ref_origin_y) * STRIDE (mv_x ref_origin_x);ref_buf_sel是乒乓切換標志每一幀解碼完成后翻轉一次。mv_x和mv_y是運動矢量ref_origin是當前塊在幀內(nèi)的起點坐標。實際工程里還得多加一層映射HEVC 的參考幀列表不只有一幀ref_idx可能指向 DPB 里的任意一幀所以更完整的實現(xiàn)是維護一個ref_frame_table把ref_idx映射到具體的物理 buffer ID再檢查該幀是否已經(jīng)重建完成——這一步不合法的話運動補償模塊會提前讀到未寫完的數(shù)據(jù)畫面會出現(xiàn)類似「拖影」的偽影。3.4 環(huán)路濾波去塊濾波的邊界強度和 SAO 補償去塊濾波器的核心是計算邊界強度Boundary StrengthBSBS 值決定了濾波器的開關和強度。判定規(guī)則在軟件里是串行 if-else在硬件里通常做成查表// 邊界強度計算簡化 always (*) begin if (is_intra_p is_intra_q) bs 4d4; // 兩側都是幀內(nèi)編碼塊最強濾波 else if (non_zero_coeff_p || non_zero_coeff_q) bs 4d2; // 有非零系數(shù)中等濾波 else if (ref_frame_p ! ref_frame_q) bs 4d2; // 參考幀不同需要濾波 else if (abs_dx_p abs_dx_q 1) bs 4d1; // 運動矢量差很小弱濾波 else bs 4d0; // 不濾波 end這段邏輯每周期輸出一個邊界強度值決定后續(xù)濾波運算是否執(zhí)行。SAO 的部分相對獨立它屬于像素域濾波先統(tǒng)計當前 CTU 的像素分類邊界補償或帶補償再把補償值累加到重建像素上。工程里 SAO 通?？梢院腿K濾波共用一個像素讀口分時復用避免多讀一次 DDR 帶寬。4. 仿真與運行實戰(zhàn)Modelsim 拉起 tb 并驗證 YUV 輸出的完整流程源碼包不帶現(xiàn)成的比特流文件但工程里有測試激勵生成腳本和標準的sim.do文件。跑仿真的第一步不是直接雙擊打開 Modelsim而是先把文件清單理清楚。4.1 第一步核對 filelist 編譯順序并完成仿真打開sim/scripts/filelist.f后你會看到全部 RTL 文件按依賴順序排列。如果文件清單沒有預先整理好仿真編譯時最常遇到的錯誤就是instance u_cabac of design unit cabac_engine not found這是因為被例化的模塊還沒編譯。正確做法是讓底層模塊先編譯頂層模塊放最后。在 Modelsim 里的執(zhí)行流程如下# 進入仿真目錄 cd sim/scripts # 創(chuàng)建 work 庫 vlib work vlib work_lib # 按依賴順序編譯全部源碼 vlog -f filelist.f -work work_lib -incr # 編譯測試平臺 vlog ../tb_top.v -work work # 啟動仿真單位用 ps 避免時間精度丟失 vsim -t ps work.tb_top -do log -r /*; run -all-t ps這個參數(shù)值得注意。HEVC 解碼器的時鐘周期通常在 10ns 級別但邏輯內(nèi)部有亞周期時序比如 FIFO 的讀寫窗口只有幾納秒。如果時間精度設置到ns波形窗口里可能看不到競爭窗口的細節(jié)。如果仿真跑起來后進度條長時間不動先看看是不是陷入了死循環(huán)——CABAC 模塊對碼流不足的響應是否正確。跑完后仿真目錄下會生成decoded.yuv輸出文件。這個文件是最直接的驗證依據(jù)如果解碼正確它應該和參考軟件解碼器輸出的 YUV 逐字節(jié)一致如果解碼失敗通常表現(xiàn)為全黑、雪花或者只解出第一幀。4.2 第二步用 YUV 對比腳本量化驗證解碼正確性光靠肉眼判斷花不花屏還不夠我一般會寫一個 Python 腳本做 PSNR 對比把輸出 YUV 和參考 YUV 逐幀比較# yuv_compare.py import sys import numpy as np def read_yuv(path, w, h, frames): data np.fromfile(path, dtypenp.uint8) frame_size w * h * 3 // 2 # YUV420 格式每像素 1.5 字節(jié) return data[:frame_size * frames].reshape( frames, frame_size ) def psnr(actual, expected, max_val255): mse np.mean((actual.astype(np.float32) - expected.astype(np.float32)) ** 2) if mse 0: return float(inf) return 10 * np.log10(max_val * max_val / mse) if __name__ __main__: w, h, frames int(sys.argv[1]), int(sys.argv[2]), int(sys.argv[3]) ours read_yuv(decoded.yuv, w, h, frames) ref read_yuv(reference.yuv, w, h, frames) for i in range(frames): p psnr(ours[i], ref[i]) print(fframe {i}: PSNR {p:.2f} dB)如果某幀的 PSNR 低于 30dB那基本可以斷定該幀前面的某個環(huán)節(jié)出了問題再結合波形窗口里ctu_done信號在哪一幀拉高異常來定位。幀數(shù)參數(shù)frames需要和仿真時的tb_top里配置一致否則np.fromfile會讀到錯誤邊界。4.3 第三步查看關鍵波形信號定位第一處異常仿真最有效的調(diào)試手段不是看完整波形而是只看幾個關鍵信號nal_start、slice_state、cabac_ready、ctu_done、frame_done。如果frame_done始終拉不高往前查ctu_done是否有周期性拉高如果ctu_done有但frame_done沒有問題大概率在參考幀管理模塊——當前幀被標記為「可參考」之前DPB 的寫入還沒有完成產(chǎn)生了握手阻塞。add wave的時候建議按分組添加把同一子模塊的信號放一個 group 里折疊后按幀推進節(jié)奏看整體數(shù)據(jù)流而不是逐個信號盯。血淚經(jīng)驗HEVC 解碼的波形動輒幾百萬周期逐一翻信號絕對會看花眼分組之后按幀索引定位異常要快得多。5. 避坑記錄仿真卡死、波形全 X 與綜合時序翻車下面幾條都是這個項目上容易被絆倒的典型坑按「現(xiàn)象 → 原因 → 解決」的順序記錄部分來自我自己的調(diào)試經(jīng)歷部分來自同行在這個系統(tǒng)上的踩坑共性?，F(xiàn)象一仿真開始后總在一個固定周期數(shù)處停住Modelsim 提示# ** Error: (vsim-8045)且 progress 不再前進。原因CABAC 模塊在碼流輸入不足時進入了不可恢復的 stall 狀態(tài)。range在重歸一化時需要從碼流讀取新的比特但如果read_side握手信號沒有和重歸一化狀態(tài)機對齊相當于狀態(tài)機停在S_RENORMAL等待一個永遠不會來的data_valid。解決在S_RENORMAL進入S_IDLE的條件上加一個超時計數(shù)器若超過 64 個周期仍未收到新數(shù)據(jù)則主動拉高stall_error便于在波形窗口直接看到錯誤標志。更根本的方式是檢查 NAL parser 到 CABAC 之間的 FIFO 深度把 FIFO 深度從 8 提高到 32通常能掩蓋輸入速率的抖動。現(xiàn)象二仿真結束但decoded.yuv是全 0波形窗口里幾乎所有信號都是 X 態(tài)。原因多數(shù)情況下不是邏輯錯誤而是測試激勵里$readmemh加載的碼流文件路徑不對。Modelsim 啟動時的工作目錄是sim/scripts如果碼流文件的相對路徑寫的是../stimulus/stream.h265但腳本是從別的目錄啟動的文件加載失敗后mem里全是 X后續(xù)所有邏輯都崩了。解決在tb_top.v里用絕對路徑或通過defineSTIM_PATH宏傳入路徑加載后立刻檢查$readmemh的返回值并打印加載字節(jié)數(shù)?，F(xiàn)象三行為仿真完全正確但綜合到 FPGA 后時序收斂不了主時鐘頻率只能跑到標稱值的 60%。原因CABAC 的上下文查表邏輯被綜合成了一個巨大的組合邏輯路徑尤其是ctx_idx到range_q的選擇樹層級過深導致關鍵路徑延遲過長。解決把查表的輸出打一拍寄存器從「組合邏輯直接決定 bin」改成「流水線決定 bin」——代價是每個 bin 多一拍延遲但換來了頻率的大幅提升。這個改動對架構影響極小具體做法是在S_DECODE和S_RENORMAL之間插入一個中間寄存器把range_q和offset的比較結果鎖存一拍?，F(xiàn)象四解碼輸出 PSNR 始終在 20dB 上下畫面看起來像是「模糊但有輪廓」。原因和熵解碼無關通常是反變換模塊的量化參數(shù)QP與當前 slice 的slice_qp_delta沒有正確累加。HEVC 里每個 CTU 可以有自己的 QP 偏移如果qp更新狀態(tài)機在 CTU 邊界處漏更新了一個周期后面的所有變換系數(shù)都會放大或縮小一個比例。解決在dequant.v里增加一個斷言比較當前 CTU 的qp與參考軟件輸出是否有超過 2 的偏差。這類問題最好在仿真階段解決進了硬件再抓會非常痛苦。6. 二次開發(fā)建議把 CABAC 改造成可配置上下文模型的思路如果你想把這個解碼器用在自己的項目里改造的切入點和優(yōu)先級建議這樣排第一優(yōu)先是替換上下文模型初始化方式第二優(yōu)先是增加流水線級數(shù)第三才是動預測和變換模塊。CABAC 的上下文模型是整個解碼器的「黑匣子」改起來收益最大也最容易驗證。最常見的改造是把ctx_model_init.v里的初始化常數(shù)做成可配置的 ROM而不是硬編碼的case分支。具體做法是把 SPS/PPS 里解析出的initial_qp和 slice 類型作為 ROM 地址高位把ctx_idx作為低位用一塊小的block memory存儲不同配置下的上下文初始值。這樣換一條不同編碼參數(shù)的碼流時不需要重新綜合工程只要把 ROM 的初始化文件替換一下即可。注意 HEVC 的上下文模型初始化和 QP 強相關不同的初始 QP 會生成完全不同的初始概率狀態(tài)默認的硬編碼方案換碼流后出現(xiàn)花屏八成就是這里的問題。第二個值得做的改造是給運動補償路徑加 AXI 接口。原始代碼的ref_fetch.v用的是簡單的同步讀端口掛在自己的 SRAM 上沒問題但如果你的系統(tǒng)里參考幀存在 DDR 里這個模塊就要改成 AXI master 發(fā)送讀請求并處理亂序返回。改造時不要把motion_comp的像素拼接邏輯動掉只需要在ref_fetch內(nèi)部換掉讀端口協(xié)議外部接口保持不變。實測 DDR 帶寬足夠時1080p 分辨率的解碼幀率能穩(wěn)住。驗證方法建議固化成一個回歸腳本每次改完 RTL跑三條標準測試流——一條低分辨率快速驗證、一條高分辨率壓測時序、一條特意用亂序參考幀的碼流檢驗 DPB 管理。從那以后我每次改熵解碼或濾波的代碼都強制先跑完這三條流再合入不再等到上板了才對著花屏畫面撓頭。希望這套思路能幫你少踩幾個這個項目里的坑跑通之后再做自己的裁剪就順了。本文還有配套的精品資源點擊獲取 用Verilog在FPGA上實現(xiàn)HEVC解碼器：核心模塊與仿真指南
簡介這是一份基于 Verilog 的 H.265/HEVC 解碼器 FPGA 工程源碼面向 Zynq7035 平臺構建適用于 FPGA 開發(fā)者、視頻編解碼研究人員及有硬件基礎的嵌入式學習者。項目在 Zynq7035 上完成驗證實現(xiàn)熵解碼、語法解析、運動補償、去塊效應濾波、逆變換和圖像重構等核心流程可作為 HEVC 硬件解碼器設計參照。壓縮包共 146 個文件約 4.62MB其中以 33 個 .v 和 19 個 .sv 源碼文件為主另含 9 個 sample 測試示例、4 個 .265 碼流文件以及工程配置、Makefile 和輔助腳本方便進行仿真、綜合與上板調(diào)試。目前已有 298 人瀏覽學習。通過這套資源可以獲得完整模塊級 Verilog 源碼、測試序列和 Zynq 工程結構結合配套文章能快速掌握 H.265 解碼的硬件實現(xiàn)方法、模塊劃分與軟硬件協(xié)同設計技巧。1. FPGA 上讀 HEVC 碼流這個 Verilog 解碼器到底能做什么如果你以為在 FPGA 上解 H.265 就是把.h265文件丟給仿真器、等波形出來就完事那第一次跑這個h265_decoder項目時大概率會翻車——跑了幾萬個周期波形窗口里一片 XYUV 輸出全是花屏。這套基于 Verilog 的 HEVC 解碼器源碼本質(zhì)是把 H.265 從「NAL 層解析」到「SAO 重建」的完整鏈路搬進了硬件描述語言面向的是想在自己的 FPGA 板卡上實現(xiàn)視頻硬解、或者想搞懂 CABAC 和 CTU 劃分到底怎么走時序的開發(fā)者。它適合兩類人一類是拿它當學習藍本對照協(xié)議看熵解碼和幀間預測的硬件實現(xiàn)另一類是直接拿它做二次開發(fā)裁剪模塊、換分辨率、掛到自己的圖像處理流水線上。這篇文章會從模塊骨架、核心代碼、仿真運行到踩坑點全部拆開講。2. 整體設計與技術骨架NAL 解析、CTU 流水與參考幀管理的分層這個解碼器的頂層設計不算復雜但分層很清晰。拿到一段 H.265 裸流硬件上要干的事和軟件解碼器是同一套邏輯先做 NAL 單元解析把 SPS、PPS、SEI、Slice 數(shù)據(jù)分開再進熵解碼層用 CABAC 解出語法元素然后按 CTUCoding Tree Unit為單位做四叉樹劃分逐個塊走幀內(nèi)預測或幀間預測、反變換、重建最后過一遍環(huán)路濾波去塊濾波 DBF 和樣點自適應補償 SAO把重建幀寫進參考幀緩沖區(qū)供后續(xù)幀做運動補償時讀取。2.1 五層流水架構從碼流到像素的硬件劃分整個工程按數(shù)據(jù)流方向分成五層每一層對應 RTL 目錄下的一個子模塊集合。第一層是nal_parser負責起始碼檢測、NAL header 解析和字節(jié)流到語法元素的位寬對齊第二層是cabac包含上下文模型初始化、bin 解碼狀態(tài)機和去量化后的語法元素分發(fā)第三層是ctu_tree負責 CTU 的四叉樹遞歸劃分和預測模式解析第四層是intra_pred、inter_pred、transform三個并行塊分別處理幀內(nèi)預測、運動補償和反 DCT/DST 變換第五層是loop_filter和dpb完成濾波并管理參考幀讀寫。這種分層的好處是每一級的接口都收斂在語法元素和像素塊上調(diào)試時可以單獨給某一級喂激勵。比如你只想驗證 CABAC 解碼是否正確就不需要把整個解碼器跑起來直接構造一個 slice 段的上下文初始化值觀察bin_out和參考軟件解碼器的輸出對比即可。實際工程里nal_parser和cabac之間還插了一個小的 FIFO用來吸收 NAL 層輸出的字節(jié)流速率波動避免 CABAC 模塊因為碼流暫時不足而進入不必要的 stall 狀態(tài)。2.2 目錄結構與模塊職責拿到源碼先看哪里打開源碼包主要的目錄結構大致是這樣h265_decoder/ ├── rtl/ │ ├── nal_parser/ │ │ ├── start_code_detect.v │ │ ├── nal_header.v │ │ └── emulation_prevention.v │ ├── cabac/ │ │ ├── cabac_engine.v │ │ ├── ctx_model_init.v │ │ └── cabac_bin_decode.v │ ├── ctu_tree/ │ │ ├── ctu_quadtree.v │ │ ├── split_flag_parser.v │ │ └── pred_mode_parser.v │ ├── intra_pred/ │ ├── inter_pred/ │ │ ├── motion_comp.v │ │ └── ref_fetch.v │ ├── transform/ │ │ ├── inverse_transform.v │ │ └── dequant.v │ ├── loop_filter/ │ │ ├── deblock.v │ │ └── sao.v │ └── dpb/ │ ├── ref_frame_mgr.v │ └── frame_buffer.v ├── sim/ │ ├── tb_top.v │ ├── stimulus/ │ ├── scripts/ │ │ ├── sim.do │ │ └── filelist.f │ └── ref_model/ ├── fpga/ │ ├── vivado/ │ └── constraints/ └── tools/ └── yuv_check/建議拿到代碼先看兩個文件sim/scripts/filelist.f和rtl/cabac/cabac_engine.v。前者告訴你整個工程的編譯順序后者是整個解碼器最容易卡住的地方。filelist.f里每一行的路徑順序不是隨意的——ctx_model_init.v必須在cabac_bin_decode.v之前編譯因為后者例化了前者的輸出作為上下文初始值ref_frame_mgr.v必須在motion_comp.v之前因為運動補償模塊調(diào)用參考幀管理器輸出的讀端口。如果你用 Vivado 的 add sources 自動導入而忽略了編譯順序跑到仿真階段大概率會報一堆Unknown module或者端口不匹配的錯誤。3. 核心模塊逐個拆解從 CABAC 到 SAO 的時序邏輯實現(xiàn)這一章是重點。我不會把全部代碼貼出來只挑四個最值得讀的核心模塊講清它們的端口含義和時序關系CABAC 熵解碼、CTU 四叉樹劃分、參考幀管理、環(huán)路濾波。這四個模塊分別對應了 HEVC 解碼器里最容易出問題、也最影響性能的四個環(huán)節(jié)。3.1 CABAC 熵解碼讓 bin 流變成語法元素的有限狀態(tài)機CABAC 在 FPGA 上實現(xiàn)時軟件里那種「while 循環(huán)讀位」的寫法完全不可綜合硬件必須把它拆成狀態(tài)機。模塊對外暴露的接口很簡潔上游解析出ctx_idx和bin_valid模塊內(nèi)部根據(jù)當前range和offset判斷下一個 bin 是 0 還是 1然后更新上下文狀態(tài)。下面是一段簡化的狀態(tài)機骨架// cabac_bin_decode.v 簡化版狀態(tài)機 module cabac_bin_decode ( input wire clk, input wire rst_n, input wire bin_valid, // 上層請求解碼一個 bin input wire [5:0] ctx_idx, // 上下文模型索引6bit 可覆蓋 64 狀態(tài) output reg bin_out, // 解碼出的 bin 值 output reg bin_ready // bin 解碼完成可接收下一個請求 ); localparam S_IDLE 2d0; localparam S_DECODE 2d1; localparam S_RENORMAL 2d2; reg [1:0] state, next_state; reg [8:0] range_q; // 當前區(qū)間的量化值HEVC 中始終保持在 [256, 510] reg [8:0] offset; // 當前碼流偏移值 reg [6:0] ctx_state; // 上下文狀態(tài)值共 64 個狀態(tài) // 狀態(tài)轉移每個 bin 至少占用 3 個時鐘周期 always (posedge clk or negedge rst_n) begin if (!rst_n) state S_IDLE; else state next_state; end always (*) begin next_state state; case (state) S_IDLE: if (bin_valid) next_state S_DECODE; S_DECODE: next_state S_RENORMAL; S_RENORMAL: next_state S_IDLE; default: next_state S_IDLE; endcase end // range 更新與判決核心公式 LUT 化 // 實際代碼中range_q 會根據(jù) ctx_state 查 64x2 的表 // 然后與 offset 比較offset range_q * prob 時 bin1 always (posedge clk or negedge rst_n) begin if (!rst_n) begin bin_out 1b0; bin_ready 1b0; end else begin bin_ready (state S_RENORMAL); case (state) S_DECODE: begin // 比較 offset 與 range 的量化乘積決定 bin 值 if (offset range_q) bin_out 1b1; else bin_out 1b0; end endcase end end endmodule這段代碼只保留了狀態(tài)機框架真正的決策邏輯在S_DECODE狀態(tài)里。range_q是當前編碼區(qū)間的高 9 位量化值HEVC 標準規(guī)定它始終不小于 256offset是碼流中已經(jīng)讀入的偏移量。判決原理是如果offset大于等于range_q * 上下文概率則 bin 為 1否則為 0。工程里常用查表代替乘法把ctx_state和range_q拼成地址輸出是該狀態(tài)下的兩個子區(qū)間邊界。ctx_idx這個參數(shù)很關鍵它決定了上下文模型的選擇。HEVC 里有幾百個上下文模型覆蓋不同類型語法元素ctx_model_init.v就是根據(jù) SPS/PPS 和 slice 類型生成這些初始值的。你在修改這個模塊時最常做的事就是調(diào)整上下文查表的位寬或初始值——如果你發(fā)現(xiàn)解碼出的split_flag總是錯先查ctx_idx是否映射到了正確的上下文模型區(qū)間。3.2 CTU 四叉樹劃分用狀態(tài)機代替遞歸的塊遍歷HEVC 的 CTU 最大是 64x64可遞歸劃分到 8x8每一層都有一個split_flag決定是否繼續(xù)分。軟件里用遞歸函數(shù)很容易寫但 Verilog 不能遞歸調(diào)用模塊所以工程里用了一個「深度計數(shù)器 待處理塊隊列」的思路// ctu_quadtree.v 四叉樹遍歷狀態(tài)機簡化 module ctu_quadtree ( input wire clk, input wire rst_n, input wire [5:0] ctu_x, ctu_y, // CTU 坐標0~63 input wire start, input wire split_flag_in, // 當前層的 split_flag output reg [5:0] block_x, block_y, // 當前正在處理的子塊坐標 output reg [1:0] cur_depth, // 當前劃分深度 output reg ctu_done ); reg [5:0] block_stack [0:15]; // 待處理的子塊棧 reg [3:0] stack_ptr; reg [1:0] depth_stack [0:15]; always (posedge clk or negedge rst_n) begin if (!rst_n) begin stack_ptr 4d0; ctu_done 1b0; end else if (start) begin block_stack[0] {ctu_x, ctu_y}; depth_stack[0] 2d0; stack_ptr 4d1; ctu_done 1b0; end else if (stack_ptr ! 4d0 split_flag_in) begin // 有 split_flag 且深度未到 3則把四個子塊壓棧 if (cur_depth 3) begin block_stack[stack_ptr] {block_x, block_y}; block_stack[stack_ptr1] {block_x, block_y 32d16}; // ... 實際按當前深度計算子塊偏移 stack_ptr stack_ptr 4d3; end end else if (stack_ptr ! 4d0) begin // 無 split_flag處理完當前塊后出棧 stack_ptr stack_ptr - 4d1; {block_x, block_y} block_stack[stack_ptr - 4d1]; cur_depth depth_stack[stack_ptr - 4d1]; if (stack_ptr 4d1) ctu_done 1b1; end end endmodule這段代碼的要點在于棧頂?shù)膕plit_flag決定當前塊是否繼續(xù)劃分而cur_depth限制了最大遞歸深度為 364x64 到 8x8 正好三次二分。實際工程里不僅需要split_flag還要解析pred_mode幀內(nèi)/幀間和part_mode對稱/非對稱劃分這些都掛在同一個狀態(tài)機上只是把待解析的信息一起壓棧。為什么不用遞歸語法因為綜合工具無法把遞歸展開成電路而顯式?？梢?。你在二次開發(fā)時如果想支持更大的 CTU比如 128x128下一代標準的方向只需要把MAX_DEPTH加 1、把坐標位寬從 6bit 擴到 7bit棧深度從 16 增到 32其他邏輯幾乎不用動。這也是這個模塊設計得比較干凈的地方。3.3 參考幀管理乒乓緩沖與 DPB 讀寫的地址映射參考幀管理是 HEVC 解碼器里最繞的部分不是算法難而是地址映射搞錯會導致花屏且極難排查。工程里采用經(jīng)典的乒乓緩沖策略兩塊幀緩存當前幀寫一塊參考幀從另一塊讀// 雙緩沖切換核心邏輯 wire [3:0] ref_read_idx ref_buf_sel ? BUF_B_ID : BUF_A_ID; wire [3:0] cur_write_idx ref_buf_sel ? BUF_A_ID : BUF_B_ID; // 運動補償讀取參考像素按塊坐標計算幀內(nèi)偏移 // 以 16x16 塊為例 wire [15:0] ref_base_addr ref_read_idx * FRAME_SIZE (mv_y ref_origin_y) * STRIDE (mv_x ref_origin_x);ref_buf_sel是乒乓切換標志每一幀解碼完成后翻轉一次。mv_x和mv_y是運動矢量ref_origin是當前塊在幀內(nèi)的起點坐標。實際工程里還得多加一層映射HEVC 的參考幀列表不只有一幀ref_idx可能指向 DPB 里的任意一幀所以更完整的實現(xiàn)是維護一個ref_frame_table把ref_idx映射到具體的物理 buffer ID再檢查該幀是否已經(jīng)重建完成——這一步不合法的話運動補償模塊會提前讀到未寫完的數(shù)據(jù)畫面會出現(xiàn)類似「拖影」的偽影。3.4 環(huán)路濾波去塊濾波的邊界強度和 SAO 補償去塊濾波器的核心是計算邊界強度Boundary StrengthBSBS 值決定了濾波器的開關和強度。判定規(guī)則在軟件里是串行 if-else在硬件里通常做成查表// 邊界強度計算簡化 always (*) begin if (is_intra_p is_intra_q) bs 4d4; // 兩側都是幀內(nèi)編碼塊最強濾波 else if (non_zero_coeff_p || non_zero_coeff_q) bs 4d2; // 有非零系數(shù)中等濾波 else if (ref_frame_p ! ref_frame_q) bs 4d2; // 參考幀不同需要濾波 else if (abs_dx_p abs_dx_q 1) bs 4d1; // 運動矢量差很小弱濾波 else bs 4d0; // 不濾波 end這段邏輯每周期輸出一個邊界強度值決定后續(xù)濾波運算是否執(zhí)行。SAO 的部分相對獨立它屬于像素域濾波先統(tǒng)計當前 CTU 的像素分類邊界補償或帶補償再把補償值累加到重建像素上。工程里 SAO 通?？梢院腿K濾波共用一個像素讀口分時復用避免多讀一次 DDR 帶寬。4. 仿真與運行實戰(zhàn)Modelsim 拉起 tb 并驗證 YUV 輸出的完整流程源碼包不帶現(xiàn)成的比特流文件但工程里有測試激勵生成腳本和標準的sim.do文件。跑仿真的第一步不是直接雙擊打開 Modelsim而是先把文件清單理清楚。4.1 第一步核對 filelist 編譯順序并完成仿真打開sim/scripts/filelist.f后你會看到全部 RTL 文件按依賴順序排列。如果文件清單沒有預先整理好仿真編譯時最常遇到的錯誤就是instance u_cabac of design unit cabac_engine not found這是因為被例化的模塊還沒編譯。正確做法是讓底層模塊先編譯頂層模塊放最后。在 Modelsim 里的執(zhí)行流程如下# 進入仿真目錄 cd sim/scripts # 創(chuàng)建 work 庫 vlib work vlib work_lib # 按依賴順序編譯全部源碼 vlog -f filelist.f -work work_lib -incr # 編譯測試平臺 vlog ../tb_top.v -work work # 啟動仿真單位用 ps 避免時間精度丟失 vsim -t ps work.tb_top -do log -r /*; run -all-t ps這個參數(shù)值得注意。HEVC 解碼器的時鐘周期通常在 10ns 級別但邏輯內(nèi)部有亞周期時序比如 FIFO 的讀寫窗口只有幾納秒。如果時間精度設置到ns波形窗口里可能看不到競爭窗口的細節(jié)。如果仿真跑起來后進度條長時間不動先看看是不是陷入了死循環(huán)——CABAC 模塊對碼流不足的響應是否正確。跑完后仿真目錄下會生成decoded.yuv輸出文件。這個文件是最直接的驗證依據(jù)如果解碼正確它應該和參考軟件解碼器輸出的 YUV 逐字節(jié)一致如果解碼失敗通常表現(xiàn)為全黑、雪花或者只解出第一幀。4.2 第二步用 YUV 對比腳本量化驗證解碼正確性光靠肉眼判斷花不花屏還不夠我一般會寫一個 Python 腳本做 PSNR 對比把輸出 YUV 和參考 YUV 逐幀比較# yuv_compare.py import sys import numpy as np def read_yuv(path, w, h, frames): data np.fromfile(path, dtypenp.uint8) frame_size w * h * 3 // 2 # YUV420 格式每像素 1.5 字節(jié) return data[:frame_size * frames].reshape( frames, frame_size ) def psnr(actual, expected, max_val255): mse np.mean((actual.astype(np.float32) - expected.astype(np.float32)) ** 2) if mse 0: return float(inf) return 10 * np.log10(max_val * max_val / mse) if __name__ __main__: w, h, frames int(sys.argv[1]), int(sys.argv[2]), int(sys.argv[3]) ours read_yuv(decoded.yuv, w, h, frames) ref read_yuv(reference.yuv, w, h, frames) for i in range(frames): p psnr(ours[i], ref[i]) print(fframe {i}: PSNR {p:.2f} dB)如果某幀的 PSNR 低于 30dB那基本可以斷定該幀前面的某個環(huán)節(jié)出了問題再結合波形窗口里ctu_done信號在哪一幀拉高異常來定位。幀數(shù)參數(shù)frames需要和仿真時的tb_top里配置一致否則np.fromfile會讀到錯誤邊界。4.3 第三步查看關鍵波形信號定位第一處異常仿真最有效的調(diào)試手段不是看完整波形而是只看幾個關鍵信號nal_start、slice_state、cabac_ready、ctu_done、frame_done。如果frame_done始終拉不高往前查ctu_done是否有周期性拉高如果ctu_done有但frame_done沒有問題大概率在參考幀管理模塊——當前幀被標記為「可參考」之前DPB 的寫入還沒有完成產(chǎn)生了握手阻塞。add wave的時候建議按分組添加把同一子模塊的信號放一個 group 里折疊后按幀推進節(jié)奏看整體數(shù)據(jù)流而不是逐個信號盯。血淚經(jīng)驗HEVC 解碼的波形動輒幾百萬周期逐一翻信號絕對會看花眼分組之后按幀索引定位異常要快得多。5. 避坑記錄仿真卡死、波形全 X 與綜合時序翻車下面幾條都是這個項目上容易被絆倒的典型坑按「現(xiàn)象 → 原因 → 解決」的順序記錄部分來自我自己的調(diào)試經(jīng)歷部分來自同行在這個系統(tǒng)上的踩坑共性?，F(xiàn)象一仿真開始后總在一個固定周期數(shù)處停住Modelsim 提示# ** Error: (vsim-8045)且 progress 不再前進。原因CABAC 模塊在碼流輸入不足時進入了不可恢復的 stall 狀態(tài)。range在重歸一化時需要從碼流讀取新的比特但如果read_side握手信號沒有和重歸一化狀態(tài)機對齊相當于狀態(tài)機停在S_RENORMAL等待一個永遠不會來的data_valid。解決在S_RENORMAL進入S_IDLE的條件上加一個超時計數(shù)器若超過 64 個周期仍未收到新數(shù)據(jù)則主動拉高stall_error便于在波形窗口直接看到錯誤標志。更根本的方式是檢查 NAL parser 到 CABAC 之間的 FIFO 深度把 FIFO 深度從 8 提高到 32通常能掩蓋輸入速率的抖動。現(xiàn)象二仿真結束但decoded.yuv是全 0波形窗口里幾乎所有信號都是 X 態(tài)。原因多數(shù)情況下不是邏輯錯誤而是測試激勵里$readmemh加載的碼流文件路徑不對。Modelsim 啟動時的工作目錄是sim/scripts如果碼流文件的相對路徑寫的是../stimulus/stream.h265但腳本是從別的目錄啟動的文件加載失敗后mem里全是 X后續(xù)所有邏輯都崩了。解決在tb_top.v里用絕對路徑或通過defineSTIM_PATH宏傳入路徑加載后立刻檢查$readmemh的返回值并打印加載字節(jié)數(shù)?，F(xiàn)象三行為仿真完全正確但綜合到 FPGA 后時序收斂不了主時鐘頻率只能跑到標稱值的 60%。原因CABAC 的上下文查表邏輯被綜合成了一個巨大的組合邏輯路徑尤其是ctx_idx到range_q的選擇樹層級過深導致關鍵路徑延遲過長。解決把查表的輸出打一拍寄存器從「組合邏輯直接決定 bin」改成「流水線決定 bin」——代價是每個 bin 多一拍延遲但換來了頻率的大幅提升。這個改動對架構影響極小具體做法是在S_DECODE和S_RENORMAL之間插入一個中間寄存器把range_q和offset的比較結果鎖存一拍?，F(xiàn)象四解碼輸出 PSNR 始終在 20dB 上下畫面看起來像是「模糊但有輪廓」。原因和熵解碼無關通常是反變換模塊的量化參數(shù)QP與當前 slice 的slice_qp_delta沒有正確累加。HEVC 里每個 CTU 可以有自己的 QP 偏移如果qp更新狀態(tài)機在 CTU 邊界處漏更新了一個周期后面的所有變換系數(shù)都會放大或縮小一個比例。解決在dequant.v里增加一個斷言比較當前 CTU 的qp與參考軟件輸出是否有超過 2 的偏差。這類問題最好在仿真階段解決進了硬件再抓會非常痛苦。6. 二次開發(fā)建議把 CABAC 改造成可配置上下文模型的思路如果你想把這個解碼器用在自己的項目里改造的切入點和優(yōu)先級建議這樣排第一優(yōu)先是替換上下文模型初始化方式第二優(yōu)先是增加流水線級數(shù)第三才是動預測和變換模塊。CABAC 的上下文模型是整個解碼器的「黑匣子」改起來收益最大也最容易驗證。最常見的改造是把ctx_model_init.v里的初始化常數(shù)做成可配置的 ROM而不是硬編碼的case分支。具體做法是把 SPS/PPS 里解析出的initial_qp和 slice 類型作為 ROM 地址高位把ctx_idx作為低位用一塊小的block memory存儲不同配置下的上下文初始值。這樣換一條不同編碼參數(shù)的碼流時不需要重新綜合工程只要把 ROM 的初始化文件替換一下即可。注意 HEVC 的上下文模型初始化和 QP 強相關不同的初始 QP 會生成完全不同的初始概率狀態(tài)默認的硬編碼方案換碼流后出現(xiàn)花屏八成就是這里的問題。第二個值得做的改造是給運動補償路徑加 AXI 接口。原始代碼的ref_fetch.v用的是簡單的同步讀端口掛在自己的 SRAM 上沒問題但如果你的系統(tǒng)里參考幀存在 DDR 里這個模塊就要改成 AXI master 發(fā)送讀請求并處理亂序返回。改造時不要把motion_comp的像素拼接邏輯動掉只需要在ref_fetch內(nèi)部換掉讀端口協(xié)議外部接口保持不變。實測 DDR 帶寬足夠時1080p 分辨率的解碼幀率能穩(wěn)住。驗證方法建議固化成一個回歸腳本每次改完 RTL跑三條標準測試流——一條低分辨率快速驗證、一條高分辨率壓測時序、一條特意用亂序參考幀的碼流檢驗 DPB 管理。從那以后我每次改熵解碼或濾波的代碼都強制先跑完這三條流再合入不再等到上板了才對著花屏畫面撓頭。希望這套思路能幫你少踩幾個這個項目里的坑跑通之后再做自己的裁剪就順了。本文還有配套的精品資源點擊獲取