AMBA CHI缓存一致性协议中RN如何选择发送的READ事务类型？

RN（Request Node）针对CPU发来的单条READ指令，选择对应CHI读指令变体的核心依据是本地缓存状态、CPU读请求的隐含属性以及CHI协议的一致性规则，具体决策逻辑可拆解为以下几点：

• 基于本地缓存的当前状态判断：

  • 若RN本地缓存已存在该数据的*Shared（S）*状态副本，RN通常直接返回数据，无需向HN（Home Node）发送请求；若需确认数据有效性或维持共享状态，会选择ReadShared。
  • 若本地缓存持有该数据的*Dirty（D）*状态副本，CPU普通读请求下RN直接返回数据，无需向HN发请求；若CPU要求独占访问，这类场景通常由写请求触发，读请求一般不会涉及。
  • 若本地缓存无该数据副本，需结合CPU需求选择：
    • 仅需可读共享副本时，发送ReadShared，获取后将本地缓存设为S状态。
    • CPU需要独占访问（比如后续大概率执行写操作，部分CPU架构会通过读指令的隐含标志或上下文告知RN）时，发送ReadUnique，获取后本地缓存设为Unique（U）状态，避免后续写操作额外协调。
    • ReadClean用于请求干净的共享副本，多在刷新本地无效状态或确保数据为最新干净版本时使用；ReadNotSharedDirty用于请求数据并确保无其他节点持有Dirty副本，多用于特定一致性同步场景。

• 关于决策算法的文档说明：
  你在CHI官方手册中未找到详细决策流程，是因为这部分属于RN的实现细节——ARM的CHI规范仅定义了协议交互规则、消息格式和状态转换要求，并未强制RN的具体决策算法。不同IP厂商（如ARM自身的CoreLink系列、第三方IP供应商）会根据自身缓存设计、性能优化目标来实现这部分逻辑。
  不过，ARM在部分架构参考手册（如Cortex系列内核技术参考手册）中会提及内核与RN之间的交互信号（比如是否携带独占访问标志），这些信号是RN判断的关键输入；部分CHI设计指南或IP厂商内部文档会包含具体决策流程，但这类文档通常需向供应商申请获取。

内容的提问来源于stack exchange，提问作者R71