A53 cache的架构解读

2024-04-04 14:44
文章标签 解读 架构 cache a53

本文主要是介绍A53 cache的架构解读,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

快速链接:

  • 【精选】ARMv8/ARMv9架构入门到精通-[目录] 👈👈👈

引流关键词:缓存,高速缓存,cache, CCI,CMN,CCI-550,CCI-500,DSU,SCU,L1,L2,L3,system cache, Non-cacheable,Cacheable, non-shareable,inner-shareable,outer-shareable, optee、ATF、TF-A、Trustzone、optee3.14、MMU、VMSA、cache、TLB、arm、armv8、armv9、TEE、安全、内存管理、页表…

快速链接:
.
👉👉👉 个人博客笔记导读目录(全部) 👈👈👈

  • ARMv8/ARMv9架构精选系列–目录 👈👈👈
  • ARMV8/ARMV9/Trustzone/TEE安全课程👈👈👈

目录

        • 1. A53使用经典的 `bit-LITTLE`架构
        • 2. A53的cache配置
        • 3. cache的层级结构:
        • 4. L2 memory System系统介绍
        • 5. 多cluster之间的缓存一致性
        • 6. CCI的介绍(以CCI-550为例)
        • 7. 经典示例框图

1. A53使用经典的 bit-LITTLE架构

以下是一张比较早期的经典的bit-LITTLE的架构图
在这里插入图片描述
在这里插入图片描述

2. 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 memory System

  • 集成了SCU( Snoop Control Unit ),做多可以连接4个core
  • SCU内重复拷贝了 L1 Data Cache的TAGs
  • L2 memory system对外的接口,可以是ACE 或 CHI,128-bit宽度

L2 cache

  • 可配置的: 128KB, 256KB, 512KB, 1MB and 2MB.
  • cacheline:64bytes
  • Physically indexed and tagged cache(PIPT)
  • 16路组相连的结构

L1 data cache TAG
A53的L1 Data cache遵从的是MOESI协议,如下所示在L1 data cache的tag中存有MOESI的标记位
在这里插入图片描述
MOESI state
在这里插入图片描述

L1 Instruction cache TAG
L1 instruction cache是只读的,所以也就无需硬件维护的多core之间instruction cache的一致性,所以也就无需组从MOESI协议,以下展示了*L1 Instruction cache的TAG,其中标记为很少,无MESI标记位。
在这里插入图片描述

3. cache的层级结构:
  • L1 cache是private的在core中
  • L2 cache是share的在cluster中

在这里插入图片描述

4. L2 memory System系统介绍

bit.LITTLE架构中中,在Cluster中,有一个SCU单元,SCU单元主要是执行和维护L1 cache的一致性(MESI协议 或 其变体如MOESI协议)。
在这里插入图片描述
在L2 Memory System的中,除了包含L2 cache,也会包含L1 Duplicate tag RAM(这里指的其实是L1 Data Cache Tags)。
在这里插入图片描述

5. 多cluster之间的缓存一致性

cluster和外界的接口,可以是ACE或CHI(目前常用的是ACE,后面的趋势可能是CHI)

在这里插入图片描述

  • 如果使用的是ACE,那么多cluster之间的一致性,依靠CCI + ACE 来维护
  • 如果使用的是CHI,那么多cluster之间的一致性,依靠CMN + CHI来维护

在这里插入图片描述

6. CCI的介绍(以CCI-550为例)

CCI-550 包含一个包容性监听过滤器(snoop filter),用于记录存储在ACE 主缓存。

侦听过滤器可以在未命中的情况下响应侦听事务,并侦听适当的主控只有在命中的情况下。Snoop 过滤器条目通过观察来自 ACE 主节点的事务来维护以确定何时必须分配和取消分配条目。

侦听过滤器可以响应多个一致性请求,而无需向所有人广播ACE 接口。例如,如果地址不在任何缓存中,则监听过滤器会以未命中和将请求定向到内存。如果地址在处理器缓存中,则请求被视为命中,并且指向在其缓存中包含该地址的 ACE 端口。

在这里插入图片描述
在这里插入图片描述

7. 经典示例框图

在这里插入图片描述


关注"Arm精选"公众号,备注进ARM交流讨论区。

1138106487-65f6cf311889c.png

这篇关于A53 cache的架构解读的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/876063

相关文章

MySQL中时区参数time_zone解读

《MySQL中时区参数time_zone解读》MySQL时区参数time_zone用于控制系统函数和字段的DEFAULTCURRENT_TIMESTAMP属性,修改时区可能会影响timestamp类型... 目录前言1.时区参数影响2.如何设置3.字段类型选择总结前言mysql 时区参数 time_zon

MySQL中的锁和MVCC机制解读

《MySQL中的锁和MVCC机制解读》MySQL事务、锁和MVCC机制是确保数据库操作原子性、一致性和隔离性的关键,事务必须遵循ACID原则,锁的类型包括表级锁、行级锁和意向锁,MVCC通过非锁定读和... 目录mysql的锁和MVCC机制事务的概念与ACID特性锁的类型及其工作机制锁的粒度与性能影响多版本

Redis过期键删除策略解读

《Redis过期键删除策略解读》Redis通过惰性删除策略和定期删除策略来管理过期键,惰性删除策略在键被访问时检查是否过期并删除,节省CPU开销但可能导致过期键滞留,定期删除策略定期扫描并删除过期键,... 目录1.Redis使用两种不同的策略来删除过期键,分别是惰性删除策略和定期删除策略1.1惰性删除策略

Redis与缓存解读

《Redis与缓存解读》文章介绍了Redis作为缓存层的优势和缺点,并分析了六种缓存更新策略,包括超时剔除、先删缓存再更新数据库、旁路缓存、先更新数据库再删缓存、先更新数据库再更新缓存、读写穿透和异步... 目录缓存缓存优缺点缓存更新策略超时剔除先删缓存再更新数据库旁路缓存(先更新数据库,再删缓存)先更新数

使用Spring Cache时设置缓存键的注意事项详解

《使用SpringCache时设置缓存键的注意事项详解》在现代的Web应用中,缓存是提高系统性能和响应速度的重要手段之一,Spring框架提供了强大的缓存支持,通过​​@Cacheable​​、​​... 目录引言1. 缓存键的基本概念2. 默认缓存键生成器3. 自定义缓存键3.1 使用​​@Cacheab

C#反射编程之GetConstructor()方法解读

《C#反射编程之GetConstructor()方法解读》C#中Type类的GetConstructor()方法用于获取指定类型的构造函数,该方法有多个重载版本,可以根据不同的参数获取不同特性的构造函... 目录C# GetConstructor()方法有4个重载以GetConstructor(Type[]

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

MCU7.keil中build产生的hex文件解读

1.hex文件大致解读 闲来无事,查看了MCU6.用keil新建项目的hex文件 用FlexHex打开 给我的第一印象是:经过软件的解释之后,发现这些数据排列地十分整齐 :02000F0080FE71:03000000020003F8:0C000300787FE4F6D8FD75810702000F3D:00000001FF 把解释后的数据当作十六进制来观察 1.每一行数据

Java ArrayList扩容机制 (源码解读)

结论:初始长度为10,若所需长度小于1.5倍原长度,则按照1.5倍扩容。若不够用则按照所需长度扩容。 一. 明确类内部重要变量含义         1:数组默认长度         2:这是一个共享的空数组实例,用于明确创建长度为0时的ArrayList ,比如通过 new ArrayList<>(0),ArrayList 内部的数组 elementData 会指向这个 EMPTY_EL