多核片上系統（SoC）架構的嵌入式DSP軟件設計
Multicore a System-on-a-Chip (SoC) Architecture
SoCs的軟件開發涉及到基於最強大的計算模型在各種處理單元之間劃分應用程序。這可能需要大量的試用anderror來建立正確的分區。在高層次上，SoCpartitioning算法如下：
將狀態機軟件（那些提供應用程序控制、排序、用戶界面控制、事件驅動軟件等的算法）放在一個RISCprocessor上，如ARM。
將信號處理軟件放在DSP上，利用DSP爲信號處理功能提供的特定於應用程序的體系結構。
在硬件加速器中放置高速率、計算密集型算法（如果它們存在並且是根據考慮的特定算法定製的）。
例如，考慮下面圖1所示的軟件分區。這個soc模型包含一個通用處理器（GPP）、一個DSP和硬件加速。GPP包含一個芯片支持庫，它是一組低層外圍API，提供對設備外圍設備的有效訪問、一個通用操作系統、一個算法層和一組API for、application和userinterface層。
該DSP包含一個類似的芯片支持庫、以aDSP爲中心的內核、一組特定於DSP的算法以及與高級應用軟件的接口。硬件加速器包含一組供程序員訪問的api和映射到加速的一些非常具體的算法。
應用程序程序員負責整個系統的劃分，並將算法映射到相應的處理元素。一些供應商可能會爲這些處理元素中的一個或多個提供“黑盒”解決方案，包括DSP和硬件加速器。
這爲應用程序開發人員提供了另一個抽象級別，他們不需要知道一些底層算法的細節。其他系統開發人員可能希望訪問這些低級算法，因此這些系統的編程模型通常具有靈活性，這取決於所需的定製和裁剪量。
Figure1. Software Architecture for SoC
SoC中的通信主要是通過軟件來建立的。例如，通過將DSP數據空間中的存儲器定義爲寄存器來實現圖1中的DSP和arm之間的通信接口。
ARM通過主機接口獲得對這些寄存器的讀/寫訪問。兩個處理器可以異步地向對方發出命令，沒有人能控制對方。命令序列是純順序的；除非DSPhas發送“命令完成”確認，否則ARM不能發出新命令。
ARM與DSP之間有兩個寄存器對建立雙向異步通信，一個寄存器對用於向ARM發送命令，另一個寄存器對用於向DSP發送命令。每個寄存器對有：
命令寄存器，用於將命令傳遞給rm或DSP；
命令完成寄存器，用於返回命令的執行狀態；
每個命令最多可傳遞30字的命令參數；
此外，每個命令執行最多可以返回30個單詞的commandreturnparameters。
ARM-to-DSP命令序列如下：
ARM將命令寫入命令寄存器
ARM將參數數寫入數字寄存器
ARM將命令參數寫入命令參數空間
ARM向DSP發出不可屏蔽的中斷
DSP讀取命令
DSP讀取命令參數
數字信號處理器執行命令
DSP清除命令寄存器
DSP將結果參數寫入結果參數空間
DSP寫入“命令完成”寄存器
DSP向ARM發出提示中斷
從DSP到ARM的命令序列如下：
DSP將命令寫入命令寄存器
數字信號處理器將參數的個數寫入數字寄存器
DSP將命令參數寫入命令參數空間
DSP向DSP發出提示中斷
ARM讀取命令
ARM讀取命令參數
ARM執行DSP命令
ARM清除命令寄存器
ARM將結果參數寫入結果參數空間
ARM寫入“命令完成”寄存器
ARM向DSP發送INT0中斷
ARM和DSP之間的通信通常使用一組通信api來完成。下面是通用處理器（在這種情況下是ARM）和DSP之間的一組通信api的示例：
#define ARM_DSP_COMM_AREA_START_ADDR 0x80
Start DSP address for ARM-DSP.
#define ARM_DSP_COMM_AREA_END_ADDR 0xFF
End DSP address for ARM-DSP.
#define ARM_DSP_DSPCR (ARM_DSP_COMM_AREA_START_ADDR)
ARM to DSP, parameters and command
from ARM.
#define ARM_DSP_DSPCCR (ARM_DSP_COMM_AREA_START_ADDR+32)
ARM to DSP, return values and
completion code from DSP.
#define ARM_DSP_ARMCR (ARM_DSP_COMM_AREA_START_ADDR+64)
DSP to ARM, parameters and command
from DSP.
#define ARM_DSP_ARMCCR (ARM_DSP_COMM_AREA_START_ADDR+96)
DSP to ARM, return values and
completion code from ARM.
#define DSP_CMD_MASK (Uint16)0x0FFF
Command mask for DSP.
#define DSP_CMD_COMPLETE (Uint16)0x4000
ARM-DSP command complete, from DSP.
#define DSP_CMD_OK (Uint16)0x0000
ARM-DSP valid command.
#define DSP_CMD_INVALID_CMD (Uint16)0x1000
ARM-DSP invalid command.
#define DSP_CMD_INVALID_PARAM (Uint16)0x2000
ARM-DSP invalid parameters.
Functions
STATUS ARMDSP_sendDspCmd (Uint16 cmd, Uint16 *cmdParams, Uint16 nParams)
Send command, parameters from ARM to
DSP.
STATUS ARMDSP_getDspReply (Uint16 *status, Uint16 *retParams, Uint16 nParams)
Get command execution status, return
parameters sent by DSP to ARM.
STATUS ARMDSP_getArmCmd (Uint16 *cmd, Uint16 *cmdParams, Uint16 nParams)
Get command, parameters sent by DSP
to ARM.
STATUS ARMDSP_sendArmReply (Uint16 status, Uint16 *retParams, Uint16 nParams)
end command execution status, return
parameters from ARM to DSP.
STATUS ARMDSP_clearReg ()
Clear ARM-DSP communication area.
SoC系統啓動順序
通常，DSP的引導映像是ARM引導映像的一部分。對於需要執行的不同任務，DSP可能有許多不同的引導映像。該序列從ARM下載與DSP要執行的特定任務相關的圖像開始。arm復位，然後DSP（通過一個控制寄存器）然後帶來複位的DSPout。
在這個階段，DSP開始在一個特定的位置執行，通常在ROM中。這個地址的ROM代碼初始化DSP內部寄存器並將DSP放入idlemode中。此時，ARM使用主機端口接口下載DSP代碼。
在完成下載DSP圖像之後，ARM可以向DSP發送一箇中斷，DSP將其從空閒模式喚醒，矢量到開始位置，並開始運行ARM加載的應用程序代碼。DSP啓動順序如下：
ARM重置DSP，然後將其從重置中取出。
數字信號處理器（DSP）退出復位，並用startaddress加載其程序計數器（PC）寄存器。
這個位置的ROM代碼將DSP分支到一個初始化routineaddress。
初始化一個DSP狀態寄存器，將矢量表移動到指定的位置，除專用的不可屏蔽中斷外，所有中斷都被禁用，並且DSP被設置爲模式。
當DSP處於其模式時，ARM用DSP代碼/數據加載DSP程序/數據存儲器。
當ARM完成下載DSP代碼時，它通過斷言一箇中斷信號從該模式喚醒DSP。
然後，DSP分支到新的interruptvector表所在的起始地址。ARM應該至少在開始代碼中加載了abranch。
SoC的工具支持
SoC工具環境還包含監視每個處理元素的詳細狀態的支持。如下圖3所示，anSoc中處理元素的詳細狀態報告和控制允許開發人員查看系統的執行概要。
此外，由於功率敏感的SoC設備可能會在應用程序執行時關閉部分或全部設備，因此瞭解應用程序的功率分佈也很有用。這也可以通過適當的分析工具得到。
一般來說，SoC和異構處理器需要更復雜的工具支持。一個SoC可以包含幾個可編程的可調試處理元素，這些處理元素需要支持代碼生成、調試訪問和可見性以及實時數據分析的工具。A這方面的一般模型如下圖2所示。一個SoC處理器將有幾個處理元件，如ARM和DSP。
這些處理元素中的每一個都需要一個開發環境，其中包括提取、處理和顯示調試和檢測數據流的機制、調用和插入內存的機制以及控制可編程元素執行的機制，以及生成、鏈接和構建可編程元素可執行映像的工具。
Figure2. An SoC tools environment
SoC工具環境還包含監視每個處理元素的詳細狀態的支持。如下圖3所示，anSoc中處理元素的詳細狀態報告和控制允許開發人員查看系統的執行概要。
此外，由於功率敏感的SoC設備可能會在應用程序執行時關閉部分或全部設備，因此瞭解應用程序的功率分佈也很有用。這也可以通過適當的分析工具得到。
Figure3. Tools support provide visibility into the status of each of theSoC processing elements
SoC的視頻處理實例
視頻處理是需要片上系統解決方案的商業應用的一個很好的例子。視頻處理應用程序是計算密集型的，需要大量的MIPS來維持這些應用程序所需的數據吞吐量。這些應用程序中的一些非常複雜的算法包括：
“圖像管道處理和視頻穩定
“壓縮和減壓
“顏色轉換
“水印和各種形式的加密
Figure4. A SoC designed for video and image processing using a RISC device(ARM926) and a DSP
要執行每秒30幀的MPEG-4算法，根據視頻的分辨率可以達到2500 MIPS。
音頻通道處理沒有要求那麼高，但是仍然需要足夠的整體MIPS來執行音頻壓縮和解壓縮、均衡和採樣率轉換。
隨着這些應用變得更加複雜和要求更高（例如，新的壓縮技術仍在開發中），這些SoC將不僅需要支持一個壓縮標準，還需要支持幾個不同的壓縮標準。用於視頻應用的soc包括用於提高性能的專用指令集加速器。soc編程模型和外圍混合允許靈活地有效地支持這些標準的幾種格式。
例如，上面圖4中的DM320 SoC處理器有一個專用於視頻處理的片上Simd引擎（稱爲iMX）。該硬件加速器可以執行常見的視頻處理算法（離散餘弦變換（DCT）、IDCT、運動估計、運動相關等）
VLCD（可變長度編碼/解碼）處理器用於支持可變長度編碼和解碼以及JPEG、H.263、MPEG-1/2/4視頻壓縮標準的量化。
如圖4所示，SoC解決方案包含適當的加速機制、專用指令集、硬件協處理器等，它們提供了DSP應用中重要算法的高效執行。我們討論了視頻處理的一個例子，但是您會發現支持其他應用程序（如無線基站和蜂窩手機）的機制是相同的。