02. CDMA (Cross-chip DMA) 行为参考
信息来源标注：[DOC] = 原始方案文档, [PPT] = feature PPT, [推导] = 从文档推导
设计原则
CDMA 与 C2C_sys 解耦
[DOC] CDMA 与 C2C_sys（Ethernet port）之间不存在固定绑定关系：任意 CDMA 可访问任意 C2C MAC。软件可灵活地将不同 CDMA 的流量分配到不同的 C2C Link 上，适配各种拓扑结构。
[DOC] 系统支持三种主体对 C2C_sys 的跨芯片访问：
- CDMA：主要的跨芯片数据搬运通道
- TPU_scalar：通过 CDMA thread 间接发起跨芯片操作
- AP（CPU）：可直接跨芯片配置远端 CDMA 指令
CDMA 个数 >= C2C MAC 个数
[DOC/PPT] CDMA 个数不少于 C2C MAC 个数，确保每个 CDMA 可独立服务一条 C2C Link，利用起所有 C2C Link 带宽。
CDMA 带宽 = MAC 带宽的 2 倍
[DOC] 每个 CDMA 带宽上限 64 GB/s，MAC 有效带宽约 32 GB/s（单向），CDMA 带宽为 MAC 带宽的 2 倍。
注：此处"MAC 有效带宽约 32 GB/s"为设计文档中的带宽规划基准值。按 112G SerDes 配置推算，单 link 线速 = 56 GB/s，扣除 MAC 协议开销（~17%）后有效带宽约 46.5 GB/s（详见 00_overview.md §5）。2 倍设计余量在 112G 下有所收窄，但仍通过多线程流水隐藏同步和仲裁开销来充分利用 link 带宽。
[推导] 2 倍冗余设计理由：
- 同步带宽损失缓解：指令切换不保序，需 fence/barrier 做同步。同步期间 datapath 无法服务当前 thread，但其他 thread 可继续使用 datapath，避免 C2C Link 空闲
- 多线程仲裁开销：8 个 thread 共享一个 datapath，thread 切换存在仲裁延迟和 pipeline 排空开销，2 倍带宽可吸收这部分损失
CDMA 线程数设计
[DOC] 线程数 >= TPU_scalar 数，确保每个 TPU_scalar 可独占一个 CDMA thread 进行异步执行。同时希望同时利用 L1 和 L2 的带宽（各需独立线程），因此 CDMA 总线程数应为 TPU_scalar 数的两倍。
RN/SN 分离策略
[DOC/PPT] NoC 中 RN（Request Node）和 SN（Slave Node）的分离设计直接影响不同流量路径之间的隔离程度。
| 资源 | 分离策略 | 原因 |
|---|---|---|
| 每个 CDMA | 独立出一个 RN | 防止不同 layer 的 C2C 反压互相影响带宽 |
| 每个 C2C | 独立出一个 SN | 防止不同 layer 带宽不均时阻塞 |
| 每个 C2C | 独立出一个 RN | 防止转发带宽影响 DDR 访问带宽 |
| Link Aggregation 组 | 同组共用一个 RN/SN | 聚合组内多 Link 视为整体 |
硬件规格
SG2262 vs SG2261 对比
| 参数 | SG2262 | SG2261 | 说明 |
|---|---|---|---|
| CDMA 数/Die | 4 | 2 | 与 C2C MAC 数量对应 |
| Thread 数/CDMA | 8 | 8 | 支持异步执行 |
| 总 Thread 数/Die | 32 | 16 | 满足 TPU_scalar 并发需求 |
| CDMA 位宽 | 512bit | 512bit | [PPT] 可处理 400Gbps |
| 带宽上限/CDMA | 64 GB/s | 64 GB/s | MAC 带宽的 2 倍 |
| 执行队列/CDMA | 1 | 1 | 所有 Thread 共享一个 datapath |
双 Die 芯片推导（SG2262）
[推导] SG2262 为双 Die 芯片：
- 总 CDMA 数/Chip = 4 x 2 = 8
- 总 Thread 数/Chip = 32 x 2 = 64
- CDMA 总带宽/Chip = 64 x 8 = 512 GB/s（> C2C 总带宽 448 GB/s，有余量）
内部模块结构
CDMA 内部由 5 个功能模块组成：
| 模块 | 职责 | 关键行为 |
|---|---|---|
| CMDQ Layer | 指令缓冲与分发 | 每线程独立 cmdq，独立地址空间，遵循 4KB boundary；搬运指令提交到 datapath；sys 指令（含 barrier）由线程独立执行 |
| Thread Arbiter | 线程仲裁 | 从多个 Ready 线程中选择一个占用 datapath；三级优先级仲裁；同一时刻只有一个线程可使用 datapath |
| CDMA Datapath | 数据搬运 | 512bit 位宽，64 GB/s 带宽上限；接收搬运指令执行读写操作；完成后触发 Bresp 收集 |
| Bresp Collector | 写响应收集 | transfer 指令：datapath 统一收集；send 指令：退出 datapath 后由 thread 独立收集 |
| Control Unit | 同步与控制 | fence/barrier 执行；msg_wait 每线程独立；write_completion 生成 |
Thread 状态机
状态定义
| 状态 | 含义 | 可被 Arbiter 选中? |
|---|---|---|
| Idle | 线程空闲，无待执行指令 | 否 |
| Ready | 有待执行指令，等待 Arbiter 仲裁 | 是 |
| Executing | 占用 datapath，正在搬运数据 | 否（已被选中） |
| FenceWait | fence 指令阻塞，等待前置搬运全部完成 | 否 |
| TCreditWait | send 指令阻塞，等待对端发送 tcredit | 否 |
状态转移条件
| 转移 | 触发条件 |
|---|---|
| Idle -> Ready | 收到 transfer/send 指令 |
| Ready -> Executing | Arbiter 选中该线程 |
| Executing -> Ready | 搬运完成且有后续指令 |
| Executing -> Idle | 搬运完成且无后续指令 |
| Executing -> FenceWait | 执行 fence 指令 |
| Executing -> TCreditWait | 执行 send 且无可用 tcredit |
| FenceWait -> Ready | bresp 全部收齐 |
| TCreditWait -> Ready | 收到 tcredit |
| Ready -> Idle | 无待执行指令 |
Thread Arbiter 仲裁逻辑
[DOC/PPT] Arbiter 采用 Round-Robin 轮询 8 个 Thread，附加三级优先级：
| 优先级 | 规则 | 说明 |
|---|---|---|
| 第一级 | 跳过 barrier/fence 线程 | barrier 阻塞本线程但不阻塞 datapath，Arbiter 直接跳过 |
| 第二级 | 优先选非数据搬运指令 | sys 指令和 eop 指令比 transfer 指令优先级更高 |
| 第三级（最高） | EOP 最优先 | cdma eop 指令在所有候选中获得最高优先级 |
仲裁流程：Round-Robin 扫描所有 Ready 线程 -> 跳过 barrier/fence 阻塞线程 -> 在候选线程中按优先级选择。
指令集与行为
指令一览
| 指令 | 类型 | 说明 |
|---|---|---|
| transfer | 搬运 | 替代 Read/Write，通过目标地址区分片内/片间 |
| fence | 同步 | 内存同步屏障，确保前置搬运全部完成 |
| send | 搬运+同步 | Send/Receive 协议发送端，自带 fence 语义 |
| receive | 同步 | Send/Receive 协议接收端 |
| write_completion | 通知 | 写完成通知，用于跨芯片同步 |
| msg_wait | 等待 | 等待消息，每线程独立运行 |
| barrier | 同步 | 线程屏障，阻塞本线程 |
关键指令行为
transfer
- 通过 44bit 地址的
addr[43:40]区分目标：== 0为片内访问，!= 0为跨芯片访问 - 由 Datapath 执行实际读写操作
fence
- 确保 fence 后的搬运在 fence 前全部完成后才执行
- 阻塞本线程（进入 FenceWait 状态），不阻塞其他线程
send
- 指定 receive chip + receive cdma thread
- 需等待对端 tcredit 才能开始发送（无 tcredit 则进入 TCreditWait）
- 自带 fence 功能：必须收集所有 bresp 后才能 retire
- 发送完所有 write_send 后退出 datapath，bresp 收集交还 thread 独立完成
receive
- 指定 send chip + send cdma thread
- 收到 write_done 后 retire
write_completion
- CDMA 生成写完成请求，用于跨芯片同步
msg_wait
- 每个线程独立运行，不阻塞其他线程
barrier
- 阻塞本线程，Arbiter 跳过此线程
关键行为规则
指令切换不保序：搬运指令执行过程中，指令切换不保证前置指令完成。需要保序时，必须使用 fence 显式同步。
Bresp 收集机制
transfer 和 send 两类搬运指令采用不同的 Bresp 收集路径：
| 维度 | transfer | send |
|---|---|---|
| 收集者 | Datapath 统一收集 | Thread 独立收集 |
| 是否占用 datapath | 是（直到 bresp 收齐） | 否（发完即退出） |
| bresp 计数 | 共享计数器 | 独立计数器 |
| 完成后动作 | 释放 datapath | 发送 write_done -> 收到 bresp -> retire |
[推导] send 退出 datapath 的设计意图：send 可能需要等待较长时间才能收齐所有 bresp（尤其过交换机场景），退出 datapath 后 thread 独立等待，datapath 可继续服务其他线程，避免长尾延迟阻塞整个 CDMA。
CHS/CFS 模式对 Bresp 收集的影响
上述 Bresp 收集路径在 CHS 和 CFS 两种内存一致性模式下有不同的时序特征（模式定义详见 03_memory-consistency.md）。
transfer 指令
| 维度 | CHS (post write) | CFS (non-post write) |
|---|---|---|
| bresp 来源 | 本地 MAC early resp | 远端写入完成后返回 |
| bresp 延迟 | ~几 ns (本地路径) | 链路 RTT (数百 ns) |
| datapath 占用时间 | 约等于数据传输时间 | 数据传输时间 + 链路 RTT |
| 下一条指令可开始时间 | 数据发完后几乎立即 | 等远端 bresp 返回后 |
[推导] CHS 下，transfer 由 datapath 统一收集 bresp，但 bresp = early resp (由本地 MAC 回复)，不需要等远端写入完成。因此 datapath 占用时间接近纯传输时间，连续 transfer 指令可近似流水执行，指令间隙仅为 early resp 收集延迟 (~几 ns)。
[推导] CFS 下，transfer 的 bresp 需要等远端实际写入完成后返回，datapath 被占用直到远端 bresp 返回。连续 transfer 之间存在显著的 RTT gap。
send 指令
send 指令在两种模式下的 datapath 占用时间相同 (发完 write_send 即退出)，差异在 thread 独立收集 bresp 的等待时间:
| 维度 | CHS | CFS |
|---|---|---|
| datapath 退出时机 | 发完所有 write_send 后 | 同 CHS |
| thread bresp 等待 | early resp，快速收齐 | 等远端确认，较慢 |
| write_done 发送时机 | bresp 收齐后 (快) | bresp 收齐后 (慢) |
对集合通信的影响
[推导] Ring AllReduce 中每步使用 transfer 搬运数据时:
- CHS: 每步延迟约等于 chunk_size / bandwidth，步间无显著间隙
- CFS: 每步延迟约等于 chunk_size / bandwidth + 链路 RTT，步间有 RTT gap
- 对于 N-chip Ring 的 2*(N-1) 步，CFS 模式额外增加 2*(N-1) * RTT 的累积延迟
与 NoC 交互
44bit 地址空间
[DOC] CDMA 使用 44bit 地址编码：
[43:40]：portid，标识目标芯片/端口[39:0]：addr offset，片内地址偏移
addr[43:40] == 0 表示本片访问，!= 0 表示跨芯片访问，由 CLE 路由表解析目标 port。
D2D Group
[DOC] NoC 侧支持 3 组 D2D group，用于管理 Die 间（D2D）通信的路由和带宽分配。D2D Group 的完整描述（3 组配置、non-hash/hash 区间映射、RNSAM 实现）见 01_mac-id-routing.md §6.2。