第4章：节点与拓扑结构
本章详细解析CHI协议中各类节点的具体功能、差异以及如何通过不同拓扑结构将它们连接起来，以构建从简单到复杂的片上系统。
4.1 请求节点(RN)详解：RN-F、RN-I、RN-D的区别
请求节点是事务的发起者，根据其一致性能力和支持的特性，分为三类。
| 特性/节点类型 | RN-F (完全一致性请求节点) | RN-I (I/O一致性请求节点) | RN-D (支持DVM的I/O一致性请求节点) |
|---|---|---|---|
| 硬件一致性缓存 | 包含。拥有可被系统一致性协议管理的缓存。 | 不包含。 | 不包含。 |
| 接收并响应侦听 | 必须。是维护系统一致性的关键参与者。 | 不能。无一致性缓存，故不接受侦听。 | 不能。 |
| 接收DVM消息 | 不适用（通常由MN处理）。 | 不能。 | 可以。这是其与RN-I的核心区别。 |
| 发起的事务类型 | 所有协议定义的事务 （除ReadNoSnpSep等特定变体外）。 |
协议定义的子集 （主要是非侦听请求，如ReadNoSnp, WriteNoSnp，以及部分可侦听请求如ReadOnce*）。 |
协议定义的子集（同RN-I）。 |
| 典型应用 | 多核CPU集群、GPU计算单元。 | 高带宽DMA控制器、网络接口卡(NIC)。 | 需要执行DVM操作（如TLB无效）的I/O设备。 |
| 关键行为 | 必须及时响应侦听请求；通过CompAck机制协助HN-F维护顺序。 |
访问可缓存位置时，建议不修改SnpAttr以避免不必要的侦听过滤器查找。 |
除具备RN-I功能外，能接收并处理DVM操作。 |
总结：RN-F是系统一致性的积极参与者；RN-I和RN-D是"旁观者"，它们能发起一致性请求以获取最新数据，但自身不维护缓存状态，其中RN-D额外负责处理系统级的虚拟内存管理操作。
4.2 主节点(HN)详解：HN-F、HN-I的功能差异
主节点是互连的智能中枢，负责请求的接收、排序和一致性管理。
| 特性/节点类型 | HN-F (完全一致性主节点) | HN-I (非一致性主节点) |
|---|---|---|
| 接收的请求类型 | 除DVMOp外的所有请求类型。 |
协议定义的有限子集（主要是非侦听请求）。 |
| 一致性管理 | 是系统的一致性点(PoC)。通过向相关RN-F发送侦听请求、整合响应来管理全局缓存一致性。 | 不包含PoC 。无法处理可侦听请求。若收到，必须返回协议合规的错误响应（如NDERR），不保证一致性。 |
| 排序职责 | 是内存请求的序列化点(PoS)。管理所有发往一致性内存空间的请求顺序。 | 是I/O请求的序列化点(PoS)。管理所有发往I/O子系统的请求顺序。 |
| 优化结构 | 可包含目录 或侦听过滤器，以减少冗余侦听，提升效率。 | 不适用。 |
| 集成缓存 | 实现可定义包含集成互连缓存。 | 不适用。 |
| 典型应用 | 连接至一致性内存区域（如DDR）的互连部分。 | 连接至I/O外设或非一致性内存区域（如PCIe子系统）的互连部分。 |
总结：HN-F是"全能协调者"，负责最复杂的完全一致性事务；HN-I是"I/O交通警察"，专门负责非一致性或I/O一致性请求的排序，将一致性管理职责上交给HN-F。
4.3 从属节点(SN)详解：SN-F、SN-I的应用场景
从属节点是事务的终点，负责最终的数据读写或操作执行。
| 特性/节点类型 | SN-F (从属节点) | SN-I (从属节点) |
|---|---|---|
| 服务的内存类型 | 普通内存。 | 外设或普通内存。 |
| 处理的请求类型 | 非侦听读、写、原子请求（含其独占变体）及缓存维护操作(CMO)请求。 | 非侦听读、写、原子请求（含其独占变体）及CMO请求。 |
| 关键区别 | 用于支持一致性内存空间。是系统物理存储点(PoPS)的典型位置。 | 用于连接I/O外设或非一致性内存。 |
| 典型应用 | DDR / LPDDR 内存控制器、HBM控制器。 | PCIe端点控制器、片上外设总线桥（如APB）、Flash控制器。 |
总结 ：SN-F和SN-I功能相似，但应用场景不同：SN-F背靠一致性内存域，是系统主内存的入口；SN-F背靠I/O或非一致性内存域，是设备寄存器和局部内存的入口。
4.4 杂项节点(MN)：DVM操作的专业处理者
杂项节点是一种功能专一的节点，其核心职责是：
- 接收来自请求节点（主要是RN-D）的分布式虚拟内存操作请求。
- 完成所需的操作（如TLB无效、缓存维护广播）。
- 返回响应。
MN有时在实现上被称为HN-D节点。它不参与普通内存事务的一致性排序，但可能负责在非同步和同步DVM操作之间进行排序。
4.5 拓扑结构选择：环形、网状、交叉开关的对比
CHI定义了组件类型，但不规定具体拓扑，这为系统设计提供了灵活性。三种典型拓扑的对比如下：
| 拓扑类型 | 交叉开关 | 环形 | 网状 |
|---|---|---|---|
| 结构 | 每个节点与所有其他节点直接相连。 | 节点首尾相连成环，每个节点只与两个邻居相连。 | 节点呈网格状排列，每个节点与相邻的四个节点相连。 |
| 性能 | 延迟最低，天然有序。 | 延迟随节点数线性增长。 | 提供高带宽和多路径，传输时间短。 |
| 可扩展性 | 差 。连线数量随节点数平方增长，成本高。 | 中等。易于扩展节点，但性能随之下降。 | 优秀。模块化设计，通过增加行列即可轻松扩展。 |
| 面积与功耗 | 连线多，面积和功耗最大。 | 连线少，面积和功耗最优。 | 介于两者之间。 |
| 适用系统规模 | 小型系统（节点数少）。 | 中型系统。 | 大型系统（如服务器、高性能计算）。 |
设计建议 ：选择拓扑时需在性能（延迟/带宽）、可扩展性、成本（面积/功耗） 之间权衡。小型控制平面系统可选交叉开关；注重能效的中型移动SoC可选环形；追求极致吞吐的大型数据中心芯片则适合网状拓扑。
第5章：通道与通信机制
本章深入剖析CHI协议中消息传输的物理路径（通道）、数据封装格式（微片）以及确保可靠传输的底层控制机制（握手与信用）。
5.1 四大通道：REQ、RSP、SNP、DAT的功能解析
CHI协议通过四条独立的物理通道来传输不同类型的消息，以实现功能分离和并行处理。每条通道都有明确的发送（TX）和接收（RX）方向。
| 通道 | 全称 | 主要功能 | 传输方向 (以RN-F为例) | 传输的消息示例 |
|---|---|---|---|---|
| REQ | 请求通道 | 发送初始事务请求。 | TXREQ (出站) | ReadNoSnp, WriteNoSnp, ReadOnce, CleanInvalid, DVMOp |
| RSP | 响应通道 | 发送无数据的完成、状态或信用响应。 | TXRSP (出站) / RXRSP (入站) | CompAck, DBIDResp, RetryAck, PCrdGrant, RespSepData |
| SNP | 侦听通道 | 由HN-F或MN发出，用于查询或修改其他RN-F的缓存状态。 | RXSNP (入站) | SnpShared, SnpUnique, SnpDVMOp |
| DAT | 数据通道 | 传输读写数据、原子操作数据或带数据的侦听响应。 | TXDAT (出站) / RXDAT (入站) | CompData, NCBWrData, SnpRespData, DataSepResp |
关键约束：
- SNP通道 ：只有HN-F 和MN可以在此通道上发出消息。RN-F只能在此通道上接收（侦听）消息。
- 通道复用 ：CHI-E允许在单个接口上独立复制特定通道（如复制多个REQ通道），以选择性地增加关键通道的带宽，这是一种比复制整个接口更高效的带宽提升方法。
5.2 微片(Flit)结构：控制字段与标识符详解
所有协议消息都以微片 的形式发送。微片是控制字段和标识符的集合，其字段并行发送，而非像PCIe那样串行化。
一个典型的请求微片包含以下关键部分：
- 操作码 ：决定事务类型和结构。例如，
ReadClean(0x02),WriteNoSnpFull(0x1D)。 - 标识符 ：用于路由、跟踪和关联事务的核心字段。
- SrcID：源节点ID，标识发送者。
- TgtID ：目标节点ID，标识接收者（SNP微片无此字段）。
- TxnID：事务ID，在源节点范围内唯一标识一个事务。CHI-D后扩展为10位，支持1024个未完成事务。
- DBID：数据缓冲区ID，仅存在于RSP和DAT微片中，用于写入数据的流控和事务释放。
- 地址与控制信息 ：如地址(
Addr)、数据大小(Size)、内存属性(MemAttr)、安全属性(NS)等。
标识符使用总结：
| 标识符 | REQ | RSP | DAT | SNP | 说明 |
|---|---|---|---|---|---|
| SrcID | ✓ | ✓ | ✓ | ✓ | 所有微片都有，用于路由。 |
| TgtID | ✓ | ✓ | ✓ | ✗ | SNP微片无TgtID，由HN-F通过其他机制路由侦听。 |
| TxnID | ✓ | ✓ | ✓ | ✓ | 所有微片都有，用于端到端事务跟踪。 |
| DBID | ✗ | ✓ | ✓ | ✗ | 仅用于写入流控和完成确认关联。 |
5.3 握手机制：FLITV与LCRDV的协同工作
CHI采用与ACE不同的基于信用的握手机制来传输微片，确保接收方有缓冲空间。
- 发送方 ：
- 在发送一个微片前，必须已从接收方获得一个链路层信用。
- 当微片数据在总线上有效时，将对应通道的
*FLITV信号置为高。
- 接收方 ：
- 通过将
*LCRDV信号置为高（并在时钟上升沿有效）来授予一个信用，表示其有空闲缓冲区。
- 通过将
- 传输时刻 ：
- 当
*FLITV为高时，在下一个时钟上升沿完成微片传输。 - 传输完成后，发送方消耗一个信用，必须等待新的信用才能发送下一个微片。
- 当
简单流程 ：LCRDV授权信用 → 发送方在获得信用后置FLITV有效 → 时钟上升沿捕获数据。
5.4 信用机制：协议信用与链路层信用的区别
CHI中存在两种不同层级的信用机制，分别解决不同层面的流控问题。
| 特性 | 链路层信用 | 协议信用 |
|---|---|---|
| 层级 | 链路层 | 协议层 |
| 目的 | 确保接收方的物理缓冲区不溢出，保证微片能被临时存储。 | 确保完成方有足够的逻辑资源（如事务跟踪条目、数据缓冲区）来处理一个新事务。 |
| 粒度 | 针对每个通道的信用。 | 针对特定类型的事务或资源（如读请求、写请求）。 |
| 信号 | 通过*LCRDV信号授予。 |
通过PCrdGrant响应消息在RSP通道上发送。 |
| 工作范围 | 单跳，在直接相连的两个链路接口之间。 | 端到端，在事务的源（如RN）和目标（如HN/SN）之间。 |
| 关联机制 | 与请求重试 机制紧密相关。当目标资源不足时，通过RetryAck拒绝请求并指示所需协议信用类型(PCrdType)。请求方必须等待匹配的PCrdGrant后才能重试请求。 |
总结 ：链路层信用 是保证物理传输不丢数据的"毛细血管级"流控；协议信用是保证逻辑资源不被耗尽的"系统级"流控。两者协同工作，共同维护系统的稳定和高效运行。
第6章：缓存一致性模型深度解析
本章深入探讨CHI协议如何维护多核系统缓存一致性的核心机制，从基本单位到高级优化技术。
6.1 64字节缓存行：一致性维护的基本单位
CHI协议中，所有一致性操作都以64字节对齐的内存区域 为基本单位，称为缓存行。
- 统一粒度：无论请求的数据大小是1字节还是64字节，一致性维护（如侦听、状态转换）都作用于整个缓存行。这简化了协议设计，避免了处理部分缓存行更新带来的复杂边界问题。
- 内存更新 ：主内存仅在缓存行的所有副本 都不再被任何缓存持有时，才必须被更新。协议不要求主内存时刻保持最新，这允许脏数据在缓存中停留更久，减少不必要的内存访问，提升性能。
- 多请求事务：对于跨越多个缓存行的大块传输（如256字节读取），协议会将其拆分为多个独立的、针对单个缓存行的事务进行处理，但每个事务仍遵循上述一致性规则。
6.2 缓存状态详解：UC、UD、SC、SD、I
CHI定义了七种缓存状态，其中五种核心状态是理解一致性的关键。每种状态由三个属性定义：有效性、所有权（唯一/共享）、清洁度（干净/脏）。
| 状态 | 全称 | 关键特性 | 可写？ | 写回责任 | 对侦听的响应 |
|---|---|---|---|---|---|
| I | 无效 | 缓存行不存在或数据无效。 | 否 | 无 | 无数据返回。 |
| UC | 唯一干净 | 数据仅存于此缓存，且与内存一致。 | 是（静默转换） | 无 | 可返回数据给Home或转发给请求者。 |
| UD | 唯一脏 | 数据仅存于此缓存 ，且已被修改（新于内存）。 | 是 | 有（必须最终写回） | 必须 返回数据给Home；预期转发给请求者。 |
| SC | 共享干净 | 数据可能存在于其他缓存，本副本与内存一致。 | 否（需先获取唯一所有权） | 无 | 若RetToSrc=0，不得 返回数据；若RetToSrc=1，建议返回。 |
| SD | 共享脏 | 数据可能存在于其他缓存 ，但已被修改 。本缓存不负责写回。 | 否（需先获取唯一所有权） | 无（由另一组件负责） | 必须 返回数据给Home；预期转发给请求者。 |
核心洞察：
- 唯一状态（UC/UD） 意味着"独占所有权"，允许本地直接写入。
- 脏状态（UD/SD） 意味着数据比内存新，但写回责任的归属不同：UD由持有者负责，SD由另一个（可能是未知的）组件负责。
- 共享状态（SC/SD） 意味着可能存在多个副本，写入前必须通过事务使所有其他副本无效。
6.3 状态转换规则：什么情况下可以转换状态？
缓存状态转换由协议事务（请求或侦听）触发，并严格遵循预定义的规则。转换可分为两类：
-
静默转换：无需通知系统中其他组件，仅在本地缓存内发生的状态改变。
- UC → UD：本地对UC行执行存储操作。
- UD → SD：本地代理将UD行共享给内部其他代理（如核心间共享）。
- UC → SC：同上，内部共享。
- UC/UCE/SC → I：缓存逐出（Evict）。
-
协议驱动转换：由协议消息触发，涉及系统内多个组件。
- I → SC/UC/UD ：通过
ReadShared/ReadClean/ReadNotSharedDirty等读取事务获取数据。 - SC → I ：收到
SnpUnique等无效化侦听。 - SD → SC/I ：收到
SnpClean等侦听，可能需返回脏数据并转换状态。 - 任何状态 → I ：收到
SnpMakeInvalid侦听（最强无效化）。
- I → SC/UC/UD ：通过
关键约束 ：状态转换必须保证写回责任 的妥善传递。例如，从UD状态转换时，如果数据未写回内存，则必须通过CompData_UD_PD或SnpRespData_I_PD等响应将"脏责任"传递给Home或请求者。
6.4 侦听机制：如何维护全局一致性视图？
侦听是HN-F维护全局一致性的核心手段。当HN-F收到一个可能影响一致性的请求（如ReadUnique写入请求）时，它会向可能持有该缓存行副本的其他RN-F发送侦听请求。
- 侦听类型 ：根据请求目标，侦听分为不同"强度"：
- 无效化侦听 （如
SnpUnique,SnpMakeInvalid）：要求被侦听方使缓存行无效，可能返回数据。 - 非无效化侦听 （如
SnpShared,SnpClean）：要求被侦听方提供数据或转换为共享状态，但不使其无效。 - 转发侦听 （如
SnpSharedFwd）：要求被侦听方直接将数据转发给原始请求者 ，这是直接缓存传输(DCT) 的基础。
- 无效化侦听 （如
- 被侦听方响应：RN-F根据自身缓存状态和侦听类型，返回相应的侦听响应（可能带数据或不带数据），并更新自身状态。
- Home的裁决：HN-F收集所有侦听响应后，整合信息（如确认所有其他副本已无效），然后向原始请求者发送完成响应，从而完成整个一致性事务。
6.5 侦听过滤器与目录：提升系统可扩展性的关键
在包含大量RN-F的大型系统中，向所有RN-F广播侦听（广播侦听）会带来巨大的带宽开销和延迟。侦听过滤器 和目录是解决此问题的关键优化技术。
| 技术 | 基本思想 | 优势 | 劣势 |
|---|---|---|---|
| 侦听过滤器 | 在HN-F内维护一个简化的、可能不精确 的位图，跟踪每个缓存行可能被哪些RN-F缓存。 | 实现相对简单，面积小。可以过滤掉对未缓存该行的RN-F的不必要侦听。 | 信息可能不精确（存在"误报"），导致仍需发送一些不必要的侦听，或需要额外的SnpQuery来确认。 |
| （基于）目录 | 在HN-F内维护一个精确的 数据结构，记录每个缓存行确切被哪些RN-F以何种状态缓存。 | 信息精确，可以精准地只向必要的RN-F发送侦听，最大程度减少冗余流量。 | 实现更复杂，存储开销更大（需要记录更多信息）。 |
对协议的影响 ：使用这些技术后，HN-F的行为会有所不同。例如，对于MakeReadUnique请求：
- 有精确目录/过滤器：若显示请求方仍是唯一持有者，HN-F可能无需发送任何侦听，直接响应完成。
- 无或不精确 ：HN-F必须保守地发送侦听（如
SnpUnique）或假定请求方已丢失数据，并在响应中提供数据。
总结 ：侦听过滤器与目录是CHI协议可扩展性的基石，它们将一致性维护的复杂度从O(N)（广播）降低到O(1)或O(k)（k为实际共享者数），使得构建数十甚至上百核心的大型SoC成为可能。