VCD/SAIF/FSDB：活动数据怎样从仿真台一路活到功耗签核（F6）
DPA 的 VCD/SAIF 格式篇讲字段；本篇沿数据流讲生命周期与溯源：S1 为调试随手录的一段波形，凭什么在几周后成为 S5 签核枢纽 里决定动态功耗与 IR-drop 的活动输入？中间格式怎么压缩、信息丢在哪、口径谁负责？
一、波形 → 活动率：一次有损压缩
- VCD：标准文本波形，记录每个信号每次跳变的时刻与新值，信息全但体积爆炸；
- FSDB（及 SHM/WLF 等厂商标配）：压缩二进制波形，主要为调试，也可转统计量；
- SAIF：不保留时间轴，只保留逐网/逐实例的统计——翻转次数（T0/T1）、0/1 静态概率、条件与状态活动，正是动态功耗
P∝α·C·V²·f需要的开关活动 α。
二、为什么「代表性 testcase」是本站的命门
功耗工具不会判断活动是否典型，它只忠实反标。录的是复位后空转，全芯片活动率极低，签出的动态功耗与 IR-drop 全是假乐观；录的是极端压力场景，又可能过悲观导致过度加 decap、面积爆掉。因此 S1 就必须约定一组覆盖典型工作模式的 testcase（正常业务、高峰吞吐、待机、低功耗模式各一），并随活动数据记录：
- 时段口径：取稳态窗口还是含启动瞬态；时钟门控是否生效；
- 层次口径：从 RTL 反标还是门级反标（门级含真实毛刺更准）；
- 模式标签：对应哪个 functional mode/power state，进 MMMC 的哪个场景。
三、活动缺失时的兜底链（最容易静默失真）
门级网表里总有节点没被任何反标覆盖（黑盒 IP、未激励块、时钟网络）。功耗工具按优先级兜底：annotated（实测反标）→ propagated（从已知点传播推断）→ state/默认表 → 全局默认翻转率。越往后越「拍脑袋」。发布活动数据时必须给出反标覆盖率，并对高比例走默认值的模块单独标红——一个全芯片 95% 反标、但关键时钟模块走默认 0.1 翻转率的结果，不能签收。
四、glitch 与时钟活动：两个专门陷阱
- 毛刺（glitch）活动：组合逻辑的非功能性跳变也烧功耗。RTL 级活动天然看不到 glitch；要可信的动态功耗，关键数据通路应在布线后网表 + SDF 上跑门级活动（与 F5 SPEF/SDF 衔接）。
- 时钟网络活动：时钟树翻转率通常直接按频率推导而非波形反标，时钟门控使能率必须来自真实场景，否则占芯片功耗大头的时钟功耗会错。
五、数据契约：随活动数据一起交付的元信息
| 项 | 内容 |
|---|---|
| 溯源 | testcase 名、RTL/网表版本、seed、仿真器与选项 |
| 口径 | 时间窗口、层次（RTL/gate）、SDF 版本 |
| 覆盖 | 反标覆盖率、默认/传播兜底占比、未覆盖清单 |
| 模式 | functional mode / power state、对应 MMMC 场景 |
| 责任 | 活动提供方与功耗签收方双签 |
六、典型交接事故
| 事故 | 根因 | 拦截 |
|---|---|---|
| 功耗假乐观 | 用复位空转波形当活动 | S1 锁定代表性 testcase 集合 |
| 关键块走默认值 | 反标覆盖率低未报告 | 强制覆盖率 + 未覆盖清单标红 |
| 毛刺功耗缺失 | 用 RTL 活动签动态功耗 | 关键路径用门级+SDF 活动 |
| 模式错配 | 活动模式与签核场景不符 | 活动带模式标签进 MMMC |
| 时段口径之争 | 启动瞬态算没算没记录 | 时间窗口写入元信息并双签 |
相关与延伸
- 消费方：S5 签核枢纽；来源：S1 RTL。
- 字段定义：VCD/SAIF 数据格式、波形数据库横评；门级时序来源见 F5 SPEF/SDF。
总结
活动数据是一次「波形→统计」的有损压缩，真正决定功耗可信度的不是格式而是口径：用哪一段代表性 testcase、RTL 还是门级、反标覆盖率多少、对应哪个模式；这些元信息必须随 SAIF 一起从 S1 溯源到 S5，否则功耗工具只会精确地给出一个错误答案。