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