G5 落地示例

把 02-08 的概念落到 SystemC AT 实现——架构骨架、三资源域设计、与上层 DES 接口、MVP 路径

核心要点:

四层模块层级:Chip → Die → Tile → Unit,AccTLMSim / NNSim 实证,后者 vs RTL 加速 3,000-13,000×

AT 4-phase 是边界协议:BEGIN_REQ → END_REQ → BEGIN_RESP → END_RESP(Accellera LRM verbatim)

混合精度策略:compute 用 LT、NoC / HBM / chiplet 边界用 AT——AT 的杀手级用例不在 compute 域

DRAM 后端三选一:DRAMsim3 / Ramulator 2.0 / DRAMSys(SystemC-native,首选)

与上层 DES 接口范本:AstraComputeAPI(get_static_runtime + simulate(...)),Chakra Node.duration_micros 作 trace

MVP 路径不要一上来全建:单 matmul → compute 闭环 → 加 memory → 加 interconnect,每步可验证

名词定义

名词	定义
SC_MODULE	SystemC 模块基础单元
Generic Payload	TLM-2.0 标准事务对象,字段含 command / address / data / length / phase / response
AT 4-phase	BEGIN_REQ → END_REQ → BEGIN_RESP → END_RESP,Approximately-Timed 协议
Temporal decoupling	让某模块在 quantum 时间内"领先"全局时间运行,减少 context switch
Quantum Keeper	管理 temporal decoupling 中各模块本地时间与全局时间偏差的对象
`nb_transport_fw/bw`	非阻塞 forward / backward 传输,AT 模式核心 API
`tlm_extension<T>`	Generic Payload 的派生扩展,用于附加 LLM workload 字段

本篇范围

本篇是综合落地章——把 02-08 的概念用 SystemC AT 实现时的具体设计选择讲清楚。基于业界公开实证(NNSim / AccTLMSim / FLECSim-SoC / ASTRA-sim AstraComputeAPI / Chakra),不引用任何项目代码。

包含:

SystemC AT 架构骨架(模块层级、时钟域、混合精度策略)
三资源域(compute / memory / interconnect)落地到 SystemC AT 的具体设计
与上层算子级 DES 的接口与 feedback loop
MVP 路径与调试可观测性
仿真速度优化

不包含:

具体代码实现——本篇给设计选择,不给完整代码
各资源域的概念性内容——已在 02 / 03 / 04 篇覆盖
标定与验证方法论——见 08 篇

SystemC AT 架构骨架

模块层级

AccTLMSim[1]、NNSim[2]、FLECSim-SoC 一致呈现四层模块层级:

Chip
  ├── Die / Cluster
  │     ├── Tile
  │     │     ├── PEArray         (compute 域)
  │     │     ├── OnChipSRAM      (memory 域,scratchpad)
  │     │     └── DMAController   (memory 域,搬数据)
  │     ├── NoCRouter             (interconnect 域)
  │     └── MemController         (memory 域,HBM 接口)

@tbl-ipm-g5-module-hierarchy 典型 cycle-approx perf model 的模块层级

NNSim 这种结构实测 vs RTL 加速 3,000-13,000×,是 SystemC AT 在 AI 芯片建模的工业精度区间。

时钟域管理

三个独立 sc_clock:

compute 时钟(PE 阵列)
NoC 时钟(片内互联)
HBM 时钟(内存控制器)

SystemC 调度器用单一事件队列统一管理这三个时钟,无需显式跨域同步——这是 SystemC LT 内部可安全跨域的根本原因。跨域 AT 事务通过 nb_transport 的 sc_time& delay 参数注入各域延迟,gem5-SystemC 集成(SAMOS 2017)用 Gem5MasterTransactor 桥接模块处理 timing protocol 到 TLM 的映射。

混合 AT / LT 精度策略

关键判断:AT 的杀手级用例不在 compute 域(02 篇与 04 篇结论一致)。工程上常用混合精度:

域	精度模式	理由
Compute(PE 内部)	LT(`b_transport` + delay)	计算单元内部不需要非阻塞事务流,无背压需求
NoC / 路由	AT(`nb_transport` 4-phase)	多 router 异步交互、credit 流控、背压传播
HBM / DRAM 控制器	AT 4-phase	bank conflict、refresh、队列调度需要事件级精度
Chiplet 边界(UCIe)	AT 4-phase + back-pressure	D2D 链路 stall 确定性传播

@tbl-ipm-g5-mixed-precision 混合 AT / LT 精度策略

AT 4-phase 的 verbatim 行为(Accellera LRM):BEGIN_REQ / BEGIN_RESP 端到端传播,END_REQ / END_RESP 仅 local hop 流控。nb_transport_fw 签名:

tlm_sync_enum nb_transport_fw(tlm_generic_payload&, tlm_phase&, sc_time&);

返回值是 TLM_ACCEPTED / TLM_UPDATED / TLM_COMPLETED 三档。

Generic Payload 的 LLM 扩展

标准字段(command / address / data / length)以内存映射总线为语义,LLM workload 需通过 tlm_extension<T> 附加:

layer_id:transformer 层 ID
seq_len:当前 KV 长度
op_type:GEMM / GEMV / Attention / Softmax
flop_count:算子 FLOPs
compute_latency:解析模型给出的时长

IEEE 1666-2011 推荐用扩展而非继承 Generic Payload——这是 SystemC 社区共识,继承会破坏跨模块兼容。

Compute 域落地

PE 阵列 Module 设计

NNSim 的可 verify 参考:

PE 阵列作为 TLM-2.0 target,以 simple_target_socket 对外暴露
内部 SC_THREAD 执行算子时长解析公式,不模拟逐 PE 逐 cycle
在 socket 边界保持 cycle-accurate 时序,跳过模块内部 MAC array 实际计算

这是 cycle-approx 档"内部 analytical / 边界 cycle-accurate"的具体落实。

Tile 调度与启动税

SCALE-Sim 公式(Axon 论文 arXiv 2501.06043 verbatim 引用):

$$\begin{equation} \tau = 2S_R + S_C + T - 2 \label{eq:ipm-g5-scalesim-tau} \end{equation}$$

其中 $S_R \times S_C$ 是阵列维度,$T$ 是时域累加深度,$(2S_R + S_C - 2)$ 是 pipeline fill + drain 启动税。

SystemC AT 集成方式:在 b_transport() 或其调用函数中:

wait(τ * period / η)

其中 $\eta$ 是 02 篇的效率因子,作为构造参数静态注入——不进入 TLM payload 或相位逻辑。SCALE-Sim v3 的两遍法等价为 compute 延迟 + memory stall 分层叠加。

三种 stationary dataflow 的映射

SCALE-Sim 的 Output-Stationary / Weight-Stationary / Input-Stationary 三种 dataflow,在 SystemC AT 里只改 $S_R$、$S_C$、$T$ 的语义映射(GEMM 三维 M / N / K 哪一维归到空间轴),不改公式结构。

η 注入点

静态 η 作为 PE 模块构造参数注入,应用于 b_transport() 内的计时公式。动态 η(随负载变化)需要 memory 域回调,属于跨 facet 边界问题,工程上常退化为静态 η + 算子分桶。

AT 4-phase 在 compute 边界的并发

TLM-2.0 LRM §14 verbatim:每时最多一个 in-flight request 和一个 in-flight response,但两者可重叠——对应 systolic array fill / drain 流水。END_REQ 后 initiator 可发下一 BEGIN_REQ,实现多 tile in-flight。AT 相比 LT blocking transport 的优势正在此并发能力。

Memory 域落地

SRAM Scratchpad 设计

SC_MODULE + tlm_utils::simple_target_socket
b_transport 回调实现读写,timing delay 累加到 sc_time 参数
多 bank 用地址高位 decode + 每 bank 独立 socket 表达多读写口
容量约束在 AccTLMSim 框架中用于 loop tiling 验证

AI 加速器 scratchpad 与 GPU shared memory 的关键差异:前者软件显式 DMA 管理,无替换逻辑,不建 tag / valid / dirty——这是 03 Memory 篇结论的具体落实。

DMA 引擎两种模式

Descriptor-based:

sc_fifo<DmaDesc> + SC_THREAD
每次从队列取 descriptor,用 b_transport 或 nb_transport_fw 向 HBM 发 TLM transaction
适合流式 prefetch 管线

Trigger-based:

sc_event 驱动
compute tile 完成后 notify() 触发搬运
适合固定 dataflow

工程上两种常并存——descriptor 主路 + trigger 辅助同步。

HBM 控制器:三选一后端

cycle-approx 档的 DRAM 仿真不重造轮子,接成熟工具:

后端	集成方式	适用
DRAMsim3[3]	`MemorySystem(config, dir, read_cb, write_cb)` + `AddTransaction(addr, is_write)` + `ClockTick()`,SystemC wrapper 以 `sc_clock` 驱动	主流,gem5 集成成熟
Ramulator 2.0[4]	`libramulator.so` + `Factory::create_frontend()` + `receive_external_requests(type, addr, ctx_id, lambda)` + `Request::callback`	协议覆盖最广(DDR5 / LPDDR5 / HBM3 / GDDR6)
DRAMSys(Fraunhofer IESE)	SystemC-native TLM-2.0 target,无需 wrapper	SystemC-first 场景首选

@tbl-ipm-g5-dram-backends DRAM 控制器后端三选一

AT 4-phase Cache Fill

nb_transport_fw 返回 TLM_ACCEPTED(Type A target),timing 以 sc_time 注解传递,不 wait():

BEGIN_REQ(fw):initiator 发请求
END_REQ(bw):target 解除 req-lock,initiator 可发下一请求
BEGIN_RESP(bw):数据就绪
END_RESP(fw):initiator 消费完

DMA 作 TLM initiator,HBM Controller 作 TLM target,内部调 DRAM sim API。完成回调触发 nb_transport_bw(BEGIN_RESP)。

背压与容量约束

背压实现:WillAcceptTransaction() 或 receive_external_requests() 返回 false 时延迟 END_REQ,自然实现限速。DMA 完成后 sc_event.notify() 通知 compute tile,支持 double-buffer 流水。

容量约束:scratchpad / KV cache 容量在模块构造时静态指定,超出时:

简单退化:报错退出(MVP 阶段够用)
工程化:fallback 到 DRAM(模拟 spillover 延迟)

容量墙公式见 03 篇。

Interconnect 域落地

NoC Router 4-stage Pipeline

NoC router 的标准 4-stage pipeline:RC(Route Compute)→ VA(VC Allocation)→ SA(Switch Allocation)→ ST(Switch Traversal)。SystemC AT 实现:

每阶段映射为一个 SC_THREAD(不能 SC_METHOD——后者无法 suspend)
通过 wait(time) 注入阶段延迟
VC buffer:sc_fifo<Flit> vc_buf[NUM_VC] + VC 状态机(IDLE / ROUTING / ACTIVE)

Credit-based flow control:

sc_signal<bool> 或 sc_fifo<int> 实现 credit-return channel
SA stage 检查 credit_count[out_vc] > 0 才授权 flit
下游出队时回传 credit
buffer depth 规则:≥ 链路往返延迟(RTT)

C2C 链路抽象

NVLink 类 C2C 链路(128-bit flit,1-18 flit/packet):

flit-level AT:每次 nb_transport_fw/bw 对应一个 flit,BEGIN_REQ 标注序列化延迟,credit 耗尽时保持 BEGIN_REQ 直到 credit-return 到达
message-level AT:成本更低但丢失 per-flit credit 停顿精度,仅当 credit pool >> max packet size 时可接受

工程取舍:对推理 perf model,message-level 通常够(decode 算子小、credit 不易满)。但跨 chiplet 与拥塞建模必须 flit-level。

集合通信原语

无专用 SystemC AT 集合通信后端。业界分层:

ASTRA-sim System layer 拆 ring-allreduce 为 (N-1) reduce-scatter + (N-1) allgather 步,每步 chunk 传输是一次 send 调用
SystemC AT 仅负责该 send 的物理链路 timing
ASTRA-sim 2.0 引入 Chakra Execution Trace(send / recv 节点依赖图),算法规格与仿真引擎解耦

这意味着 G5 的 SystemC AT 不需要重新实现集合通信算法,只需提供单次 send / recv 的精确 timing,算法层交给 ASTRA-sim 或类似工具。

Chiplet 边界(UCIe FDI)

UCIe 1.1 FDI 接口的四信号握手:

valid / bits / ready / irdy
Stall back-pressure 确定性 1-cycle 传播:plStallReq → 1 拍 → lpStallAck
D2D adapter 层 credit 在初始化参数协商时交换,无 credit 禁止发送

SystemC AT 映射:FDI flit 传输 = 一次 nb_transport 周期,stall 期间持续保持 END_REQ。这是 07 多目标与异构篇中 chiplet 边界判据的具体实现。

Garnet 3.0 协同

Garnet 3.0 是 gem5 Ruby 子系统的一部分,不可独立封装为 SystemC AT module。当 gem5 在 SystemC 内运行时,Garnet 隐式工作在 gem5 event queue 内,SystemC 侧在 memory port 边界只见聚合延迟。

实用耦合模式:

SystemC AT master → TLM socket → Gem5MasterTransactor → gem5 Ruby/Garnet 3.0

适合复用现成 NoC 模型,但要接受 gem5 与 SystemC 双引擎的协同开销。

与算子级 DES 的接口

cycle-approx 的输出只有上层 DES 消费才有意义。这一节给标准接口范本。

Kernel 时长导出格式

最小接口:(op_id, duration_ns)——ASTRA-sim Roofline 后端就用这一档。

扩展三元组(LLMCompass[5]):

(duration_ns, avg_power_W, hw_utilization_ratio)

是文献中记录最完整的 cycle-approx → DES 接口格式。

AstraComputeAPI 范本

AstraComputeAPI 是最完整的公开接口范本(verbatim 自 GitHub astra-sim/astra-sim):

class AstraComputeAPI {
  // 同步:立即返回时长
  virtual timespec_t get_static_runtime(ComputeKernel&) = 0;

  // 异步:回调通知时长
  virtual void simulate(
      ComputeKernel& kernel,
      Sys* sys,
      Callable callback,
      meta_t* meta) = 0;
};

输入是类型 + 属性 map(ComputeKernel),输出只有时长——功率 / 利用率刻意不进此结构,保持核心接口最小化。工厂方法封装 map 构造(如 create_llama_attn(batch, seq_len, ...))。

Chakra Trace 接口

Chakra(MLCommons)proto Node 的 duration_micros 字段(uint64,微秒)是 cycle-approx 插入点:

字段	类型	用途
`duration_micros`	uint64	cycle-approx 写入
`start_time_micros`	uint64	DES 动态赋值
`NodeType`	enum(8 类)	COMP_NODE / COMM_COLL_NODE 等
`data_deps` / `ctrl_deps`	edge list	DAG 依赖

@tbl-ipm-g5-chakra-fields Chakra Node 关键字段

Chakra 的价值是解除 cycle-approx 工具与 DES 的点对点耦合——任何符合 Chakra schema 的工具都可互换。

Feedback Loop

cycle-approx 与 DES 不是单向喂养,而是 feedback 循环。三层工程化:

按算术强度分桶采样:memory / compute / balanced 各 10-20 个代表性点跑 cycle-approx
拟合 $\eta$ per-optype 向量:$\eta = T_{\text{roofline}} / T_{\text{cycle-approx}}$,注入 DES
DES 扫描中 Z-score > 2 的 outlier 回触发 cycle-approx 精确标定,更新 LUT / RF,不重跑全量

已知局限:$\eta$ 需随硬件固件版本重标定——这是范式有向图(01 总览)的实践代价。

MVP 路径

新人最常踩的坑:一上来全建,迟迟跑不通。正确顺序是渐进闭环,每步可验证:

步	内容	验证标志
1	单 matmul kernel + PE 阵列 + scratchpad,无 NoC、无 HBM	算子时长输出 vs SCALE-Sim 公式
2	加 DMA + 简化 HBM(固定 latency 模型)	KV 读延迟在合理区间
3	加 DRAM 控制器(DRAMSys 或 DRAMsim3)	bank conflict / refresh 出现
4	加 NoC + 多 tile 并发	多 tile in-flight 数 > 1
5	加 c2c / chiplet 边界	跨 chiplet 通信延迟可测
6	接 Chakra trace 喂上层 DES	DES 端到端 TTFT / TPOT 输出

@tbl-ipm-g5-mvp-path SystemC AT G5 建模的 MVP 渐进路径

每步定可验证输出(单一 latency 数字),才能定位是哪一层引入的误差。Step 1-2 完成 = MVP 闭环,已经能给 02 / 03 篇的内容做交叉验证。

仿真速度优化与调试可观测性

速度优化

手法	收益	注意
Temporal decoupling + Quantum Keeper	减少 context switch	quantum 建议对齐一次 matmul tile $\sim 10\text{-}100$ ns
LT 内部避免显式 `wait()`	减少调度开销	仅 AT 边界 `wait`
Multi-threading 并行仿真	多 Die / Tile 实例分线程	需要 SystemC 多线程扩展(非标准 SC)
Prefill / Decode 用不同精度	prefill compute-bound 可 LT,decode memory-bound 用 AT	标定时口径要一致

@tbl-ipm-g5-speed-opt SystemC AT 仿真速度优化手法

调试可观测性

AT 模型没有波形,需要替代手段:

sc_trace:对关键信号(credit count、buffer 占用、TLM phase)生成 VCD,GTKWave 查看
Phase 日志:在 nb_transport_fw/bw 入口打印 phase 转换,确认 4-phase 顺序正确
Overlap 验证:专门日志记录 compute 节点与 communication 节点的 [start_time, end_time] 区间,事后画 Gantt 验证重叠是否真发生
资源占用追踪:每 quantum 输出各模块 utilization,定位瓶颈

陷阱:AT 不等于无时序——最常见误区是把 AT 当成 analytical 的"有代码版本",直接 wait(latency) 了事。AT 的价值在于资源争用与背压传播,这些必须靠 TLM socket 连接和 target 端 blocking transport 才能涌现。跳过这步 AT 退化成 "带 SystemC 语法的 analytical",精度无提升。

时间单位隐患

sc_time 默认 double 精度,但 LLM 推理通信时延跨度从 ns(片内 SRAM)到 μs(c2c 链路)。混用 SC_NS / SC_US 且没有统一换算入口,多模块集成时出现量级错误且不报错,只是仿真结果偏小。

工程纪律:整个项目统一基础单位为 SC_NS,所有 sc_time 构造经统一工厂函数,杜绝裸字面量。

标定与验证闭环

与 08 篇的方法论对接:

MVP 闭环(Step 1-2)对标 SCALE-Sim 解析公式,验证 compute 延迟
加 HBM(Step 3)对标 DRAMsim3 / Ramulator 独立运行结果,验证 memory 延迟
加 NoC(Step 4)对标 Garnet 独立运行结果,验证通信延迟
接 Chakra 喂 DES(Step 6)对标 ASTRA-sim 端到端,验证集成正确性
跨硬件外推前必须做 sensitivity analysis(08 篇),Pareto 稳定性 < 5% 差距下不可信

报告精度规范继承 08 篇:G5 输出必须含 max / P95 / P99,不能只给 avg——SimAI PP 77.2% 是反面教材。

升降档判据(G5 维度)

MVP 第一刀切到哪:单 matmul + compute 域(Step 1)——任何更复杂的起步都会卡住
加 cycle-approx DRAM 何时:回答"KV 带宽实际多少"、bank conflict 影响——简单 SLO 评估不需要
加 NoC 何时:回答"多 tile 通信延迟"、TP AllReduce 实际开销——单 chip 推理可省
加 chiplet 边界 AT 何时:回答"跨 die 通信瓶颈"——单 die 设计无需
不要把所有都升 AT:compute 域 LT + 边界 AT 是工程最优,全 AT 是常见过度设计

Takeaway

知识点	核心结论
模块层级	Chip → Die → Tile → Unit 四层,NNSim/AccTLMSim 实证
速度区间	SystemC AT vs RTL 加速 3,000-13,000×
AT 4-phase	BEGIN_REQ → END_REQ → BEGIN_RESP → END_RESP,Accellera LRM verbatim
混合精度	compute LT、NoC/HBM/chiplet 边界 AT,工程最优
Compute 落地	PE 阵列做 TLM target + SC_THREAD 跑 SCALE-Sim 公式 + η 静态注入
Memory 落地	scratchpad 显式管理 + DMA 两种 + DRAM 后端三选一(DRAMSys 首选)
Interconnect 落地	NoC 4-stage pipeline + c2c flit/message-level + 集合通信交给上层
与 DES 接口	AstraComputeAPI 范本 + Chakra trace + Z-score>2 outlier 回触发标定
MVP 路径	渐进 6 步,每步可验证,不要一上来全建
调试	sc_trace + phase log + Gantt overlap 验证;AT 不是带语法的 analytical

开放问题

G5 与 gem5 / SST 等其它 cycle-approx 框架的可移植性:接口标准(Chakra)解决了与上层 DES 的耦合,但底层资源域(NoC / DRAM)的可移植性仍是各家专有
动态 $\eta$ 在 SystemC AT 内的实现:静态 $\eta$ 是当前工程退化,动态(随负载变化)需要 memory 域回调,缺成熟模式
国产 AI 芯片的 SystemC AT 范例:寒武纪 / 壁仞 / 燧原 / 华为昇腾的 perf model 不公开,无法对标本篇结论
G5 自身的 P99 / 尾分布报告:08 篇强调精度报告必须含尾分布,但 cycle-approx 单次运行无法直接产出尾分布,需多次随机种子或 sensitivity 配合,工程化路径未充分研究

参考资料

AccTLMSim: Transaction-level Model Simulator for Communication-Limited Accelerators, 2020. https://arxiv.org/abs/2007.14897
Lee et al., NNSim: A Fast and Accurate SystemC/TLM Simulator for Deep Convolutional Neural Network Accelerators, IEEE VLSI-DAT 2019. https://ieeexplore.ieee.org/document/8741950/
Li et al., DRAMsim3: A Cycle-Accurate, Thermal-Capable DRAM Simulator, IEEE CAL 2020. https://github.com/umd-memsys/DRAMsim3
Luo et al., Ramulator 2.0: A Modern, Modular, and Extensible DRAM Simulator, IEEE LCA 2023. https://arxiv.org/abs/2308.11030
Zhang et al., LLMCompass: A Hardware Evaluation Framework for LLM Inference, ISCA 2024. https://arxiv.org/abs/2312.03134

名词定义​

本篇范围​

SystemC AT 架构骨架​

模块层级​

时钟域管理​

混合 AT / LT 精度策略​

Generic Payload 的 LLM 扩展​

Compute 域落地​

PE 阵列 Module 设计​

Tile 调度与启动税​

三种 stationary dataflow 的映射​

η 注入点​

AT 4-phase 在 compute 边界的并发​

Memory 域落地​

SRAM Scratchpad 设计​

DMA 引擎两种模式​

HBM 控制器:三选一后端​

AT 4-phase Cache Fill​

背压与容量约束​

Interconnect 域落地​

NoC Router 4-stage Pipeline​

C2C 链路抽象​

集合通信原语​

Chiplet 边界(UCIe FDI)​

Garnet 3.0 协同​

与算子级 DES 的接口​

Kernel 时长导出格式​

AstraComputeAPI 范本​

Chakra Trace 接口​

Feedback Loop​

MVP 路径​

仿真速度优化与调试可观测性​

速度优化​

调试可观测性​

时间单位隐患​

标定与验证闭环​

升降档判据(G5 维度)​

Takeaway​

开放问题​

参考资料​

延伸阅读​