1.7 How to choose a CPU for Your System on Chip Design

1.7 如何为你的Soc设计进行CPU选型

   CPU选型在任何嵌入式系统设计当中都是一件有意思的事情，但是通常情况下是很随意。Stephen Olsen 曾经写过一篇关于在Soc设计过程中需要考虑哪些事情的的文章，文章里面包含了很多尤其关键的一些点，这些点的大多数也很适用于普通的板卡级别（board-based）系统设计，本章节内容就是基于Stephen Olsen的那篇文章。 ——Colin Walls

    在接下来的Soc设计过程中如何CPU选型需要考虑很多因素，如果把Soc中的CPU比作汽车里面的发动机的话，你不会指望悍马车里装一个大众的发动机还能工作，同样，一个法拉利发动机也不适合这种车辆，它能提供与悍马发动机差不多的马力，但是它缺少扭矩力。简单使用汽车领域的评估指标“马力”来比喻CPU选型会产生误导，对某项功能来说，总有一个最优的的解决方案，这个同样也适用于SoC设计中的CPU选型，很多情况下，CPU选型是取决于系统架构师的知识结构和以往对某种设备（或某方面）的经验，实际上决定使用哪个CPU需要考虑整个系统规格：整体系统设计的复杂性，设计可重用性、系统保护、系统性能、功耗、尺寸、成本、开发工具以及中层软件（middleware ）可获取性等等。

1.7.1 系统设计的复杂性

  系统设计的复杂性对于CPU选择来说非常关键，例如，如果设计一个要求执行单状态机（single-state machine）且带一些中断的小的外设设备，你最好选择一些小的CPU或者MCU，像8051或Z80，最初的很多系统可能都适合这类CPU。例如一个寻呼机，它内存占用小，信号很慢，并且电池消耗要非常低。

算法和交互决定了系统的复杂性，也决定了是否需要RTOS。通常，当系统复杂性增加，需要更大位宽（bit-width）处理器可能性也会相应增加。

1.7.2 设计重用

  设计持续重用导致系统复杂性持续增加。寻呼机在2000年设计出来，在2005升级成可以播放MP3，现在它需要支持触摸屏功能，显然一个8位的CPU已经不能满足。一个设计包含多少个交互接口可以很好的决定处理器的功耗需求，在寻呼机的例子，最初有2个交互接口：用户界面和射频连接（Radio link），比较新的设计里面包含了一个MP3播放器，我们为此需要增加一个存储器接口来存储数据和数据解码，还需要增加一个音频播放接口来播放数据（音乐），对比最初的设计，现在的设计的复杂性已经大幅增加，如果我们用前瞻性眼光来设计，很多早期的设计都可以被重用。确信你有为未来预留升级空间。现在的8位设计能适应MP3播放器，但是当这个设计被重用在机顶盒，一个需要更高带宽的外设，可能就要考虑重新设计完整解决方案，通过移植到ARM、MIPS或PowerPC架构下来处理这些新的约束和挑战。

1.7.3 存储器架构与保护

系统可能需要保护自身安全，抵抗外部或内它本身的“攻击”，这可能使得我们要去找那些包含（或支持）MMU的CPU，虚拟存储器允许被信任的程序能获取整个系统资源，不被信任的程序只能得到分配给它的那些资源，一个3G手机是一个关于系统保护最好例子，当一个恶意程序使你手机崩溃之后，你肯定不会再使用没有MMU的CPU了，尽管MMU不能完全避免系统崩溃，但是它减少了很难分辨系统故障的可能性。

三个主要的CPU架构周围包括了有8 bit、16 bit、32 bit 数据寄存器和16 bit、24 bit、32 bit地址总线，这些CPU主要的区别在于一个寄存器能存储多少信息以及所能寻址的空间范围

• 8 bit data/16 bit address =( 0-256 ),64K 地址空间
• 16 bit data/24 bit address =( 0-65535 ),16M 地址空间
  
• 32 bit data/24 bit address =( 0-2^32-1),4G 地址空间
  

  为什么一个嵌入式系统会需要4G的寻址空间？答案很简单：当系统要求执行更多更复杂任务时，代码的尺寸和复杂性会增加。早些时候CPM在Z80上利用将存储器分块和页交换（banking memory and page swapping）的方式在8-bit机器上实现复杂的程序，64K的寻址空间不够，它采用的一个解决办法就是内存覆盖技术（overlap memory）。

似乎一个24 bit地址总线对很多设计来说已经足够了，但是一对关键因素使我们更趋向选择32 bit地址空间：“保护”和“指针”，“保护”指的是拥有虚拟存储器的CPU可以使用整个4G空间，可以将实际的物理内存划分成分离的虚拟地址空间，这样实现对“坏指针”的隔离保护，同时因为是32bit的寄存器，寄存器可以直接当成一个地址，而不需要重新地址变换（索引），能简化软件。

1.7.4 CPU性能

  CPU的性能会极大影响到系统的整体性能，特别是像cache、MMU、流水线（pipeline）、分支预测（branch prediction）、超标量（superscalar）等这些特点会直接影响到系统速度，根据SoC性能需要，这些特点有时候很必要。

1.7.5 功耗

  最终的使用场景决定了设计功耗，如果的你的使用场景是电池供电，那么CPU内部需要有尽可能的功耗考虑，例如，一些CPU有睡眠（sleep）、空闲、浅睡眠（doze）等几种模式，当在空闲模式，CPU会停止运作并关闭CPU的一些内部功能以降低功耗，正是由于这些功能差异，不同的CPU执行相同的任务会体现出不同的功耗。

1.7.6 成本

CPU的成本可以有几种方式衡量，一是IP 成本（intelligence property cost），它是为SoC很衍生产品花在获取IP的费用；二是设计开发工具费用； 三是SoC验证成本。

1.7.7 软件问题

RTOS和中层软件的获得可能会决定CPU选型的好坏，比如设计一个PDA，你可能会选择Linux作为中层软件，但是这种支持虚拟存储器功能的系统，你就不能选择不带MMU的CPU。

如果还需要图形系统或文件系统，这就需要选择支持这些的RTOS，一些RTOS供应商针对某些CPU架构提供支持，其它的则没有。大多数8-bit CPU有简单的调度器利用一些外购（外包）代码（outsourced code）能满足一些小系统设计，但是有些设计无论使用多少外购代码都不能满足要求，此时的外包的解决方案会强烈影响到RTOS的选择，RTOS转而影响到选择哪些CPU。

必要的设计工具：是否有标准的ANSI C/C++编译器可以使用？怎么进行系统调试？在软/硬件协同仿真环境里面还是在SoC上面？JTAG接口是否存在？CPU在JTAG上调试？或者必须要一个专用的串口？选择一个高级语言C++或UML语言可能也需要更高的总线宽度和时钟频率来应付代码尺寸和复杂性。

1.7.8 多核SoC

  多核的SoC可能更好当系统可以划分几个子处理系统并且几个子系统直接通过松散连接的FIFO或串行通道进行通信。一些设计包含一个DSP按的RISC CPU一起协同工作来简化每一个处理器的管理范围，这种情况下可以选择多核处理器，但是这样也可能会使系统更复杂，可能要花几倍以上的时间。

1.7.9 结论

  对系统架构师来说现代SoC设计已经呈现出新的挑战，不再是琐碎的CPU选型，而是需要利用系统各项规格，像整体设计复杂性、设计重用、系统保护、系统性能、功耗、尺寸、成本、工具及中层软件可获取性等等来简化CPU选型。