03. 内存一致性与保护
本文档描述 SG2262 C2C 子系统的内存一致性保序机制、内存保护功能与 RAS 设计。 信息来源标注：[DOC] = 原始方案文档, [PPT] = feature PPT, [推导] = 从文档推导
CHS (C2C post-write Hardware Sequence)
方案定义
[DOC] CHS 方案下，C2C 仅发送 post write 请求。硬件沿数据路径的每一级保证请求处理顺序不被打乱。对需要严格保序的特殊请求（flag 写入、msg sync 等），通过保序窗口保证其与前置数据写入的先后关系。
保序链条
[DOC] 从请求发出到写入目标 Memory，经过四级硬件保序：
| 级别 | 环节 | 保序行为 |
|---|---|---|
| 1 | CDMA | 按指令顺序发出写请求 |
| 2 | MAC 保序 | MAC 接收请求后按序传递给下游 |
| 3 | 交换系统保序 | 同 src macid、同 dst macid、同 hash value 的报文在交换机内严格保序 |
| 4 | 芯片转发 + 写 Memory 保序 | 目标芯片通过保序窗口保证需保序请求的执行顺序 |
网络约束
[DOC] CHS 要求 C2C 网络路径唯一：同 src macid、同 dst macid、同 hash value 的报文走相同交换机路径。不支持 ECMP 多路径算法，仅支持同芯片多 C2C Link 间 ITLV 分散带宽。
[PPT] CHS 模式下不支持量化反量化传输的重封包/重解包功能，只能根据量化前 ITLV 粒度封包。
CFS (C2C Fence Sequence)
方案定义
[DOC] CFS 方案下，C2C 仅发送 non-post write 请求。通过 fence 指令建立保序屏障。CDMA 搬运指令切换时不保证前置指令搬运全部完成——当一条 transfer 指令的最后一笔写请求发射后，CDMA 即可切换到下一条指令，此时前一条指令的 bresp 可能尚未全部收齐。
fence 指令行为
[DOC] fence 指令语义：fence 之后的所有搬运指令，必须在 fence 之前的所有搬运指令全部完成后才能执行。
具体行为：
- CDMA Thread 遇到 fence 指令时进入 FenceWait 状态
- Thread Arbiter 跳过处于 FenceWait 的线程，不阻塞其他线程使用 datapath
- 等待该线程所有前置搬运的 bresp 全部收齐
- bresp 收齐后 fence 完成，线程回到 Ready 状态，后续指令可参与仲裁
[推导] fence 阻塞范围仅限单个线程。其他线程可正常使用 datapath，通过多线程流水隐藏 fence 等待时间。
send 指令自带 fence
[DOC] send 指令自带 fence 功能：必须收集所有 bresp 后才能 retire。具体流程：
- send 指令发送完所有 write_send 后退出 datapath（释放 datapath 给其他线程）
- Thread 独立等待所有 write_send 的 bresp 收齐
- bresp 全部收齐后发送 write_done
- 收到 write_done 的 bresp 后 retire send 指令
- 此后才可执行后续指令
[DOC] send 退出 datapath 的设计意图：send 可能需要等待较长时间收齐 bresp（尤其过交换机场景），一直占用 datapath 会阻塞其他线程。
CHS vs CFS 对比
Send/Receive 流程差异
[DOC] 两种方案在 Send/Receive 协议中的关键差异：
| 差异点 | CFS 模式 | CHS 模式 |
|---|---|---|
| 写请求类型 | non-post write | post write |
| write_send 与 write_done 的保序 | fence 指令保序：send 指令自带 fence，收齐所有 write_send 的 bresp 后才发送 write_done | 保序窗口保序：write_done 地址配置在保序窗口内，硬件确保所有 write_send 完成后才释放 write_done |
| write_done 地址约束 | 无特殊约束 | 必须落在保序窗口配置范围内 |
| write_done 的处理 | send thread 收齐 bresp 后主动发送 | C2C_sys 在保序窗口确认前置 write_send 完成后自动释放 |
性能与适用性对比
[PPT] 两种方案的 tradeoff：
| 维度 | CHS | CFS |
|---|---|---|
| 指令切换开销 | 无额外开销（post write 无需等 bresp） | 切换本身无开销，但需在关键位置插入 fence |
| 同步机制 | 保序窗口硬件自动处理 | fence 阻塞线程，等待前置 bresp |
| 网络要求 | 路径唯一，不支持 ECMP | 无网络保序要求，可支持多路径 |
| 小数据量场景 | 硬件保序无额外同步开销 | fence 同步占比高（如 DeepSeek all2all 每 expert 仅约 14KB） |
| 量化反量化 | 不支持重封包/重解包 | 无此限制 |
[PPT] 最终决策：CHS（C2C 支持 post write + 不支持 DDRCN forwarding）确认为基线方案，CFS 作为备选保留。
保序窗口
基本信息
[DOC] 保序窗口用于保护中断/MSG 同步/atomic 请求与数据传输之间的顺序。
- 位置：MAC MST AXI 出口处
- 行为：落在配置地址区域的写请求，需等待前置所有写请求全部完成后才释放给下游
三种模式
[DOC] 保序窗口支持三种模式，由寄存器 reg_x4_mod_wr_order_ib_atu 三选一：
| 模式 | 寄存器值 | 窗口数 | 窗口编号 | 匹配条件 |
|---|---|---|---|---|
| 模式 0 | 0 | 8 | order 0~7 | 64 bit 地址全匹配 |
| 模式 1 | 1 | 12 | order 20~31 | chipid + 48 bit 地址匹配 |
| 模式 2 | 2 | 32 | order 0~31 | chipid + fun_num + msi + 48 bit 地址匹配 |
各模式匹配细节：
| 模式 | 匹配表达式 |
|---|---|
| 模式 0 | addr_i[63:0] vs reg_x4_addr[63:0] |
| 模式 1 | addr_i[chipid]==7 且 {addr_i[dstboard_id], addr_i[39:0]} vs reg_x4_addr[47:0] |
| 模式 2 | addr_i[chipid]!=7 且 {fun_num, msi, addr_i[39:0]} vs reg_x4_addr[42:0] |
注：模式 1 的地址匹配位宽是 48 bit（dstboard_id 与 addr_i[39:0] 的拼接），并非 40 bit。
保序行为
[DOC] 保序窗口工作流程：
- 写请求到达 MAC MST AXI 出口
- 检查请求地址是否命中任一已配置的保序窗口
- 命中：该请求进入等待状态，直到当前窗口内所有前置写请求的 resp 全部收齐后才释放
- 未命中：正常通过，不受影响
[DOC] 关键特性：保序窗口支持 OSTD（Outstanding）——多个请求可同时命中保序窗口，命中的请求不阻塞后续请求的发射，在窗口中等待的 flag 请求最多支持 8 个同时等待。
[推导] OSTD 设计避免保序窗口成为性能瓶颈：不需要保序的常规数据写入可持续流水发送，只有命中窗口的 flag/msg 写入才会排队等待。
Memory Protect
保护场景
[DOC] SG2262 支持 3 种场景的内存保护，当访问地址触及非法地址空间时上报中断：
| 场景 | 保护对象 | 说明 |
|---|---|---|
| CDMA -> 本芯片 | CDMA 对本芯片内请求地址做 MP | 防止 CDMA 搬运写坏本芯片关键内存区域 |
| CDMA -> PC | CDMA 对 PC 请求地址做 MP | 防止 CDMA 搬运写坏 PCIe 设备空间 |
| PCIe -> 本芯片 | PCIe 对本芯片内请求地址做 MP | 防止外部 PCIe 设备写坏芯片内存 |
寄存器配置
[DOC] 每种场景支持 16 组可配置地址空间，每组包含：
| 寄存器 | 位宽 | 说明 |
|---|---|---|
reg_mpu_start_addr | 40 bit | 保护区间起始地址 |
reg_mpu_end_addr | 40 bit | 保护区间结束地址 |
访问属性（2 bit）：
| 属性值 | 含义 |
|---|---|
| 0x0 | 不使能保护 |
| 0x1 | 不可读（读请求被拦截并上报中断） |
| 0x2 | 不可写（写请求被拦截并上报中断） |
| 0x3 | 不可读写（读写请求均被拦截并上报中断） |
转发请求不做保护
[DOC] C2C 不对转发的请求做 Memory Protect。仅 CDMA 本地发起的请求和 PCIe 发起的请求需要做 MP 检查。经由本芯片 C2C 转发到其他芯片的请求，由目标芯片自身的 MP 机制负责保护。
RAS 设计
核心要求
[DOC] RAS 对 C2C 的核心要求：
- 每个芯片作为算力池中任务分配的最小单元
- 系统节点发生错误不应扩散到算力池中其他节点
- 支持软件介入恢复和节点下线两种方式
- 所有经过 C2C 的报文添加 CRC 校验，数据路径或控制路径错误时通过中断通知软件
隔离模式
[DOC] C2C 支持两种独立的隔离流程：
隔离模式一：停止发送
| 步骤 | 行为 |
|---|---|
| 1 | 软件控制 C2C Link 停止发送请求报文 |
| 2 | 等待接收所有响应报文 |
| 3 | 若长时间未收齐，视为完成（剩余响应由交换机处理：交换机发现 DA 不匹配时丢弃报文） |
| 4 | 隔离完成 |
此模式下不需要自动回复前置未完成的请求。
隔离模式二：停止接收
| 步骤 | 行为 |
|---|---|
| 1 | 软件控制 C2C Link 停止接收请求报文，同时停止接收响应报文 |
| 2 | 回复所有未完成请求，标志为 Error 的响应发给源芯片 |
| 3 | 源芯片通过中断获知目的节点下线 |
| 4 | 隔离完成 |
[DOC] 注意：如果是 C2C Link 本身发生错误（而非目的节点故障），则只能所有节点下线。
隔离后恢复
[DOC] 隔离完成后，软件有两种选择：
| 恢复方式 | 行为 |
|---|---|
| 介入恢复 | 软件诊断错误原因，修复后重新上线该节点 |
| 重置下线 | 对故障节点执行重置，从算力池中移除 |