跳到主要内容

ISSUE-028: G5 CDMA 指令流水化与 fence/msg 同步语义未对齐原始 spec

发现日期：2026-05-19 状态：已修复 类型：建模误差 影响范围：所有 collective 通信仿真 （Ring 系列本 thread Transfer 链被串行化偏慢；alltoall pairwise/bruck 跨 chip 数据同步缺失，MoE dispatch/combine 仿真精度受影响，TPS186 baseline 怀疑误差抵消）. 不影响纯 P2P Transfer 仿真。

问题现象​

G5 仿真器对 SG2262 CDMA 设计的 5 个核心 spec 设计点未对齐。这 5 项是同一套 spec 设计 （"指令切换不保证完成 + 软件用 fence/msg 显式保护"） 在不同侧面的表现，因此合并为一个 issue 追踪。

  1. L281 「指令切换不保证前置搬运完成」未建模

    • 当前 G5: cmd_id_dep 等 sync_id, sync_id 在 PAXI on_remote_done 推进 (tier6/cdma/callbacks.rs:23) → 同 thread 上 cmd_id_dep 串成的链让本 thread Transfer 串行化执行
    • spec 描述：指令切换可以在前置搬运未完成时进行，由 fence 显式保护数据依赖

  2. L77 / L141 「指令切换支持流水」未实现

    • spec changelog (L77) + 规格条目 (L141) 明确承诺支持指令流水
    • G5-CDMA 建模设计规格 §硬件参数对照表已标注 "单笔 busy_until", disp_fifo / inst_fifo 无流水化

  3. L371 「write+msg 跨 chip 同步」未在 alltoall 应用

    • Ring/Halving 系列 collective 已用 Transfer + cmd_id_dep_remote + RemoteMsgSend + MsgWait 模式 (collective/helpers.rs:255 注释明确指向 spec L132/L193 write_done sideband)
    • collective/alltoall.rs:42-44 Pairwise：所有 Transfer cmd_id_dep = NO_DEP, N-1 个 Transfer 并发 dispatch，无任何跨 chip 同步
    • collective/alltoall.rs:95-119 Bruck：仅本地 cmd_id_dep，无 cmd_id_dep_remote 也无 MsgWait，跨 step 远端数据到达依赖未建模

  4. L297 「CFS 模式软件 emit fence」未实现

    • mapping 层 perfmodel/mapping/g5/program.py:57 仅有 CDMAOpType.FENCE = auto() 枚举定义
    • 全项目 grep OpType.FENCE / emit_fence / \.fence\( 零匹配，无任何上游产生 Fence cmd
    • Rust 侧 Fence 状态机已实现但无下游 emit，当前依赖 Ring 系列用 msg 替代，CFS 路径下本 thread 内连续 Transfer 数据依赖场景未覆盖

  5. L128-129 「fence bit modifier」未建模

    • spec L128-129: "对于 sys, fence, send 指令默认携带 fence 指令，除 sys, fence, send 指令外携带 fence bit 可以译码为指令+fence 指令"
    • G5 的 CDMACommand 无 fence_bit 字段，仅支持独立的 CDMAOpType::Fence

量化偏差​

  • TPS186 baseline 验证 (docs/validation/通信原语评估-TPS186/comm-primitive.md L206-207):
    • MoE dispatch (pairwise, N=64, 0.875 MB, single-switch): G5/Math = 1.13x
    • MoE combine (pairwise, N=64, 1.75 MB, single-switch): G5/Math = 1.00x
  • 现有文档 (L217) 归因为 "switch 端口 64 路 hash 散布瞬时排队尾部". 本次排查发现可能是两个误差抵消的巧合：
    • alltoall 缺跨 chip 同步 → 偏快
    • 本 thread Transfer 链串行化 + 端口排队 → 偏慢
    • 净效果 ≈ Math
  • 换拓扑 （fat-tree 多跳 / 多 board） 后排队特征改变，误差方向会暴露
  • Bruck 算法无任何 G5 vs Math 对照测试 (alltoall.rs 现有测试仅 cmd_count / destination / send_counts)，偏差方向不可判断

调查过程​

  • [查 spec] 读 SG2262 C2C 方案.md + 2262 CDMA spec v2.2.md → 定位 L37, L71, L77, L78, L126, L128-129, L141, L281, L297, L298, L371, L440-441, L466-490
  • [查 spec] 读 docs/specs/G5仿真建模/G5-CDMA建模设计规格.md → 确认 sync_id 推进时机 + WRR Phase 2 待办 + 硬件参数对照表标注 "单笔 busy_until"
  • [查代码] 追踪 perfmodel/evaluation/g5/src/collective/helpers.rs:174-279 expand_ring_steps → Ring 系列用 write+msg 模式 (Transfer + cmd_id_dep_remote + RemoteMsgSend + MsgWait)
  • [查代码] 追踪 perfmodel/evaluation/g5/src/collective/alltoall.rs:42-44 / 95-119 → alltoall Pairwise/Bruck 未用 write+msg，无跨 chip 同步
  • [查代码] 追踪 perfmodel/evaluation/g5/src/tier6/cdma/callbacks.rs:23 on_remote_done → sync_id 推进时机锁定本 thread cmd 串行
  • [查代码] 全项目 grep OpType\.FENCE / emit_fence / \.fence\( → 零匹配
  • [查 spec] 读 docs/interconnect/04-集合通信/09-all-to-all.md:147-151 → 公式 T_pairwise = (N-1)·α + (N-1)M/(Nβ) 隐含 step-major 同步推进，与 G5 当前 NO_DEP 实现不一致
  • [查代码] 默认算法核对：baseline_sweep.py:75 / verify_tps186.py:28-29 / run_eval.py:686 确认 alltoall 默认走 pairwise, MoE dispatch/combine 也用 pairwise
  • [与用户讨论确认] msg 与 fence 是 spec 中两个独立同步体系：msg 是跨 chip 事件到达 (msg_central + A4S), fence 是本 thread 内 bresp 屏障。不互替

根因分析​

5 项 spec 缺口是同一套设计的不同侧面：

侧面spec 设计G5 缺口
流水化语义L281 指令切换不保证完成sync_id 等 PAXI 完成 → 本 thread Transfer 链串行化
流水化实现L77 / L141 datapath 流水"单笔 busy_until"，无流水
跨 chip 同步L371 write+msg 替代 Send/Receivealltoall.rs 未用
本 thread 同步L297 软件插 fencemapping 层无人 emit
指令编码L128-129 fence bit modifierCDMACommand 无 fence_bit 字段

根因：G5 早期实现按 "保守串行" 模型建模，没有承担 SG2262 spec 流水化设计的完整责任 （指令切换不保证完成 + 由软件用 fence/msg 显式保护）. 流水化语义缺失让本 thread Transfer 链串行化，5 项缺口呈现为系统性偏差。

Spec / 文档依据​

原始 Spec （SG2262 硬件文档）：

L77 (changelog)：指令切换调整为支持流水。调整指令传输结构，支持指令流水。考虑相同指令以及不同指令切换时指令流水的实现方式。考虑 datapath 的指令流水实现方式。 — 2262 CDMA spec v2.2.md

L141：指令切换做成流水形式 — 2262 CDMA spec v2.2.md

L128-129：对于 sys, fence, send 指令默认携带 fence 指令，除 sys, fence, send 指令外携带 fence bit 可以译码为指令+fence 指令 — 2262 CDMA spec v2.2.md

L281: SG2262 CDMA 需要支持 fence 指令。在搬运指令执行过程中指令切换将不再保证前置指令搬运全部完成，改而由 fence 指令确保 fence 指令之后的所有搬运指令执行之前已经完成了 fence 指令之前的所有搬运指令的所有搬运。 — SG2262 C2C 方案.md

L297：软件在需要保序的位置插入 fence 指令。 — SG2262 C2C 方案.md

L371：通过 Send/Receive 配对，可完成发送芯片和接收芯片的同步。需注意，如果芯片不支持 Send/Receive，也可通过 write+msg 的方式替代，且无须软件参与，但是芯片之间交互的地址需在运行模型之前预分配好，并且所有芯片的片间交互地址应相同。 — SG2262 C2C 方案.md

项目 Spec：

docs/specs/G5仿真建模/G5-CDMA建模设计规格.md §硬件参数对照表 已标注 "单笔 busy_until" （流水化未实现） + WRR Phase 2 待办

docs/interconnect/04-集合通信/09-all-to-all.md:147-151 T_pairwise = (N-1)·α + (N-1)M/(Nβ) — 公式隐含 step-major 同步推进，与 G5 当前 alltoall NO_DEP 实现不一致

docs/specs/G5仿真建模/G5-CDMA建模设计规格.md §跨 chip 数据到达依赖 + helpers.rs:255 注释 已确认 Ring 系列采用 spec L371 write+msg 路径，对齐 spec L132/L193 write_done sideband

未解决：

  • spec L490 「目前 disp_fifo 深度为 1, 考虑做成指令流水形式」 — spec 自身未冻结具体 fifo 深度方案，本 issue 不覆盖流水化的具体 fifo 模型
  • CHS 保序窗口独立路径：当前 G5 选 CFS 路径覆盖 (write+msg), CHS post-write 保序窗口未独立建模，留作未来工作

解决方案​

实际修复 (v1.4.2)​

调查过程中发现原始问题分析过度泛化：5 项 spec 缺口中，第 3 项 (alltoall write+msg) 的 Pairwise 部分是 spec 自身的分类错误，不是代码漏实现。

根因修正：spec v1.4.1 §collective 实现约束 (L308-L320) 将 Pairwise AllToAll 归入 "需要 write+msg 跨 step 同步" 类别。但 Pairwise 算法中 chunk c[i][(i+r)%N] 在 collective 开始前已在本 chip 内存准备好，不依赖任何先前 step 接收的数据，属于 "算法层独立型". 按错误 spec 实现 write+msg 后，每 step 被 MsgWait 串行化、且所有 Transfer 被限制在单 CDMA thread，导致 MoE dispatch/combine 仿真延迟暴增 +335%/+248%.

实际改动：

文件改动
docs/specs/G5仿真建模/G5-CDMA建模设计规格.mdv1.4.1 → v1.4.2: §collective 实现约束 完整重写为两分类 （跨 step 数据依赖型 vs 算法层独立型）
perfmodel/evaluation/g5/src/collective/alltoall.rsPairwise 回滚为 NO_DEP 单向 Transfer + 多 CDMA thread 分发；Bruck write+msg 保留不变
perfmodel/evaluation/g5/src/collective/expand.rstest_alltoall_default_pairwise 期望值 32 → 12
perfmodel/evaluation/g5/src/collective/tree_allreduce.rstest_alltoall_4chips 期望值 26 → 12

其余 4 项 （流水化语义/实现/fence emit/fence bit） 的 Ring 系列改进 （sync_id 推进时机 + inst_fifo + fence_bit 字段） 在本 issue 前序提交中已完成，效果保留。

验证​

单元测试​

cargo test 325/325 PASS （含 alltoall 新增的 Pairwise NO_DEP 断言 + Bruck write+msg 断言 + send_counts 测试）.

TPS186 Baseline (verify_tps186.py)​

Case算法修复前 G5/Math修复后 G5/Math变化
Dense_MLP AllReduce N=2Ringbaseline-9.3%Ring sync_id 改进
MLA AllGather N=2Ringbaseline-18.4%Ring sync_id 改进
MLA ReduceScatter N=2Ringbaseline-16.0%Ring sync_id 改进
MoE dispatch N=64Pairwise+335%-13.8%Pairwise 回滚 NO_DEP
MoE combine N=64Pairwise+248%-7.4%Pairwise 回滚 NO_DEP

所有 5 个 case 均优于修复前 baseline.

遗留问题​

  • disp_fifo / inst_fifo 深度方案 (spec L490): spec 自身标注 "考虑做成"，未冻结具体深度。等 spec 更新后另立 issue
  • CDMA spec 对齐待查项：每线程 msg_send + msg_wait 上限 (L126) / scatter 子功能 MSG/atomic/CPS/ARE/2D 覆盖度 / 动态 OSTD 256B / 512B / bresp 拼包 c2c_sys_top CAM merge / write_completion 指令。建议另立 ISSUE-030 "CDMA spec 对齐待查项" 逐项核对
  • WRR + 三切换条件：G5-CDMA 建模设计规格已标 Phase 2 待办，不在本 issue 范围
  • CHS 保序窗口独立路径：当前 G5 选 CFS 路径覆盖，CHS post-write 保序窗口未独立建模，留作未来工作