原创 多核SoC的嵌入式软件开发(二)

在多处理器设计中，对功能模块的划分要求非常小心，因为处理器之间过多的交互会大大抵消多处理器设计所带来的优势。处理器之间常常以共享存储器和通过连接端口或者UART端口两种方式进行通讯。

处理器之间的通信

双端口与多端口、有仲裁机制和邮箱，或者带有DMA的存储器系统等都适用于多个处理器共享存储器的通讯方式。通常情况下，系统会通过中断将相关的信息，如模式改变、邮箱空/满等情况，传递给其它的处理器。除邮箱之外，中断往往是由软件通过类似GPIO/XIO的存储器映射寄存器驱动而产生的，因此握手信号可以完全受软件的控制。

在通过端口的通讯方式中，端口主要指点对点的串行通讯端口UART、主机IO端口(存储器直接访问、对其它处理器的控制等)，以及FIFO等等。在很多设计中，系统对端口的使用时间进行了了详细分割，以方便多个处理器以一定的方式进行通讯，并访问系统中的不同器件。

RealView Debugger具有支持同时调试多个处理器内核、支持用户自行定义附加的存储器映射寄存器作为SOC的外设或者子系统等主要特性，使多核、多处理器系统的调试过程变得简单起来。

相对于点对点通讯，处理器之间的通讯是并不均匀的，这种不均匀反映在各个处理器的数据传输率与延迟等待时间上。通常，不均匀设计会使系统调试与编码更加方便，但是对应用分割的要求则非常严格。

共享存储器是处理器之间最常用的通讯方式，原因之一是通过共享存储器系统可以完全控制处理器之间的对称关系与工作比例。处理器可以待机以等待子处理器或者DSP发送应答信息。另一方面，当每一次处理周期结束时，DSP会对共享存储器进行检测。当采用中断机制时，DSP会将中断设置为最低优先级，而处理器会将中断设置为最高优先级。当DSP没有任务需要完成时，它将进入休眠状态，等待处理器发送中断将其唤醒并进行新的数据处理。下面是一些处理器之间通讯的实例。

EX1：系统启动时，一个处理器将负责收集重要的代码与数据，并将其装载到共享存储空间中，以供其它处理器使用。由于主处理器拥有将其它处理器复位的能力，所以主处理器负责控制系统启动的时间，这样可以避免外部寻址，减少等待时间。一个典型例子就是微处理器通过主机端口或者共享存储器填充启动空间，然后微处理器再通过GPIO释放RESET线。

通过共享存储空间，子处理器可以向处理器要求更多的代码与数据。这种启动方式非常有意义，例如通过启动时的用户设置以及其它一些启动信息(包括引脚电平、微动开关设置等)，主处理器可以决定将什么样的算法或者查找表载入到DSP子处理器中。对于常见的DSP来说，寻址空间是有限的，这种方法可以在没有特定专用的块(Bank)切换硬件逻辑或者其它技术的情况下，对系统进行完全控制。

EX2：在下一个控制请求到来之前，子处理器处于休眠状态以避免产生不必要的功耗。当子处理器处于某种特定任务中时，或者子处理器正在接收主处理器发送来的数据时，这样的设计都是可行的。

EX3：当系统使用RTOS时，最常见的解决方法就是通过中断服务程序(ISR)从子处理器中读取数据，并将得到的信息放到队列或者其它RTOS资源中。这些数据可以是子处理器所需的更新信息(如策略信息、连接时间、核算资料、当前状态等)，也可以是系统将要发送给某个外设的数据(如LCD、存储器件、共享的音频等)。这种使用RTOS的方法的优势包括：当系统带宽有限时，可以对数据进行缓冲，避免了由于等待数据而引起的处理器等待。当然，如果系统对数据带宽与响应时间有较为苛刻的要求，DMA或者UART也不失为一种很好的解决方案。

将DSP或者子处理器看作系统的外设对系统的调试有很大的帮助。这可以帮助开发人员规划设计、算法，并将应用进行划分。在这个模型中，微处理器数据负责写“数据寄存器”(处于共享存储空间内)与“控制寄存器”(通常是可以中断子处理的GPIO)。然后，微处理器以轮询方式等待相应状态(处于共享存储器空间内)的发生，或者等待标志有新数据产生的中断的到来。与此同时，微处理器可以读“数据寄存器”(处于共享存储空间内)。

当将子处理器看作系统外设时，子处理器仍然可以与微处理器进行异步通讯。这样做的优势是可以减少死锁的产生(由于微处理器负责驱动所有的通讯，并对其具体作用做出仲裁)，并使代码的编写与调试更加方便。但是它同时也存在缺点，它将增加子处理器的等待时间，减少多处理器设计所带来的性能优势。

一个较为明显的例子就是这种模型将DSP仿真成一个自动缓冲的串口。微处理器将输出的数据装载到共享存储器中(如MP3或者无线数据码流)。当缓冲区“将要空”、或者“已经空”时，子处理器会通知主处理器。这种技术对码流处理非常有用，因为它可以控制装载过程的平衡，从而避免主处理器的实时性与确定性太强。

应用的划分

如何对应用进行划分很大程度上依赖于工作的性质与系统支持的架构。磁盘控制器首先需要对伺服系统做出快速反馈，然后响应需求通道的请求(即数据的转移地址等)，最后才响应其它的输入。一个循环处理系统(如汽车传动、防抱死刹车、引擎控制等)都必须在每一个处理周期之初(常被称为“上止点”)开始处理。

为保证一致性，所有的计算都从同一点出发。当一组数据处理完后，系统停止运算并等待下一个开始点。对流处理来说，其主要目标是保持输入输出通道在任意时刻都是满的，而输出往往是瓶颈，因此处理速度必须足够快，以保证输出信道不会产生断流或者故障。对于包处理，如网络路由器或者交换机，系统在每一个新数据包或者数据帧到来之时开始处理，此时的转换时间成为主要测量指标。因此，响应时间对系统非常重要。

当设计多处理器系统时，对应用的划分通常是由应用需求决定的。通常，一部分外部输入输出需要较短的响应时间与较高的带宽，而另一部分则不需要。响应时间必须在最坏的情况与系统平均水平之间达到平衡。如果电话从输入到输出的平均延迟时间是20毫秒，用户就会感觉通话质量非常差(人耳的灵敏度完全可以感知这样长时间的延迟)。通常情况下，带宽是由系统的平均响应时间决定的，因此开发人员必须考虑系统的缓冲能力。

在单一处理器系统中，在从系统硬件接收到输入信号，到发送输出信号之间的这段时间内，系统的所有负载都必须被计算在内，其中包括处理器资源冲突(cache命中、等待态、延迟、长指令的中断禁止、流水线延迟等待，等等)，中断延迟与响应时间，器件处理消耗，总体软件成本(包括最坏情况下的处理时间)。在多处理器设计中，由于硬件设计的特殊性，系统负载的数量会大大减少。通常每个处理器负责一部分特定的工作，在这种情况下，中断不会对整个系统造成过大负担，尤其是对上下文切换来说。而且，数据输入到输出之间的路径非常明确，因此避免了大量的软件消耗。对响应时间有严格要求的应用模块，可以通过简单的操作系统与硬件提取模型进行处理。很多情况下，应用模块之间的通讯非常少，因此处理器之间的通讯也很少使用。

值得注意的是，将应用分配给不同处理器来完成与将应用划分给RTOS的不同任务来完成的过程非常相似。在RTOS中采用多线程以及线程优先级的设置，就是为了在响应时间、负载与通讯之间达到平衡。

同样，应用模块应该能够不被调试干扰，即一个处理器被调试器停止时，其它处理器可以继续持续工作。如果此时其它的处理器也被迫停止工作，则无法完成系统的调试。

系统调试

开发人员在硬件设计过程中要求考虑调试的需要，因为多核、多处理器系统的调试过程更加复杂。多处理器系统调试的一个难点就是调试器本身。

目前，能够支持同时调试多处理器的调试器非常少。当系统中包含多种不同性质的处理器时，调试过程变得更加困难。幸运的是，RealView Debugger拥有以上所有功能，其主要特性包括：支持同时调试多个处理器内核；支持用户自行定义附加的存储器映射寄存器作为SOC的外设或者子系统；支持用户自行定义存储器类型；支持RTOS调试，调试器可以显示RTOS或者OS内核的资源状态(包括线程)；支持调试优化过的代码；能在闪存、PROM或者ROM中调试代码；能烧写闪存；能在ROM或者闪存中设置断点；支持跟踪、分析与信息统计功能(图)。

本文详细介绍了开发、调试多处理器系统时会遇到的一系列复杂问题，同时介绍了ARM RealView产品对多核系统的支持。总之，ARM RealView为ARM处理器内核与总线开发人员提供了强大的调试工具产品，为当前与未来的多核SOC设计提供了最优化的解决方案。

作者：Paul Kimelman，ARM公司