基于USB 2.0集成芯片的H.264解碼器芯片設(shè)計

H.264/AVC標準具有一系列優(yōu)于MPEG4和H.263的新特性，在相同的重建圖像質(zhì)量下，H.264比H.263節(jié)約50％左右的碼率。但是節(jié)約碼率的代價是增加了算法復雜度。由于僅用軟件已經(jīng)無法實現(xiàn)實時地解碼過程。所以必須利用硬件加速，這正是本解碼器設(shè)計的初衷。

雖然H.264相較同質(zhì)量的H.263圖像，碼率節(jié)約一半，但是由于本解碼器的目標是解決H.264的高清圖像（1080i）的解碼工作，同時也要適用于普遍的視頻外設(shè)，所以選用的接口既需要完成高速的碼流源文件的傳輸工作也要易于插拔。而USB接口恰好符合這兩個條件。高質(zhì)量的源碼文件數(shù)據(jù)量較大，對傳輸接口要求較高。并且在FPGA的仿真環(huán)境下，USB接口還要擔負起向PC上位機回傳解碼結(jié)果的任務(wù)。這就要求傳輸速度至少要保證超越解碼速度。和USB 1.1接口相比，USB 2.0接口的傳輸更加符合本設(shè)計的要求。

經(jīng)過計算可知，傳輸接口需要至少30MB/s的傳輸速率，才能保證對1080i的圖像進行解碼。

器件選型

使用FPGA進行仿真和驗證基本已成為IC設(shè)計過程中必不可少的環(huán)節(jié)，尤其對于大規(guī)模的設(shè)計。本解碼器IC的設(shè)計使用Virtex II FPGA作為仿真環(huán)境。對于本設(shè)計，利用FF1517 BGA封裝的XC2V6000已經(jīng)充分滿足設(shè)計要求。在考慮設(shè)計成本的前提下，該款FPGA是相對高性價比的選擇。

Cypress公司的EZ-USB FX2是一款集成了USB 2.0的微處理器，它集成了USB 2.0收發(fā)器、SIE（串行接口引擎）、增強的8051微控制器和可編程的外圍接口。FX2的這種優(yōu)化設(shè)計，幾乎能達到56MB/s的數(shù)據(jù)傳輸率，而USB 2.0允許的最大帶寬是480Mb/s，即60MB/s。該芯片在對傳輸帶寬影響很小的前提下，增加了許多集成的控制功能。GPIF和Slave FIFO模式為外部的FPGA、DSP和ATA等提供了簡單和無縫的連接接口。

系統(tǒng)構(gòu)架

本設(shè)計的主體如圖1所示，在FPGA的仿真平臺中，Virtex II包括了解碼器主體和FPGA的接口模塊。USB 2.0芯片68013A作為獨立部分，負責FPGA和PC之間的USB數(shù)據(jù)傳輸。FPGA片外的SRAM與DRAM作為FPGA的擴展存儲設(shè)備，用于存放解碼器所需的源碼文件，解碼后的文件以及解碼器中用到的軟件程序文件。

圖1 FPGA仿真?zhèn)鬏斒疽鈭D

本設(shè)計中，解碼器端具備強大的功能，內(nèi)嵌有一個CPU?？梢赃M行主動識別命令的功能。所以PC端和解碼器處于對等的地位。PC端的工作包括發(fā)送命令頭，發(fā)送命令，發(fā)送碼流，接收回傳解碼結(jié)果等；FPGA端的工作包括接收并識別命令頭與PC命令，接收并向SRAM和DRAM中存儲碼流，讀取SRAM和DRAM中的解碼結(jié)果并且回傳給PC端。

USB 2.0芯片的工作方式及固件編寫

1 芯片工作方式的確定

在設(shè)計中，存在兩個過程涉及到大批量的數(shù)據(jù)文件傳輸：PC向下傳輸源碼文件，F(xiàn)PGA向上位PC傳輸解碼結(jié)果文件。其對USB傳輸要求最高。如果當傳輸?shù)脑创a文件無法適應解碼速度時，會導致解碼器停頓；如果當回傳解碼結(jié)果滯后時，會造成未被傳輸?shù)慕獯a結(jié)果被覆蓋。任何一種情況的出現(xiàn)，都將直接導致解碼器工作失敗。

在傳輸要求甚高的情況下，選用EZ-USB FX2提供的Slave FIFO的BULK（批量傳輸）模式，能很好的滿足傳輸要求。在這種模式下，USB芯片內(nèi)存單元中劃分出6個端點（endpoint），以下簡稱為EP。EP0和EP1被保留作為芯片配置FIFO。EP2、4、6、8可作為用戶傳輸，并且4個EP采用雙重FIFO（double FIFO）的方式組織構(gòu)成。

舉例來說，如圖2所示，USB執(zhí)行OUT傳輸，將EP2端點設(shè)成512字節(jié)雙重FIFO。在外部器件看來，USB端只要有1個512字節(jié)的FIFO為“半滿”，就可以繼續(xù)發(fā)送數(shù)據(jù)。當操作的FIFO寫“滿”時，F(xiàn)X2自動將其轉(zhuǎn)換到外部接口端，排除等候讀?。徊SB接口隊列中下一個為“空”的FIFO轉(zhuǎn)移到USB接口上，供其繼續(xù)寫數(shù)據(jù)。外部接口端與此類似，只要有1個FIFO為“半滿”，就可以繼續(xù)讀取數(shù)據(jù)。當前操作的FIFO讀“空”時，F(xiàn)X2自動將其轉(zhuǎn)換到USB接口端，排除等候?qū)懖⑼獠拷涌陉犃兄邢乱粋€為“滿”的FIFO轉(zhuǎn)移到接口上，供外部器件使用。

圖2 EndPoint示意圖

圖3所示為雙重FIFO的工作過程。當一個512字節(jié)的FIFO滿時，F(xiàn)PGA可以取出里面的數(shù)據(jù)，同時PC可以向另一個FIFO寫入數(shù)據(jù)（一組實箭頭）。當一個512字節(jié)的FIFO空時，PC可以寫入數(shù)據(jù)。同時FPGA可以讀取另一個仍然有數(shù)據(jù)的FIFO（一組虛箭頭）。

圖3 雙重EP運作模式

2 固件程序設(shè)計

在通過編寫固件程序初始化USB設(shè)備過程中，以下重要的配置寄存器需要設(shè)置。

IFCONFIG；設(shè)置USB時鐘由外部提供，并且選用Slave FIFO模式。

EPXCFG（X=2，4，6，8）；配置4個EP（端點FIFO）的模式。

EPXFIFOCFG（X=2，4，6，8）；配置4個EP的自動傳輸模式以及傳輸位寬。

其他一些寄存器，根據(jù)實際的需要可以單獨配置。本設(shè)計中配置EP2用于傳輸命令頭，EP4用于傳輸源碼文件，EP6用于傳輸命令，EP8用于傳輸解碼結(jié)果文件。

在完成固件程序的設(shè)計之后，可以利用FX2自帶的Control Panel將固件程序的編譯結(jié)果下載到68013A的芯片中，或者存放在外部的I2C中，以便下次復位時，芯片自己讀取。

3 電路設(shè)計原理圖

圖4為本設(shè)計的電路設(shè)計原理圖，原件按左起以及上起順序分別為：CY7C68013A芯片、電源耦合電容組、USB 2.0標準接口、標準RS232串行口、外部晶體振蕩器和HIN232串口芯片。本設(shè)計是按照這一電路原理圖制作電路板圖，完成USB 2.0的功能的。

圖4 電路設(shè)計原理圖

FPGA上解碼器與USB接口模塊的設(shè)計

SLAVE FIFO的模式下，F(xiàn)PGA可以主動決定是否有必要讀取USB內(nèi)部FIFO中的數(shù)據(jù)，而不僅僅是被動的接受PC發(fā)送的數(shù)據(jù)。如圖5所示，控制方式：SLOE、SLRD和SLWR作為EP的讀寫信號與使能控制信號。FIFOADR[1：0]作為4個EP的選擇信號，即選擇當前操作的目標EP。PKTEND是FPGA主動命令USB芯片向上位PC發(fā)送數(shù)據(jù)的控制端。FLAGX（X=A，B，C，D）表示當前選中的FIFO的空滿信息。FD（8位或者16位）為雙向的數(shù)據(jù)傳輸口。FPGA接口控制這些端口，達到對USB進行操作的目的。

圖5 解碼器與USB接口

FPGA接口中，本設(shè)計還定義了一個深度為256，寬度為32位的FIFO（內(nèi)部FIFO）。原因在于：本設(shè)計中SRAM和DRAM部分要不斷地被解碼器調(diào)用，這樣就導致存儲單元被占用。此時USB是無法對存儲單元操作的。所以在FPGA接口中，先將多個USB傳輸?shù)臄?shù)據(jù)FD（8位或者16位）拼接成32位數(shù)據(jù)存入內(nèi)部FIFO，當SRAM和DRAM空閑時，再向其傳輸。這樣的處理，使得USB傳輸不依賴于存儲單元的工作狀態(tài)，進一步提高了USB傳輸?shù)乃俣龋詽M足傳輸?shù)囊蟆?/P>

設(shè)計驗證及結(jié)果分析

當開發(fā)完Windows操作系統(tǒng)下的USB驅(qū)動程序后，本設(shè)計成功的利用EZ-USB芯片與Virtex II FPGA完成了視頻數(shù)據(jù)的傳輸工作。并且在FPGA工作的66MHz以下的頻率時，完成了對H.264格式視頻的實時傳輸、解碼。傳輸速率的檢測中，USB對大批量數(shù)據(jù)的傳輸可以達到33MB/s以上的速度，完全適應解碼器的要求。

設(shè)計分析：本設(shè)計利用了兩級的FIFO，充分的發(fā)揮了USB 2.0的速度優(yōu)勢。設(shè)計方案解除了傳輸與解碼過程中的瓶頸，實現(xiàn)了無縫連接。不足之處是由于USB芯片的Slave FIFO模式限制，PC與解碼器直接必須使用命令交互的方式進行通信，占用了一定的帶寬。在命令過于頻繁的狀態(tài)下，效率不高，但對大批量數(shù)據(jù)傳輸影響很小。

結(jié)束語

驗證平臺下成功，并且實際通過多種壓縮率的源碼文件測試，實現(xiàn)了平均33MB/s，最高40MB/s的速率。完成并且超過了設(shè)計要求。