快速入門 TI 的 Codec Engine

helloxchen發表於2010-10-27

幫您快速入門 TI 的 Codec Engine

德州儀器半導體技術（上海）有限公司 通用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)的操作。

快速入門 TI 的 Codec Engine

圖1 達芬奇軟體結構框圖

2．Codec Engine入門第一步，從Codec Engine釋出說明文件(release notes)開始


快速入門 TI 的 Codec Engine

圖2 Codec Engine 1.20 Release Notes截圖

3．Codec Engine入門第二步，瞭解Codec Engine的執行環境及依賴的軟體模組和工具


點選Codec Engine的釋出說明文件 （如圖2）的Validation Info，我們可以知道Codec Engine 1.20需要和以下軟體模組和工具配合使用：

  • Framework Components 1.20.02
  • xDAIS 5.21
  • XDC Tools 2.93.01
  • DSP/BIOS Link 1.40.05, configured for the DM6446 EVM
  • C6x Code Generation Tools version 6.0.8
  • DSP/BIOS 5.31.05
  • MontaVista Linux v4.0
  • Red Hat Enterprise Linux 3 (SMP)

因此，我們需要在該Codec Engine安裝的DVSDK檔案包下面檢查上面提到的軟體模組和工具是否安裝，版本是否正確。否則，可能會編譯不過 Codec Engine的例子。那麼，什麼是 Framework Components，什麼是xDAIS，什麼又是XDC Tools呢？你可以分別到它們的根目錄下瀏覽它們各自的釋出說明文件，做一個總體的瞭解。

這裡我們簡單介紹一下，可以幫助大家儘快找到和自己相關的重點及資源。

1） Framework Components是TI提供的一個軟體模組，負責DSP側的memory 和DMA資源管理。因此，DSP演算法工程師需要了解這個軟體模組。

2） xDAIS 是一個標準，它定義了TI DSP演算法介面的標準。這樣大大提高了DSP演算法軟體的通用性。DSP演算法工程師要寫出能被ARM透過Codec Engine呼叫的演算法，必須保證自己的演算法介面符合這個標準。因此，DSP演算法工程師也必須瞭解這個軟體模組。

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版本以後的使用者就無需此操作。


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系統工程師需要了解這個作業系統。

    4．Codec Engine入門第三步，根據自己的角色參考相關的文件和例子進行開發


    開發ARM＋DSP平臺需要三類工程師：ARM應用程式工程師、DSP演算法工程師和DSP系統工程師。而開發ARM＋協處理器平臺只需要ARM應用程式工程師。下面就讓我們針對這三類工程師做分別介紹。如果您使用的是TI或TI第三方的編解碼演算法，就不需要關注DSP演算法工程師的部分。如果使用ARM＋協處理器平臺，就只需關心ARM應用工程師的部分。

    4．1 DSP演算法工程師應該如何著手？
    這裡我們不討論如何開發DSP演算法，只討論DSP演算法工程師怎樣讓自己的演算法可以被ARM透過Codec Engine呼叫。（參考，這個文件會講到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）。具體請參考：

    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安裝路徑下packagestisdofcdman3examples有一個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。


    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裡的引數都請參考：

    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，參考：

    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）如果遇到問題可以先訪問 。

    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的資料結構請參考：

    。

    4） Codec Engine DSP側會涉及到Cache一致性的問題。請參考：

    5） 關於Codec Engine系統除錯，有以下幾種方法：

        A. 開啟Codec Engine trace，透過列印資訊看問題出在什麼地方。比如engine_open失敗，DSP側不能建立codec 等等。

          a) Codec Engine 2.0及以上版本，請參考：

          b) Codec Engine 1.x版本，請參考：

        B. ARM應用程式跑起來後，用模擬器連上CCS除錯DSP側程式，參考：

        C. 用Soc Analyzer可以做系統除錯之外，還可以統計具體函式執行（ARM和DSP側）時間（benchmark）。請參考：
      6） 因為Codec Engine是介於ARM 應用程式和編解碼演算法中間的軟體模組，很多工程師非常想知道它的開銷(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 == %dn”, (t2-t1));
      }

      6．結語


      以上針對如何上手TI的Codec Engine做了簡單的歸納，還有很多具體細節的問題沒有涉及到。還請各位工程師從自己要用的軟體模組釋出說明文件開始找到相關的文件並研究。經常訪問TI的網頁，和找到最新的資訊和資料。也非常歡迎您在wiki上提問。

      轉載：http://focus.ti.com.cn/cn/general/docs/gencontent.tsp?contentId=61575[@more@]

      來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24790158/viewspace-1040472/，如需轉載，請註明出處，否則將追究法律責任。

      相關文章