一種面向H.264視頻編碼器的SoC驗證平臺※

任懷魯，張德學

（山東科技大學 嵌入式系統與集成電路實驗室，青島 266510）

引 言

H.264編碼算法復雜，其硬件實現包含眾多模塊。H.264編碼器往往采用軟硬件協同設計：在宏塊級及以下，運算量巨大，用軟件往往無法實現實時編碼，適用于用硬件實現；而在宏塊級以上，是一些圖像信息打包的工作，運算量小，且隨視頻序列的不同而不同，為了保證編碼器的通用性和靈活性往往用軟件實現。軟硬件協同設計技術是SoC的主要技術之一，但同時它也使SoC芯片的規模和SoC設計的復雜度大大提高。在這種情況下，仿真和驗證就成為了影響項目進度的瓶頸，往往占整個芯片開發周期50%～80%的時間。為了縮短SoC驗證時間，基于FPGA的原型驗證（包括硬件原型和軟件原型）已經成為SoC設計流程前期階段的常用手段。

OR1200以及其他諸多的與之配套的IP核由Opencores組織負責開發和維護，功能強大，軟硬件開發工具齊全，采用免費和開源的授權策略，可以自由地獲取源代碼，而且大多都經過了ASIC驗證，已經受到學術界和工業界越來越多的關注。

為了搭建適用于H.264視頻編碼器的SoC驗證平臺，本文主要做了以下幾項工作：

①采用OR1200微處理器作為SoC系統的控制核心，通過Wishbone總線互聯規范將Opencores組織發布維護的相關IP核集成在目標SoC系統上，構成了最初的SoC驗證平臺。

②采用臺灣友晶科技公司發布的500萬像素圖像視頻采集模塊，為H.264視頻編碼系統提供原始視頻數據，并根據H.264標準的要求，在視頻采集模塊中加入了RGB到YUV顏色空間轉換模塊，以及逐行輸入／任意宏塊順序輸出的多端口SDRAM控制器（簡稱為“多端口SDRAM控制器”）模塊。

③在所構建的SoC驗證平臺上移植了μC／OS－II系統以及μC／TCP－IP協議棧，使H.264視頻編碼系統生成的數據流輸出到通用處理器終端，作進一步的驗證。

1 相關技術簡介

1.1 OR1200微處理器以及Wishbone總線

OR1200是一種32位、標量、哈佛結構、5級整數流水線的RISC處理器，支持Cache、MMU和基本的DSP功能。在300MHz時，可以提供300DMIPS和300M次32位×32位的DSP乘加操作的能力。OR1200定位于嵌入式、移動和網絡應用環境。

Wishbone總線規范是一種片上系統IP核互連體系結構。它定義了一種IP核之間公共的邏輯接口，減輕了系統組件集成的難度，提高了系統組件的可重用性、可靠性和可移植性。Opencores組織經過ASIC或FPGA驗證的開源IP核大多都支持Wishbone總線協議。

1.2 H.264／AVC視頻編碼標準

H.264／AVC標準是迄今最新的一套視頻編碼標準，它與以往的 MPEG2標準相比，碼流節省了50%以上。H.264標準中所用的編碼技術主要有：幀內預測、運動估計、整形變換和環路濾波等。

H.264標準以宏塊（16×16大小的像素塊）為單位進行編碼。所以它的數據輸入是以宏塊為單位的像素塊，輸出是經過了預測編碼、變換編碼以及量化和熵編碼之后的比特流數據。

1.3 TRDB－D5M圖像采集模塊

TRDB－D5M圖像采集模塊中的采用Micron公司生產的CMOS傳感器MT9P031。它具有以下特性：低功耗，逐行掃描圖像傳感器；最高支持到2 592×1 944＠12fps；12位A／D轉換器；支持攝像模式（viewfinder）和快照模式（snapshot）；曝光時間可調；雙線串行接口（I2C總線接口）等。

2 SoC驗證平臺的總體框架

如圖1所示，SoC驗證平臺主要包括OR1200處理器、片上RAM 控制器、SSRAM控制器、Flash控制器、UART－BOOT模塊（用于啟動）、UART－16550模塊（用于顯示信息）、GPIO模塊、DM9000A控制器、圖像采集模塊、雙端口SDRAM控制器和VGA控制器。

圖1 SoC驗證平臺整體結構

OR1200微處理器是整個驗證平臺的控制核心，根據系統的需求和節約的原則，裁去了OR1200中的指令緩存器（IC）、數據緩存器（DC）和存儲器管理單元（IMMU和DMMU）。SoC平臺中另一個重要的模塊就是片上存儲器（Onchip－Memory）。片上存儲器數據訪問能力強，功耗低，但是容量有限，只能實現代碼量比較小的特定功能（如硬件初始化、CPU啟動引導等）。當完成這些操作后處理器就會跳轉到主存儲器SSRAM的地址空間執行代碼。

在其他的外設模塊中，UART－BOOT模塊只帶有一個Wishbone主端口，用于控制CPU的啟動和程序下載，它不需要分配地址。其他模塊的地址空間分配情況如表1所列。

表1 SoC系統的地址空間分配

在圖1所示的IP核中，除了以下幾個模塊外均可從Opencores網站上免費獲得：UART－BOOT模塊是為了在驗證過程中更加方便地更新下載軟件代碼和對SoC平臺進行控制，需要自主設計；圖像采集模塊可參考友晶科技公司的參考設計，但是其采集到的數據為RGB格式，需要轉換為H.264編碼器所需要的YUV格式；此外，由于圖像采集模塊內部的MT9P031圖像傳感器是逐行掃描的，而 H.264編碼器是以宏塊順序進行編碼的，因此SDRAM的控制器需要重新進行設計，以滿足逐行寫入和按宏塊讀出的要求。

之前有很多人對構建基于嵌入式軟核的SoC系統作了研究，本文重點介紹與H.264編碼器驗證相關的自主設計的模塊上。

3 多端口SDRAM控制器

逐行輸入／任意宏塊順序輸出的多端口SDRAM控制器的整體結構如圖2所示。

3.1 讀寫端口和讀寫仲裁器

圖2中有一個讀端口和一個寫端口，分別用于H.264編碼器讀出數據和圖像采集模塊寫入數據。其實還有一個用于VGA顯示的讀端口，其時序與圖像采集模塊的寫時序相同，都是逐行掃描，在此處略去了。

圖2 逐行輸入／任意宏塊順序輸出的多端口SDRAM控制器結構

在讀＆寫仲裁器（Read＆Write Arbiter）中處理來自讀端口的讀請求和來自寫端口的寫請求。寫請求的優先級高于讀請求的優先級。寫端口由寫緩存器（WE＿FIFO）和寫地址生成器（WE＿Addr Generator）組成。WE＿FIFO的深度為512字（每個字32位，存一個像素），當圖像采集模塊在WE＿FIFO中寫夠256個字之后，就會發起一次寫請求。寫地址生成器每完成一次寫請求之后便會增加256，地址增加的順序與CMOS圖像傳感器的掃描順序相同。

讀端口由讀緩存器（RD＿FIFO）、讀地址生成器（RD＿Addr Generator）、讀狀態機（RD＿FSM）和行計數器（Line＿Cnt）組成。RD＿FIFO的深度為256字，載入宏塊地址（addr＿load）的命令發出后，RD＿FSM 就進入了工作狀態（read＿stat信號為1）。同時，讀地址生成器已經根據宏塊的水平位置（mb＿num＿h）和垂直位置（mb＿num＿v）計算出了宏塊所在SDRAM中的基地址。當RD＿FSM處于工作狀態時，讀請求一直有效，如果此時寫請求無效，就會發起一次長度為16的突發讀傳輸，從SDRAM中讀取16個像素數據到RD＿FIFO。當完成一次讀傳輸之后，讀地址生成器會自動加一行的長度（可配置，此處為800），也就是指向當前宏塊下一行的基地址處。與此同時，Read＆Write Arbiter模塊會檢測寫請求是否有效，如果有效則優先發起長度為256的突發寫傳輸，等寫傳輸完成后再完成下一次長度為16的突發讀傳輸。如此，當完成16次突發讀傳輸后，所讀宏塊的數據也就完全寫入到RD＿FIFO中了，此時，RD＿FSM由工作狀態轉為閑置狀態，等待下一次的宏塊讀請求。

當RD＿FIFO中的數據數量（rd＿usedw）不為零時，H.264編碼器即可從RD＿FIFO中讀取數據。當讀完256個數據，即一個宏塊的數據后，rd＿usedw的值變為零，一個宏塊數據也便讀完了。

3.2 SDRAM命令生成器和命令仲裁器

SDRAM命令生成器（Command Generator）主要作用是根據SDRAM的控制時序生成SDRAM接口處的控制命令，這些命令是有可能發生沖突的。命令仲裁器（Command Arbiter）的作用就是對命令生成器產生的命令進行仲裁。

SDRAM的初始化過程可分成初始化延遲、預充電、刷新、設置模式寄存器4個階段，這4個階段由一個初始化計數器（initial timer）控制。SDRAM命令生成器根據初始化計數器的值會產生初始化延遲（initial）命令、預充電（precharge）命令、刷新（refresh）命令和設置模式寄存器（load＿mode）命令。其中，刷新（refresh）命令也可以在SDRAM的工作過程中根據刷新計數器（refresh timer）的值產生。這是因為SDRAM的特性要求每64ms就要對SDRAM的所有行刷新一遍。由于此設計中SDRAM工作在自動預充電模式，所以說預充電命令也只會在初始化過程中出現。

命令生成器還會根據Read＆Write Arbiter傳過來的讀寫請求產生讀寫（read／write）命令。讀寫（read／write）命令的優先級是最低的，當SDRAM控制器處于初始化過程，或者正在執行刷新命令時，命令仲裁器就會讓讀寫請求一直等待更高優先級的命令執行完畢。此外，由于SDRAM是工作在full－page模式，需要根據寫或讀的突發長度產生突發終止命令。突發終止命令根據讀計數器（write timer）和寫計數器（read timer）的值產生，它的優先級低于刷新（refresh）命令，卻高于讀寫（read／write）命令。

4 SoC平臺的軟件支持

參照參考文獻［1］，設計了DM9000A的控制端口，并在所設計的SoC平臺上移植了μC／OS－II實時操作系統和μC／TCP－IP協議棧。這是為了方便把H.264編碼器所生成的比特流數據傳送到PC機端作進一步驗證。

5 實驗結果

設計了一個H.264編碼器模型，它主要實現的功能就是模擬H.264編碼器與SDRAM控制器接口處的讀時序，從SDRAM中讀取數據。同時，它也帶有一個 Wishbone從接口，可以把讀取的數據傳送給OR1200微處理器，OR1200微處理器再經過網口把圖像數據傳送到PC機，以驗證所讀取的數據是否正確。利用Wishbone總線功能模型（BFM）在ModelSim SE 6.5f環境下對所設計的模塊進行了RTL級的仿真，驗證方案框架圖如圖3所示。

圖3 多端口SDRAM控制器驗證方案

此外，對整個SoC系統選用Altera公司的Cyclone II系列FPGA EP2C70F896C6進行了綜合，并在臺灣友晶科技公司的DE2－70開發板上實現。整個平臺的所占用資源為：邏輯單元10 662個，寄存器4 689個，存儲器418 104位。

將圖像采集模塊的時鐘設為25MHz，SDRAM控制器的時鐘設置為100MHz，其他各個模塊均運行在50 MHz。前述方法把從SDRAM控制器中以宏塊為順序采集到的YUV圖像數據通過網口傳輸到PC機，在PC機端YUV圖像數據轉換成正常的圖像順序，把Y分量以灰度位圖的格式顯示，并與VGA顯示器中所顯示的圖像（RGB通道都輸入變換后的Y分量）進行對比。

結 語

本文基于OR1200微處理器設計了一種面向H.264視頻編碼器的SoC驗證平臺，在集成了常用的各類IP核的基礎上，重點對與 H.264編碼器特性相關的多端口SDRAM控制器進行了設計。經過RTL級以及FPGA驗證，所設計的平臺可以滿足H.264編碼器軟硬件協同驗證的各種要求，可大大縮短H.264編碼器的開發時間。

編者注：本文為期刊縮略版，全文見本刊網站www.mesnet.com.cn。

［1］Lin Zuo.System－on－Chip design with Open Cores［OL］.［2011－08］.http：／／www.olivercamel.com／post／master＿thesis.html.

［2］OR1200OpenRISC Processor［OL］.［2011－08］.http：／／opencores.org／or1k／OR1200 ＿OpenRISC＿Processor.

［3］Micron.5－Megapixel，1／2.5－Inch CMOS Image Sensor for Wide FOV and Electronic Pan／Tilt Cameras［OL］.［2011－08］.http：／／download.micron. com／pdf／flyers／MT9P031%－20Flyer.pdf.

［4］張力航，林濤.軟硬件協同設計技術在 H.264解碼器設計中的應用［J］.電子技術應用，2006（9）.

［5］虞致國，魏敬和.基于FPGA的ARM SoC原型驗證平臺設計［J］.電子與封裝，2007（5）.

［6］Busa N，Alkadi G.A modular，multi－board，heterogeneous multi－processor，PCI bus based prototyping framework for the validation of SoC VLSI designs［C］／／13th IEEE International Workshop onRapid System Prototyping，2002：159－165.

［7］桑圣峰，張德學.AEMB軟核處理器的SoC系統驗證平臺［J］.單片機與嵌入式系統應用，2007（5）.

［8］徐敏，孫愷.開源軟核處理器OpenRisc的SOPC設計［M］.北京：北京航空航天大學出版社，2008.

［9］孫愷，王田苗.嵌入式CPU軟核綜述［J］.計算機工程，2006（7）.

［10］Pei Ke，Zhang Gang.Design of Boot Loader with Multiple Communication Port［C］∥Computer Science and Software Engineering，12－14Dec.2008：169－175.

［11］Gyounghwan Hyun，Yongseok Jin.A Synchronous DRAM Controller for an H.264／AVC Encoder［C］∥SoC Design Conference，24－25Nov.2008.

［12］Zhang Yu，Ling Ming.Performance Exploration and Optimization of SDRAM－Controller Architecture on SDRAM Access［C］∥ASICON 2005，Oct.2005：203－207.

［13］Szymanski T，Kielbik R.SDRAM controller for real time digital image processing systems［C］∥CAD Systems in Microelectronics，2001：72－75.