針對當前應用的復雜性，SOC芯片更好能能滿足應用和媒體的需求，集成眾多接口，用ARM做為應用處理器進行多樣化的應用開發和用戶界面和接口，利用DSP進行算法加速，特別是媒體的編解碼算法加速，既能夠保持算法的靈活性，又能提供強大的處理能力。德州儀器（TI）繼第一系列Davinci芯片DM644x之後，又陸續推出了DM643x，DM35x/36x，DM6467，OMAP35x，OMAPLx等一系列ARM＋DSP或ARM＋視頻協處理器的多媒體處理器平台。眾多有很強DSP開發經驗的工程師，以及應用處理開發經驗的工程師都轉到使用達芬奇或OMAP平台上開發視頻監控、視頻會議及便攜式多媒體終端等產品。基於ARM+DSP的芯片架構，如何進行開發實現做期望的嵌入式應用呢？
傳統的芯片，基本是一個處理器內核，或者是通用處理器如ARM，或者是DSP。對於控制和用戶接口，一般用通用處理器實現，算法處理或者媒體處理則依賴於DSP或者硬件芯片，很多系統都是雙芯片的架構。開發模式也比較單純，比如ARM芯片，有ARM的的仿真工具，基於OS之上進行應用開發；DSP有DSP的開發工具，如TI的CCS以及510、560的仿真器，可以進行算法的移植、優化、跟蹤、調試等。這時，所需要的經驗也比較單一。
基於ARM+DSP的雙核架構，很多工程師不知道如何入手進行開發，提出了很多的疑問，比如對ARM工程師，很困惑的是如何使用DSP的資源？如何進行數據的交互？如何保持雙核之間的同步？對DSP工程師，則問到如何進行ARM調試？如何啟動DSP？如果進行媒體加速，如何操作外設獲取或發送數據等。基於不同的開發經驗和基礎，ARM工程師和DSP工程師會從完全不同的角度來看SOC的芯片，以至於拿到SOC的芯片根本不知道如何入手，這裡就本人的經驗與大家分享一下。
首先ARM+DSP的芯片，他是一個雙核的，對應ARM和DSP分別是不同的指令集和編譯器，可以把SOC的芯片看成是兩個單芯片的合成，需要兩套不同的開發工具，CCS3.3可以進行芯片級的調試和仿真，但是對應ARM和DSP需要選擇不同的平台。一般來說，ARM上面跑操作系統，比如Linux，Wince等，在ARM上的開發，除了bootloader以外，基本都是基於OS的開發，比如驅動，內核裁減，以及上層應用等，需要的調試和仿真主要靠log或者OS提供的調試器，如KGDB，Platform Builder等。基於DSP核的開發和傳統單核DSP一樣，需要用CCS+仿真器來進行開發調試。
其次，對於芯片的外設接口，ARM核和DSP核都可以訪問，典型的情況是ARM控制所有的外設，通過OS上的驅動去控制和管理，這部分和傳統的ARM芯片類似；DSP主要是進行算法加速，只是和memory打交道，為了保持芯片的資源管理的一致性，盡量避免由DSP去訪問外設。當然，根據具體的應用需求，DSP也是可以控制外設接口進行數據的收發，這時，需要做好系統的管理，避免雙核操作的沖突。
對memory的使用，非易失的存儲空間，比如NAND、NORFlash，基本也是由ARM訪問，DSP的算法代碼作為ARM端OS文件系統的一個文件存在，通過應用程序進行DSP程序的下載和DSP芯片的控制。外部RAM空間，即DDR存儲區，是ARM和DSP共享存在的，但是在系統設計的時候，需要把ARM和DSP使用的內存嚴格物理地址分開，以及預留出一部分用來交互的內存空間。一般情況，ARM是用低端地址，DSP通過CMD文件分配高端地址，中間預留部分空間用來做數據交互，比如在OMAP3的Linux下的DVSDK中，128MB的DDR空間被分成三部分，低端地址從0x8000000到0x85800000-1的88MB空間給Linux內核使用；從0x85800000到0x86800000-1的16MB給CMEM的驅動，用來做ARM和DSP的大塊數據交互，從0x86800000到0x88000000-1的24MB是DSP的代碼和數據空間。
芯片的啟動也是需要重點考慮的問題，一般情況下，是ARM啟動，和傳統的單核ARM一樣，支持不同的啟動方式，比如可以支持NAND，NOR，UART，SPI，USB，PCI等接口啟動。DSP默認處於復位狀態，只有通過ARM的應用下載代碼並且解除復位以後，DSP才能跑起來。有些應用場景，需要DSP直接從外部上電就自啟動，有些芯片也是支持這種模式的。
最後，關於芯片的通信和同步，這個是困擾很多工程師的問題，為了便於客戶的開發和使用，TI提供了DSPLINK，CODECENGINE的DVSDK開發套件，基於DVSDK可以很方便的進行ARM+DSP的應用開發，下面對DVSDK的軟件架構，各個軟件模塊的功能等做簡要介紹。
DVSDK是多個軟件模塊的集成，包括純DSP端的軟件模塊，ARM的軟件模塊和雙核交互的軟件模塊。DVSDK的軟件包都是基於實時軟件模塊（Real-Time-Software-Component：RTSC）的，還需要安裝RTSC的工具XDC，XDC是TI開源的一個工具，可以支持跨平台的開發，能夠最大程度的代碼重用；如果需要進行純ARM的開發，還需要ARM的編譯工具以及Linux內核或者Wince的BSP；如果需要進行DSP的算法開發或者DSP端開執行代碼生成，還需要安裝DSP的編譯器cgtools和DSP/BIOS；為了便於配置生成DSP端的可執行代碼，通過向導生成Codec的RTSC包和可執行代碼，還可以選裝ceutils和cg_xml。
DVSDK的核心是CodecEngine，所有的其他軟件模塊基本都是圍繞Codec Engine的。Codec Engine是連接ARM和DSP的橋梁，是介於應用層（ARM側的應用程序）和信號處理層（DSP側的算法）之間的軟件模塊，在編譯DSP端可執行代碼和ARM端應用程序時，都需要Codec Engine的支持。Codec Engine主要有兩部分：
ARM端應用適配層，提供了精簡的API和對應的庫給應用層使用。
DSP的算法調用層，提供了DSP算法的接口封裝規范，是的所有的算法通過簡單的配置就可以編譯到DSP的可執行程序中。
最終的應用程序需要通過Codec Engine的API接口來下載DSP代碼，調用DSP端的封裝好的算法，以及進行ARM和DSP的通信。
關於CodecEngine的介紹，可以參考《幫您快速入門Codec Engine》。
Codec Engine底層ARM和DSP的通信是建立在DSP/BIOSLink之上的，DSP/BIOSLink真正實現ARM和DSP交互的軟件模塊。由於DSP/BIOS Link是跨平台的，也是有ARM部分和DSP部分組成，其中在ARM端，包括基於OS的驅動和供應用調用的庫文件，DSP端，必須要用DSP/BIOS，DSP的可執行代碼需要包含DSP/BIOSLink的庫文件。DSP/BIOSLink常用的主要有如下幾部分的軟件模塊：
PROC相關的，主要是用來做DSP芯片的控制，比如啟動，停止等，下載DSP的可執行代碼，以及直接讀寫DSP端的memory空間等
MSGQ相關，ARM和DSP的通信是基於MSGQ的，MSGQ有輪詢等待的方式或者中斷的方式，MSG是基於共享內存池的方式。Codec Engine通過MSGQ交互一些關鍵數據，比如控制，和一些大塊數據的地址指針等。大量的數據交互需要通過cmem實現。
在ARM端，配合CodecEngine使用的軟件模塊有LinuxUtils或者WinceUtils，包含cmem，SDMA等，cmem是用來在OS之外分配連續物理內存空間，進行物理地址到虛地址，以及虛地址到物理地址空間轉化的。為了避免數據的多次復制，需要開辟一塊ARM和DSP共享的數據空間，ARM和DSP都可以直接訪問，這部分空間需要通過CMEM管理。對ARM來說，CMEM是OS上的一個驅動程序，需要通過IOCTL來實現內存分配或者地址空間轉化。由於DSP可以訪問任何物理地址空間，通過ARM傳給DSP的指針必須是物理地址。
為了適配一些播放器的接口，DVSDK還提供了DMAI（Digital Media Application Interface），DMAI提供了更為精簡的媒體接口和基於OS的音視頻捕捉、回放等接口，在Linux下的gstreamer和Wince下的dshow filter都是基於DMAI的。並且DMAI也提供了最基本的測試應用例子，可以很方便的進行修改和測試。
如果只是調用現成的或者第三方的算法庫，可以只了解ARM端的軟件模塊，Codec Engine或者DMAI已經提供了豐富的應用接口，DSP可以認為是個單純的媒體加速器，把ARM+DSP的芯片當作ASIC一樣使用。如果要充分發揮DSP的性能，就需要對DSP進行開發了。Codec Engine對DSP的算法只是規范了接口，以便於和Codec Engine一起生成DSP的可執行程序。
開發DSP算法的工程師，和傳統的單核的DSP開發模式類似，只需要操作DSP核，基於CCS進行算法開發，最後封裝成xDM的接口就可以了。具體如何進行DSP的打包，如何生成DSP的可執行程序，在後續的文章繼續討論。