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

引言

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

　　OR1200以及其他諸多的與之配套的IP核由Opencores組織負責開(kāi)發(fā)和維護，功能強大，軟硬件開(kāi)發(fā)工具齊全，采用免費和開(kāi)源的授權策略，可以自由地獲取源代碼，而且大多都經(jīng)過(guò)了ASIC驗證，已經(jīng)受到學(xué)術(shù)界和工業(yè)界越來(lái)越多的關(guān)注。

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

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

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

③ 在所構建的SoC驗證平臺上移植了μC/OSII系統以及μC/TCPIP協(xié)議棧，使H.264視頻編碼系統生成的數據流輸出到通用處理器終端，作進(jìn)一步的驗證。

1　相關(guān)技術(shù)簡(jiǎn)介

1.1　OR1200微處理器以及Wishbone總線(xiàn)

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

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

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

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

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

1.3　TRDBD5M圖像采集模塊

　　TRDBD5M圖像采集模塊中的采用Micron公司生產(chǎn)的CMOS傳感器MT9P031。它具有以下特性：低功耗，逐行掃描圖像傳感器；最高支持到2 592×1944@12fps；12位A/D轉換器；支持攝像模式（viewfinder）和快照模式（snapshot）；曝光時(shí)間可調；雙線(xiàn)串行接口（I2C總線(xiàn)接口）等。

圖1　SoC驗證平臺整體結構

2　SoC驗證平臺的總體框架

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

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

　　在其他的外設模塊中，UARTBOOT模塊只帶有一個(gè)Wishbone主端口，用于控制CPU的啟動(dòng)和程序下載，它不需要分配地址。其他模塊的地址空間分配情況如表1所列。
表1　SoC系統的地址空間分配


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

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

3　多端口SDRAM控制器

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

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

3.1　讀寫(xiě)端口和讀寫(xiě)仲裁器

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

　　在讀寫(xiě)仲裁器（ReadWrite Arbiter）中處理來(lái)自讀端口的讀請求和來(lái)自寫(xiě)端口的寫(xiě)請求。寫(xiě)請求的優(yōu)先級高于讀請求的優(yōu)先級。寫(xiě)端口由寫(xiě)緩存器(WE_FIFO)和寫(xiě)地址生成器(WE_Addr Generator)組成。WE_FIFO的深度為512字（每個(gè)字32位，存一個(gè)像素），當圖像采集模塊在WE_FIFO中寫(xiě)夠256個(gè)字之后，就會(huì )發(fā)起一次寫(xiě)請求。寫(xiě)地址生成器每完成一次寫(xiě)請求之后便會(huì )增加256，地址增加的順序與CMOS圖像傳感器的掃描順序相同。

　　讀端口由讀緩存器（RD_FIFO）、讀地址生成器（RD_Addr Generator）、讀狀態(tài)機（RD_FSM）和行計數器（Line_Cnt）組成。RD_FIFO的深度為256字，載入宏塊地址（addr_load）的命令發(fā)出后，RD_FSM就進(jìn)入了工作狀態(tài)（read_stat信號為1）。同時(shí)，讀地址生成器已經(jīng)根據宏塊的水平位置（mb_num_h）和垂直位置（mb_num_v）計算出了宏塊所在SDRAM中的基地址。當RD_FSM處于工作狀態(tài)時(shí)，讀請求一直有效，如果此時(shí)寫(xiě)請求無(wú)效，就會(huì )發(fā)起一次長(cháng)度為16的突發(fā)讀傳輸，從SDRAM中讀取16個(gè)像素數據到RD_FIFO。當完成一次讀傳輸之后，讀地址生成器會(huì )自動(dòng)加一行的長(cháng)度（可配置，此處為800），也就是指向當前宏塊下一行的基地址處。與此同時(shí)，ReadWrite Arbiter模塊會(huì )檢測寫(xiě)請求是否有效，如果有效則優(yōu)先發(fā)起長(cháng)度為256的突發(fā)寫(xiě)傳輸，等寫(xiě)傳輸完成后再完成下一次長(cháng)度為16的突發(fā)讀傳輸。如此，當完成16次突發(fā)讀傳輸后，所讀宏塊的數據也就完全寫(xiě)入到RD_FIFO中了，此時(shí)，RD_FSM由工作狀態(tài)轉為閑置狀態(tài)，等待下一次的宏塊讀請求。

　　當RD_FIFO中的數據數量（rd_usedw）不為零時(shí)，H264編碼器即可從RD_FIFO中讀取數據。當讀完256個(gè)數據，即一個(gè)宏塊的數據后，rd_usedw的值變?yōu)榱?，一個(gè)宏塊數據也便讀完了。

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

　　SDRAM命令生成器（Command Generator）主要作用是根據SDRAM的控制時(shí)序生成SDRAM接口處的控制命令，這些命令是有可能發(fā)生沖突的。命令仲裁器（Command Arbiter）的作用就是對命令生成器產(chǎn)生的命令進(jìn)行仲裁。

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

　　命令生成器還會(huì )根據ReadWrite Arbiter傳過(guò)來(lái)的讀寫(xiě)請求產(chǎn)生讀寫(xiě)（read/write）命令。讀寫(xiě)（read/write）命令的優(yōu)先級是最低的，當SDRAM控制器處于初始化過(guò)程，或者正在執行刷新命令時(shí)，命令仲裁器就會(huì )讓讀寫(xiě)請求一直等待更高優(yōu)先級的命令執行完畢。此外，由于SDRAM是工作在fullpage模式，需要根據寫(xiě)或讀的突發(fā)長(cháng)度產(chǎn)生突發(fā)終止命令。突發(fā)終止命令根據讀計數器（write timer）和寫(xiě)計數器（read timer）的值產(chǎn)生，它的優(yōu)先級低于刷新（refresh）命令，卻高于讀寫(xiě)（read/write）命令。

4　SoC平臺的軟件支持

　　參照參考文獻[1]，設計了DM9000A的控制端口，并在所設計的SoC平臺上移植了μC/OSII實(shí)時(shí)操作系統和μC/TCPIP協(xié)議棧。這是為了方便把H.264編碼器所生成的比特流數據傳送到PC機端作進(jìn)一步驗證。

5　實(shí)驗結果

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

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

　　此外，對整個(gè)SoC系統選用Altera公司的Cyclone II系列FPGA EP2C70F896C6進(jìn)行了綜合，并在臺灣友晶科技公司的DE270開(kāi)發(fā)板上實(shí)現。整個(gè)平臺的所占用資源為：邏輯單元10 662個(gè)，寄存器4 689個(gè)，存儲器418 104位。

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

結語(yǔ)

　　本文基于OR1200微處理器設計了一種面向H.264視頻編碼器的SoC驗證平臺，在集成了常用的各類(lèi)IP核的基礎上，重點(diǎn)對與H.264編碼器特性相關(guān)的多端口SDRAM控制器進(jìn)行了設計。經(jīng)過(guò)RTL級以及FPGA驗證，所設計的平臺可以滿(mǎn)足H.264編碼器軟硬件協(xié)同驗證的各種要求，可大大縮短H.264編碼器的開(kāi)發(fā)時(shí)間。