如何構建達芬奇的DSP Server

• 如何構建達芬奇的DSP Server
• 作者：德州儀器 通用DSP技術應用工程師 崔晶

•        德州儀器(TI)的達芬奇(DaVinci)數位媒體技術平台包括四大部分：晶片(處理器)、開發工具或開發套件、軟體及支援人員。其中軟體開發涉及到作業系統、音視頻編解碼演算法及ARM和DSP之間的分工協作，讓很多工程師感到比較複雜。        為此TI推出了一系列軟體模組和工具來建立Davinci軟體開發的架構，方便工程師在此基礎上快速的開發自己的產品。這些軟體模組和工具包含在TI的基於達芬奇技術的數位視訊評估板的軟體開發包中。        一般的視頻應用系統中，Davinci的ARM負責作業系統應用，DSP負責運行音視頻codec演算法處理，ARM通過TI的Codec Engine機制調用DSP側的codec。那麼怎樣把不同的codec演算法整合到一個DSP可執行程式(稱為DSP Server)中，又保證它們佔用的資源不衝突？本文從Davinci軟體結構入手，介紹如何構建DSP Server，及如何通過DSP Server的設定檔配置FC(Framework Component)，以便通過FC管理DSP的資源。        達芬奇DMSoC軟體概述        一般來講，軟體系統分為應用程式層、訊號處理層和I/O層三部分，TI提供的達芬奇參考軟體架構就是基於這樣的結構，1所示。Davinci的應用工程師可以在系統的使用者空間在系統功能性上添加和發揮自己的特色。訊號處理層通常都運行在DSP一側負責訊號處理，包括音視頻編解碼演算法、Codec Engine、DSP的即時作業系統DSP/BIOS及和ARM通訊的模組。I/O層就是我們通常所說的驅動，是針對Davinci外設模組的驅動程式。  
         其中應用程式層通過Codec Engine的VISA(Video, Image, Speech, Audio)API來調用DSP側的演算法，通過EPSI(Easy Peripheral Software Interface)API來訪問和操作Davinci的外設。這三個部分通常對應三個Davinci軟體開發小組。當然還需要一個系統整合工程師把這三個部分整合起來，不過VISA API和EPSI API的存在已經大大簡化了整合工作的複雜程度。        2所示，DaVinci的軟體開發通常需要四個步驟(本文以codec運行在DSP為例)：
         圖2：軟體系統分為應用程式層、訊號處理層和I/O層三部分，達芬奇軟體開發通常需要以上四個步驟。         第一步，工程師需要基於DSP利用CCS開發自己的音視頻編解碼演算法，編譯產生一個編解碼演算法的庫檔案*.lib(等同於Linux環境下的 *.a64P，直接在Linux環境下修改檔案尾碼名即可)。如果要通過Codec Engine調用這個庫檔案中的演算法函數，那麼這些演算法實現需要符合xDM(xDAIS(eXpress DSP Algorithm Interface Standard) for Digital Media)標準；Codec Engine機制下不符合xDM標準的演算法實現需要建立演算法自己的Stub和Skeleton(具體請參考spraae7.pdf)。        第二步，產生一個在DSP上啟動並執行可執行程式*.x64P(即.out檔案)，也就是DSP Server。本文將詳細介紹這一步。        第三步，根據DSP Server的名字及其中包含的具體的音視頻編解碼演算法建立Codec Engine的設定檔*.cfg。這個檔案定義Engine的不同配置，包括Engine的名字、每個Engine裡包括的codecs及每個 codec運行在ARM還是DSP側等等(具體說明，請參考sprue67.pdf的第5章Integrating an Engine)。        最後，應用工程師收到不同的codec包、DSP Server和Engine設定檔*.cfg，把自己的應用程式通過編譯、連結，最終產生ARM側可執行檔。       Codec Engine概述        前面我們提到，應用工程師通過調用Codec Engine的API來調用和運行符合xDAIS的演算法(關於API的具體資訊，請參考sprue67.pdf第4章)。在Davinci軟體中，符合 xDAIS的音視頻編解碼演算法(即xDM演算法)的調用是通過Codec Engine的VISA API完成的。Codec Engine通過這套API為演算法的執行提供了一個標準的軟體架構和介面，體現在以下幾個方面：        1. 通過Codec Engine API調用的演算法可以運行在本地(ARM側)或者遠端(DSP側)；       2. Codec Engine可以基於ARM＋DSP、DSP或ARM上運行；       3. 無論Codec Engine運行在ARM還是DSP上，對應的Codec Engine API都是完全一致的；       4. Codec Engine的API與作業系統無關。比如Linux、VxWorks和WinCE環境下的Codec Engine API都是完全一致的。 
          Codec Engine是介於應用程式和具體演算法之間的軟體模組，其中的VISA API通過stub和skeleton訪問Engine SPI最終調用具體的演算法。因此，Codec Engine的工作是通過完成VISA API的任務來體現的。VISA API分為四部分VISA create/control/process/delete，我們以codec演算法運行在DSP為例，通過VISA API的執行過程瞭解Codec Engine的工作原理。        在調用VISA API之前需要在應用程式中通過Engine_open()這個Engine API把DSP的可執行程式載入到DSP的memory，同時把DSP從複位狀態釋放，這時DSP開始運行DSP Server的初始化程式在DSP側建立一個優先順序最低的任務RMS(Remote Management Server)，RMS負責管理和維護對應到具體codec演算法的Instances。3所示，應用程式調用VISA create API，相應的VISA create函數到Engine SPI中的Codec table中查到這個codec運行在遠端DSP側。        接著Engine SPI通過OSAL(Operating System Abstraction Layer)、DSP Link把VISA create的命令傳到DSP側的RMS。RMS通過DSP側Engine SPI的codec table找到要調用的codec演算法後，就會在RMS中建立一個相應的Instance(即一個DSP/BIOS系統中的任務)。VISA create會返回一個Instance的Handle，以便於給這個Instance做後續的VISA control/process/delete提供資訊。VISA delete和VISA create原理類似，只是RMS刪除掉相應的codec演算法的Instance和執行codec演算法的任務。  
  圖3：VISA create/delete流程說明圖。         概括來說，VISA control用來動態修改codec instance的屬性，VISA process用來對演算法的輸入資料流做處理並返回一個輸出資料流。4所示，應用程式在調用VISA process/control時會通過xDM Stub把傳遞給codec演算法的參數收集起來，並且轉換成DSP可以識別的物理地址。Stub把這些參數和相關的命令通過Engine SPI、OSAL和DSP Link傳遞到DSP側的Instance。Instance再通過Skeleton把傳遞過來的參數和命令解析出來，通過DSP側VISA control/process對codec演算法執行control/process。        對Codec Engine有了基本工作原理的瞭解之後，我們就會更清楚的理解DSP的軟體怎樣配合應用程式工作及DSP Server中除演算法之外還應該包括哪些內容。        建立DSP Server        對達芬奇的軟體來說，DSP Server也叫Codec Server。其中“codec”是一組演算法。從圖3和4可以看到，除演算法之外，DSP Server還整合了其他的軟體模組(如DSP/BIOS、DSP Link、Codec Engine等)。         1. xDC簡介        達芬奇的軟體開發環境中，有一個DSP工程師比較陌生的工具xDC(Express DSP Component)。和gmake類似，xDC根據一套build指令build產生可執行檔。xDC同時也會build依賴檔案，並且可以一次 build多個目標對象的可執行檔(5中的hello.x64P是DSP的可執行檔，hello.x470MV是ARM的可執行檔)。xDC的源檔案可以是C程式、C++程式、組譯工具和庫檔案等。
         5所示，xDC按照build指令，對DSP Server的源檔案進行build(類似於make)產生DSP Server .x64P檔案。這個過程可以分為三部分：建立DSP Server的源檔案；設定xDC的設定檔；執行“make”產生可執行檔。  

  圖5：xDC按照構建指令，對DSP Server的源檔案進行構建產生DSP Server .x64P檔案。

         圖5：xDC按照構建指令，對DSP Server的源檔案進行構建產生DSP Server .x64P檔案。        2. DSP Server的源檔案        以Codec Engine_1_02中的video_copy為例，6我們可以看到video_copy的DSP Server中包括和圖5對應的源檔案main.c、video_copy.tcf和link.cmd。圖5中的packages是指圖3和圖4中的 codecs、RMS、Engine SPI和OSAL。接下來，我們可以通過xDC的設定檔看到如何把packages添加到Server中。        要構建DSP Server首先就需要建立main.c和server的DSP BIOS設定檔.tcf及link.cmd。我們提到engine_open會把DSP從複位狀態釋放，DSP Server程式開始運行初始化等等。這個初始化就是DSP Server main.c(見圖7)中的CERuntime_init()。除此之外在main.c中還可以開啟Codec Engine的trace功能，讀取或更改main函數的參數等。

   
         DSP BIOS的設定檔.tcf中定義DSP的memory map、設定DSP的複位/中斷向量表並且建立和初始化BIOS程式需要的各種資料對象(8的.tcf)。在.tcf中我們只能定義編譯器預設的 sections(如.text和.bss等)。但是，我們可以在link.cmd中定義自己的sections(8 link.cmd中.tables和.csl_vect等)。
          3. xDC檔案        在Linux中我們用make命令根據makefile來產生可執行檔，xDC也有類似的產生指令檔(我們統稱為xDC檔案)。6所示，其中 package.bld、package.xdc和video_copy.cfg三個檔案就是提供給xDC build DSP Server的xDC檔案。        在package.xdc中聲明DSP Server的名字、它的路徑及Server的依賴檔案。Package.bld檔案的功能類似於Linux中的makefile，它會告訴xDC怎麼樣 build DSP Server的源檔案。9所示在package.bld中定義target是C64P DSP、要產生針對target的可執行程式，其中配置指令檔是video_copy.tcf(與圖8中的.tcf類似)、連結選項是連結 link.cmd(與圖8中的link.cmd類似)檔案，同時還要產生main.c的目標代碼。

         xDC的強大之處還在於它提供給系統整合工程師一個強大的工具，這個工具可以用來把各種各樣的代碼模組組合成自己的最終產品。其中xDC的設定檔就是 DSP Server中的.cfg(例5中的video_copy.cfg)負責系統級的管理。請注意這裡的.cfg檔案不同於第一章提到的Codec Engine的.cfg檔案(例如 CE_INSTALL_DIR/examples/apps/video_copy/dualcpu/ceapp.cfg)，下文中提到的.cfg都是指 DSP Server的.cfg檔案。

         xDC會根據以上提到的設定檔產生package.mak(類似於makefile)，並最終運行它來產生圖5所示的包括可執行檔的package。我們可以開啟查看package.mak，但不能修改。因為重新運行xDC之後會產生新的package.mak。        4. 設定xDC的設定檔        既然.cfg檔案負責系統級的管理，我們需要先瞭解什麼需要管理？當然是DSP的資源，無非就是CPU cycles、memory及DMA。針對Davinci上DSP的軟體開發，TI提供了Framework Components來方便DSP軟體工程師使用DSP的memory和DMA資源。xDM和xDAIS演算法的Instance都向FC提出自己的資源請求，比如請求1KByte的memory或一個DMA通道。FC中的DSKT2和DMAN3就通過標準的、可以配置的方法給演算法的instances分配資源(包括instances之間可以共用的資源)。舉例來說，有了DSKT2負責不同演算法開發的工程師就不必擔心自己要用的某一段memory是否已經被別的演算法佔用等一系列問題，因為每一個演算法的memory都是由DSKT2分配的。        a. DSKT2 Framework        DSKT2負責管理系統中所有xDAIS演算法的memory需求，它和應用程式層的介面非常簡單“Create, Execute, Delete”。系統整合工程師需要用所有可以利用的memory初始化DSKT2模組。DSKT2模組包括兩種類型的memory，永久性的 memory(只要這個演算法存在，它就會佔用的memory)和scratch memory(演算法之間可以共用的memory)。當一個演算法被建立的時候，永久性memory才會被DSKT2分配給這個演算法，在演算法被刪除的時候，這段memory被返回到heap。當一個演算法申請scratch memory時，會被分配一個memory 'pool'，這個pool被擁有同一個scratch pool ID的其它演算法共用。也就是說，共用scratch memory的演算法屬於同一個優先順序，不能中斷對方。        b. 配置DSP Server的.cfg檔案        在.cfg檔案中可以做以下三個部分的配置。        (1) Codec配置：每一個codec都被包含在各自的線程中； 配置每一個codec線程的屬性(線程優先順序、堆棧大小和堆棧的memory資源)。具體請參考CE_INSTALL_DIR/xdoc/index.html。       (2) DSKT2配置： 把所有的IALG memory類型結合到可用的DSP memory；定義預設的scratch組的memory大小。       (3) DMAN3配置：定義DMAN3可以管理的DMA通道號；定義DMAN3可以提供給演算法的TCC號。        以video_copy.cfg為例，對應到圖4所示的DSP Server部分，.cfg檔案中對OSAL和codecs模組做了聲明和定義。我們可以看到video_copy的server中包括 VIDDEC_COPY和VIDENC_COPY兩個codec。
         接著對server進行配置，包括各個線程的屬性配置。Codec engine將自動匹配演算法的scratch memory ID和演算法線程的優先順序，保證安全操作。  
         對DSKT2的配置，參看下面的例子。需要注意的是這裡的每一個scratch memory pool的大小通過數組的形式定義，數組的第一個元素對應scratch pool ID0，第二個元素對應scratch pool ID2，依次類推。  
         以下是DMAN3的配置例子。因為DMA需要memory存放PARAM和其他的通道配置，所以在DMAN3分配有heap(分為internal heap和external heap)。DMAN3的PARAM是通過它自己的base index和數量分配的，本例分配給DMAN3 48個PARAM。從這個例子中我們還可以看到DMAN3有8個可用的QDMA通道，tcc是通過bit mask來分配的。         5. xDC的build 過程 xDC的調用是通過執行命令 XDC完成的。在此之前，我們需要做以下幾步：a. 在config.bld中定義平台(ARM或DSP)，config.bld所在路徑由xdcbuildcfg定義；b. 在package.xdc中定義package，package.xdc在當前路徑下(6的video_copy樣本)；c. 在package.bld中定義要build的可執行檔和庫檔案，package.bld在當前路徑下(6的video_copy樣本)；d. 按照前面的介紹根據自己的應用修改server的.cfg檔案。 執行XDC後先產生package.mak，XDC再運行package.mak產生包含可執行檔的package。 本文小結 以上的介紹基於工程師在實際開發過程中遇到的一些問題。我們希望通過這篇文章可以先理清思路，然後工程師可以有針對性的進一步研究和學習。要想瞭解更多的構建DSP Server的細節還請大家參考sprued5.pdf及文中提到的使用者手冊和應用文檔。  

來源：電子系統設計
作者：德州儀器 通用DSP技術應用工程師 崔晶