【汽车芯片功能安全分析与故障注入实践 05】Architectural、RTL、Netlist 三个阶段的安全分析差异

作者： Darren H. Chen
方向： 汽车芯片功能安全分析与故障注入实践
Demo： D05_arch_rtl_netlist_flow
标签： 汽车芯片 功能安全 Architecture RTL Netlist FIT DC

Demo 说明

D05_arch_rtl_netlist_flow 的目标是说明同一个功能安全分析流程，在 Architecture、RTL、Gate-level Netlist 三个阶段分别能做什么、不能做什么，以及如何保持结果可对比。

对应的通用工具名称为：

text 复制代码

safeic-designstats

它的作用是把不同阶段的设计输入统一转化为 design_stats.json，供后续 BFR、FIT 模型、结构分析和 DC 计算使用。

1. 为什么要区分三个阶段

汽车芯片开发周期很长，功能安全分析不可能等到最终网表完成后才开始。

如果等到 gate-level netlist 才第一次看 FIT/DC，问题可能已经太晚：

text 复制代码

安全机制插入代价高
架构修改成本高
验证资源不足
故障注入周期过长

因此，功能安全分析应该贯穿三个阶段：

text 复制代码

Architectural Stage
RTL Stage
Gate-level Netlist Stage

每个阶段的目标不同。

阶段	主要目标	精度	工程价值
Architectural	早期估算风险和安全机制方向	低	快速决策
RTL	结构级分析和安全机制探索	中	指导设计修改
Netlist	最终指标验证和签核前证据	高	接近真实实现

2. Architectural 阶段：先用规模估算建立方向

Architecture 阶段通常还没有完整 RTL。

此时能输入的是：

text 复制代码

模块划分
寄存器数量估算
SRAM 容量
接口数量
安全机制规划
第三方 IP 估算值

例如：

yaml 复制代码

modules:
  cpu_ctrl:
    estimated_gates: 50000
    estimated_ff: 3000
    memory_bits: 0
  sram_subsystem:
    estimated_gates: 8000
    memory_bits: 262144
  bus_fabric:
    estimated_gates: 20000
    estimated_ff: 1200

Architecture 阶段不能精确判断每个 Endpoint 的结构贡献，但可以回答：

text 复制代码

风险主要来自逻辑还是 memory？
哪个模块需要优先考虑安全机制？
ASIL 目标是否可能达成？
是否需要 ECC、lockstep 或 end-to-end protection？

这个阶段的核心价值是早期方向，而不是最终精度。

3. RTL 阶段：开始进行结构化安全分析

RTL 阶段已经有设计文件，可以开始提取结构。

可做的事情包括：

text 复制代码

统计寄存器、memory、模块层次
识别潜在 startpoint / endpoint
估算 combinational cone
建立 failure mode library
建立 safety mechanism map
生成初步 fault list

RTL 阶段的优势是：

text 复制代码

设计还可以修改
安全机制还可以补充
仿真环境逐步成熟
VCD 可以开始产生

但 RTL 阶段也有局限：

text 复制代码

综合优化尚未发生
最终门级结构未知
某些 RTL 信号在 netlist 中会被重命名或优化
面积和门数只是估算

因此，RTL 分析适合做 safety exploration，而不是作为最终结论。

4. Netlist 阶段：接近真实实现的最终验证

Gate-level netlist 阶段有综合后的真实结构。

此时可以更准确地分析：

text 复制代码

真实标准单元数量
真实触发器数量
真实组合逻辑 cone
综合后 endpoint 名称
真实 fan-in / fan-out
安全机制是否被优化影响

Netlist 阶段适合做：

text 复制代码

最终 FIT/DC 计算
最终 fault list 生成
最终 fault campaign
fault result 回灌到 metric validation
FMEDA 报告定稿

但 netlist 阶段的缺点是：

text 复制代码

设计修改成本更高
fault campaign 规模更大
调试信号更难读
RTL 到 gate mapping 成为问题

所以正确方法不是只做 netlist 分析，而是三阶段逐步收敛。

5. 三阶段之间如何保持一致

如果三阶段各自输出完全不同格式，后续无法比较。

因此，safeic-designstats 要把三类输入统一成同一个输出接口：

text 复制代码

design_stats.json

示例：

json 复制代码

{
  "project": "automotive_safeic_practice",
  "demo": "D05_arch_rtl_netlist_flow",
  "stage": "rtl",
  "top": "toy_soc_top",
  "modules": [
    {
      "name": "u_cpu_ctrl",
      "gate_count": 12000,
      "sequential_count": 850,
      "memory_bits": 0,
      "blackbox": false
    },
    {
      "name": "u_sram",
      "gate_count": 500,
      "sequential_count": 20,
      "memory_bits": 8192,
      "blackbox": false
    }
  ]
}

无论输入来自 architecture count、RTL 解析还是 netlist 统计，后续工具都只消费这个统一结果。

6. 三阶段数据流架构

Architectural Count YAML
safeic-designstats
RTL Filelist
Gate-level Netlist
design_stats.arch.json
design_stats.rtl.json
design_stats.netlist.json
Stage Compare
stage_compare.csv
design_stats_summary.md

这个架构的关键是：

text 复制代码

不同阶段的输入不同
但输出接口一致

后续 FIT 模型、BFR、FMEDA、benchmark 都可以复用。

7. Stage Compare 为什么重要

三阶段结果应该逐步收敛，但不一定完全一致。

例如：

csv 复制代码

stage,gate_count,sequential_count,memory_bits,total_fit
arch,100000,6000,262144,0.80
rtl,112000,6200,262144,0.86
netlist,118500,6180,262144,0.89

这个对比能回答：

text 复制代码

RTL 相比 architecture 增加了多少风险？
netlist 综合后是否出现明显面积变化？
安全机制插入后是否增加了新的 FIT 贡献？
memory bit 是否和预期一致？

如果某个阶段差异很大，就需要追查：

text 复制代码

统计模型不同？
输入文件缺失？
某些模块被黑盒处理？
综合优化导致结构变化？
memory macro 统计方式不同？

8. RTL 到 Netlist 的名称映射问题

功能安全验证中一个非常实际的问题是：RTL 中的信号名在 netlist 中可能变化。

例如：

text 复制代码

RTL:     top.u_ctrl.state[0]
Netlist: top.u_ctrl.state_reg[0].Q

如果 fault list、observe point、SM map 基于 RTL 名称，而最终 fault campaign 基于 netlist，就需要映射关系。

可以使用一个简化 mapping 文件：

text 复制代码

rtl_name gate_name
top.u_ctrl.state[0] top.u_ctrl.state_reg[0].Q
top.u_ctrl.state[1] top.u_ctrl.state_reg[1].Q

D05 不需要完整解决 mapping 问题，但要在工具架构中预留接口。
RTL Signal
Name Mapping
Gate-level Node
Fault List / Observe Point

这个问题后续会影响 fault list 生成和最终指标验证。

9. D05 Demo 的目录建议

text 复制代码

D05_arch_rtl_netlist_flow/
  README.md
  run_demo.csh
  run_demo.sh
  inputs/
    arch_count.yaml
    rtl/
      toy_soc_top.v
      toy_ctrl.v
      toy_sram_wrapper.v
    filelist.f
    netlist/
      toy_soc_top_mapped.v
    rtl_to_gate.map
  outputs/
    design_stats.arch.json
    design_stats.rtl.json
    design_stats.netlist.json
    stage_compare.csv
    design_stats_summary.md
  scripts/
    safeic_designstats.py

运行方式：

bash 复制代码

python3 scripts/safeic_designstats.py \
  --arch inputs/arch_count.yaml \
  --rtl-filelist inputs/filelist.f \
  --netlist inputs/netlist/toy_soc_top_mapped.v \
  --out outputs

10. 和后续工具的关系

safeic-designstats 是多个后续工具的基础。
safeic-designstats
safeic-bfr
safeic-fitmodel
safeic-structure
safeic-epcont
safeic-benchmark

如果 design statistics 不稳定，后续所有结果都会不稳定。

因此，D05 的价值不是"多统计几个数字"，而是建立跨阶段一致的数据接口。

11. 方法论总结

汽车芯片功能安全分析不应该只发生在最终 netlist 阶段。

更合理的方法是：

text 复制代码

Architecture 阶段：快速估算，指导安全机制方向
RTL 阶段：结构探索，建立 SM map 和初步 fault list
Netlist 阶段：最终验证，支持 sign-off 前指标闭环

D05_arch_rtl_netlist_flow 的核心作用是把三阶段输入统一成 design_stats.json，让后续 FIT、DC、Fault Campaign 和 Benchmark 都能复用。

这也是从"文章 + Demo"走向"工程实践平台"的关键一步。