DPA‑DB：Emulator 硬件仿真器的私有活动数据库
在 DPA 技术报告第 4 章 里，Emulator（如 Cadence Palladium、Synopsys Zebu）被定位为系统级动态功耗分析的主战场。它跑得动完整 SoC + 固件 + 操作系统，但有个关键设计：仿真时不算功耗，只把每个逻辑单元的翻转事件写进一个私有数据库，之后再离线算。这个数据库就是 DPA‑DB。
术语前置：DPA‑DB（Dynamic Power Analysis Database，动态功耗分析数据库）是硬件仿真器厂商定义的私有格式，存储带全局时间戳的单元级 toggle 活动，支持按时间窗口截取与离线重放，是 Emulator 做 DPA 的核心资产。
1 为什么不用 SAIF/VCD 直接存
Emulator 跑的是真实业务，周期量级可以到亿级。如果仿真过程中实时把活动写成 SAIF 或 VCD：
- 写盘带宽会拖垮仿真速度（仿真器最怕 I/O 卡脖子）；
- 长周期全量 SAIF 体积仍不可控。
所以 Emulator 的做法是用专用硬件逻辑在线采集 toggle，落进一个为高效追加写入设计的私有库（DPA‑DB），仿真照常满速跑；功耗计算完全挪到仿真结束后的离线阶段。这正是 报告 4.2 节 强调"仿真阶段不做功耗计算"的原因。
2 DPA‑DB 里装了什么
核心字段语义：
- 全局时间戳：Emulator 给所有采集事件打统一时钟，保证跨模块、跨电源域的活动能在同一时间轴上对齐（这点在多 FPGA 路线里极难，见 VCD/SAIF 文档）；
- 实例/电源域标识：记录这次翻转发生在哪个模块、哪个电源域，支撑后续分层功耗统计；
- toggle 事件流：每个单元每个周期的翻转类型（上升沿/下降沿），供离线折算翻转率。
3 在线采集与离线重放的分工
这个分工带来两个工程好处：
- 仿真不被拖慢：采集是硬件旁路，不影响 Emulator 主仿真速率；
- 一次采集、多次重算：同一个 DPA‑DB 可以换不同窗口、不同工艺角（不同
.lib）反复出报告，不用重跑仿真——这对 what‑if 对比极其友好（见 UPF/.lib/SDF 文档）。
4 窗口与触发：控制 DB 体积的关键
DPA‑DB 不是无限增长的黑盒。Runtime 工程师在采集时可以设：
- 时间窗口触发：只记某段业务（如 AI 推理的 10 秒）；
- 信号触发：用业务特征信号（如 "NPU 开始推理" 拉高）作为起点。
不设置的话，亿周期全量写库，磁盘很快写满——这正是 报告 5.7 节 Runtime 坑位清单 里"DPA‑DB 爆盘"那条的根因。合理配置后，DB 体积与窗口长度成正比，可控。
5 导出 SAIF 衔接后端
DPA‑DB 是厂商私有格式，后端 PrimePower 不一定直接认。常规动作是：
- 从 DPA‑DB 截出目标窗口；
- 后处理引擎把 toggle 折算成 SAIF（节点路径 + 翻转次数 + 时长）；
- 把 SAIF 交给 PrimePower/PT‑PX 做精细功耗与 IR‑Drop。
也就是说，DPA‑DB 是"源"，SAIF 是"给后端的交付物"，二者通过 Emulator 后处理衔接。链路详见 VCD/SAIF 文档。
6 一句话总结
DPA‑DB 是 Emulator 在线旁路采集、离线重放的私有活动库，用"仿真不算功耗、事后算"的设计保住仿真速度，又用窗口/触发控制体积，最终导出 SAIF 打通后端功耗分析。