ARM的cache和mem零散记录(属性)

5.由于core改写了数据，就导致cache的一致性问题，怎么解决？什么时候解决？

6.是不是先通知其他core数据或指令被修改了，然后过一段时间数据才能更新？就是先发现数据更新了，等一段这个更新才能传过来

9.Instruction cache speculative memory accesses

什么是预测存取？对cache有什么影响？和指令的分支预测有什么关系？

0.相关博客推荐

深度学习arm cache系列--一篇就够了_刷cache机制-CSDN博客

1.arm的mem type

类型和属性都有什么含义 什么情况下使用，也就是每个属性是为了解决什么问题？

属性中non-execute是什么含义

1.1 axi中支持的cache attr

1.2 ARM A78AE cpu的cache mem attr

上面给出了L1 数据cache的TLB cacheline的结构

上图给出了L1 指令cache的TLB cacheline的结构

从上面两图可以看到，L1的指令或者数据对应的DDR空间属性其实是在TLB的cacheLine中存储的

1.3 Memory attributes和type

ARMV8定义了mem的type和属性【相关内容都可以在ArmV8的架构参考手册中找到】：

ARM把mem分为了两大类，分别是Device和Normal mem。简单理解Device就是外设的映射空间；Normal就是常见的DDR。

无论是Device还是normal mem都有两类共同的属性：

【直接理解mem的属性比较奇怪，应该是这段mem对应存储的数据在传输过程中的共享性和可缓存性】

• shareability(共享性和cache的一致性有关)
• Cacheability(缓存性和写ddr有关)

对于Device mem还有其特殊的属性：

• Gathering 或者non Gathering (G or nG)。这个特性表示对多个memory的访问是否可以合并，如果是nG，表示处理器必须严格按照代码中内存访问来进行，不能把两次访问合并成一次。例如：代码中有2次对同样的一个地址的读访问，那么处理器必须严格进行两次read transaction。
• Re-ordering (R or nR)。这个特性用来表示是否允许处理器对内存访问指令进行重排。nR表示必须严格执行program order。
• Early Write Acknowledgement (E or nE)。PE访问memory是有问有答的（更专业的术语叫做transaction），对于write而言，PE需要write ack操作以便确定完成一个write transaction。为了加快写的速度，系统的中间环节可能会设定一些write buffer。nE表示写操作的ack必须来自最终的目的地而不是中间的write buffer。

1.3.1 mem的Cacheability

cacheable属性是对某一个或某段内存地址空间数据的传输来讲的，non-cacheable就表示这段空间的数据在传输过程中是不能经过cache的，或者说它的数据是不会在任何cache上的。

device mem就属于这种类型的memory。那么这种类型的memory虽然不用考虑一致性问题，但是要考虑读写顺序问题。

cacheable的trans包括两种类型：

• write-back
• write-through

需要说明的是无论write-back还是write-through都有cache一致性问题。

1.3.2 mem的Shareability

首先需要明确的是 Shareability属性是指的某一内存地址是否可以被多个master访问。被多个master访问就存在一致性的问题。

在ARMv8中定义了三种Shareability domain

• Non-shareable：该domain只包含一个master；该段内存只给一个特定的核使用
• Inner Shareable：该domain包含了几个master；意味着Inner Shareable的内存只可以在此域共享
• Outer Shareable：该domain包含了Inner domain和其它master；意味着此内存可以被Inner Shareable和Outer Shareable域共享

这里的inner和outer的划分，是可以配置定义的。outer shareable domain可以包含多个inner domain。 而一个outer domian内的inner domian的内存空间是不能为outer所共享，但是outer domian的内存空间可以被内部的所有inner domain共享。

由上面Note第一条可知，device为non-cacheable，所以device mem都是outer shareable domian 

在同一个shareability domain内，数据是要保持一致性的。

ArmV8的架构参考手册DDI0487J_a_a-profile_architecture_reference_manual.pdf给出了Inner和Outer Shareable Normal memory定义：

仔细对比上面两段话就可以发现inner和outer只是一个区域划分的问题，对于domian内部的observers来说要求是一样的。

1.3.3 device memory的特殊属性

简单提一下device mem的定义: 

上面的定义说Device memory是不能被推测性的读。是把被外设内存映射的区域赋为Device memory的属性。

上面的memory locations翻译为mem区域更好理解一些。就是说device类型的mem，它的读写是与读写命令次数以及读写命令顺序相关的，所以定义了以下的属性：

• Gathering 或者non Gathering (G or nG)。这个特性表示对多个memory的访问是否可以合并，如果是nG，表示处理器必须严格按照代码中内存访问来进行，不能把两次访问合并成一次。例如：代码中有2次对同样的一个地址的读访问，那么处理器必须严格进行两次read transaction。
• Re-ordering (R or nR)。这个特性用来表示是否允许处理器对内存访问指令进行重排。nR表示必须严格执行program order。
• Early Write Acknowledgement (E or nE)。PE访问memory是有问有答的（更专业的术语叫做transaction），对于write而言，PE需要write ack操作以便确定完成一个write transaction。为了加快写的速度，系统的中间环节可能会设定一些write buffer。nE表示写操作的ack必须来自最终的目的地而不是中间的write buffer。

对于gather，有的device先后两个读同一个地址，得到的数据可能是不一样的，这种情况下就不能gather两次读操作。比如read clear, read inc addr(读同一个寄存器，实际会递增的去访问某一块memory)

从1.1节和1.2节的截图中可以看到AXI和A78 cpu支持的device memory属性组合有下面4种：

000： Device nGnRnE

001： Device nGnRE

010： Device nGRE

011： Device GRE

2.写cache及回写模式

1.cpu为什么会有写cache

在core运行过程中，很容易会出现将某个地址的数据改写掉，在写回原地址的情况，此时就涉及到d-cache的cache line修改。

2.cpu会不会写icache？会不会改写指令？什么情况下改写指令，要不要同步(一致性问题)

cpu会改写指令，但不是直接修改icache，可参考第8节内容

3.写cache都有哪些模式？

内存的数据被加载到Cache后，在某个时刻其要被写回内存，写内存有如下5种策略：写通（write-through）、写回（write-back）、写一次（write-once）、WC（write-combining）和UC（uncacheable）

参考文章：

arm cpu cache写策略-CSDN博客

3.读改写与narrow和数据位宽

3.1节的讨论 我们做一个限定 即只有一个master和一个slave。保证master和slave看到的数据位宽都是一致的，否则master端的narrow到了slave端可能就是一个

3.1读改写和narrow

armV8的cache line是64Byte，但是core实际使用数据和指令的最小单位是byte，所以如果修改的某一byte数据要回写DDR的时候，但是cache miss了，就有两种处理方式：

• 将包含该数据地址的cache line 读到cache中，修改了该cache line之后，再在适当的时间回写到DDR----对应write back
• 将该byte数据用narrow写的方式 直接写到DDR----对应write through

第一种情况需要先读cache line，存在一个读改写的过程

有下面几个问题

1.第二种情况是怎么处理的？

2.总线的读改写和哪些因素有关？

3.总线narrow就一定不能直接写DDR吗？和DDR的数据位宽有没有关系？

对于narrow写，AXI协议和NOC总线本身是不会对narrow写trans做处理的，所以到了DDR subsys，就需要DDR controller来处理，DDRC有两种处理方法：

• DDR支持mask写
• DDRC采用读改写方式

读改写在DDR端来看，根本原因就是要写的数据和DDR的数据位宽不匹配，在数据trans上就体现为两点：

• 写trans数据和地址不对齐，到了DDR端就需要拆分trans，并用到mask写或者读改写
• 写trans数据位宽比DDR数据位宽窄，narrow写

回到上面的几个问题，

第一个问题第二种情况(narrow写+write through)就是使用DDR的mask写或者DDRC的读改写。

第二个问题严格来说总线是不支持读改写的，读改写的操作都是在master【cpu cache】或者slave端【DDR】做的。

第三个问题就是narrow的数据可以直接写到DDR，通过DDR mask写或DDRC读改写可以解决问题。【这里假定narrow的数据位宽是小于DDR的数据位宽】

如果DDR的mask写和读改写过多  都会对DDR性能产生较大的影响，要避免这种情况的出现，所以在master端会做一些处理，比如d-cache的write back模式，在DDRC之前添加LLC等模块对trans进行整理。

3.2在谈trans地址对齐和数据位宽

AXI和NOC的最大数据位宽不一定要比slave的数据位宽窄。

比如做一个假设，只有一个master，一个slave，把AXI和NOC的数据位宽做宽一点，那么用大位宽的link传输数据肯定比小位宽占用的时间短，那么当有多个master时，这个大位宽的master就可以把总线空出来给别的master使用。这样做的代价当然是在slave口要有buff来做带宽匹配。

在soc的noc总线上会接不同的数据位宽的AXI总线，最终是不是都统一到了DDR的数据位宽？

对于只有一个DDR作为slave的系统，肯定所有的不同位宽的AXI数据最终都转成了DDR的数据位宽。但实际系统中往往有多个带宽不同的slave，这些slave的位宽各不相同，所以router之间的link上数据位宽可能都不一样。NOC上每个master和slave的位宽都是灵活可配的，以满足不同的性能需求。而不同的数据位宽的转换只有两种方式：

• 使用narrow写----只对写trans有效
• 使用trans合并和分解

对于读DDR的trans，如果出现master对数据的需求小于总线位宽或者基地址不对齐总线位宽的情况，由于AXI没有narrow读的特性，且AXI和NOC都不支持地址不对齐的trans，所以DDR应该是没有mask读的，这时候就只能靠master测自己处理，多读数据或者拆分、合并trans。

对于写DDR的trans，如果master对数据的需求小于总线位宽，可以发送narrow trans；如果出现基地址不对齐总线位宽，AXI总线和NOC是不支持的，即使DDR支持mask写也没用，只能在master测上总线之前处理掉。实际上narrow trans主要还是靠读改写来处理，很多DDR已经不在支持mask写了。

7.cache的歧义和别名

cache的歧义和别名是什么东西？会造成什么影响？

歧义：一个虚拟地址先后指向两个（或者多个）物理地址

别名：两个（或者多个）虚拟地址同时指向一个物理地址

对于cpu来说物理地址是唯一的，如果用物理地址作为i-cache/d-cache的index和tag，必然不会出现歧义和别名的问题。

只有查找i/d-cache的index和tag出现了虚拟地址的情况才会有歧义和别名出现。

由12节的描述可知，对于i/d-cache有三种查找cache line的方式，VIVT(虚拟index和虚拟tag)的方式全部使用虚拟地址。发生歧义和别名的情况分别如下：

歧义发生：两个进程的某一相同虚拟机地址指向了不同的物理地址，进程A运行时CPU把此虚拟地址加载到了Cacheline中，进程B运行时，CPU在Cache中查找此地址时会发现Cache hit，从而加载了错误的物理地址内存。

别名发生：在2个虚拟地址对应同一个物理地址时，对于index和tag，2个虚拟地址虽然不同，但是属于同一物理地址读回来的数据，那么一旦出现其中一个cacheline的数据被修改了，另一个cacheline的数据由于虚拟地址不同【尽管他们的物理地址一样，但是物理地址在cache比对中完全不掺和】而无法同步修改就会出现不一致的问题。

7.1 TLB与id-cache在歧义与别名的区别

处理区别见第12节

8.icache有没有歧义和别名的问题？icache和dcache的一致性是什么？

icache一般是只读cache，所以即使有多个虚拟地址指向一个物理地址也就是别名的情况，也不会发生错误，因为两个cache line看到的是相同的内容

icache和dcache的一致性和cpu core改写指令有关，由于i-cache是只读cache，当core改写了指令的时候，做了以下处理：

1. 将需要修改的指令数据加载到dCache中【从内存加载还是从icache加载？更偏向于从内存，icache和dcache不做直接的通路】
2. 修改成新指令，写回dCache。

那么就会面临2个问题：

1. 如果旧指令已经缓存在iCache中。那么对于程序执行来说依然会命中iCache。这不是我们想要的结果。
2. 如果旧指令没有缓存iCache，那么指令会从主存中缓存到iCache中。如果dCache使用的是写回策略，那么新指令依然缓存在dCache中。这种情况也不是我们想要的。

解决这两个问题可以从软件和硬件两个方面，这里不在详细说明，请参考本人转载的文章：

iCache和dCache的一致性及指令改写-CSDN博客

10.什么是write streaming mode

10.1 问题和解答

1. 读写allocated是什么？

见10.2节描述

2. write streaming mode时 读还会allocated吗？

此时为什么还有读？是因为write miss的原因吗？

在写数据的时候，如果cache miss，而且写的是整个cache line，我认为此时是不需要读cache line的，如果写cache line的一部分，而且是采用write back的回写模式，这个时候只能先把miss的整个cache line读回来，改写其中一部分byte，然后在写入到内存。这个过程就有读allocate的过程

并不是改写cache line的一部分byte时，一定要先读到cache，AXI的narrow 写也可以完成，比如cache回写ddr采用write through。

只是write through性能太低，用的比较少。都用write back模式，先读cacheline进来

10.2 write streaming mode

一般core的d-cache都是write allocated和read allocated，意思就是当读写d-cache的时候如果cache miss，那么就会将物理内存中的这段数据缓存到cache中，也就是在cache中分配一个cache line。

至于i-cache，一般情况下，core没有改写指令的需求，所以i-cache一般设置为只读cache，但特殊情况下也有改写指令的情况，这种情况i-cache还是只读，但会用到d-cache暂存指令。

所以这里讲的write streaming mode主要是d-cache。从字面意思可以看出既然是写数据流，那么数据量就比较大，比如执行memset(ptr,0,len) 操作，core需要将很大一段内存空间写为0，此时如果按照正常的处理流程，必然会导致d-cache 不停的读取cache line，然后把数据改为0，然后在回写到对应内存中【不停读写的原因在于memset的空间太大，必然导致这些空间不在cache中】。

这种情况使cache中充满了没有太多意义的为0的cache line，同时还浪费功耗和性能，所以armV8开始就有了write streaming mode。【目前来看只有L1有WSM】在这种模式下，不需要在写入miss时分配新的cache line。

那么就需要cache模块能够检测出write streaming mode，目前的检测条件如下：

• core要写入大量的完整的高速缓存行要写入

如果L1检测到连续写入超过配置阈值的完整cache line，则切换到write streaming mode。

当处于WSM时，

read操作和正常情况相同，任然进行cache line的allocate和fill

write这边也会在cache中查找，但如果miss了，不会在L1 cache中allocate和fill，只会将数据写到L2，或者L3，system cache或DRAM【为什么不是直接写到DRAM，我理解可能和当前配置的写内存的方式有关：

写通（write-through）、写回（write-back）、写一次（write-once）、WC（write-combining）和UC（uncacheable）】

L1退出WSM的条件如下：

• 没有完整的写入cache line
• cache的命中率很高

参考：

memset会导致一大块内存进cache吗_memset函数会消耗系统内存吗-CSDN博客

11.arm cache替换策略与inclusive/exclusive

11.1问题

L1 cache的数据一定在L2 cache中吗？它们数据有没有重复？

在miss的时候，是对L1和L2同时更新吗？

core会直接访问L2 cache吗？

从11.2节的解释，是不会直接从L2拿数据的，都是先放到L1里面

这里涉及cache之间的Cache inclusion policy，包括inclusive和exclusive以及non-inclusive non-exclusive.这个同时和替换策略有关.下面的文字就解释了上面的问题

11.2 答案

多级cache的替换策略设计有很多种方式，可以根据一个cache的内容，是否同时存在于其他级cache来分类，即Cache inclusion policy。如果低级别cache中的所有cache line，也存在于较高级别cache中，则称高级别cache包含（inclusive）低级别cache。如果高级别的cache，仅包含低级别cache不存在的cache line，则称高级别的cache不包含（exclusive）较低级别的cache。如果高级cache的内容，既不严格包含，也不排除低级cache，则称为非包含非排他（non-inclusive non-exclusive，NINE）cache。

Inclusive Policy cache：CPU对数据A进行读取操作时，若A在L1 cache中找到，则从L1 cache中读取数据，并返回给CPU。若A未在L1 cache中找到，但存在L2 cache中，则从L2 cache中提取该数据所在cache line，并将其填充到L1中。若一个cache line从L1 cache中被逐出，则L2 cache不做操作。若在L1或L2中均未找到想要的数据，则从L3中寻找，找到后会填充到L2、L1，若未在L3中找到，则从DDR中以cache line为单位取出该数据，并将其填充到L1、L2、L3中。若有来自L2的逐出，L2会向L1发送invalidation，以便遵循“Inclusive Policy”。

为了保持inclusion，需要满足：

• 无论set的数量多少，L2 way的数量都必须大于或等于 L1 way的数量。
• 无论 L2 way的数量多少，L2 set的数量必须大于或等于 L1 set的数量。

Exclusive Policy cache：CPU对数据A进行读取操作时，若A在L1中找到，则从 L1 中读取数据并返回给CPU。若未在L1中找到，但存在L2中，则将该A数据所在的cache line从L2移动到L1。若一个cache line从L1中被逐出，则被逐出的cache line将被放置到L2中。这是L2 填充的唯一方式。若在L1、L2中都未找到A数据，则将其从L3中取出，并填充到L1，若在L3中也未找到，则在主存中取出，并填充到L1中。

NINE（non-inclusive non-exclusive）Policy：CPU对数据A进行读取操作时，若A在L1中找到，则从L1中读取数据并返回给CPU。若在L1中未找到，但存在L2中，则从L2中提取（复制）该数据对应的cache line，并放置到L1中。若一个cache line从L1中被逐出，则L2不做操作，这与inclusive policy相同。若在L1、L2中都没找到该A数据，则从L3中查找，若L3中找到该数据，将该数据所在cache line取出，并填充到L1、L2，若L3中没找到，从主存中取出该数据对应的cache line，填充到L1、L2、L3。

三种数据关系策略的比较：

• inclusive policy的优点：在每个处理器都有私有cache 时，如果存在cache miss，则检查其他处理器私有cache，以查找该cache line。如果L2 cache包含L1 cache，并且在L1 cache中miss，则不需要再大面积搜索L2 cache。这意味着与exclusive cache和 NINE cache相比，inclusive cache的miss 延迟更短。
• inclusive policy的缺点：cache的内存容量由L3 cache决定的。exclusive cache的容量是层次结构中，所有cache的总容量。如果L3 cache较小，则在inclusive cache中浪费的cache容量更多。
• 尽管exclusive cache具有更多的内存容量，但相比NINE cache，它需要占用更多的带宽，因为L1 cache 逐出时，会将逐出数据填充到L2、L3 cache。

11.3 参考资料

一文搞懂cpu cache工作原理 - 知乎

11.2节的答案就摘自该篇文章，该文章主要讲述了以下内容

12.TLB 和i/d-cache寻址方式和区别

12.1 TLB寻址方式

TLB cacheline是虚拟地址(index+tag)+物理地址+ASID+VMID+nG+其他属性。用不用多级页表，TLB的cache line结构都不会变化。多级页表只和TTW(PTW) translation table walk有关，和TLB本身没有关系。就像有没有目录，书本的内容不会改变一样。举个例子：4K的页大小，4GB存储空间，4way的32set的TLB，物理地址32bit有效。其中[11:0]为page offset，不在cacheline中，也不参与TLB寻址。用index来区分set，用tag来区分set内哪一way。则VA[16:12]用来做index，VA[31:17]用来做tag。

为什么用VA[16:12]这5个中间的bit来做index？原因在于有32个set，和5bit一一对应，所以set的可以直接用index索引，而不用全比对；另外由于程序的局部性原理，页表也具有连续性，用VA[16:12]可以把连续的页表分在不同的set，更能充分利用TLB，否则用VA[31:27]做index，那么大部分情况下有效cacheline都会在一个set内，造成其他set浪费。

VA[31:17]用来做tag，明显比4way多了很多bit，所以只能对tag在set内进行全比对。

所以可以得到如下结论：

1. TLB寻址需要除了page offset之外的所有虚拟地址位
2. index使用寻址的虚拟地址的低位，且位宽和set数一一对应
3. 去除1，2两步的地址之后，剩余的全部为tag地址，用作set内全比对
4. 以上三段地址没有相互覆盖和断层

TLB的index+tag只能是由虚拟地址得到，那么按照第7节的介绍肯定会出现歧义和别名的问题，而TLB采用了另外分配ASID+VMID的方式解决了歧义和别名的问题。

另外在TTW中，也会用虚拟地址分段作为各级页表内的index，过程不在这里描述，可以参考：

内存管理(mmu)/内存分配原理/多级页表-CSDN博客

的3.1节描述。

12.2 i/d-cache寻址方式

i/d-cache的cacheline包含：index+tag+数据/指令+其他

首先设TLB将虚拟地址分为VA={VA_TLB,page Offset}

设有64K的d-cache，4way，每个cacheline的有效数据为64B，则可以知道一共有256set。256set的一对一索引需要8bit index，64B数据按byte索引需要6bit offset，对于32bit的地址VA[31:0],tag至少需要18bit.

对于给定的cache大小，和way数，index和byte索引offset需要的位宽为ib_w=cacheSize/(way nums)，这两类位宽就是取VA[ib_w-1:0]。这里面index和12.1节的TLB index一样只能选择与byte offset相连的VA低位地址。剩下的VA[31:ib_w]就是tag的地址。

经过第7节的分析可知，这种寻址方式一定是有别名和歧义的问题出现。而因为有MMU的存在，i/d-cache是可以用PA做i/d-cache的查询地址。所以就有了3种查询方式：

VIVT：虚拟index+虚拟tag

VIPT：虚拟index+物理tag

PIPT：物理index+物理tag

显然上文给的例子就是VIVT，VIVT会有歧义和别名的问题；如果是PIPT，index和tag以及offset和上文说的VIVT情况类似，但由于物理地址的唯一性，就不会出现歧义和别名的问题。对于VIPT情况要复杂一些，下面做详细介绍。

设页大小为4K，d-cache为16K，4way，64B有效数据，则page offset为VA[11:0]=PA[11:0]，ib_w=16K/4=4K，所以{d_index, byte_offset} = VA[11:0] = PA[11:0]，可以发现这种情况下d_index虽然是虚拟index，但是和物理index值一致，所以就不存在歧义和别名。

假设d-cache为64K，则{d_index, byte_offset}=VA[13:0]={VA[13:12], PA[11:0]},d_index={VA[13:12], PA[11:6]}。此时则会出现别名的问题，比如两个虚拟地址：

xxxx_xxxx_xxxx_xxxx_xx00_xxxx_xxxx_xxxx

xxxx_xxxx_xxxx_xxxx_xx01_xxxx_xxxx_xxxx

都被映射到同一个物理地址，但是由于d-index不同，在d-cache中是不同的cache line，就造成了别名的问题。

在说VIPT的歧义问题之前，先说一下i/d-cache的tag，将[ib_w:0]之外的地址段作为tag，是tag的最低要求，但是如果用更多位做tag，由于tag是全比对的，必然也没有问题。

那么如果VIPT用PA[31:ib_w]作为tag，是会出现歧义的。比如两个不同进程的相同VA映射后VA_0=VA_1,PA_0[31:ib_w] = PA_1[31:ib_w], PA_0[ib_w-1:0] != PA_1[ib_w-1:0]，则此时由于index_0=index_1,tag_0=tag_1, 出现了两个不同的物理地址落到了同一个cache line,所以有歧义出现。但是如果将tag扩位，用byte offset之外的所有PA做tag，就不会出现歧义的问题。

个别的参考博客认为只要是VIPT就没有歧义出现，我认为是不正确的，虽然PA不同不能说明tag一定不同。参考博客连接如下：

图解 | CPU-Cache | 歧义别名 - 知乎

经过上面的分析之后我们还可以得到一个结论：

TLB的地址分段(VA_TLB,page offset)和i/d-cache的地址分段(index,tag,byteOffset)没有什么必然的关系文章来源地址https://www.toymoban.com/news/detail-839593.html

到了这里，关于ARM的cache和mem零散记录(属性)的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！