作者：Bruce Lee，德州仪器软件与开发工具工程师

从消费类通信产品到多媒体产品，各种数字信号处理应用都要求具备高性能与高集成度的片上系统 (SoC) ，这无疑向开发人员提出了新的挑战。其中众多挑战源自异构架构（包含多种处理器、协处理器、加速器和外设）的集成、开发、测试以及验证的内在复杂性。不过，SoC 架构的整体系统方案才能够使其提供当今主要应用所需的高性能。

典型异构 SoC 由许多子系统和处理器组成。例如，一个多媒体处理器可能包括一个通用处理器 (GPP)、多个 DSP、音频／视频接口、编解码器、加速器、WI-FI 等无线接口、闪存、高速通信链路、传感器以及显示控制器等。开发人员凭借整套多内核感知工具 (multi-core aware tool) 不仅能够解决共享资源争用问题，基于实际应用环境进行性能优化，而且还能跨多内核实现电源管理，从而使他们能够轻松释放 SoC 器件的强大功能并对市场快速做出响应。另外，通过对这些子系统的适当调整可以针对具体应用情况实现功能、功耗和性能的优化，开发人员无需像使用集成度较低的架构那样彻头彻尾地重新设计产品。

各自为政

过去，异构架构（如 GPP+DSP）设计小组一般至少分为三个组。一个小组为 GPP 编写代码，主要负责控制处理；第二个小组为 DSP 和片上协处理器编写代码，负责大部分数据处理；第三个小组负责系统集成，将其他两个小组的设计整合在一起，并且根据新的约束和限制条件动态地重新划分系统。

大部分编程人员在特定代码块方面都会有诸多担心，如代码密度、内存占用、功耗以及高速缓存的效率。但是，离开完整的系统，我们无法精确地对这些参数进行单独测量。代码的运行效率取决于多个代码块之间对处理周期、存储器以及外设的争用。

系统级设计小组能够看清独立编程小组无法察觉的利弊。例如，将某项功能分配给 GPP 还是 DSP 的决定一般情况下取决于在该处理器上编程该功能的复杂性。GPP 更适合控制及 UI 功能，因此一般会将这些功能划分给 GPP，而数据处理功能划分给 DSP。不过，有时候上述显而易见的划分并不具有最高的效率。

我们可以看一下数码相机的自动聚焦功能，其是一种非常适合 DSP 处理的功能。与 GPP 相比，编程人员更易于为 DSP 编写自动聚焦功能，而且代码更简短，运行速度也更快。考虑到 DSP 的功耗也低于 GPP，这一决策显然不言而喻。

但是，如果考虑到典型的摄像应用模式，相关选择并非那么简单。用户往往在相机打开并且开始聚焦时并不取景或准备拍摄，这意味着并不使用 DSP。如果在 DSP 上实施自动聚焦功能，那么在上述过程中必须同时为 GPP 和 DSP 供电。如果在 GPP 上实施自动聚焦功能（假设有足够的开销），则可以使 DSP 保持断电状态。在用户实际拍照时，DSP 可以迅速进入工作状态，并且以最低时延捕获图像。

这方面的利弊是：如果在 GPP 上实施，自动聚焦功能可能效率较低，需要更多 CPU 周期而且反应速度较慢；但是，由于能够使 DSP 断电而提高整体电池使用寿命，所带来的节电优势会超过上述不足。

动态分组

在权衡系统级的分组优势时，编程人员必须将使用环境纳入考虑范围。例如，用户有时候会连续拍摄许多张照片。如果完全利用 GPP，则系统的瓶颈可能在于写入闪存或硬盘驱动器，其既限制相机排队的最大照片数量，又会限制连续拍照的速度。通过减轻 GPP 的任务处理负担可以加快图像保存速度，从而提高相机的性能。在上述情况下，在 DSP 上实施自动聚焦功能可以实现最高的系统性能。那么，编程人员应该将自动聚焦功能分配在何处呢？

答案是动态分组，这种方法使编程人员能够同时在两种处理器上实现某种功能，从而可以在两种情况下都能够达到最佳性能。如果照片队列为空，GPP 会负责自动聚焦，而 DSP 断电。在拍下第一张照片后，GPP 唤醒 DSP 以采集图像。同时，它将自动聚焦功能的执行转移至 DSP。在 DSP 出于工作状态时负责自动聚焦。在不需要 DSP 时，即用户在等待拍摄另一张照片时，则 DSP 向 GPP 发送消息，通知准备好再次断电。GPP 继续执行自动聚焦功能并通知 DSP 断电。

可以利用现成的商业实时内核管理自动聚焦功能，如：DSP／BIOS 或其他嵌入式 RTOS。如果功能可以同时在两种处理器上执行，则可以为 GPP 或 DSP 无缝地创建自动聚焦任务 (AutoFocusTask)。

两套代码总比一套好

在实施动态分组时，首要担心的是编程人员必须为不同的处理器分两次编写相同的代码。在大多情况下，此类代码均采用 C 语言编写；因此，在处理器之间移植代码仅需稍微调整一下相应编译程序生成的优化代码即可。需要注意的是，在同时具备两套代码的情况下，我们还可以获得其他优势。例如，自动聚焦功能在DSP 上会比在 GPP 上运行速度更快而且功耗更低。当今的开发环境为配置存储器使用（包括高速缓存可视化）、监控功耗以及分析总线流量提供了高级的工具，从而使开发人员确定同时在 GPP 和 DSP 上进行执行功能配置是否合理。

利用两套代码，您还可以测试在其他情况下无法评估的、更复杂的分组方案。系统的实际性能并不等于各个部件的总和。它主要取决于具体使用环境和其他工作代码。对于在 DSP 中产生高负载的视频等算法，自动聚焦功能可以返回至 GPP。您可以在多种功能之间测试不同的分组情形，以确定哪种能够提供最低的功耗以及最高的性能。您可以在开发环境中自动执行此类测试，利用各种组合并根据性能和／或功耗要求寻找最佳的配置。采用两套代码使系统集成人员能够测试新配置，而无需要求编程小组进行意外更改。但是，如果必须在一个处理器上运行代码，则无法实现上述目标。

两步调试

在异构架构中需要注意的一个系统要素是对电路系统进行调试或仿真。处理器的此类内部电路可以减少代码的调试工作量，从而使您能够更准确了解系统的运行时曲线。另外，您还可以更好地设计如何使用存储器，并且如何能够更好地优化快速内存的使用。例如，高性能 DSP 包含的高级电路可用于支持无干扰的电路内仿真 (ICE)、管理 JTAG 扫描、监控电源、提高跟踪能力、监视总线动态、执行高速数据交互、实现系统触发，以及支持在调试会话过程中提供高系统可视化的其他重要功能。

另一个重要的成分是调试程序以及开发环境中的多内核感知度。您需要能够同时停止多个处理器，以便解决某些调试问题。由于能够了解叠加的地方，并且当代码在叠加部分内部或者处理器之间转移时能够更新变量地址和观察点，因此此类工具可以加快您的开发进程。另外，您可能还需要偶然禁用调试程序。您可能希望测试某个内核退出睡眠模式的反应速度（在提供跟踪信息时不能处于睡眠状态）或者需要通信栈连续处理（即使在系统遇到断点情况下也如此），以便不丢失信息。

需要记住的是，USB 或 IEEE 1394 等协议栈可以在应用不使用它们时用于传输有用的调试信息。通过在其中一个内核上实施的协议栈，您可以更轻松地同时调试多个内核。另外，您还可以在不影响整个系统情况下控制如何传输和格式化调试数据。例如，如果您只是在调试代码中使用 printf，那么就有可能造成连接器输入不属于系统组成部分的大型库元素。

仅对该过程某一方面熟悉的开发人员（即，GPP 或 DSP）很难在设计过程前期评估权衡决策。另外，他们也无法为了优化性能或者实现动态分组而重新划分某个功能，而且在移植代码方面走进死胡同的小组也无法充分利用在编写代码过程中积累的丰富经验。不过，利用正确的代码与工具组合，您可以在系统级、而非按照独立的处理单元来检查自己的应用。您可以站在更高的层面（“我在调试 MP3 组件”），而非仅考虑 GPP 或 DSP 编程。

渴求效率

节省异构系统的一种方法是按照主／从配置运行多个处理器。主处理器在负责管理系统事件和用户界面时从处理器处于断电状态；在低利用率或者空闲期间不必要让两个处理器都耗费电源。一般情况下，GPP 或控制处理器担当主处理器，因为系统管理和用户界面功能一般在该处理器上实施。时钟更新或键盘响应等简单事件的处理无需唤醒 DSP。如果 DSP 是主处理器，则任何事件都会唤醒 GPP 进行处理。这是选择 GPP 用作主处理器的主要原因，虽然它的功耗一般高于 DSP。

在发生事件处理时，主处理器唤醒从处理器必须执行的功能。对于多功能器件而言，唤醒 DSP 由于叠加而变得复杂。为了提高处理效率及电源利用率，必须在 DSP 的快速程序存储器被唤醒前在其中加载适当的算法——该存储器的空间可能不足以保存器件需要支持的全部算法。在大多情况下，可以将程序叠加部分保存在主处理器的扩展存储器中。这样，主处理器可以在从处理器的快速程序内存中覆盖相应代码。

虽然覆盖功能由系统级小组管理，但是它们仍然使其他两个设计小组的代码编写过程变得更为复杂。代码的编写必须不依赖固定的地址；代码必须能够从程序内存的任何地方执行，而且可以从相对指针存取变量。由于快速程序内存空间有限，因此您肯定不希望在这里保存不经常使用的代码。编程人员可能还需要限制全局变量的使用。虽然使用全局变量可以简化编程，但是，无论使用与否，它们都会占用宝贵的内存资源。如果您使用 RTOS，可以配置操作系统或内核，以使其管理这些问题。

请注意，您无需完全使从处理器断电。在某些情况下，您可能仅需降低从处理器的速度，以便保持适当的功能和性能。例如，您可以将从处理器时钟频率降低到正好可以执行实时自动聚焦的水平。从处理器的编程好似踩汽车的油门，即只要能够全面控制速度和功率利用率，就不会浪费电源。

了解用户

在开始分组之前，关键是花时间评估使用环境。对于从动态分组中捞不到一点好处的功能，同时为两个处理器编写代码纯粹是浪费资源。首先应当确定典型的和最差的使用环境。然后评价各项功能在每种环境中的使用范围及其对其他功能的依赖性。

接下来是划分功能的优先级别。用于存储的图像处理不可打折扣，因为它可能成为系统的瓶颈。另一方面，如果系统存在过载情况，可以在质量或分辨率方面降低预览功能（即：显示用户即将拍照的画面）；用户希望拍到高质量的照片，而不是要一个可能连一眼也不看的高质量临时图像。

开发人员应当对可以动态分组的功能进行打包处理，以便系统集成人员使用任一个版本。可以考虑实施一套标准化的编码规则和 API，其概要说明某个功能在何处运行以及如何为系统就绪型使用“打包”相应的算法。我们可以轻松获得此类规则，例如，德州仪器 (TI) 提供了《TMS320 DSP算法标准》，其又称为 XDAIS。您可能还需要创建透明传输功能，以便在处理器之间传输所有相关状态、全局变量和系统变量，以确保动态重新划分功能时实现平稳的过渡，即在转移自动聚焦功能时屏幕上不出现闪变 [glitch]）。同样，BIOS／Link 等嵌入式内核或操作系统可以提供高效连接主／从内核的简单机制，从而无需开发人员自己重新开发此类机制。

应当考虑一项功能需要接入哪些外设和计算单元。某些处理器允许关闭芯片中实际上不使用的这部分功能。例如，您可以使用 DMA 来提高某特定功能的性能。但是，如果系统未得到全面利用，您可以通过动态地禁用 DMA 和关闭 DMA 电路来提高电源效率。

需要牢记的是，您可以降低功能。例如，如果您拥有一个双处理内核，可以选择同时处理两个图像或者同一图像的两个部分。在前一种情况下，您需要两个完整的图像缓冲器；在第二种情况下，通过分两个部分处理同一个图像，您只需单个图像缓冲器，从而使内存需求降低一半。另外，某些器件拥有可以实现长处理管线 (Pipe) 的多个加速器和协处理器。因此，通过优化的并行计算可以实现高性能处理；我们可以想象 10 个引擎同时处理一组数据。同样，您可以完全控制如何使用可用的引擎。

SoC 芯片编程在过去是一大难题。但是，由于 SoC 设计可以融合硬件和软件，而且开发人员能够进一步实现设计的抽象化，这使得我们可以站在系统级的层面评估相关权衡。借助当今各种先进的高级工具，开发人员可以无缝地设计异构系统（GPP、DSP 和其他子系统），为整个设计团队展开系统的全貌。因此，传统的三组开发团队可以发展成为一个拥有共同专业知识、效率更高的统一团队。这样的团队在统一协作的单个设计环境中可以开发用于不同产品的基础软件和硬件；例如，可以为不同的 DSC 及 DV 摄像机产品应用同一种异构 SoC 设计。

随着子系统之间的围墙土崩瓦解，开发人员可以像利用单内核架构那样发挥最复杂的 SoC 架构的高级功能。 利用动态分组等理想的工具和技术，开发人员可以实现其设计的更高性能和更长的电池使用寿命，同时还能显著加速产品上市进程。

行业背景补充资料

随着处理器功能日益增多，某些多内核设计可以回退到较传统的单内核设计。例如，典型的数字信号处理器 (DSP) 也可以得心应手地处理用户及外设控制。另一方面，功能强大的通用处理器 (GPP) 可以在无需 DSP 协助的情况下处理单通道MP3 解码。此前的多内核系统如今已能够在单内核芯片中实现：单个 DSP、GPP或 FPGA。

同样重要的是，应当认识到多内核 SoC 可能并不适合单功能设备，如：无线电监控设备 (radio control watch) 或助听器。这些设备一般不需要用户互动和再编程功能。这些应用中普遍采用的内核可以专门用于执行预定条件下的任务且功耗相对而言低得多。多内核器件的高灵活性和可扩展性对于这些应用来说可谓是大材小用。

另外，某些产品并不过多考虑功耗问题。对于此类产品，设计人员一般会提高时钟频率，以便获得执行单内核处理的各种任务所需要的处理功率。在此情况下，一般选择 1GHz 器件。对于基础应用，每通道功耗应具有极高竞争力，即便是器件功率仅有 1～2W 也是如此。可以在保持代码兼容性的同时通过选择 600MHz～1GHz 的时钟频率来调整所需的性能和功耗。

设计工程师可能还会问：“我到底该在何时决定我的设计需要多少内核？”这是一个典型的问题，答案是应当尽可能耐心地等待，但是不应牺牲软件或功能集。这可以给您带来随设计进度而不断增强的设计灵活性。在开发过程中，产品需求经常会随市场情况的改变而改变。因此，许多公司采用了螺旋式的产品开发模式。每个周期都涉及反馈信息、改进/重新设计、优化以及成本分析等。设计灵活性越高，周期就越多。一个最初的多内核 SoC 设计可能最终变成一个简单的单内核系统或者相反。大多数情况下更倾向于从多内核 SoC 逐渐降低到更简化的单内核设计。许多公司都开发了自用或商业工具，通过组合软件和硬件模块促进高级设计。因此，更重要的问题是：面对瞬息万变的市场需求，设计团队应拥有多高的灵活性和开发能力。