AMBA-CHI协议详解(十九)

news/2025/2/23 15:52:00

在这里插入图片描述

文章目录

    • 4.6 Silent cache state transitions
    • 4.7 Cache state transitions at a Requester
      • 4.7.1 Read request transactions
      • 4.7.2 Dataless request transactions
      • 4.7.3 Write request transactions
      • 4.7.4 Atomic transactions
      • 4.7.5 Other request transactions


4.6 Silent cache state transitions

  缓存可以由于内部事件而改变状态,而无需通知系统的其余部分。

合法的静默缓存状态转换如下表所示。 在某些情况下,可以但不要求发出事务以指示转换已发生。 如果发出了这样的事务,则缓存状态转换对互连是可见的,并且不被归类为静默转换。

下表中描述的RN-F动作为Local sharing,描述了RN-F将Unique缓存行指定为Shared的情况,有效地忽略了缓存行对RN-F保持Unique的事实。例如,当RN-F包含多个内部代理并且缓存行在它们之间共享时,就会发生这种情况。

对于静默缓存状态转换:

  • Cache eviction and Local sharing转换可以在任何时刻发生。
  • Store和Cache Invalidate转换只能作为故意操作的结果发生,在核心的情况下,这是由执行特定程序指令引起的。

下表备注列指示如何使静默缓存转换变为非静默或在接口上可见。

在这里插入图片描述
缓存状态从UC变为UCE是不允许的。

静默转换的序列也可以发生。 任何导致缓存行处于UD、UDP或SC状态的静默转换都可以进行进一步的静默转换。

4.7 Cache state transitions at a Requester

本节指定以下请求事务的缓存状态转换和完成响应:

  • Read request transactions
  • Dataless request transactions
  • Write request transactions
  • Atomic transactions
  • Other request transactions

4.7.1 Read request transactions

  下表显示了请求者的缓存状态转换及读取请求事务的完成响应,除了 MakeReadUnique 事务。

从属节点对请求者的数据响应中的缓存状态为 UC,即 CompData_UC,无论原始请求类型如何。 请求者必须忽略在对 ReadNoSnp、ReadOnce、ReadOnceCleanInvalid 和 ReadOnceMakeInvalid 的 CompData响应中的缓存状态,并隐式假设缓存状态值为 I。

在非 DMT 数据传输中,CompData 响应从从属发送到主节点,响应中的缓存状态可以是 I 或 UC。通常,预计从属的设计可以通过始终使用 UC 来简化。然后,主节点将带有适当缓存状态值的 CompData 发送给请求者。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
a. 对于ReadOnce*, ReadNotSharedDirty and ReadShared事务,请求者在初始状态为 UCE 时,必须在请求未完成时不将缓存行升级为 UDP 或UD。

b. 处于初始状态 SD 的请求者如果接收CompData_SC 或DataSepResp_SC响应,必须保持在 SD 状态。 同样,使用Snoop filter来跟踪请求者的缓存状态的主节点,必须不根据对请求者的响应中的状态来降低Snoop filter中缓存行的状态。

c. 如果缓存状态为 UD 或 SD,则从内存接收到的数据必须被丢弃;如果缓存状态为 UDP,则必须合并从内存接收到的数据。当缓存状态为 SC 或 UC 时,从内存接收到的数据必须与缓存的数据相同。

MakeReadUnique transaction
本节描述了请求者在 MakeReadUnique 和 MakeReadUnique(Excl) 事务中的允许响应和缓存状态转换。

Permitted responses
下表显示了 MakeReadUnique 事务中的允许响应。

允许响应的一些关键特性包括:

  • 没有数据的响应 Comp_UD_PD 表示请求者正在承担Dirty缓存行的责任。
    当请求者持有缓存行的SharedClean副本,而另一个代理持有SharedDirty时,这种情况可能会发生。 主节点使SharedDirty无效,例如使用 SnpMakeInvalid 事务,然后将脏缓存行的责任传递给发出 MakeReadUnique 事务的请求者。

  • 仅在响应Exclusive版本的 MakeReadUnique 时,才允许具有 SC 缓存状态的响应。
    Comp_SC 是具有 SC 缓存状态的响应的一个示例,当主节点确定独占存储失败,但 snoop filter或对请求者的 SnpQuery snoop 的响应表明请求者仍持有缓存行的副本,同时系统中还有另一个共享副本时,会发送该响应。

上述情况可能发生在非全地址 PoC 独占监视器中。 一个LP可以通过另一个LP对不同地址位置执行独占存储来重置监视位。 对不同地址的存储不会使第一个请求者正在进行独占访问的地址位置的缓存副本失效。

下表显示了在非独占和独占MakeReadUnique事务中允许的响应。
在这里插入图片描述
在这里插入图片描述
下表显示了在独占MakeReadUnique事务中额外允许的响应。
在这里插入图片描述
预期的Snoop
主节点使用Snoop来使Snoopee的缓存行失效,以响应非独占的 MakeReadUnique 或通过独占检查的独占 MakeReadUnique,具体如下:

  • 主节点预计使用 SnpCleanInvalid 窥探:
    — 主节点可以使用 SnpUnique 代替 SnpCleanInvalid。
    — 如果主节点确定请求者丢失了缓存行的缓存副本,则可以使用 SnpUniqueFwd。
    — 如果主节点确定Snoopee没有缓存行的脏副本,则也可以使用 SnpMakeInvalid 代替 SnpCleanInvalid。

Cache line state transitions
  MakeReadUnique 事务后缓存行的最终状态取决于事务响应收到之前缓存行的状态。 这可能与事务发出时缓存行的状态不同。

对于 MakeReadUnique,请求者必须保留缓存行的副本,除非它收到invalidating snoop。

  • Invalidating snoops包括 SnpUnique、SnpUniqueFwd、SnpCleanInvalid、SnpMakeInvalid、SnpUniqueStash 和 SnpMakeInvalidStash。
  • 请求者可以将 SnpPreferUnique 和 SnpPreferUniqueFwd 视为invalidating或non-invalidating。 主节点可以通过检查snoop响应来确定这些snoop如何被Snoopee处理。
  • 所有其他snoop都是non-invalidating的,请求者必须保留缓存行的副本。

如果主节点没有 SF,或者 SF 不精确,并且主节点无法确定请求者在事务完成时是否仍然拥有缓存行的副本,则主节点必须假设缓存行在请求者处丢失,并在响应中提供数据。

在持有 SD 状态的行时,接收到带有数据的响应的请求者必须使用其自己的缓存行副本,而不是响应中返回的副本。

一个请求者在持有SD状态的缓存行时接收到带有数据的响应,这意味着系统中没有snoop filter或snoop filter不精确。 在这种情况下,返回的响应数据可能是过时的。

如果请求者知道没有snoop filter,那么它可以使用CleanUnique事务,而不是MakeReadUnique,以避免在缓存行未被其他代理缓存时进行不必要的内存读取。

在没有snoop filter的情况下,使用CleanUnique事务可以避免不必要的内存读取。 不必要的内存读取发生在缓存行仍然在请求者处缓存,但系统中没有snoop filter,或者没有使用SnpQuery snoop ,并且系统中没有来自其他代理的缓存副本。 然而,在事务进行中,如果缓存行因snoop 而丢失,使用CleanUnique事务将导致请求者需要发出另一个事务。

响应规则为:

  • 对非独占MakeReadUnique的响应中的缓存状态必须是Unique的。
  • 对独占MakeReadUnique的响应中的缓存状态可以是Unique的或Shared的。
  • 对独占和非独占MakeReadUnique的响应中的缓存状态不得包含Shared Dirty。
  • 对于每个允许的组合完成和数据响应,允许对应的单独完成和数据响应。

下表展示了
• 初始缓存状态。
• 在接收到事务响应之前的缓存状态。
• 每个可能响应组合的最终状态。

在这里插入图片描述

在这里插入图片描述

4.7.2 Dataless request transactions

下表显示了请求者的缓存状态转换及Dataless请求事务的完成响应。
在这里插入图片描述
在执行CleanInvalid、CleanInvalidPoPA、MakeInvalid或Evict事务之前,缓存状态可以是UC、UCE或SC。然而,要求在发出事务之前,缓存状态必须转换为I状态。

4.7.3 Write request transactions

下表显示了请求者的缓存状态转换、写数据响应,以及写入和相应的组合写请求事务的完成或单独完成和 DBIDResp 响应。
在这里插入图片描述
在这里插入图片描述
a. 在写入待处理时,可能会收到一个snoop,这会导致缓存行状态在 WriteData 或 CompAck 响应之前发生变化。
b. 如果主节点决定不请求数据,则发送 Comp。
c. 一旦请求发送,请求者被允许将缓存状态保持为 UC,但不得修改缓存行。

在 WriteClean 事务完成后,处于Unique状态的缓存行可以立即转换为Dirty状态。

4.7.4 Atomic transactions

下表显示了请求者的缓存状态转换,以及原子事务的完成和响应。
在这里插入图片描述

4.7.5 Other request transactions

DVMOp 和 PrefetchTgt 请求没有与之相关的缓存状态转换。


http://www.niftyadmin.cn/n/5863553.html

相关文章

linux根目录下的各目录主要作用

linux中下面这些目录的主要作用 bin boot dev etc home lib lib64 lostfound media mnt opt proc root run sbin srv sys tmp usr var 在 Linux 文件系统中,每个目录都有其特定的用途和功能。以下是这些目录的主要作用: 1. /bin 作用:存放系…

25林业研究生复试面试问题汇总 林业专业知识问题很全! 林业复试全流程攻略 林业考研复试真题汇总

25 林业考研复试,专业面试咋准备?学姐来支招! 宝子们,一提到林业考研复试面试,是不是就慌得不行,感觉老师会扔出一堆超难的问题?别怕别怕,其实林业考研复试就那么些套路,…

第六章 数据库设计

1 数据库设计概述 1.1 引言 在当今这个信息爆炸的时代,数据已经成为了一种极其重要的资源。无论是大型企业还是小型创业公司,有效的数据管理都是成功的关键之一。随着信息技术的发展,我们收集、存储和分析的数据量正在以前所未有的速度增长。…

蓝思科技赋能灵伴科技:AI眼镜产能与供应链双升级

2月22日,蓝思科技宣布与AI交互领军企业杭州灵伴科技(Rokid)达成深度战略合作,通过整机组装与全产业链整合,为2025年全球AI眼镜出货量爆发式增长(预计达400万-1200万台)提供核心支撑。 双方合作通…

我们来学人工智能 -- DeepSeek客户端

DeepSeek客户端 题记使用后记系列文章 题记 我选择了 Cherry Studio是国内产品由CherryHQ团队开源是一个平台在这里,有豆包、kimi、通义千问的入口当然,最主要是作为大模型的UI正如标题,这里,作为DeepSeep的客户端 使用 下载本…

postman调用ollama的api

按照如下设置,不需要设置key 保持长会话的方法 # 首次请求 curl http://localhost:11434/api/generate -d {"model": "deepseek-r1:32b","prompt": "请永久记住:110,1-12,之后所有数学计算必…

Python天梯赛10分题-念数字、求整数段和、比较大小、计算阶乘和

007-念数字 输入一个整数,输出每个数字对应的拼音。当整数为负数时,先输出fu字。十个数字对应的拼音如下: 0: ling 1: yi 2: er 3: san 4: si 5: wu 6: liu 7: qi 8: ba 9: jiu输入格式: 输入在一行中给出一个整数,如&…

Vue.js 与 Ajax(Axios)的深入探索

Vue.js 与 Ajax(Axios)的深入探索 引言 在当前的前端开发领域,Vue.js 已经成为了最受欢迎的 JavaScript 框架之一。它以其简洁的语法、高效的性能和强大的生态系统获得了广泛的应用。而在与后端服务交互时,Ajax 技术是不可或缺的。本文将深入探讨 Vue.js 与 Ajax(Axios)…