本文以典型的视频应用为例解释了在嵌入式多核DSP平台上的实时软件开发，分析了针对典型视频应用的SOC在信号处理能力、功耗、性能、实时性，可扩展性、硬件加速协处理器等方面的特性。然后针对一个典型的视频应用，如何在多核间进行任务功能的划分以及核间IPC通信和任务调度。摘要：DSP 多核 SOC 硬件加速 VPSS  IMX C64x+ ARM  VLCD Davinci H.264 核间通信; 设计和构建嵌入式系统是一件困难的工作，这和嵌入式系统固有的资源不足相关 (如计算能力，功耗要求，内存，数据吞吐率，电池寿命，成本等的)。因而在设计时需要trade-off这些不足的资源。现代的嵌入式系统一般采用单一芯片上的多个处理单元，即多核的SOC（multicore system-on-a-chip），这种集成降低了功耗（也就是延长了电池寿命），同时也减少了系统成本。 一个基于DSP的SOC如下图1所示。多核的实现可以降低单一core的频率（为了相同的性能，多核系统每个core可以跑在更低的频率上），从而降低了整体的系统功耗，这种实现相对于单一高频的芯片实现还能带来更好的成本，以及性能和灵活性的提高。 图1. DSP SOC的架构框图 下面讨论的SoC有以下的特性，分别论述： 1. 为特定应用定制的SoC。" 跟一般的嵌入式系统类似，SoC也是根据特定的应用而定制的。如下面的图2中所示的嵌入式视频应用场合。这个系统包括实时输入采集子系统，输出显示子系统。为了构建灵活多样的系统，需要处理包含模拟输入，AD数字转换，数字格式的信号处理等，因而一个SoC需要集成的模块包括：处理单元，外设，存储器，I/O。图3是TI的Davinci视频处理器的框图，包含了各种对输入信号处理，运算和输出视频的单元。 图2. TI的视频SoC处理系统框图 2. SoCs改进了功耗/性能比。处理器运行在更高的频率更消耗能量，可能还需要冷却以维持正常运行。而低频的小系统在不消耗如此多的功率也可以有相同的处理能力。图1里的一个ARM处理器，两个DSPs，以及其他的硬件加速器可以对应用进行功能划分构成一个更为有效的处理系统。 3. 很多应用程序需要可编程性。SoC包含如此多的可编程的功能单元，原因如下：可编程性意味着你可以随时比较容易的改变算法和功能特性，如加入一个新的video编码标准，新的算法开发出来实现一个新的编码格式，还有些新的特性加入到应用中。一些数字视频应用需要支持多种文件格式，多种音视频编码标准。这些在可编程的系统中显然更为容易实现和升级。可编程的系统给设计者提供针对特定算法的定制和优化，这给程序的多样性提供了便利条件。这种便利性也让系统更好重用，新设计出来的视频模块也许会很容易在其他系统里重用。 4. 实时性，功耗和成本限制。在实时嵌入式系统里有很多的制约，很多这种制约都需要针对应用来定制平衡。 图3. TI的数字视频SoC处理器系统框图 5. 特殊的指令—— SoCs都有针对特定应用的特殊的CPU指令。图3中的SoC就有如下的特殊加速指令（当然很多特性来源于通用DSP）：
精度更高的32-bit乘法（C64x+ Core）；
FFT和DCT算法的加速算术函数；
复数乘法；
为增加FIR滤波器的吞吐量的双点积；
并行的打包指令；
Galois伽罗瓦域的乘法； 这些指令能加速某些视频算法的快速处理。当然需要编译器支持来使用这些特殊的指令，TI提供了intrinsics来方便灵活的使用这些指令。 6. 可扩展性；很多的SoCs可以在存储空间和cache大小方面扩展，当系统参数修改时，可以根据需要来扩展处理器特性。 7. 硬件加速器。 在SoC系统里使用硬件加速有很多的好处，一个主要的原因就是平衡成本和性能，专用的硬件加速器能提供更为有效的针对某一应用的实现，如视频编解码算法的专用加速器。当把应用的算法分解成若干子系统分别在不同的处理单元来完成时，可以降低整个系统的成本和功耗。硬件加速器把一些算法直接实现从而减少了CPU的负载，如一些bit运算需要很多寄存器来实现，通用的CPU寄存器通常不适用于实现这类操作，而可以有专门处理比特操作的硬件加速器来有效的给CPU减负。I/O操作也是非常适合I/O外设来加速的操作。对于需要处理流数据的应用，如在很多无线和多媒体应用中，这些流媒体的处理显然不适用于那些包含cache系统的通用CPU架构，因为流数据的短生命周期导致的不断的cache更新。而专用的硬件加速器可以用专门的读取逻辑来加速实现。 图4. TI的数字视频SoC视频处理子系统框图 SoCs 系统的硬件加速器可以有效的处理某一种类型的算法，我们提到了视频算法的加速，使用这些硬件加速可以有效的减少功率消耗。图3中的SoC具备一些硬件加速支持，如图4列出的VPSS视频处理子系统。而DSP子系统中的视频加速模块可以有效的处理视频算法。VPSS的框图中包含模块： 前端模块：
CCDC (charge coupled device)
Previewer
Resizer (接受previewer的内存数据进行多大4x缩放处理) 后端模块:
{MOD}度空间转换
DACS
数字输出
On-screen显示 VPSS处理单元减轻了DSP/ARM的负载，一个使用VPSS的应用如图5所示。 图5. 使用VPSS加速模块的视频电话系统 8. 异构存储器系统 很多SoC处理器都为每个处理器单元提供分离的存储空间，由于内存访问的低延时因而有性能的提升，同时减少了总线仲裁和切换从而也降低了系统功耗。 上述的TI的Davinci处理器还包含一个可编程的协处理器，该协处理器是为图像和视频应用优化设计的，该加速器能优化实现诸如滤波，缩放，矩阵乘法，加减和取差的绝对值等操作。这些运算都有针对流数据的数组处理的命令，有一个简单的APIs集来调用加速器，这样一个加速API指令能减少DSP系统的几百几千个周期。图6是使用并行计算来有效加速的一个加速协处理器的例子。它可以把那些直接交给CPU处理并不高效的运算交给加速器处理。 图6. 图像和视频硬件协处理框图 该加速器的iMX单元包括8个并行的MACs，这能加速并行处理很多信号处理算法，包括JPEG编解码，MPEG-1/2/4编解码，H.263编解码，WMV9解码器和H.264 基准（baseline profile）解码器等。协处理中的可变长度编解码 (VLCD)模块能有效的处理如下的基本操作: 量化和反量化 (Q/IQ)
可变长度编解码 (VLC/VLD)
哈弗曼码表(Huffman tables)
灵活的之字扫描（Zigzag scan） VLCD模块能一次处理多个宏块 (最多6个8x8块， 4:2:0格式)，开始编码或者解码一个码流前，VLCD模块的寄存器和存储空间需要应用程序进行初始化操作。 该硬件协处理器还有一个叫做sequencer的单元，其实sequencer是一个16位的微处理器，主要用于简单控制，地址计算和循环控制等。这个模块是为了减少DSP端对视频协处理器的调度。应程序员可以编程sequencer来协调各个加速器单元如iMX, VLCD, 系统DMA以及DSP。Sequencer的代码通常由宏控制来编译，然后在链接到DSP代码，运行时再由DSP来加载sequencer的代码。 DSP软件框架 使用SoC源于日益增长的对性能的要求，性能的要求已经远超过单一CPU能处理的了。处理性能的分配关乎反应时间，因而在复杂的实时系统里采用多CPU更为有效。专业外设CPU和特殊的加速器能降低主CPU的低层次处理的负载，从而可以专注于高层次的函数处理。SoC上的软件开发包括把运算应用根据运算模块的有效性分配给各个处理单元，这需要对处理的流程和任务分配做不断的尝试，SoC任务划分算法如下： 1. 把状态机控制部分放在如ARM类的RISC处理器上(包括提供应用控制，执行次序，用户界面控制，事件驱动程序等等) 2. 把数字信号处理算法部分放在DSP上，这可以利用DSP提供的专用指令来有效的进行数字信号处理。 3. 如果系统里有硬件加速器，把高速率，计算密集的算法放在硬件加速器，否则交给DSP处理，这个划分也要按照模块来划分，因为协处理一般对一段的数据处理更为有效。 一个软件划分的例子如图7所示。这个SoC处理器包括了通用处理器 (GPP), DSP和硬件加速器。GPP包括了一个底层外设API的芯片支持库用来提供对各种设备外设的支持，该GPP还用来运行操作系统OS以及算法的调度API和用户界面。DSP包括一个类似的芯片支持库，DSP的核心，一个DSP特定的算法和调度API。硬件加速器包含了一系列的APIs来实现特定算法到加速器的映射。应用程序员负责系统的整体划分并把算法映射到各个处理单元，一些厂商提供了针对DSP和硬件加速的黑盒方案，这给应用程序员提供了一个抽象层，可以不用非常清楚底层算法的细节，对于需要访问底层算法的系统设计者而言，通常还需要系统的编程灵活性以传递一些算法和控制参数。 图7. SoC的软件框架 SoC的通信通常由软件来实现，图7是ARM和DSP间的通信接口，ARM可以通过共享内存（该部分内存可以映射成寄存器）来访问DSP端的数据或者通过消息队列来控制DSP算法操作。两个处理器都能异步的发送给对方一些命令，这些命令通常都是串行的，ARM只有在接到DSP的已经完成前面的指令的回应后才能发送下一条命令，反之亦然。ARM和DSP间的异步通信过程如下： ARM –》 DSP命令:
ARM 写控制字到内存映射的寄存器；
ARM 写参数的个数到计数寄存器；
ARM 写参数到命令参数空间
ARM 发送一个不可屏蔽中断给DSP
DSP 读取命令；
DSP 读取命令参数
DSP 执行命令
DSP 情况命令寄存器；
DSP 把结果参数写入到参数空间；
DSP 写"命令执行完成"寄存器；
DSP 发送硬件中断给ARM The DSP to ARM command sequence is as follows:
DSP writes command to command register
DSP writes number of parameters to number register
DSP writes command parameters into the command parameter space
DSP issues an HINT interrupt to the DSP
ARM reads the command
ARM reads the command parameters
ARM executes DSP command
ARM clears the command register
ARM writes result parameters into the result parameter space
ARM writes "command complete" register
ARM sends an INT0 interrupt to the DSP DSP –》 ARM命令:
DSP写控制字到内存映射的寄存器；
DSP写参数的个数到计数寄存器；
DSP写参数到命令参数空间
DSP发送一个硬件中断给ARM
ARM读取命令；
ARM读取命令参数
ARM执行命令
ARM情况命令寄存器；
ARM把结果参数写入到参数空间；
ARM写"命令执行完成"寄存器；
ARM发送INT0中断给ARM ARM和DSP间一般通过提供的通信APIs进行通信，各种SoC会提供诸如下面的寄存器和通信APIs。 #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来启动的，首先ARM加载DSP的映像到指定的DSP空间，然后ARM通过控制寄存器复位DSP，然后DSP开始执行一些在预定义的位置的代码（该代码通常放在ROM内），ROM代码初始化DSP内部寄存器，并把DSP至于空闲状态，此时ARM就可以下载DSP的代码到指定空间了，下载完成ARM就可以发送一个中断给DSP，把DSP唤醒开始执行ARM加载的DSP映像。 SoC的工具支持 SoC以及其他通用的异构处理器通常都需要很复杂的的支持工具因为其不同类型的core需要不同类型的编译和debug工具。图8是一个通用的模型来说明一个SoC处理器需要什么工具来处理包括ARM和DSP的处理子系统。每个处理单元都需要一个开发环境来提取和处理数据，显示调试信息，在指定位置暂停供调试，以及代码编译链接工具等。 图8. SoC的开发环境 如图9所示，SoC的开发工具需要有开发环境来监测每个处理单元详细的状态，这些状态能让开发人员了解每个处理单元的执行情况。另外由于SoC设备会有功耗控制，可能会关闭某些处理单元，因而在调试时需要清楚应用程序执行时的功耗控制策略，这些策略也是可以通过分析工具得到。 图9. SoC处理单元的可视化工具 SoC上的视频处理系统 视频处理系统是一个很好的需要SoC系统的例子，视频处理应用程序需要很大的运算量，为了数据吞吐率需要很高的MIPs，一些运算量很大的算法如下:

" 视频和图像的稳定性预处理；
" 压缩和解压缩
" {MOD}度空间转换
" 水印以及其他加密算法 图10.  ARM+DSP的视频图像处理SoC系统 一个MPEG-4的720x480@30fps的编码可能需要2500 MIPS，虽然Audio的处理并不需要很大的运算量，但是为了保证实时性，音频的编解码、均衡和采样率转换也需要一定的MIPS。同时这些音视频算法也变得越来越复杂，如新的压缩算法由于压缩率的提升通常负责度更高，对于SoC而言，也许不仅仅支持一路的音视频输入/显示。因而SoC需要提供非常灵活的外设接口和可编程能力来支持更多的格式和标准。图10的SoC处理器有视频和图像专用的SIMD加速器（iMX），能完成很多视频处理算法，如DCT/IDCT,运动检测，运动补偿等。VLCD模块则能处理诸如JPEG, H.263, MPEG-1/2/4视频压缩算法的比特流的编码和解码。 总结 一个SoC的解决方案包含多种加速策略，专用的指令集，硬件的协处理器，这些能有效的执行DSP应用的算法，为了构建有效的SoC系统，需要进行有效的软件划分，根据应用需要和各种加速模块的效率来合理选择适合的处理单元。 Reference http://www.eetimes.com/design/embedded/4007241/Embedded-DSP-Software-Design-on-a-Multicore-SoC-Architecture-Part-1 http://www.eetimes.com/design/embedded/4007244/Embedded-DSP-Software-Design-Using-Multicore-a-System-on-a-Chip-SoC-Architecture-Part-2 http://www.blog.163.com/houh-1984/ 摘要：DSP 多核 SOC 硬件加速 VPSS  IMX C64x+ ARM VLCD Davinci H.264 本文以典型的视频应用为例解释了在嵌入式多核DSP平台上的实时软件开发，分析了针对典型视频应用的SOC在信号处理能力、功耗、性能、实时性，可扩展性、硬件加速协处理器等方面的特性。然后针对一个典型的视频应用，如何在多核间进行任务功能的划分以及核间IPC通信和任务调度 http://houh-1984.blog.163.com/blog/static/31127834201110504411749/