快速實現ARM和DSP的通信和協同工作
德州儀器（TI）的第一顆達芬奇（DaVinci）芯片（處理器）DM6446已經問世快三年了。繼DM644x之後，TI又陸續推出了DM643x，DM35x，DM6467，OMAP353x等一系列ARM＋DSP或ARM＋視頻協處理器的多媒體處理器平臺。很多有很強DSP開發經驗或ARM開發經驗的工程師都轉到達芬奇或通用OMAP（OMAP353x）平臺上開發視頻監控、視頻會議及便攜式多媒體終端等產品。大家都面臨着同一個問題，那就是如何實現ARM和DSP或協處理器的通信和協同工作？TI的數字視頻軟件開發包（DVSDK）提供了Codec Engine這樣一個軟件模塊來實現ARM和DSP或協處理器的協同工作。有很多工程師反饋這個軟件模塊非常好用，節省了很多開發時間，也有工程師認爲TI提供的資料太多，不知如何快速上手。本文將從一個第一次接觸Codec Engine的工程師角度出發，歸納TI提供的相關資源（文檔，例程和網絡資源）並介紹相關開發調試方法幫您快速入門Codec Engine。
1. Codec Engine概述
如圖1所示，Codec Engine是連接ARM和DSP或協處理器的橋樑，是介於應用層（ARM側的應用程序）和信號處理層（DSP側的算法）之間的軟件模塊。ARM應用程序調用Codec Engine的VISA （Video, Image, Speech, Audio）API，如圖1中VIDENC_process(a, b, c )。Codec Engine的stub （ARM側）會把參數a, b, c以及要調用DSP側process這個信息打包，通過消息隊列（message queue）傳遞到DSP。Codec Engine的skeleton（DSP側）會解開這個參數包，把參數a, b, c轉換成DSP側對應的參數x, y, z（比如ARM側傳遞的是虛擬地址，而DSP只能認物理地址），DSP側的server（優先級較低，負責和ARM通信的任務）會根據process這一信息創建一個DSP側的process(x, y, x)任務最終實現VIDENC_process(a, b, c)的操作。
圖1 達芬奇軟件結構框圖
通過第一部分的介紹，我們知道了TI數字視頻軟件開發包（DVSDK）中的Codec Engine軟件模塊可以幫助我們輕鬆地實現ARM和DSP或協處理器的協同工作，以及Codec Engine軟件模塊的概要情況，下面我們將告訴你如何走完Codec Engine入門的第一步和第二步。
2. Codec Engine入門第一步
從Codec Engine發佈說明文檔（release notes）開始。
有些初學者認爲Codec Engine文件包結構複雜，很難找到自己想找的文檔或例子。其實在Codec Engine文件包的根目下有一個發佈說明文檔，比如Codec Engine 1.20 根目錄下的release_notes_codec_engine_1_20.html。這個文檔就是你瞭解Codec Engine的開始，裏面有關於該版本Codec Engine的介紹、相關文檔資料的鏈接、新的功能、支持哪些芯片、已知的bug、修正了哪些bug及例子等等的具體說明。具體如圖2藍色字體所示。瀏覽該文檔後，初學者至少可以知道哪裏可以找到自己想要的文檔或例子。舉例來說，如果想找相關的文檔，點擊 Documentation就可以看到這個Codec Engine文件包裏的文檔的鏈接。
圖2 Codec Engine 1.20 Release Notes截圖
3. Codec Engine入門第二步
瞭解Codec Engine的運行環境及依賴的軟件模塊和工具。
點擊Codec Engine的發佈說明文檔 （如圖2）的Validation Info，我們可以知道Codec Engine 1.20需要和以下軟件模塊和工具配合使用：
q Framework Components 1.20.02
q xDAIS 5.21
q XDC Tools 2.93.01
q DSP/BIOS Link 1.40.05, configured for the DM6446 EVM
q C6x Code Generation Tools version 6.0.8
q DSP/BIOS 5.31.05
q MontaVista Linux v4.0
q Red Hat Enterprise Linux 3 (SMP)
因此，我們需要在該Codec Engine安裝的DVSDK文件包下面檢查上面提到的軟件模塊和工具是否安裝，版本是否正確。否則，可能會編譯不過 Codec Engine的例子。那麼，什麼是 Framework Components，什麼是xDAIS，什麼又是XDC Tools呢？你可以分別到它們的根目錄下瀏覽它們各自的發佈說明文檔，做一個總體的瞭解。
這裏我們簡單介紹一下，可以幫助大家儘快找到和自己相關的重點及資源。
1) Framework Components是TI提供的一個軟件模塊，負責DSP側的memory 和DMA資源管理。因此，DSP算法工程師需要了解這個軟件模塊。
http://tiexpressdsp.com/wiki/index.php?title=Framework_Components_FAQ
2) xDAIS 是一個標準，它定義了TI DSP算法接口的標準。這樣大大提高了DSP算法軟件的通用性。DSP算法工程師要寫出能被ARM通過Codec Engine調用的算法，必須保證自己的算法接口符合這個標準。因此，DSP算法工程師也必須瞭解這個軟件模塊。
http://tiexpressdsp.com/wiki/index.php?title=Category:XDAIS
3) XDC Tools和gmake類似，是一個工具。XDC根據用戶定義的一套build指令，通過調用用戶指定的ARM 工具鏈（Tool Chain）和DSP編譯器（C6x Code Generation Tools ）build出ARM側和DSP側的可執行文件。可以先不必細究這個工具，只需通過編Codec Engine的例子，知道如何設置build指令就可以了。
4) DSP/BIOS Link是實現ARM和DSP之間通信的底層軟件，Codec Engine就是建立在這個底層軟件之上。在修改系統內存分配（缺省是256MB的DDR2）時，DSP/BIOS Link 1.38版本的用戶需要修改DSP/BIOS Link的配置文件，並重新build DSP/BIOS Link。而DSP/BIOS Link 1.40版本以後的用戶就無需此操作。
http://tiexpressdsp.com/wiki/index.php?title=DSPLink_Overview
http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map
5) C6x Code Generation Tools是Linux環境下C6000系列DSP的編譯器。我們用CCS開發DSP時都是用的Windows環境下的DSP編譯器。
6) DSP/BIOS是TI 免費提供的DSP實時操作系統。和上面C6x Code Generation Tools一樣，這裏的DSP/BIOS也是Linux環境下的版本。DSP系統工程師需要了解這個操作系統。
http://tiexpressdsp.com/wiki/index.php?title=Category:DSPBIOS
4. Codec Engine入門第三步
根據自己的角色參考相關的文檔和例子進行開發。
開發ARM＋DSP平臺需要三類工程師：ARM應用程序工程師、DSP算法工程師和DSP系統工程師。而開發ARM＋協處理器平臺只需要ARM應用程序工程師。下面就讓我們針對這三類工程師做分別介紹。如果您使用的是TI或TI第三方的編解碼算法，就不需要關注DSP算法工程師的部分。如果使用ARM＋協處理器平臺，就只需關心ARM應用工程師的部分。
4.1. DSP算法工程師應該如何着手？
這裏我們不討論如何開發DSP算法，只討論DSP算法工程師怎樣讓自己的算法可以被ARM通過Codec Engine調用。（參考http://www.ti.com/litv/pdf/sprued6c，這個文檔會講到codec package及相關的.xs和.xdc文件，Codec Engine1.20及以上版本的用戶可以先不細究這些內容，後面會介紹工具幫您自動生成這些文件。）
1) 熟悉xDAIS和xDM標準
xDM只是xDAIS的擴展，因此，需要先了解xDAIS。在xDAIS 軟件包根目錄下的發佈說明文檔裏，可以很快找到關於xDAIS和xDM的文檔鏈接。
http://focus.ti.com/lit/ug/spruec8b/spruec8b.pdf
在xDAIS安裝路徑下的examples/ti/xdais/dm/examples/g711有一個g711_sun_internal.c，這個算法不符合xDAIS標準。在同一個路徑下的g711dec_sun_ialg.c (decoder)和g711enc_sun_ialg.c (encoder)是封裝成符合xDM標準之後的編解碼算法。可以通過這個例子學習和了解如何把自己算法封裝成符合xDM標準的算法。
xDAIS 6.10及其以後的版本，包含了一個工具QualiTI，可以檢查您的DSP算法是否滿足xDAIS標準（但不會檢查是否滿足xDM）。具體請參考：
http://tiexpressdsp.com/wiki/index.php?title=QualiTI_XDAIS_Compliance_Tool
2) 熟悉Framework Components
Framework Components主要包括兩個模塊DSKT2和DMAN3，它們分別負責DSP側的memory 和EDMA資源管理。DSP算法使用的memory必須是先向DSKT2提出申請並由DSKT2分配得到的。同樣DSP算法使用的EDMA通道也是向DMAN3申請並由DMAN3分配得到的。而關於QDMA的操作，是通過ACPY3這個模塊實現的。這樣的好處是很容易對DSP側不同的算法做整合，不同的算法之間不用擔心資源（Memory和EDMA）的衝突問題。
在Framework Components 軟件包根目錄下的發佈說明文檔裏，可以很快找到相關文檔的鏈接。在Framework Components安裝路徑下packages\ti\sdo\fc\dman3\examples有一個Fast Copy的例子，可以幫您理解如何基於Framework Components的ACPY3模塊實現QDMA的操作。
另外，有些用戶DSP側的算法比較簡單，在確保不和ARM側EDMA資源衝突的前提下在算法裏直接操作EDMA不使用DMAN3也是可以的。這樣做的弊端是和其它算法做整合時會遇到資源使用衝突的問題。
4.2. DSP系統工程師應該如何着手？
通常DSP算法工程師都會把自己的符合xDM標準算法編成一個.lib文件（或 .a64P），供DSP系統工程師調用。DSP系統工程師最終build出一個DSP Server（也就是DSP的可執行程序.x64P，和CCS下編譯生成的.out類似）。（參考http://focus.ti.com/lit/ug/sprued5b/sprued5b.pdf，這個文檔會講到.xdc和.bld等文件，Codec Engine1.20及以上版本的用戶可以先不細究，後面介紹工具幫您自動生成這些文件。）
1) 如果現在有一個.lib文件（或 .a64P）（算法必須符合xDM標準），如何生成自己的DSP Server呢？下面URL有詳細的關於RTSC Codec and Server Package Wizard工具介紹，教您如何把一個.lib文件封裝成RTSC Codec 包和RTSC DSP Server包，並最終build出DSP的可執行程序.x64P。
http://wiki.davincidsp.com/index.php?title=RTSC_Codec_And_Server_Package_Wizards
http://wiki.davincidsp.com/index.php?title=I_just_want_my_video_codec_to_work_with_the_DVSDK
2) 如果您使用的是Codec Engine 1.20以前的版本，請參考Codec Engine安裝路徑下examples/servers/video_copy這個例子。這時就需要搞清楚sprued6c.pdf和sprued5b.pdf中提到的.xdc和.xs等文件的功能，也可以在video_copy中的相關文件的基礎上修改手動創建出自己的RTSC Codec包和RTSC DSP server包。
3) 創建好RTSC Codec 和RTSC DSP Server包之後，就是如何build出.x64P的問題了。點擊圖2所示的Examples，就可以找到build Codec Engine例子的說明文檔的鏈接。按照這個文檔做一遍後，就可以對如何build Codec Server有一個清楚的瞭解。其中關鍵是修改user.bld和xdcpaths.mak文件，設置Codec Engine依賴的其它軟件模塊和工具的正確路徑。
4) 如果自己的硬件DDR2大小和例子中的256Mbytes不一致，需要修改DSP的.tcf文件和其他配置。還有些工程師不清楚如何分配memory及如何決定具體段，如：DDRALGHEAP和DDR的大小，以及如何配置./loadmodules裏的參數都請參考：
http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map。
4.3. ARM應用程序工程師應該如何着手？
ARM應用工程師需要調用Codec Engine的VISA API，最終編出ARM側的可執行程序，因此，必須根據自己的應用學習相關的VISA API、如何創建應用側Codec Engine的package及配置文件。（參考http://focus.ti.com/lit/ug/sprue67d/sprue67d.pdf，這個文檔也涉及到如何調試Codec Engine的內容）。
1) 瞭解ARM應用程序調用Codec Engine的流程、VISA API和其他Codec Engine API。可以參考Codec Engine安裝路徑下examples/apps/video_copy的例子（較簡單）或者DVSDK安裝路徑下demos裏的encode/decode/encodedecode例子（較複雜）。
2) 瞭解ceapp.cfg文件。sprue67d.pdf有相關介紹，可以先讀懂
examples/apps/video_copy/ceapp.cfg
3) 用4.2 3)中提到的方法學習如何build ARM側的可執行程序。
4) 如何在多線程中調用codec engine，參考：
http://wiki.davincidsp.com/index.php?title=Multiple_Threads_using_Codec_Engine_Handle
5) 還可以參考以下三個文檔瞭解更多TI demo的ARM應用程序的結構、線程調度等具體的問題。
EncodeDecode Demo for the DaVinci DVEVM/DVSDK 1.2 (Rev. A) (spraah0a.htm, 8 KB) 27 Jun 2007 Abstract
Encode Demo for the DaVinci DVEVM/DVSDK 1.2 (Rev. A) (spraa96a.htm, 8 KB) 27 Jun 2007 Abstract
Decode Demo for the DaVinci DVEVM/DVSDK 1.2 (Rev. A) (spraag9a.htm, 8 KB) 27 Jun 2007 Abstract
5. 使用中常碰到的問題
1) 如果遇到問題可以先訪問
http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ
2) 有些工程師沒有DSP開發經驗，或者暫時沒有仿真器通過JTAG調試DSP。可以參考下面網頁的內容，先做一個“Hello World”的例程對ARM和DSP如何協同工作有個感性認識。
3) 很多工程師都是參考video_copy的例子，在它的基礎上把自己的算法加進去。因爲有源代碼，這樣比較容易。但肯定要根據自己算法的需要修改ARM和DSP之間傳遞的buffer和參數，重要的是先保證ARM側的應用程序可以把buffer和參數正確傳遞到DSP，DSP可以把處理之後的buffer正確的傳到ARM側的應用程序。把這個通路打通之後，就比較容易定位問題是出在ARM應用程序還是DSP側的算法。另外，參考video_copy例子時注意代碼的註釋，以便清楚哪一句代碼可以刪掉哪一句必須要修改或保留。
如果要擴展xDM的數據結構請參考：
http://wiki.davincidsp.com/index.php?title=Extending_data_structures_in_xDM
4) Codec Engine DSP側會涉及到Cache一致性的問題。請參考：
http://wiki.davincidsp.com/index.php?title=Cache_Management
5) 關於Codec Engine系統調試，有以下幾種方法：
q 打開Codec Engine trace，通過打印信息看問題出在什麼地方。比如engine_open失敗，DSP側不能創建codec 等等。
² Codec Engine 2.0及以上版本，請參考： http://wiki.davincidsp.com/index.php?title=Easy_CE_Debugging_Feature_in_CE_2.0
² Codec Engine 1.x版本，請參考：
http://wiki.davincidsp.com/index.php?title=TraceUtil
q ARM應用程序跑起來後，用仿真器連上CCS調試DSP側程序，參考：
q 用Soc Analyzer可以做系統調試之外，還可以統計具體函數運行（ARM和DSP側）時間（benchmark）。請參考：
http://tiexpressdsp.com/wiki/index.php?title=SoC_Analyzer
6) 因爲Codec Engine是介於ARM 應用程序和編解碼算法中間的軟件模塊，很多工程師非常想知道它的開銷(overhead)，請參考：
http://wiki.davincidsp.com/index.php?title=Codec_Engine_Overhead
7) 如何在Linux環境下編DSP的彙編或線性彙編程序？
在Codec Engine安裝路徑下/packages/config.bld文件裏
var C64P = xdc.useModule(‘ti.targets.C64P’);
之後添加：
C64P.extensions[“.sa”] = {
suf: “.sa”, typ: “asm:-fl”
}
或
C64P.extensions[“.asm”] = {
suf: “.asm”, typ: “asm:-fa”
8) DSP側如何統計具體函數運行時間？
TI DSPC64x+內核有一個64位的硬件定時器（Time Stamp Counter），它的頻率和CPU頻率一致。
最簡單的辦法是使用TSC的低32位TSCL。注意在DM644x中，TSCH用於ARM。
#include void main ()
{
…
TSCL=0;
…
t1=TSCL;
my_code_to_benchmark();
t2=TSCL;
printf(“# cycles == %d\n”, (t2-t1));
}
6. 結語
以上針對如何上手TI的Codec Engine做了簡單的歸納，還有很多具體細節的問題沒有涉及到。還請各位工程師從自己要用的軟件模塊發佈說明文檔開始找到相關的文檔並研究。經常訪問TI的網頁，http://wiki.davincidsp.com和http://tiexpressdsp.com/wiki找到最新的信息和資料。也非常歡迎您在wiki上提問。
數字視頻系統設計中的集成新概念（下）
數字視頻配置工具
將數字視頻嵌入應用中的首要難題在於實施視頻的複雜性要遠遠超過簡單的圖像與音頻壓縮和解壓縮。數字視頻可以採用形形色色的形式與格式，開發人員需要支持繁雜的配置和各種不同的方面，其中包括不同的分辨率/顯示器尺寸、不同的比特率、實時問題乃至視頻源的可靠性等，例如來自硬盤驅動器的視頻流與來自無線通信鏈路的視頻流的區別和處理。即使是那些看似簡單明瞭的任務——如高效管理音頻/視頻同步以及在IP 網絡上實現可靠的視頻傳輸，仍然會讓開發人員傷透腦筋。
如何使這些技術難題迎刃而解就成爲採用達芬奇技術成功實現數字視頻系統設計的關鍵。達芬奇技術所包含的四大要素，即處理器、開發工具、軟件以及系統專業技術對於數字視頻設計的集成具有重要的作用，其中一個極爲有效的工具就是包含在TI爲配合達芬奇開發所提供的數字視頻開發包（DVSDK）中的數字視頻配置工具（eXpressDSP Configuration Kit）。
由於在達芬奇技術軟件結構中引入了編解碼引擎（Codec Engine）結構，Codec Engine就提供了對DSP標準化算法（XDAIS）的完全包裝，使得應用程序與DSP程序的開發分離，更爲方便簡捷，Codec Engine使得DSP開發人員不必關心應用程序端，只需按照相應的標準開發出Codec Server,即可被應用程序正確調用。有了eXpressDSP配置工具的支持，開發人員模塊之間的接口，eXpressDSP配置工具會自動綁定編解碼器（CODEC）以及符合xDM標準的軟件模塊，不需要任何其它的操作，幾乎可以將開發時間從數月降到幾周之內，使軟件的重使用率大大增加。eXpressDSP配置工具彙集了Linux和達芬奇技術的CODEC ENGINE以及DSP/BIOS，DSP/BIOS LINK。下圖爲系統集成圖：
數字視頻配置工具使得配置一個CODEC的過程極其簡單，只需進行簡單的腳本配置，無需DSP編程便可以完成，首先得到在DSP上的符合xDM標準Codec庫，通過腳本配置語言進行簡單的配置，將此Codec庫至於Codec Engine中，進行再次編譯鏈接。至此已經完成了Codec上的全部工作。下面將逐步描述一個基於達芬奇開發板的應用程序的生成過程：
第一步，開發並完成Codec。就是要開發音視頻編解碼的核心算法，按照xDM標準封裝成爲Codec庫，Codec主要完成音視頻的核心算法，應用程序運行時被調用，並不參與其他功能。
第二步，將Codec集成到Codec Engine中。將第一步開發完成的Codec或已有的符合xDM的Codec集成到Codec Engine中，這一步需要配置兩個JavaScript的腳本文件，其中一個腳本文件表明了，Codec的使用和配置信息，文件名一般爲*.cfg，另一個描述了Codec在達芬奇上的內存分配的配置，文件名一般爲*tcf，配置好這兩個文件後，使用make命令即可生成Codec Engine，其文件名一般爲*.X64P。可被應用程序直接調用。
第三步，開發音視頻應用程序，並在其中調用Codec Engine。在Linux下開發音視頻應用程序，包括用戶界面，音視頻的採集、播放、同步等，其中完成對Codec Engine的調用，應用程序也要完成一個擴展名爲cfg的腳本配置文件，以表明對Codec Engine的使用狀況。
第四步，加載DSPLINK和CMEM模塊，運行應用程序
至此一個完整的達芬奇音視頻應用程序就完成了，其中許多過程是通過腳本文件配置完成的，過程非常簡單易懂，下面我們需要在達芬奇上運行它，首先要加載DSPLINK和CMEM兩個驅動程序模塊，其中DSPLINK主要實現了arm和dsp的底層通信，而CMEM則主要是完成了在物理段上分配連續內存的功能，加載完這兩個模塊，我們便可以直接運行已完成的應用程序。
圖形系統可視化工具
將多個軟件模塊集成只是整個開發過程的第一步，DVDSK還包含一個圖形系統可視化工具，可用於分析和顯示整個系統的性能，從而幫助快速開發數字媒體軟件。基於TMS320DM644x SoC分析器的可視化分析，以最小化的干預快速辨別和分離系統的各部分執行狀況，並通過捕捉數據鑑定程序運行狀況，以及顯示系統交互，負載分佈和其它類型的行爲。在消除大量不必要的斷點跟蹤調試後，開發者便可判斷出系統的瓶頸在哪裏並加以解決。
TMS320DM644x SoC分析器使用戶花費時間解決問題而不僅僅是發現問題，作爲一個完全的可視化分析工具，通過它用戶可以得到諸如系統交互分析、各部分負荷分析、瓶頸分離、異常行爲分析和應用的基準性能等功能。
當一個任務在DSP和ARM上同時運行時，分析器採集並顯示數據，提供了對應用程序完全的系統可視化，消除了手工收集、對比數據的繁瑣過程，如圖一所示可視化分析流程。
圖一 可視化分析流程
TI所實現的業界首創的圖形系統可視化技術爲數字視頻系統設計帶來了最大化的設計效率與性能，其多窗的圖形界面極爲友好，在同一圖象上顯示 ARM 與 DSP 的任務運行情況，如圖二所示。
圖二，數據可視化工具界面
結語：實現集成新概念
現在用達芬奇技術搭建一個視頻應用系統已經成爲一件輕鬆愉快的事情，而集成的概念已經在小小的單片系統上展開。數字視頻的開發人員首先需要搭建DSP的通用集成開發環境，然後利用業界優化的數字視頻配置工具即可儘可能減小設計工作的複雜性，進而利用全面的圖形系統可視化工具實現設計效率與性能的最大化。新技術和新手段的應用就可以這樣一來全面簡化數字視頻系統的設計開發過程而獲得更高層次的數字視頻創新。
參考: http://www.ti.com.cn/general/cn/docs/gencontent.tsp?contentId=61575