摘 要：作為SoC設計的三大關鍵支撐技術之一，軟硬件協同設計技術已經得到了越來越廣泛的應用。針對H.264解碼芯片的設計,本文提出了一種軟硬件協同設計、仿真以及驗證的系統模型。設計實踐證明，軟硬件協同設計有效地提高了設計效率，加快了開發進度。
關鍵詞：軟硬件協同設計；H.264；SoC

引言
H.264/AVC標準是由ISO/IEC的運動圖像專家組(MPEG)和ITU-T的視頻編碼專家組(VCEG)共同制訂的新一代圖像壓縮標準，它具有一系列優于MPEG4和H.263的新特性，在相同的重建圖像質量下，能比H.263節約50%左右的碼率。但是，在獲得優越性能的同時，H.264的計算復雜度卻大大增加。據估計，其編碼的計算復雜度大約相當于H.263的3倍，解碼復雜度大約相當于H.263的2倍。在這種情況下，如果用純軟件的方式進行實時解碼就會顯得力不從心，因此需要由軟件結合硬件加速器來完成實時的編解碼任務。本文提出了一種基于軟硬件協同設計技術的H.264解碼芯片的SoC設計方案。

軟硬件協同設計理論

SoC設計主要有3個關鍵的支撐技術：
1. 軟硬件協同設計技術：它主要是面向不同目標系統的軟件和硬件的功能劃分理論和設計空間搜索技術。
2. IP模塊復用技術。IP是指那些集成度較高并具有完整功能的單元模塊，如MPU、DSP、DRAM、Flash等模塊。IP模塊的再利用除了可以縮短芯片的設計時間外，還能大大降低設計和制造的成本，提高可靠性。
3. 模塊以及模塊界面間的綜合分析和驗證技術。綜合分析和驗證是難點，要為硬件和軟件的協同描述、驗證和綜合提供一個自動化的集成開發環境。

圖1 軟硬件協同設計的基本流程

其中軟硬件協同設計技術往往成為影響開發周期以及系統性能的關鍵因素。軟硬件協同設計的基本流程如圖1所示。設計初期需要對設計進行系統級建模。在經過分析后對軟硬件進行適當的劃分，于是系統設計分為軟件設計和硬件設計兩條路線。為了保證軟硬件設計的協同，在設計的各個時期還要對軟硬件接口進行設計。當軟硬件設計完成后，就可將設計中軟件和硬件部分加以集成以完成最后的設計。如果此時的設計不能完全滿足設計目標，還需要將整個架構進行重新劃分，進行迭代直到設計滿足要求。

圖2 H.264解碼功能模塊劃分

系統軟硬件劃分
采用軟硬件協同設計，在系統模型建立以后，就要對系統的軟硬件進行劃分。一部分工作需要交給嵌入式處理器用軟件來完成，而剩余的部分則要用硬件來實現。在劃分時，要考慮目標體系結構、軟硬件實現所占用的成本等各種因素。劃分完后，產生軟硬件分割界面，供軟硬件仿真、驗證和測試使用。

H.264的解碼功能模塊如圖2所示，整個解碼的過程由碼流輸入單元、熵解碼單元、反量化及反離散余弦變換單元、幀內預測單元、幀間預測單元、去塊效應單元、內存控制單元、顯示輸出單元、圖像信息管理單元、解碼過程控制單元和內存等功能單元組成。

對高清碼流進行解碼時，解碼器的工作頻率一般為200MHz，此時對一個宏塊圖像的信息進行處理的時間平均只有900個時鐘，實時性要求很高，因此必須將軟件的工作量減小。設計中采用嵌入式處理器控制解碼過程能給系統設計帶來更大的靈活性，而圖像信息管理只涉及針對圖像級別的計算，在對一幀圖像進行解碼時只會計算一次，故將這兩部分任務交給嵌入式處理器完成。為了保證軟硬件負荷的平衡，還將碼流輸入和熵解碼任務交給嵌入式處理器處理。圖2中灰色的模塊則需要用專門的硬件加速模塊來完成。

圖3 H.264解碼器軟硬件協同設計的軟件仿真模型

系統的軟硬件協同設計

H.264解碼器軟硬件協同設計的仿真平臺

當系統設計的軟硬件劃分完成后，設計就分成軟件設計和硬件設計兩條路線，為了保證在軟、硬件設計過程中能夠隨時進行聯合仿真，本文建立了如圖3所示的仿真模型。由圖中的硬件設計部分可知，嵌入式處理器將通過片內高速總線對掛在總線上的各個硬件加速器進行控制。為了使得軟硬件劃分的界面更加清晰，嵌入式處理器解碼時產生的數據通過連接在片內高速總線上的動態存儲控制器存入DRAM中，而后各個硬件加速器通過片內高速總線將各自需要的數據從動態存儲器中讀出，進行相應的解碼。考慮到片內高速總線的負擔比較重，設計中將總線位寬設定為64bit，以提高數據傳輸的速度。

為了保持軟件與硬件設計的協同性，在進行硬件加速模塊設計的同時，軟件設計也需要作相應的改動。如圖3所示，在已經劃分好的由嵌入式處理器完成的軟件模型和將由硬件實現的軟件模型之間，加入數據打包和數據解包單元。數據打包單元是為了生成軟件仿真所需要的輸入向量，數據解包單元用于將打包后的數據還原，作為將由硬件實現的軟件模型的輸入，以便模型能夠生成硬件設計部分進行軟仿真所需要的參照向量。

在軟件仿真時期，軟件與硬件的接口主要通過數據打包單元完成。各個硬件加速器解碼所需的數據是從動態存儲器獲取的，而這些數據是由嵌入式處理器通過片內高速總線事先存入動態存儲器中的。于是在數據打包單元的幫助下，軟件模型就可以用打包單元模擬DRAM輸出數據，而后硬件設計中就可以將這些數據加載到自己的軟件仿真測試平臺中，供其軟件仿真使用。為了驗證硬件設計的正確性，在硬件設計中還加入了測試單元。測試單元將硬件解碼的數據暫存到其內部緩存中，測試平臺中的解碼數據檢測單元就可以通過片內總線將解碼后的數據讀回，與軟件模型生成的參照向量進行比較。于是，通過軟件仿真便可以初步驗證硬件設計的正確性。考慮到在硬件與軟件協同仿真完成后，要通過PC對設計進行加速驗證，本文在硬件設計中加入了PCI總線到片內高速總線橋接器。

H.264解碼器軟硬件協同設計的加速驗證環節
由于解碼器設計的規模比較大，硬件設計進行軟件仿真的速度比較慢，而且在前期設計中軟件和硬件都是通過生成的輸入向量和參照向量的方式進行耦合的。為了加快仿真的速度，并為嵌入式處理器和硬件加速器的集成做進一步的準備，設計中將圖3所示的仿真模型演變成了圖4所示的模型。

在設計完成并通過軟件仿真后，硬件設計被綜合成網表文件下載到FPGA中。系統通過PCI 總線到片內總線橋接器與PC相連，PC模擬嵌入式處理器的軟件工作，并通過PCI總線將控制信號以及解碼數據送到FPGA內部的片內高速總線上，由硬件模塊完成最終的解碼任務。

為了驗證設計的正確性，PC可以通過PCI總線將硬件解碼后的數據從測試單元讀出，與圖3模型中生成的參照向量進行比較，驗證解碼的正確性。由于在FPGA中硬件仿真的速度遠高于軟件仿真，因此使驗證的速度得以加快。

圖4 H.264解碼器軟硬件協同設計的加速驗證模型

H.264解碼器軟硬件協同設計的系統集成
通過如圖4所示的驗證環節后，設計的正確性以及軟硬件設計的協同性得到了進一步的驗證。為了方便軟、硬件的集成，本文將圖4中的設計模型進一步進行了修改。圖5所示的設計模型為H.264解碼器軟硬件集成后的最終系統評估和設計驗證模型。可見，在經過PC模擬嵌入式處理器行為與硬件聯合進行硬件仿真后，嵌入式處理器通過片內高速總線與硬件系統進行了連接，最終完成了軟硬件的集成。

圖5 H.264解碼器的最終系統評估和設計驗證模型

此時系統仍使用PCI接口對碼流進行輸入，并將解碼后的數據從測試單元讀入PC，與圖3模型中生成的參照向量進行比較，對最終設計的正確性進行驗證。當驗證完成后測試單元將被移除。

當然此時的設計不一定能完全滿足設計要求，如果沒有完全達到設計的要求，那么整個設計將從軟硬件劃分步驟重新進行，一次次進行迭代直到滿足最終的要求。

結語
由于采用了軟硬件協同設計技術，整個SoC系統的軟件設計和硬件設計能夠方便地進行聯合仿真以及測試。在整個設計過程中，軟件設計和硬件設計能夠很好地協同，當軟件或硬件的一方需要改動的時候，另一方能夠及時地進行相應的改動。同時軟件設計還能在設計的各個階段為硬件設計提供必要的驗證數據，使得軟件與硬件設計能夠進行快速有效的集成，從而減小了系統在開發過程中的風險，提高了系統設計的正確性，加快了開發的速度。
　　
參考文獻：
1 Joint Video Team (JVT) of ISO/IEC MPEG ITU-T VCEG. Proposed Draft Errata List with Revision-Marked Corrections for H.264/AVC[M], 2003.12.
2 畢厚杰. 新一代視頻壓縮編碼標準―H.264/AVC[M]. 北京：人民郵電出版社，2005.5.
3 (美)Rochit Raj Suman. System On Chip：Design and Test. 于敦山,盛世敏,田澤譯. 北京：北京航空航天大學出版社，2003
4 郭鵬飛. SoC設計中的軟硬件協同設計. 中國電子站，2005.02.11