1.1 OMAP3530的硬件平臺
　　0MAP3530的硬件平臺主要由ARM內核、DSP內核以及流量控制器(Traffic Controler，TC)組成。
　　(1)ARM內核
　　OMAP3530采用ARM Cortex-A8核，工作主頻最高可達720 MHz。它包括存儲器管理單元、16 KB的高速指令緩沖存儲器、16 KB的數據高速緩沖存儲器和256K字的二級Cache;片內有64 KB的內部SRAM，為液晶顯示等應用提供了大量的數據和代碼存儲空間。CortexA8內核采用13級流水線、32位的RISC處理器架構。系統中的控制寄存器對MMU、Cache和讀寫緩存控制器進行存取操作。ARM內核具有整個系統的控制權，可以設置DSP、TC以及各種外設的時鐘及其他工作參數，控制DSP的運行停止。OMAP3530平臺可支持包含繪圖、多媒體內容和Java程序的先進應用。
　　(2)DSP內核
　　TMS320C64X+內核具有最佳的功耗性能比，工作主頻最高為520 MHz;它具有高度的并行能力，32位讀寫和功能強大的EMIF，雙流水線的獨立操作以及雙MAC的運算能力。它采用3項關鍵的革新技術：增大的空閑省電區域、變長指令和擴大的并行機制。其結構針對多媒體應用高度優化，適合低功耗的實時語音圖像處理。另外，TMS320C64X+內核增加了固化了算法的硬件加速器，來處理運動估計、8×8的DCT/IDCT和1/2像素插值，降低了視頻處理的功耗。
　　(3)流量控制器
　　流量控制器TC用于控制ARM、DSP、DMA以及本地總線對OMAP3530內所有存儲器(包括SRAM，SDRAM、Flash和ROM等)的訪問。
　　OMAP3530具有豐富的外圍接口，如液晶控制器、存儲器接口、攝像機接口、空中接口、藍牙接口、通用異步收發器、I2C主機接口、脈寬音頻發生器、串行接口、主客戶機USB口、安全數字多媒體卡控制器接口、鍵盤接口等。這些豐富的外圍接口使應用OMAP的系統具有更大的靈活性和可擴展性。
　　1.2 OMAP3530的軟件平臺
　　利用OMAP可以建立兩個操作系統：基于ARM的操作系統(如WinCE、Linux等)，以及基于DSP的DSP/BIOS。連接兩個操作系統使用的核心技術是DSP/BIOS橋。0MAP支持多種實時多任務操作系統在ARM微處理器上工作，用來對ARM微處理器進行實時多任務調度管理，對TMS320C64X+進行控制和通信;同時，支持多種實時多任務操作系統在TMS320C64X+上工作，實現復雜的多媒體信號處理。DSP/BIOS橋包含DSP管理器、DSP管理服務器、DSP和外圍接口鏈接驅動器。DSP/BIOS橋提供運行在Cortex-A8上的應用程序和運行TMS320C64X+上的算法之間的通信管理服務。開發者可以利用DSP/BIOS橋中的應用編程接口控制在DSP中實時任務的執行，并同DSP交換任務運行結果和狀態消息。在這個環境下，開發者可以調用局部DSP網關組件來實現諸如視頻、音頻和語音等功能。因此，開發者不需要了解DSP和DSP/BIOS橋，就能開發新的應用軟件。使用標準應用編程接口開發的應用軟件，與基于0MAP的未來無線設備兼容。
　　2 視頻編碼標準與OMAP圖形圖像庫應用
　　2.1 視頻編碼標準
　　從1988年開始，ISO/IEC MPEG和ITU-T針對不同的應用制訂了一系列視頻編碼國際標準。MPEG的有MPEG-1、MPEG-2、MPEG-4標準，ITU-T的有H.261、H.263、H_263+/H.263++以及H.264標準。2001年12月，ISO和ITU-T正式成立聯合視頻小組(Joint Video Team，JVT)共同制定新的H.264編碼標準。2002年6月，我國信息產業部制訂了我國的數字音視頻編碼技術標準(Audio-Video Coding Standard，AVS)。AVS是我國具備自主知識產權的第二代信源編碼標準。與目前比較流行的標準(如MPEG-2、MPEG-4、H.263、H.264)相比，從編碼效率來看，MPEG-4是MPEG-2的1.4倍，AVS和H.264都是MPEG-2的2倍以上;從算法復雜度上來看，H.264的算法在編碼端比MPEG-2復雜4～5倍，在解碼端復雜2～3倍，而AVS在復雜度上比H.264有較大幅度降低，且不需要交納高昂的專利費用。
　　目前，應用比較廣泛的視頻編碼標準中，基本上都有如下的步驟：將圖像序列編碼為幀內模式和幀問模式兩種，并且分別進行編碼。采用幀內編碼時，直接對8×8的像素塊進行DCT變換，然后將量化系數進行變長編碼后形成輸出碼流;另一路經反量化、反DCT變換后形成恢復圖像，直接存入幀存儲器。采用幀間編碼時，對原始數據的每個塊先進行運動估計，并與經運動估計后的預測圖像相減，產生差分圖像，接著進行DCT變換和量化，并同運動矢量數據一起編碼形成碼流;另一路經反量化、反DCT變換后形成恢復圖像，存入幀存儲器，用于下一步的運動估計。
　　不同的標準具有各自的特點，例如MPEGl與H.261采用整像素，MPEG4和H.263采用半像素，H.264與AVS采用1/4至1/8像素精度的運動估計，H.261采用單參考幀，H.264與AVS采用多參考幀等。特別是目前的H.264標準，采用整數DCT/IDCT、幀內預測、多模式運動估計、去塊效應濾波器等先進技術，造成了極大的算法復雜度，對硬件實時解碼提供了很高的要求。
　　2.2 OMAP圖形圖像庫(IMGLIB)應用
　　針對圖像與視頻處理的需要，TI提供了IMGLIB庫供C程序調用。庫里內容主要有2部分：
　?、儆布铀俨糠?。由匯編語言編寫，但是計算由硬件的加速模塊來實現，無法修改。例如DCT/IDCT都是針對8×8塊進行的，變換矩陣已經固定，硬件加速指令共有16種，其中DCT/IDCT各1條，運動估計指令10條，插值指令4條。
　?、谲浖铀俨糠?。用匯編語言編寫，包括矩陣量化反量化、JPEG變長編碼、一維/二維離散小波變換反變換及小波包變換反變換，以及圖像的直方圖計算、邊緣檢測、帶移位操作的3×3掩模操作等。這些軟件加速指令都提供了標準的C接口，用戶可以直接調用，也可以模仿編寫規則編譯生成自己的庫文件。

　　在視頻編解碼過程中，運動估計、DCT/IDCT和像素插值占據了大量的運算時間，0MAP平臺提供的硬件加速單元可以高效地完成上述運算，而幾乎不占用CPU時鐘(這里，不占用是指運算過程，實際上數據的輸入輸出仍需要花費少量時間);同時，優化的軟件加速單元也可以較快地完成運算。以DCT/IDCT為例，耗時情況如表1所列。
　　

 
　　由表1可知，硬件DCT耗時約為軟件DCT的1/7，硬件IDCT耗時約為軟件IDCT的1/4.5。因此，采用硬件加速模塊可以極大地提高運算速度并降低功耗。
　　對于最新的H.264以及AVS標準，需要采用OMAP3530才能發揮0MAP系列的硬件加速優勢。OMAP3530的硬件加速器集成了加速模塊的半像素插值，采用的整數DCT/IDCT類變換硬件加速模塊，而且集成了去塊效應濾波器。在通用計算機上，H.264的解碼過程中各部分所需的時間如表2所列。
　　

 
　　從表2中可以看出，在H.264的解碼過程中，環路濾波、插值以及反變換反量化占據了超過70%的計算時間。因此，用0MAP3530來進行H.264以及AVS的解碼時，如果能有效地利用0MAP3530的硬件加速資源，可以提高計算效率，實現實時解碼。另外，除了硬件加速器之外，0MAP3530的體系結構比較適合于視頻處理，這主要基于以下考慮：
　?、倌壳笆袌錾贤瞥龅恼狭薃RM與DSP的多媒體專用芯片并不多，OMAP可以使用單一芯片實現嵌入式操作系統(Linux、WinCE等)的功能，并且可以獲得TI廣大的第三方提供的豐富的算法支持。基于操作系統的編程更靈活方便，便于產品的軟件升級。相比之下，單一的DSP無法實現操作系統的功能，若額外采用ARM構建操作系統，成本以及硬件軟件復雜度無疑會大于采用OMAP平臺。
　?、诠牡目紤]。表3列出了OMAPl510上運行MPEG4解碼時的功耗情況。
　　

 
　　可以看出，在OMAPl510平臺上，對于QCIF(常用的標準化圖像格式)、15 fps的應用來說，功耗在9.9～28.5mW。對于常見的650 mAh時的手機電池，大概可以連續工作34～59小時，這對一般的應用來說顯然是夠用的。而TI的另一款專用多媒體處理芯片DM642，其功耗為1.5W，是OMAP的50～150倍。對于便攜式的多媒體終端而言，由于并不需要太高的運算處理能力，采用OMAP平臺既能滿足需要，又可以節約電池電力。
　　③速度的考慮。TMS320C64X+最多可以并行執行8條指令，所以理論上的最大速度是4 160 MIPS(520MHz)。這一點相比目前最快的多媒體處理芯片DM642(4 800 MIPS，600 MHz)來說稍低，但兩者的目標定位不同。DM642主要用于實時編碼等對速度要求較高的場合，而0MAP主要用于手持設備的解碼。以H.264算法的Base Profilc為例，復雜度比MPEG-4高20%～30%。對于MPEG4，在QCIF、15 fps下需要28 MIPS;對應的H.264算法的Base Profile要求40 MIPS的運算速度。

　?、艹绦蚪Y構的考慮。DSP的片內內存速度最快，但是非常有限，所以必須將片外的數據倒入內存。由于目前的編碼方式全都是采用基于宏塊的，每個宏塊至多16×16，所以比較通用的辦法是采用，DMA方式將要用到的數據提前倒入片內。DMA傳送速度很快，所以可以并行也可以串行傳送。
　?、蒈浖铀俚目紤]?？梢苑抡誌MGLIB的編寫規則用匯編語言對耗時最多的部分進行重寫，同時結合TI公司的數據手冊進行C語言級以及匯編級的程序優化。由于TI公司編譯器的編譯效率一直在提高，從通用及可讀性的角度上講，推薦采用C語言。
　　3 實時視頻解碼在OMAP上的軟件實現
　　在OMAP上開發程序通常分為兩部分：ARM端負責控制、顯示等;DSP端負責數據處理。采用TI公司提供的DSP開發工具CCS在這兩端分別開發，視頻解碼流程如圖2所示。
　　

 
　　ARM端：初始化整個OMAP3530芯片，包括ARM、DSP、TC等的時鐘設置，DSP的開啟關閉以及復位，LCD、定時器等各個外設的初始化。在啟動完成后，ARM內核就一直查詢共享內存中的某一標志位，當查詢到一幀解碼結束時，就啟動LCD專用DMA，在LCD上進行顯示。
　　DSP端：負責壓縮的解碼。將壓縮碼流放置在SDRAM中。與基于PC的解碼程序的主要區別在于，由于DSP的片內內存有限，所以不可能將當前幀以及參考幀都放在片內，所以以宏塊為單位在SDRAM與片內內存之間進行數據傳遞。另外，由于在液晶屏上顯示時需要轉換成RGB圖像，所以，在每一幀結束后都要通過YUV轉RGB來實現實時顯示。
　　4 實驗結果
　　在0MAP3530平臺上實現了AVS解碼，表4給出了OMAP3530上的實驗數據。
　　

 
　　結語
　　TI公司提出的0MAP體系結構開放性好，在這種體系結構下編寫的程序移植方便，適合于多媒體平臺的應用。越來越多的廠商選用OMAP芯片作為移動多媒體視頻的載體，OMAP與流行的視頻標準的結合在移動通信與多媒體信號處理方面也將有良好的應用前景。