概要设计实例_多核片上系统（SoC）架构的嵌入式DSP软件设计

多核片上系统（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 0x80Start DSP address for ARM-DSP.
#define ARM_DSP_COMM_AREA_END_ADDR 0xFFEnd 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)0x0FFFCommand mask for DSP.
#define DSP_CMD_COMPLETE (Uint16)0x4000ARM-DSP command complete, from DSP.
#define DSP_CMD_OK (Uint16)0x0000ARM-DSP valid command.
#define DSP_CMD_INVALID_CMD (Uint16)0x1000ARM-DSP invalid command.
#define DSP_CMD_INVALID_PARAM (Uint16)0x2000ARM-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应用中重要算法的高效执行。我们讨论了视频处理的一个例子，但是您会发现支持其他应用程序（如无线基站和蜂窝手机）的机制是相同的。