一種面向H．264視頻編碼器的SoC驗證平臺
加入技術(shù)交流群
3．1 讀寫(xiě)端口和讀寫(xiě)仲裁器
圖2中有一個(gè)讀端口和一個(gè)寫(xiě)端口，分別用于H．264編碼器讀出數據和圖像采集模塊寫(xiě)入數據。其實(shí)還有一個(gè)用于VGA顯示的讀端口，其時(shí)序與圖像采集模塊的寫(xiě)時(shí)序相同，都是逐行掃描，在此處略去了。
在讀＆寫(xiě)仲裁器(Read＆Write 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í)，Read＆Write 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_u sedw的值變?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ì )根據Read＆Write Arbiter傳過(guò)來(lái)的讀寫(xiě)請求產(chǎn)生讀寫(xiě)(read／write)命令。讀寫(xiě)(read／write)命令的優(yōu)先級是最低的，當SDRAM控制器處于初始化過(guò)程，或者正在執行刷新命令時(shí)，命令仲裁器就會(huì )讓讀寫(xiě)請求一直等待更高優(yōu)先級的命令執行完畢。此外，由于SDRAM是工作在full-page模式，需要根據寫(xiě)或讀的突發(fā)長(cháng)度產(chǎn)生突發(fā)終止命令。突發(fā)終止命令根據讀計數器(write timer)和寫(xiě)計數器(read timer)的值產(chǎn)生，它的優(yōu)先級低于刷新(refresh)命令，卻高于讀寫(xiě)(read／write)命令。
4 SoC平臺的軟件支持
參照參考文獻，設計了DM9000A的控制端口，并在所設計的SoC平臺上移植了μC／OS-II實(shí)時(shí)操作系統和μC／TCP-IP協(xié)議棧。這是為了方便把H．264編碼器所生成的比特流數據傳送到PC機端作進(jìn)一步驗證。
5 實(shí)驗結果
設計了一個(gè)H．264編碼器模型，它主要實(shí)現的功能就是模擬H．264編碼器與SDRAM控制器接口處的讀時(shí)序，從SDRAM中讀取數據。同時(shí)，它也帶有一個(gè)Wish-bone從接口，可以把讀取的數據傳送給OR1200微處理器，OR1200微處理器再經(jīng)過(guò)網(wǎng)口把圖像數據傳送到PC機，以驗證所讀取的數據是否正確。利用Wishbone總線(xiàn)功能模型(BFM)在ModelSim SE 6．5f環(huán)境下對所設計的模塊進(jìn)行了RTL級的仿真，驗證方案框架圖如圖3所示。本文引用地址：http://dyxdggzs.com/article/165871.htm
此外，對整個(gè)SoC系統選用Altera公司的Cyclone II系列FPGA EP2C70F896C6進(jìn)行了綜合，并在臺灣友晶科技公司的DE2-70開(kāi)發(fā)板上實(shí)現。整個(gè)平臺的所占用資源為：邏輯單元10 662個(gè)，寄存器4 689個(gè)，存儲器418104位。
將圖像采集模塊的時(shí)鐘設為25 MHz，SDRAM控制器的時(shí)鐘設置為100 MHz，其他各個(gè)模塊均運行在50MHz。前述方法把從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í)間。
評論