本文继续阐述基于低端控制器CPU的SoC固件架构设计。第一节 SoC嵌入式软件架构设计之一：系统内存需求评估 讲述了系统内存需求的评估。这一节讲述内存空间的具体规划分配。CPU有两种体系结构：哈佛结构和冯诺依曼结构。哈佛结构是一种将程序指令存储和数据存储分开的存储器结构，如80251，代码空间与数据空间完全分开，独立编址；冯诺依曼结构是一种将程序指令存储器和数据存储器合并在一起的存储器结构，如MIPS，ARM等，其代码和数据空间是统一编址。这里就以冯诺依曼体系结构为例。
一、嵌入式系统软件分层
系统软件层次包括：启动、驱动、操作系统、文件系统、libc、中间件、应用框架、应用等层次。
1）驱动、文件系统和操作系统的时间管理、中断管理等接口一般都是通过API来进行调用；
2）libc和中间件、应用框架在系统中的处理可能以API的形式进行调用，也可以直接作为静态库与应用直接进行链接。
3）libc和中间件、应用框架作为静态库时，会减少API的占用空间（API往往是常驻空间，没理由调用API时还要从外存储中将API的代码加载到内存，这样效率太低），省去API层也可以提高调用速度，但会增加库函数的代码空间。如果库函数链接时可以运行在Bank内存中，由于Bank内存可以复用，增加的代码空间可以忽略，从这一点来看其又是一个优点。如判断某个文件是哪种解码格式时，其可以作为中间件来实现，并链接到应用的Bank空间，因为这是音乐解码前的预处理，可以和解码时刻的控制流复用同一块Bank空间。
4）libc和中间件、应用框架以API形式来调用时，会产生API的常驻内存空间需求，在内存中也只存在一份真正的代码，供所有模块共同调用，而且应用开发者无需关心接口实现，也不允许开发者去修改。
各个模块应根据实际情况来决定其供上层调用的形式。
代码分页（块，Bank）设计请参考： SoC嵌入式软件架构设计之二：没有MMU的CPU实现虚拟内存管理的设计方法 和 SoC嵌入式软件架构设计之三：代码分块(Bank)设计原则。
二、程序段组成
这里程序段是指可执行文件中出现的段名，如.CODE、.DATA、.BSS等默认段名和其他自定义的段名。GNU工具链，各种编译输出段名称是可以在链接脚本中指定的，当然在编写代码时也可以指定函数或者代码的编译输出段名称，如在定义一个数据变量时添加一个属性__attribute__((section("bank_data")))时，该数据变量将会被重定位在bank_data段。下图是具有Bank代码段的程序与可执行文件段名的对应关系图：
三、SoC内置内存规划
一般地，如果SOC中内置SRAM超过32K，数字工程师也会将内置内存进行分块，一是为了减少电路延时，二是为了让内存得到更有效率的利用。如某块内存在某个时刻是作为代码使用，有时也可能作为数据使用（如果是哈佛结构，那就要切换内存的选址译码电路，从代码空间转到数据空间），有时也可能用作特别的解码buffer使用，而有些解码的缓存是以24bit作为单位，如果所有内存都作为一块来设计，显然是满足不了这样的需求的。下图是常见的SRAM示意图：
四、程序内存空间分配
根据软件分层和程序段综合考虑，一般在物理内存的基础上先进行分层划分内存区域，再进行各层程序的段内存划分。有以下原则：
1）各层的常驻段（代码和数据）应该紧凑分配，而各层的Bank空间与常驻空间分块，也应该紧凑分配。
2）Bank空间的起始地址应该与扇区单位对齐，可取得最好的加载代码性能。
3）先把常见的场景的内存分配好，再考虑特殊场景的需求，看看特殊场景能否复用普通场景的内存空间。
4）buffer的划分也要考虑场景的复用，否则太浪费。如解码的buffer可以在未解码的时候用作预处理时的媒体文件有效性判断的buffer。
5）有时两组Bank空间可以合并起来当作另一个场景的一组Bank空间来使用。如解码时的软件分层比较多，涉及到应用中间件和算法中间件，而文件浏览应用则没有这么多层次，可以将两个中间件的Bank合并起来当一组Bank来使用。
6）一个模块的代码不应该跨越两个物理内存块，否则访问性能会降低。
7）尽可能提高内存利用率，避免内存碎片。
8）内存分配的细节要以公共链接文件出现，并用有意义的名称来定义各段的起始地址和长度，除架构设计师外，其他人不允许修改该文件。
下图是一个系统的局部分配，程序内存空间分配大致如此：Rcode是常驻段，Bank是复用内存的代码块。
