程序的大部分代码都可以在必要的时候才加载到内存去执行，运行完后可以被直接丢弃或者被其他代码覆盖。我们PC上同时跑着很多的应用程序，每个应用程序使用的虚拟地址空间几乎可以整个线性地址空间（除了部分留给操作系统或者预留它用），可以认为每个应用程序都独占了整个虚拟地址空间（字长是32的CPU是4G的虚拟地址空间），但我们的物理内存只是1G或者2G。即多个应用程序在同时竞争使用这块物理内存，其必然会导致某个时刻只存在程序的某个片段在执行，也即是所有程序代码和数据分时复用物理内存空间—这就是内存管理单元(MMU)工作核心作用所在。
处理器系列的芯片（如X86、ARM7以上、MIPS）一般都会有MMU，跟操作系统一块实现虚拟内存管理，MMU也是Linux、Wince等操作系统的硬件要求。而控制器系统的芯片（面向低端控制领域，ARM7，MIPS M系列，80251等）一般都没有MMU，或者其只有单一的线性映射机制。
本文要谈的是控制器领域SoC的内存管理单元的硬件设计，其重要的理念同样是代码和数据分时复用物理内存空间，在保障系统功能和性能的基础上最大限度地节省物理内存的目的。相关的文章包括：SoC软件架构设计之一：系统内存需求评估和节省内存的软件设计技巧。
一、内存管理单元(MMU)的工作机制
在阐述控制器领域的内存管理之前，还是要先介绍处理器领域的虚拟内存管理机制，前者很大程度上是对后者核心机制精髓的借鉴。实现虚拟内存管理有几个模块是协调工作的：CPU、MMU、操作系统、物理内存，如图示（假设该芯片系列没有cache）：
我们根据上图来分析一下CPU访问内存的过程，假设寻址是0x10000008，一页大小为4K（12比特）。则虚拟地址会分成两个部分：页映射部分（20bit，0x10000）+页内偏移（12bit， 0x8）。CPU通过总线把地址信号（0x10000008）送给MMU，MMU会把该地址的页映射部分（20bit）拿到TLB中匹配。
TLB是什么东西？Translation Lookaside Buffer，网上有称为“翻译后备缓冲器”。这个翻译都不知道它干什么。它的作用就是页表的缓冲，我喜欢叫它为页表cache。其结构图如下：
可以想象，TLB就是索引地址数组，数组的每个元素就是一个索引结构，包含虚拟页地址和物理页地址。其在芯片内部表现为寄存器形式，一般寄存器都是32位，实际上TLB中的页地址也是32位寄存器，只不过索引比较时是比较前20bit，后12bit其实也是有用的，例如可以设置某个bit是表示常驻的，即该索引是永远有效的，不能更换，这种场景一般是为适合一些性能要求特别高的编解码算法而设计的。非常驻内存的一般在某个时刻（如TLB填满时访问一个新的页地址）就会发生置换。
1） 假如0x10000008的前20bit在TLB中第M个索引中命中，这时就表示该虚拟页在物理内存中已经给它分配好对应的物理内存，页表中也已经做好记录。至于虚拟地址对应的代码页是否从外存储（flash，card，硬盘）的程序中加载到内存中还需要要另外的标记，怎么标记呢？就是利用上面所讲的TLB低12位的某一bit（我们称为K）来标识，1标识代码数据已经加载到内存，0表示还没加载到内存。假如是1，那就会用M中的物理地址作为高20bit，以页内偏移0x8作为低12bit，形成一个物理地址，送到内存去访问。此时该次访问就会完成。
2） 假如K是0，那意味着代码数据尚未加载到内存，这时MMU会向中断管理模块输出信号，触发一个中断进行内核态，由操作系统负责将对应的代码页加载到内存。并修改对应页表项的K比特和TLB对应项的K比特为1.
3） 假如0x10000008的前20bit在TLB所有索引中都没有命中，则MMU也会向中断管理模块输出一个信号触发中断进入内核态，由操作系统将0x10000008右移12位（即除以4K）到页表中去取得对应的物理页值，假如物理页值非0有效，说明代码已经加载到内存了，这时将页表项的值填入到某一个空闲的TLB项中；假如物理页值为0，说明尚未给这个虚拟页分配实际的物理内存空间，这时会给它分配实际的物理内存，并写好页表的对应项（这时K是0），最后将这索引项写入TLB的其中一条。
2）和3）其实都是在中断内核态中完成的，为什么不一块做了呢？主要是因为一次中断不应该做太多事情，以加大中断延时，影响系统性能。当然如果有芯片将两者做成一个中断也是可以理解的。我们再来看看页表的结构。页表当然也可以按TLB那样做成索引数组，但是这样有两个不好的地方：
1）页表是要映射所有的虚拟页面的，其维护在内存中也需要不小的空间。页大小是4K时，那映射全部就是4G/4K=1M条索引，每条索引4*2=8个字节，就是8M内存。
2）假如按TLB那种结构，那匹配索引的过程就是一个for循环匹配电路，效率很低，要知道我们做这个都是在中断态完成的。
所以一般的页表都是设计成一维数组，即以整个线性虚拟地址空间按页为单位依次作为数组的下标，即页表的第一个字（4字节）就映射虚拟地址空间的最低4K，第二个字映射虚拟地址最低的第二个4K，以此类推，页表的第N个字就映射虚拟地址空间的第N个4K空间，即(N-1)*4K~4KN的地址空间。这样页表的大小就是1M*4=4M字节，而且匹配索引的时候只是一个偏移计算，非常快。
承前启后，在引出第二部分之前先明确两个概念：
1. Bank表示代码分块的意思，类似于上面提到的页的概念。
2．不同代码分时复用内存：不同代码即意味着不同的虚拟地址对应的代码，（程序链接后的地址都是虚拟地址），内存即物理内存，即一定大小的不同虚拟地址的代码在不同的时刻都跑在同一块一定大小的物理内存空间上。每一块不同的代码块即是不同的代码Bank。
二、控制器领域SoC内存管理单元的硬件设计
这里专指没有内存管理单元的SoC设计，一般为了降低成本，在性能足够时，如果16位或者24位字长CPU能够解决问题，一般都不会去选32位字长的CPU，除非是计算性能考虑，或者32位CPU的license更便宜（一般很少见）。只要能够达到高效地进行内存管理，实现物理内存分时复用的目的，那都可以称为是成功或者有效的。
有两种方法可以实现在MMU硬件单元的情况下实现代码分块管理：
1）利用工具链来实现内存分时复用的机制。
2）结合MMU和这个工具链实现的分块处理方法去设计我们新的内存管理单元，包括其硬件工作机制和软件设计和关键机制。
由于2）中的内容涉及到在审专利，暂时隐藏，后续再公开，抱歉！
在集成没有MMU的CPU时，SoC要实现内存管理，需要另外设计一个内存管理模块，实现MMU的核心功能，即代码分页（块）映射的功能，而且需要简化设计以达到最高的效率，同时代码分块需要直接地体现在链接脚本上。为了追求效率，编译链接后的可执行性文件还会被离线解析组织成一个更简化的执行文件，把不需要的段都删除，并将分块代码按逻辑顺序放好，以便于操作系统在必要时更快地加载。当然，操作系统的代码内存管理也需要配合内存管理硬件电路，并能够解析重新打包后的执行程序文件。因此内存管理的实现是需要架构师从软件和硬件上全面考虑，尽可能地在实现核心功能的基础上简化电路和设计，涉及的模块包括：硬件机制设计、物理内存分配、代码分块原则、linker脚本定义、打包执行文件、操作系统定制等等。