作者简介
baron (网名:代码改变世界ctw)，九年手机安全/SOC底层安全开发经验。擅长trustzone/tee安全产品的设计和开发

1. cache是多级相连的

cache是多级的，在一个系统中你可能会看到L1、L2、L3, 当然越靠近core就越小，也是越昂贵。一般来说，对于 big.LITTLE架构中，在L1是core中，L1又分为L1 data cache和 L1 Instruction cache， L2 cache在cluster中，L3则在BUS总线上。

2. cache一般是和MMU结合在一起使用的

很多时候cache都是和MMU一起使用的(即同时开启或同时关闭)，因为MMU页表的entry的属性中控制着内存权限和cache缓存策略等

在ARM架构中，L1 cache都是VIPT的，也就是当有一个虚拟地址送进来，MMU在开始进行地址翻译的时候，Virtual Index就可以去L1 cache中查询了，MMU查询和L1 cache的index查询是同时进行的。如果L1 Miss了，则再去查询L2，L2还找不到则再去查询L3。注意在arm架构中，仅仅L1 cache是VIPT，L1L2和L3都是PIPT。

3. 硬件架构基础介绍

big.LITTLE架构 和 DynamIQ架构 的cache是有区别的

在 big.LITTLE 架构中，大核小核在不同的cluster中，做为两个不同的ACE或CHI Master，连接到缓存一致性总线上(CCI或CMN)。大核cluster和小核cluster的缓存一致性，也需要通过一致性总线来解决。

到了 DynamIQ 架构中，大核和小核都是一个DSU cluster中，一个DSU cluster最多可以支持8个core。如果你的系统是8个core，那么一个DSU就够了，那么系统中也就只有一个ACE或CHI Master，大核和小核之间的一致性，都在DSU cluster内完成了。

3.1 big.LITTLE架构的cache

在 big.LITTLE的架构中，L1是在core中的，是core私有的；L2是在cluster中的，对cluster中的core是共享的；L3则对所有cluster共享。big.LITTLE的架构的一个cache层级关系图如下所示：

3.2 DynamIQ架构架构的cache

在 dynamIQ的架构中，L1和L2都在core中的，都是core私有的；L3则是在cluster中的，对cluster中的core是共享的；如有L3或system cache，则是所有cluster共享。dynamIQ的架构的一个cache层级关系图如下所示。注意，一般来说一个DSU Cluster就可以做到支持8个core，以下只是举一个极端的例子，在硬件设计时，我非要放置两个DSU cluster 可不可以？两个DSU Cluster做为两个ACE Master连接到了CCI一致性总线上。

3.3 缓存一致性总线-CCI

用于ACE Master缓存一致性总线有 CCI-550、 CCI-500、 CCI-400。

它的主要作用是可以互联多个 ACEMaster、 ACE-liteMaster，然后通过ACE接口协议，做到多个Master之间的缓存一致性。CCI最多支持2个 ACEMaster，共计支持8个 ACEMaster+ ACE-liteMaster。所以呢，如果是 big.LITTLE架构的，那么最多支持两个cluster互联，每个cluster 8个core，所以最多支持8个core；如果是 dynamIQ架构的，那么最多支持两个DSU cluster互联，每个cluster 8个core，所以最多支持16个core

3.4 缓存一致性总线-CMN

用于CHI Master缓存一致性总线有 CMN-700、 CMN-600.

它的主要作用是可以互联多个 CHIMaster、 ACE-liteMaster，然后通过CHI接口协议，做到多个Master之间的缓存一致性。CCI-600最多支持8个 CHIMaster，共计支持8个 CHIMaster+ ACE-liteMaster。

3.5 big.LITTLE架构中的cluster interface

在 big.LITTLE架构中，cluster连接到一致性总线的接口，可以是ACE，也可以是CHI，所以big.LITTLE cluster既可以做为ACE Master连接到总线，也可以做为CHI Master连接到总线。

3.6 dynamIQ架构中的DSU interface

2017年引入dynamIQ架构， 在DSU(dynamIQ Share Unit)规范中，连接到一致性总线的接口，可以是ACE，也可以是CHI，所以DSU cluster既可以做为ACE Master连接到总线，也可以做为CHI Master连接到总线。

而在DSU-110中， 连接到一致性总线的接口可以是CHI ,但不再有ACE了。如果你使用的是DSU-110，DSU Cluster做为CHI Master了，那么你一定是采用CMN的总线互联方式。

3.7 架构图示例

所以呢，你看到的系统架构图(也是近几年最常用的)，可能是下面这个样子的，所有的core都在一个DSU cluster中，所有core共享L3 cache，DSU接到CCI或CMN缓存互联一致性总线上，可以和其它ACE-Lite Master(如 GPU)共享缓存数据

当然了，举个稍微极端的例子，如下连接架构图也不是不可能，系统中有两个DSU cluster，DSU接到CCI或CMN缓存互联一致性总线上。

事实上big.LITTLE架构的cluster，也是可以做为CHI Master。下面这种超极端的例子，技术理论上也是可行的(当然可能不会有人用)。

4. L1/L2/L3 cache的大小

可以参考ARM文档，

对于 big.LITTLE架构的core，其cache大小基本是固定的。

对于 dynamIQ架构的core，其L1和L2 cache大小基本是固定的。但对于L2 cache 则是可选择可配置的

另外查阅DSU TRM文档，可以看到L3 Cache可以配置 0 - 16MB的大小。

5. cache的组织形式（index, way, set）

cache的组织形式有：

全相连
直接相连
多路组相连（如4路组相连）

在一个core中一个架构中一个SOC中，所有cache的组织形式并不是都一样的。即使L1 D-cache和L1 I-cache的组织形式，也都可能不是一样的的。具体的组织形式是怎样的，需要查询你的core trm手册。

例如我们查询到Cortex-A53的cache信息如下：

L1 I-Cache

可配:8KB, 16KB, 32KB, or 64KB

cacheline:64bytes

2路组相连

128-bit的读L2 memory的接口

L1 D-Cache

可配:8KB, 16KB, 32KB, or 64KB

cacheline:64bytes

4路组相连

256-bit的写L2 memory的接口

128-bit的读L2 memory的接口

64-bit的读L1到datapath

128-bit的写datapath到L1

L2 cache

可配置的: 128KB, 256KB, 512KB, 1MB and 2MB.

cacheline:64bytes

Physically indexed and tagged cache（PIPT）

16路组相连的结构

因为有了多路组相连这个cache，所以也就有了一些术语概念：

index ：用白话理解，其实就是在一块cache中，一行一行的编号(事实是没有编号/地址的)
Set ：用index查询到的cache line可能是多个，这些index值一样的cacheline称之为一个set
way：用白话来说，将cache分成了多个块（多路），每一块是一个way
cache TAG ：查询到了一行cache后，cachelne由 TAG + DATA组成
cache Data ：查询到了一行cache后，cachelne由 TAG + DATA组成
cache Line 和 entry 是一个概念

6. cache的种类（VIVT, PIPT, VIPT）

cache一般是有如下种类；

• PIPT
• VIVT
• VIPT

在一个core中一个架构中一个SOC中，你所使用的cache是哪种类型的，都是固定的，是软件改不了的。 在ARM架构中，一般L1 cache都是VIPT的，其余的都是PIPT的。VIPT和PIPT的原理，基本也都是一样的，只是硬件查询时稍微有一丁点的区别，在后续讲cache查询时会再次介绍。

那么，你还学什么VIVT？你为什么还要去理解VIVT的原理？你为什么还要去分析cache同名、重名的问题？这样的问题，在armv7/armv8/armv9架构中都是不存在的

7. cache的分配策略

读分配(read allocation) 当CPU读数据时，发生cache缺失，这种情况下都会分配一个cache line缓存从主存读取的数据。默认情况下，cache都支持读分配。

写分配(write allocation) 当CPU写数据发生cache缺失时，才会考虑写分配策略。当我们不支持写分配的情况下，写指令只会更新主存数据，然后就结束了。当支持写分配的时候，我们首先从主存中加载数据到cache line中（相当于先做个读分配动作），然后会更新cache line中的数据。

写直通(write through) 当CPU执行store指令并在cache命中时，我们更新cache中的数据并且更新主存中的数据。cache和主存的数据始终保持一致。

写回(write back) 当CPU执行store指令并在cache命中时，我们只更新cache中的数据。并且每个cache line中会有一个bit位记录数据是否被修改过，称之为dirty bit（翻翻前面的图片，cache line旁边有一个D就是dirty bit）。我们会将dirty bit置位。主存中的数据只会在cache line被替换或者显示的clean操作时更新。因此，主存中的数据可能是未修改的数据，而修改的数据躺在cache中。cache和主存的数据可能不一致

8. 架构中定义cache的范围

对于cacheable属性，inner和outer描述的是cache的定义或分类。比如把L1/L2看做是inner cache，把L3看做是outer cache。

通常，内部集成的cache属于inner cache，外部总线AMBA上的cache属于outer cache。例如:

对于big.LITTLE架构（A53为例)中，L1/L2属于inner cache，如果SOC上挂了L3的话，则其属于outer cache

对于DynamIQ架构（A76为例)中，L1/L2/L3属于inner cache，如果SOC上挂了System cache（或其它名称）的话，则其属于outer cache

然后我们可以对每类cache进行单独是属性配置，例如：

配置 inner Non-cacheable 、配置 inner Write-Through Cacheable 、配置 inner Write-back Cacheable

配置 outer Non-cacheable 、配置 outer Write-Through Cacheable 、配置 outer Write-back Cacheable

对于shareable属性，inner和outer描述的是cache的范围。比如inner是指L1/L2范围内的cache，outer是指L1/L2/L3范围内的cache

9. 架构中内存的类型

在arm架构中，将物理内存分成了device和normal两种类型

而是每种的内存下(device和normal)又分出了多种属性。ARM提供一个 MAIR寄存器, 将一个64位的寄存器分成8个attr属性域，每个attr属性域有8个比特，可配置成不同的内存属性。也就是说，在一个arm core，最多支持8中物理内存类型。

而我们在MMU使用的页表的entry中的属性位中，BIT[4:2]占3个比特，表示index，其实就是指向MAIR寄存器中的attr。（Attribute fields in stage 1 VMSAv8-64 Block and Page descriptors）

PBHA, bits[62:59] ：for FEAT_HPDS2

XN or UXN, bit[54] ：Execute-never or Unprivileged execute-never

PXN, bit[53] ：Privileged execute-never

Contiguous, bit[52] ：translation table entry 是连续的，可以存在一个TLB Entry中

DBM, bit[51] ：Dirty Bit Modifier

GP, bit[50] ：for FEAT_BTI

nT, bit[16] ：for FEAT_BBM

nG, bit[11] ：缓存在TLB中的翻译是否使用ASID标识

AF, bit[10] ：Access flag, AF=0后，第一次访问该页面时，会将该标志置为1. 即暗示第一次访问

SH, bits[9:8] ：shareable属性

AP[2:1], bits[7:6] ：Data Access Permissions bits,

NS, bit[5] ：Non-secure bit

AttrIndx[2:0], bits[4:2]

也就是说，页表的每一个entry中，都指向MAIR寄存器中的一个属性域。也就是页表的每一个entry都配置了一种内存类型。如下所示，便很好的展示了，MMU页表的每一个page descriptor(也叫entry)都指向一个内存属性类型。

10. cache的查询原理

高速缓存控制器(cache controller )是负责管理高速缓存内存的硬件块，其方式对程序来说在很大程度上是不可见的。它自动将代码或数据从主存写入缓存。它从core接收读取和写入内存请求，并对高速缓存或外部存储器执行必要的操作。

当它收到来自core的请求时，它必须检查是否能在缓存中找到所请求的地址。这称为缓存查找(cache look-up)。它通过将请求的地址位的subset(index)与与缓存中的physical TAG 进行比较来做到这一点。如果存在匹配，称为命中(hit)，并且该行被标记为有效，则使用高速缓存进行读取或写入。

当core从特定地址请求指令或数据，但与缓存标签不匹配或标签无效时，会导致缓存未命中，请求必须传递到内存层次结构的下一层，即 L2缓存或外部存储器。它还可能导致缓存行填充。缓存行填充会导致将一块主内存的内容复制到缓存中。同时，请求的数据或指令被流式传输到core。这个过程软件开发人员不能直接看到。在使用数据之前，core不需要等待 linefill 完成。高速缓存控制器通常首先访问高速缓存行内的关键字。例如，如果您执行的加载指令在缓存中未命中并触发缓存行填充，则内核首先检索缓存行中包含所请求数据的那部分。这些关键数据被提供给core流水线，而缓存硬件和外部总线接口随后在后台读取缓存线的其余部分。

总结一下就是：先使用index去查询cache，然后再比较TAG，比较TAG之后再检查valid标志位。但是这里要注意：TAG包含了不仅仅是物理地址，还有很多其它的东西，如NS比特位等，这些都是在比较TAG的时候完成。

11. cache的查询示例

假设一个4路相连的cache（如cortex-A710），大小64KB, cache line = 64bytes，那么 1 way = 16KB，indexs = 16KB / 64bytes = 256 (注: 0x4000 = 16KB、0x40 = 64 bytes)

0x*4000 -- index 0
0x4040 -- index 1
0x4080 -- index 2
......
0x*7fc0 -- index 255

0x*8000 -- index 0
0x8040 -- index 1
0x8080 -- index 2
......
0x*bfc0 -- index 255

细心的同学可以发现，这里就有了一个很大的问题，你用于cache look-up的index是vaddr[15:6]， 如果granue size是4KB，那么vaddr[11:0] = paddrr[11:0] ， 但是vaddr[15:12]比特并不等于paddrr[15：12] ，那么你这样的index查询的cache有效吗？会不会发生同名、歧义 ?

其实大可不必担心，因为对于每个core，L1是VIPT的，其实它们的L1 Cache TAG中，已经规定了physical address[39:12]，正好是到BIT12。所以只要TAG比较之后，就不会出现同名和歧义。