基于DSP設計MPEG-4無線視頻產品方案

2. 量化/反量化DDCU

量化和反量化是視頻編解碼中的兩種基本操作，其計算量占整個視頻編解碼計算量的10%甚至更多。量化/反量化DDCU允許在單周期內處理多像素，其內部操作可以滿足多種MPEG-4等級的量化需求。在比特流/可變長度解碼DDCU中，將可變長度解碼模塊的計算需求降低15.4%時，指令存儲空間也會減小，這一特性同樣適用于量化、反量化DDCU。

3. 半像素內插/運動補償DDCU

這種運算單元用于加速半像素內插操作，該操作所需計算量相當大。在解碼器中，內插/補償操作所消耗的時鐘周期約為總時鐘周期的40％。該單元中所涉及的運算其實很簡單，只需要面積很小的硅片就能完成，因此很容易移入DDCU中去。就算是邊緣擴展這樣的涉及大量計算的操作，只要不需要進行優化處理，也還是可以較好地移入硬件中。

不論采用哪種內插類型，內插/運動補償DDCU中的指令組都允許每周期內插4個像素，這一特性也減少了需要執行的指令數。通過使用內插/運動補償DDCU，半像素內插/運動補償操作的速度可以增快74.6%。

4. DCT/IDCT DDCU

IDCT(反離散余弦變換)和DCT(離散余弦變換)都是視頻編碼中固有的運算。眾所周知，這兩種運算需要占用大量的時鐘周期，并要求在編寫其匯編代碼時非常小心。本文談到的這種專用DCT/IDCT DDCU單元(依據IEEE 1180－1990規范)可模仿DCT/IDCT中的“蝶形”運算。通過使用這種計算單元可以大大提高視頻設計的性能和生產力，從而使開發人員能夠集中精力開發視頻應用中的其他方面，以達到使其產品區別于其他同類產品的目的。

5. 運動估計(MEMC)DDCU

MEMC單元用于幫助完成運動估計這一計算量最大的操作。無線視頻應用中，在每個運動矢量的位置上都必須進行誤差測量。MEMC DDCU可以完成兩種最常見的誤差測量計算：絕對誤差和(SAD)測量和平方誤差和(SSE)測量。DSP平臺中若加入該運算單元，那么每周期誤差測量時所比較和累加的像素位置就可以多達4個。

6. 四分之一像素運動補償單元

基本來說，該單元所提供的功能是對半像素內插單元的一種必要的擴展。四分之一像素算法比半像素算法稍微復雜一些，因為它首先采用了一個2維FIR 濾波器來獲取半像素值，然后才使用線性插值法來計算四分之一像素值。這個2維濾波器直接并入半像素內插單元，致使半像素內插單元的硅片面積稍有增大，但這種方式仍然保持了較高的像素處理速度，這一速度遠遠超過只采用Simple Profile 設計的DSP引擎。

7. 全局運動補償單元

在視頻應用中有一種變形函數(warping function)專門用來描述當前視頻對像相對于參考視頻對像的變化。全局運動補償(GMC)單元就是為加速這種函數的運算而設計的。該單元最大可支持 3點變形(即參考VOP的仿射變換)。一旦從比特流中分析出變形點的個數后，就用這個數值來初始化GMC。GMC計算變形等式的速度遠遠快于純軟件實現方式的計算速度。

8. 語境自適應算法編/解碼DDCU

構成語境需要進行逐位操作，而逐位操作只能在標準的32位DSP中實現。為了打破這一限制，語境自適應算法編/解碼DDCU采用硬件方法形成語境值。該DDCU內部有一個查找表，用于存放所有可能的語境值，以便快速查找判斷。語境自適應編解碼運算單元支持以1b/周期的速度進行算法編、解碼。

怎樣創建一個工作平臺

設計者定義了需要用到的DDCU之后，就可以用它們來創建滿足其特殊要求的用戶應用引擎，并由此構建起工作平臺，從而設計出具有MPEG-4視頻功能的產品。

為清楚起見，讓我們來看一個例子，例中的引擎是專門針對可傳送MPEG-4信息的3G移動電話設計的。這樣的引擎要想在3G移動電話上實現預期的視頻功能，就必須以低于20MHz的速度處理第1級和第2級MPEG-4簡單視覺等級，這樣才能為諸如音頻和語音處理等其他DSP功能留有一定的可規劃帶寬。

在開始設計用戶DSP時，分配1 ALU、1 SHIFT和1MAC單元作為起始基準平臺是比較合理的。要想增加并行性，只需將這些計算單元再分配給兩個單獨的指令段：ALU和SHIFT分配給同一段， MAC分配給另一段。如果該視頻應用采用的是幀處理速度為每秒15幀的CIF格式，那么要在這個用戶平臺上編譯視頻應用程序就需要40MHz的帶寬，若采用QCIF格式則只需10MHz帶寬。盡管這樣的帶寬已經很具競爭力了，但仍然不能滿足前面提到的具有MPEG-4功能的3G移動電話的需要。

降低帶寬要求的解決方案

首先，要分析在用戶平臺中加入不同的計算單元對其性能的影響(這些計算單元全部來自MPEG-4 DDCU庫)。也就是說，我們定義了一系列的引擎，以此分析不同的計算單元混用方式所造成的性能影響。分析表明，應該保留兩段型引擎定義，因為這可以限制指令寬度，使之不至于過寬。

然后再定義一些新的引擎，經過編譯，分析其結果。新引擎定義分析的整個過程用了1或2個小時。由于DDCU庫是提前創建好的，因此許多引擎可以在一天時間內就分析完。接著從這些引擎中選出最能滿足目標產品要求的，用來構建工作平臺。

這樣得到的工作平臺與基準平臺相比，增加了一個ALU和四個MPEG-4 DDCU：比特流DDCU、量化/反量化DDCU、半像素DDCU和DCT/IDCT DDCU(見圖2)。在起始平臺的基礎上添加這些運算單元，目的就是在不增大指令存儲或數據存儲的前提下，盡可能降低對時鐘速率(MHz)的要求。完成這些操作之后，我們得到了這樣一個用戶應用引擎，該引擎可以用帶寬只有18MHz的DSP完成每秒15幀的CIF格式圖像的解碼，同時還能滿足這種3G無線視頻應用的其他關鍵要求(低功率、小晶片尺寸以及低時鐘速率)。

從圖3中可以看出DDCU對加快整個應用運行速度的作用。圖中第一條表示在標準CU構成的基準平臺上，整個運算時間在IDCT、運動補償(MC)以及可變長度編碼和反量化(VLD/DQnt)這幾種DDCU之間的分布情況。

可以看出，在這幾種DDCU中，MC部分占用時鐘周期最多。因此我們在工作平臺上添加了一個DDCU來加速半像素內插操作，提高MC部分的速度。一旦MC部分所占用的時鐘周期數大幅降低，VLD/DQnt馬上就上升成為了限制整個應用性能的最主要因素。針對這一情況，再添加一個比特流 DDCU和一個量化/反量化DDCU，又進一步提高了性能。這樣，最初的基準平臺已經經過了兩次組合。此時，再將IDCT DDCU加入其中，整個應用的性能就得到了更大的提高。圖3中的最后一條給出了三次組合后整個應用需要耗費的時鐘周期。

上面介紹的只是一個典型案例。一般而言，在無線視頻應用的開發中，按照以上這幾步進行操作，我們就可以快速地構造一個優化的引擎，為移動電話或PDA設備開發出收發MPEG-4視頻信息的功能。更妙的是，在構造起這個引擎的同時還可以解放一部分處理器資源，使之有余力去支持其他的一些新興功能，比如MP3音頻、網絡瀏覽，甚至更多。