架构仿真器全景¶
架构仿真不是为了生成一个“看起来很准”的性能数字，而是用可控模型回答设计问题。先确定问题需要的抽象层和精度，再选工具；越详细的模型通常越慢、参数越多，也越容易产生伪精确。
四类模型¶
flowchart LR
F[功能仿真<br/>结果是否正确] --> T[Trace 驱动<br/>固定指令/事件流]
T --> C[时序/周期模型<br/>资源冲突与延迟]
C --> P[RTL/电路级<br/>实现与时序收敛]
A[解析/代价模型<br/>公式 + 映射] -. 快速设计空间搜索 .-> T| 类型 | 主要输入 | 主要输出 | 适合回答 | 不适合直接回答 |
|---|---|---|---|---|
| 功能仿真 | 程序、ISA/设备模型 | 执行结果、事件 | 指令语义是否正确，软件能否运行 | 精确周期与功耗 |
| Trace 驱动 | 预采集指令/访存 Trace | 吞吐、Cache/流水线统计 | 固定路径在不同配置下怎样变化 | 改 ISA 后动态行为、输入相关控制流 |
| 时序/周期模型 | 程序或 Trace + 微架构配置 | 周期、队列、争用 | Pipeline、Cache、NoC 和调度瓶颈 | 未建模的软件/物理效应 |
| 解析/代价模型 | 算子、映射、硬件参数 | 延迟、能耗、流量估计 | 大规模 Mapping/设计空间搜索 | 复杂动态控制和周期级瞬态 |
| RTL/电路级 | RTL、工艺与约束 | 周期、面积、功耗、时序 | 实现能否闭合，真实硬件代价 | 早期的大范围快速探索 |
工具如何分工¶
| 工具 | 主要对象 | 特点 | 典型问题 |
|---|---|---|---|
| gem5 | CPU、Cache、内存与完整系统 | 事件驱动；支持 Syscall Emulation 与 Full System 等模式 | Cache/内存改动、CPU 微架构、OS 交互如何影响性能？ |
| GPGPU-Sim / Accel-Sim | NVIDIA 风格 GPU | PTX 或 SASS Trace 前端 + 详细 GPU 性能模型 | Warp 调度、Cache、访存与核心配置对 kernel 有何影响？ |
| Timeloop / Accelergy | 张量加速器 | 解析模型、Mapping 搜索，估算性能/能耗 | Buffer 大小、阵列规模、Loop Mapping 如何权衡？ |
| MAESTRO | DNN 数据流 | 用数据复用与占用描述时空 Mapping | Weight/Output/Row Stationary 等数据流的流量与代价如何比较？ |
| SCALE-Sim | Systolic Array | 面向矩阵/卷积阵列的轻量周期估计 | 阵列尺寸与 Dataflow 如何影响利用率和带宽？ |
工具不是按名气选择
研究 A100 Warp Scheduler 或 Cache 行为时，Timeloop 的抽象通常过高；搜索 NPU 的 PE 阵列、Buffer 和 Dataflow 时，用完整 GPU 周期模拟又过重。先写清“要比较的设计变量”和“必须可信的指标”。
精度—速度—可解释性三角¶
flowchart TB
Q{研究问题} --> D[需要周期级争用?]
D -->|否| A[解析模型 / Roofline]
D -->|是| P[时序或 Trace 模型]
P --> OS[需要 OS / 驱动交互?]
OS -->|否| SE[应用/Kernel 级模拟]
OS -->|是| FS[Full-System 模拟]
A --> V[用少量实测校准]
SE --> V
FS --> V选择最小充分模型有三个好处：
- 速度：更容易覆盖不同形状、Mapping 与硬件配置。
- 可解释性：输出能回到明确的流量、资源占用和排队原因。
- 可验证性：较少的自由参数更容易通过微基准校准。
一个可复用的实验记录¶
| 项目 | 必须记录 |
|---|---|
| 问题 | 假设、对照组、唯一主要变量 |
| Workload | 模型/Kernel、输入形状、精度、软件版本、Trace 来源 |
| 架构 | 核心/阵列、频率、Cache/Buffer、带宽、拓扑、调度策略 |
| 仿真 | 工具 commit、配置文件、Warmup/ROI、随机种子 |
| 输出 | 周期、吞吐、流量、命中率、利用率、能耗及单位 |
| 校准 | 对应硬件、计时方法、误差分布与异常点 |
| 结论 | 哪些结论可推广，哪些只对当前模型和输入成立 |