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