一種面向H.264視頻編碼器的SoC驗證平臺
引言
H.264編碼算法復雜,其硬件實現(xiàn)包含眾多模塊。H.264編碼器往往采用軟硬件協(xié)同設計:在宏塊級及以下,運算量巨大,用軟件往往無法實現(xiàn)實時編碼,適用于用硬件實現(xiàn);而在宏塊級以上,是一些圖像信息打包的工作,運算量小,且隨視頻序列的不同而不同,為了保證編碼器的通用性和靈活性往往用軟件實現(xiàn)。軟硬件協(xié)同設計技術是SoC的主要技術之一,但同時它也使SoC芯片的規(guī)模和SoC設計的復雜度大大提高。在這種情況下,仿真和驗證就成為了影響項目進度的瓶頸,往往占整個芯片開發(fā)周期50%~80%的時間。為了縮短SoC驗證時間,基于FPGA的原型驗證(包括硬件原型和軟件原型)已經(jīng)成為SoC設計流程前期階段的常用手段。
OR1200以及其他諸多的與之配套的IP核由Opencores組織負責開發(fā)和維護,功能強大,軟硬件開發(fā)工具齊全,采用免費和開源的授權策略,可以自由地獲取源代碼,而且大多都經(jīng)過了ASIC驗證,已經(jīng)受到學術界和工業(yè)界越來越多的關注。
為了搭建適用于H.264視頻編碼器的SoC驗證平臺,本文主要做了以下幾項工作:
① 采用OR1200微處理器作為SoC系統(tǒng)的控制核心,通過Wishbone總線互聯(lián)規(guī)范將Opencores組織發(fā)布維護的相關IP核集成在目標SoC系統(tǒng)上,構成了最初的SoC驗證平臺。
② 采用臺灣友晶科技公司發(fā)布的500萬像素圖像視頻采集模塊,為H.264視頻編碼系統(tǒng)提供原始視頻數(shù)據(jù),并根據(jù)H.264標準的要求,在視頻采集模塊中加入了RGB到YUV顏色空間轉(zhuǎn)換模塊,以及逐行輸入/任意宏塊順序輸出的多端口SDRAM控制器(簡稱為“多端口SDRAM控制器”)模塊。
③ 在所構建的SoC驗證平臺上移植了μC/OSII系統(tǒng)以及μC/TCPIP協(xié)議棧,使H.264視頻編碼系統(tǒng)生成的數(shù)據(jù)流輸出到通用處理器終端,作進一步的驗證。
1 相關技術簡介
1.1 OR1200微處理器以及Wishbone總線
OR1200是一種32位、標量、哈佛結構、5級整數(shù)流水線的RISC處理器,支持Cache、MMU和基本的DSP功能。在300 MHz時,可以提供300 DMIPS和300M次32位×32位的DSP乘加操作的能力。OR1200定位于嵌入式、移動和網(wǎng)絡應用環(huán)境。
Wishbone總線規(guī)范是一種片上系統(tǒng)IP核互連體系結構。它定義了一種IP核之間公共的邏輯接口,減輕了系統(tǒng)組件集成的難度,提高了系統(tǒng)組件的可重用性、可靠性和可移植性。
Opencores組織經(jīng)過ASIC或FPGA驗證的開源IP核大多都支持Wishbone總線協(xié)議。
1.2 H.264/AVC視頻編碼標準
H.264/AVC標準是迄今最新的一套視頻編碼標準,它與以往的MPEG2標準相比,碼流節(jié)省了50%以上。H.264標準中所用的編碼技術主要有:幀內(nèi)預測、運動估計、整形變換和環(huán)路濾波等。
H.264標準以宏塊(16×16大小的像素塊)為單位進行編碼。所以它的數(shù)據(jù)輸入是以宏塊為單位的像素塊,輸出是經(jīng)過了預測編碼、變換編碼以及量化和熵編碼之后的比特流數(shù)據(jù)。
1.3 TRDBD5M圖像采集模塊
TRDBD5M圖像采集模塊中的采用Micron公司生產(chǎn)的CMOS傳感器MT9P031。它具有以下特性:低功耗,逐行掃描圖像傳感器;最高支持到2 592×1944@12fps;12位A/D轉(zhuǎn)換器;支持攝像模式(viewfinder)和快照模式(snapshot);曝光時間可調(diào);雙線串行接口(I2C總線接口)等。
圖1 SoC驗證平臺整體結構
2 SoC驗證平臺的總體框架
如圖1所示,SoC驗證平臺主要包括OR1200處理器、片上RAM控制器、SSRAM控制器、Flash控制器、UARTBOOT模塊(用于啟動)、UART16550模塊(用于顯示信息)、GPIO模塊、DM9000A控制器、圖像采集模塊、雙端口SDRAM控制器和VGA控制器。
OR1200微處理器是整個驗證平臺的控制核心,根據(jù)系統(tǒng)的需求和節(jié)約的原則,裁去了OR1200中的指令緩存器(IC)、數(shù)據(jù)緩存器(DC)和存儲器管理單元(IMMU和DMMU)。SoC平臺中另一個重要的模塊就是片上存儲器(OnchipMemory)。片上存儲器數(shù)據(jù)訪問能力強,功耗低,但是容量有限,只能實現(xiàn)代碼量比較小的特定功能(如硬件初始化、CPU啟動引導等)。當完成這些操作后處理器就會跳轉(zhuǎn)到主存儲器SSRAM的地址空間執(zhí)行代碼。
在其他的外設模塊中,UARTBOOT模塊只帶有一個Wishbone主端口,用于控制CPU的啟動和程序下載,它不需要分配地址。其他模塊的地址空間分配情況如表1所列。
表1 SoC系統(tǒng)的地址空間分配
在圖1所示的IP核中,除了以下幾個模塊外均可從Opencores網(wǎng)站上免費獲得: UARTBOOT模塊是為了在驗證過程中更加方便地更新下載軟件代碼和對SoC平臺進行控制,需要自主設計;圖像采集模塊可參考友晶科技公司的參考設計,但是其采集到的數(shù)據(jù)為RGB格式,需要轉(zhuǎn)換為H.264編碼器所需要的YUV格式;此外,由于圖像采集模塊內(nèi)部的MT9P031圖像傳感器是逐行掃描的,而H.264編碼器是以宏塊順序進行編碼的,因此SDRAM的控制器需要重新進行設計,以滿足逐行寫入和按宏塊讀出的要求。
之前有很多人對構建基于嵌入式軟核的SoC系統(tǒng)作了研究,本文重點介紹與H.264編碼器驗證相關的自主設計的模塊上。
3 多端口SDRAM控制器
逐行輸入/任意宏塊順序輸出的多端口SDRAM控制器的整體結構如圖2所示。
圖2 逐行輸入/任意宏塊順序輸出的多端口SDRAM控制器結構
3.1 讀寫端口和讀寫仲裁器
圖2中有一個讀端口和一個寫端口,分別用于H.264編碼器讀出數(shù)據(jù)和圖像采集模塊寫入數(shù)據(jù)。其實還有一個用于VGA顯示的讀端口,其時序與圖像采集模塊的寫時序相同,都是逐行掃描,在此處略去了。
在讀寫仲裁器(ReadWrite Arbiter)中處理來自讀端口的讀請求和來自寫端口的寫請求。寫請求的優(yōu)先級高于讀請求的優(yōu)先級。寫端口由寫緩存器(WE_FIFO)和寫地址生成器(WE_Addr Generator)組成。WE_FIFO的深度為512字(每個字32位,存一個像素),當圖像采集模塊在WE_FIFO中寫夠256個字之后,就會發(fā)起一次寫請求。寫地址生成器每完成一次寫請求之后便會增加256,地址增加的順序與CMOS圖像傳感器的掃描順序相同。
讀端口由讀緩存器(RD_FIFO)、讀地址生成器(RD_Addr Generator)、讀狀態(tài)機(RD_FSM)和行計數(shù)器(Line_Cnt)組成。RD_FIFO的深度為256字,載入宏塊地址(addr_load)的命令發(fā)出后,RD_FSM就進入了工作狀態(tài)(read_stat信號為1)。同時,讀地址生成器已經(jīng)根據(jù)宏塊的水平位置(mb_num_h)和垂直位置(mb_num_v)計算出了宏塊所在SDRAM中的基地址。當RD_FSM處于工作狀態(tài)時,讀請求一直有效,如果此時寫請求無效,就會發(fā)起一次長度為16的突發(fā)讀傳輸,從SDRAM中讀取16個像素數(shù)據(jù)到RD_FIFO。當完成一次讀傳輸之后,讀地址生成器會自動加一行的長度(可配置,此處為800),也就是指向當前宏塊下一行的基地址處。與此同時,ReadWrite Arbiter模塊會檢測寫請求是否有效,如果有效則優(yōu)先發(fā)起長度為256的突發(fā)寫傳輸,等寫傳輸完成后再完成下一次長度為16的突發(fā)讀傳輸。如此,當完成16次突發(fā)讀傳輸后,所讀宏塊的數(shù)據(jù)也就完全寫入到RD_FIFO中了,此時,RD_FSM由工作狀態(tài)轉(zhuǎn)為閑置狀態(tài),等待下一次的宏塊讀請求。
當RD_FIFO中的數(shù)據(jù)數(shù)量(rd_usedw)不為零時,H264編碼器即可從RD_FIFO中讀取數(shù)據(jù)。當讀完256個數(shù)據(jù),即一個宏塊的數(shù)據(jù)后,rd_usedw的值變?yōu)榱?,一個宏塊數(shù)據(jù)也便讀完了。
3.2 SDRAM命令生成器和命令仲裁器
SDRAM命令生成器(Command Generator)主要作用是根據(jù)SDRAM的控制時序生成SDRAM接口處的控制命令,這些命令是有可能發(fā)生沖突的。命令仲裁器(Command Arbiter)的作用就是對命令生成器產(chǎn)生的命令進行仲裁。
SDRAM的初始化過程可分成初始化延遲、預充電、刷新、設置模式寄存器4個階段,這4個階段由一個初始化計數(shù)器(initial timer)控制。SDRAM命令生成器根據(jù)初始化計數(shù)器的值會產(chǎn)生初始化延遲(initial)命令、預充電(precharge)命令、刷新(refresh)命令和設置模式寄存器(load_mode)命令。其中,刷新(refresh)命令也可以在SDRAM的工作過程中根據(jù)刷新計數(shù)器(refresh timer)的值產(chǎn)生。這是因為SDRAM的特性要求每64 ms就要對SDRAM的所有行刷新一遍。由于此設計中SDRAM工作在自動預充電模式,所以說預充電命令也只會在初始化過程中出現(xiàn)。
命令生成器還會根據(jù)ReadWrite Arbiter傳過來的讀寫請求產(chǎn)生讀寫(read/write)命令。讀寫(read/write)命令的優(yōu)先級是最低的,當SDRAM控制器處于初始化過程,或者正在執(zhí)行刷新命令時,命令仲裁器就會讓讀寫請求一直等待更高優(yōu)先級的命令執(zhí)行完畢。此外,由于SDRAM是工作在fullpage模式,需要根據(jù)寫或讀的突發(fā)長度產(chǎn)生突發(fā)終止命令。突發(fā)終止命令根據(jù)讀計數(shù)器(write timer)和寫計數(shù)器(read timer)的值產(chǎn)生,它的優(yōu)先級低于刷新(refresh)命令,卻高于讀寫(read/write)命令。
4 SoC平臺的軟件支持
參照參考文獻[1],設計了DM9000A的控制端口,并在所設計的SoC平臺上移植了μC/OSII實時操作系統(tǒng)和μC/TCPIP協(xié)議棧。這是為了方便把H.264編碼器所生成的比特流數(shù)據(jù)傳送到PC機端作進一步驗證。
5 實驗結果
設計了一個H.264編碼器模型,它主要實現(xiàn)的功能就是模擬H.264編碼器與SDRAM控制器接口處的讀時序,從SDRAM中讀取數(shù)據(jù)。同時,它也帶有一個Wishbone從接口,可以把讀取的數(shù)據(jù)傳送給OR1200微處理器,OR1200微處理器再經(jīng)過網(wǎng)口把圖像數(shù)據(jù)傳送到PC機,以驗證所讀取的數(shù)據(jù)是否正確。利用Wishbone總線功能模型(BFM)在ModelSim SE 6.5f環(huán)境下對所設計的模塊進行了RTL級的仿真,驗證方案框架圖如圖3所示。
圖3 多端口SDRAM控制器驗證方案
此外,對整個SoC系統(tǒng)選用Altera公司的Cyclone II系列FPGA EP2C70F896C6進行了綜合,并在臺灣友晶科技公司的DE270開發(fā)板上實現(xiàn)。整個平臺的所占用資源為:邏輯單元10 662個,寄存器4 689個,存儲器418 104位。
將圖像采集模塊的時鐘設為25 MHz,SDRAM控制器的時鐘設置為100 MHz,其他各個模塊均運行在50 MHz。前述方法把從SDRAM控制器中以宏塊為順序采集到的YUV圖像數(shù)據(jù)通過網(wǎng)口傳輸?shù)絇C機,在PC機端YUV圖像數(shù)據(jù)轉(zhuǎn)換成正常的圖像順序,把Y分量以灰度位圖的格式顯示,并與VGA顯示器中所顯示的圖像(RGB通道都輸入變換后的Y分量)進行對比。
結語
本文基于OR1200微處理器設計了一種面向H.264視頻編碼器的SoC驗證平臺,在集成了常用的各類IP核的基礎上,重點對與H.264編碼器特性相關的多端口SDRAM控制器進行了設計。經(jīng)過RTL級以及FPGA驗證,所設計的平臺可以滿足H.264編碼器軟硬件協(xié)同驗證的各種要求,可大大縮短H.264編碼器的開發(fā)時間。
評論