作者： Darren H. Chen
方向： 汽车芯片功能安全分析与故障注入实践
Demo： D04_fit_standard_models
标签： 汽车芯片 功能安全 FIT模型 IEC62380 SN29500 Mission Profile

---

Demo 说明

D04_fit_standard_models 的目标是把 FIT 模型从“标准条文”转化为可配置、可审计、可替换的工程模块。

对应的通用工具名称为：

safeic-fitmodel

本 Demo 不追求一开始完整实现所有标准细节，而是先建立一个清晰的工程框架：

reliability input data
+ design statistics
+ model resolver
+ FIT computation
+ verbose report
= explainable FIT model engine

---

1. 为什么 FIT 模型需要工程化

在功能安全分析中，FIT 不是一个孤立数字。

它依赖很多输入：

工艺类型
单元类型
晶体管数量或 memory bit 数量
温度条件
mission profile
制造年份
封装假设
永久故障模型
瞬态故障模型

如果这些输入都硬编码在脚本里，后续会出现严重问题：

不同项目无法复用
不同模型无法对比
参数来源不可追溯
报告结果难以审查
商用工具对比困难

因此，FIT 模型要工程化，就必须把模型、参数、设计统计和报告分离。

---

2. IEC 62380 与 SN29500 的工程差异

从工程使用角度看，可以把两类模型理解为不同的 FIT 计算策略。

维度	IEC 62380 思路	SN29500 思路
关注重点	mission profile、温度、工艺、封装等综合影响	reference condition 到 operating condition 的转换
输入复杂度	相对更复杂	相对更结构化
工程实现	需要更多项目参数	适合模型化封装
Demo 处理	simplified_iec62380	simplified_sn29500

这里不需要一开始实现标准的全部细节。对于实践平台，第一阶段更重要的是：

模型接口统一
输入参数显式
计算过程可展开
输出报告可审查

后续如果需要更高精度，可以逐步替换模型内部实现。

---

3. FIT 模型的四层输入

一个可维护的 FIT 模型输入可以拆成四层。

3.1 Design Statistics

设计规模统计，例如：

{
  "stdcell_gate_count": 1200,
  "sequential_count": 96,
  "memory_bits": 2048,
  "analog_block_count": 0,
  "blackbox_count": 1
}

3.2 Technology Data

工艺和 lambda 参数，例如：

process:
  default: MOS.ASIC.STDCELL
lambda:
  MOS.ASIC.STDCELL:
    permanent_per_gate: 1.0e-6
    transient_per_gate: 1.0e-6
  MOS.STD.SRAM:
    permanent_per_bit: 1.7e-7
    transient_per_bit: 1.0e-6

3.3 Mission Profile

使用场景，例如：

mission_profile:
  name: passenger_compartment
  temperature_ja: 65
  active_ratio: 0.80
  dormant_ratio: 0.20

3.4 Model Configuration

选择模型：

fit_model:
  standard: simplified_iec62380
  include_transient: true
  include_permanent: true
  verbose: true

这四层分开后，模型才可复用、可替换、可对比。

---

4. FIT 模型引擎的内部架构

safeic-fitmodel 不应该写成一个长脚本，而应该分成几个清晰组件。

其中：

组件	功能
Input Loader	读取设计规模、工艺、mission profile、模型配置
Model Resolver	根据配置选择 simplified IEC 或 simplified SN 模型
Permanent FIT Calculator	计算永久失效贡献
Transient FIT Calculator	计算瞬态失效贡献
Breakdown Generator	按模块/类型输出贡献
Verbose Reporter	输出详细计算过程

---

5. 为什么需要 verbose report

FIT 计算最怕只输出一个总数。

例如：

Total FIT = 0.128

这个结果单独看意义不大。工程师更需要知道：

stdcell 贡献多少？
sequential 贡献多少？
memory 贡献多少？
permanent 和 transient 分别是多少？
用了哪个 lambda？
用了哪个 temperature factor？
用了哪个 mission profile？

因此，safeic-fitmodel 必须输出 verbose report。

示例：

FIT Model: simplified_iec62380
Top: toy_soc
Stage: rtl
Mission Profile: passenger_compartment
TemperatureJA: 65

Breakdown:
- STD Cell permanent FIT: 0.0012
- FF transient FIT: 0.0960
- SRAM transient FIT: 0.0020
- Total permanent FIT: 0.0012
- Total transient FIT: 0.0980

verbose report 的作用是让计算结果可以被审查，而不是只被相信。

---

6. 模型不应和设计绑定

一个常见错误是把 FIT 参数写进设计脚本里。

这会导致：

换设计时要改脚本
换标准时要改代码
换 mission profile 时结果不可追溯

更好的做法是：

design_stats.json：描述设计
technology.yaml：描述工艺和 lambda
mission_profile.yaml：描述使用条件
model_config.yaml：描述计算模型

这样同一个设计可以跑不同模型：

safeic-fitmodel --model simplified_iec62380
safeic-fitmodel --model simplified_sn29500

输出可以对比：

fit_compare.csv

这就是 Demo D04 的关键价值。

---

7. FIT 模型与 DC 模型的关系

FIT 模型回答的是：

随机硬件故障风险有多大？

DC 模型回答的是：

这些风险中有多少被安全机制覆盖？

两者必须分开。

如果把 FIT 和 DC 混在一起，后续很难判断是失效率模型问题，还是安全机制覆盖率问题。

因此：

D04 只负责 FIT 模型工程化
D08 才负责 Diagnostic Coverage Engine

---

8. Demo 输出文件设计

D04_fit_standard_models 的建议目录：

D04_fit_standard_models/
  README.md
  run_demo.csh
  run_demo.sh
  inputs/
    design_stats.json
    technology.yaml
    mission_profile.yaml
    model_config_iec.yaml
    model_config_sn.yaml
  outputs/
    fit_model_iec_detail.csv
    fit_model_sn_detail.csv
    fit_model_compare.csv
    verbose_fit_iec.md
    verbose_fit_sn.md
  scripts/
    safeic_fitmodel.py

输出的 fit_model_compare.csv 可以类似：

model,total_permanent_fit,total_transient_fit,total_fit
simplified_iec62380,0.0012,0.0980,0.0992
simplified_sn29500,0.0010,0.0950,0.0960

这为后续商用工具对比提供基础。

---

9. 方法论：先建立模型接口，再追求模型精度

在实际工程中，很容易陷入一个误区：一开始就追求完整实现标准模型。

这会导致项目启动很慢，而且很难验证框架是否合理。

更稳妥的方法是：

第一步：建立模型输入输出接口
第二步：实现 simplified model
第三步：输出 verbose report
第四步：用 toy design 验证数据流
第五步：逐步替换为更精确模型

这种方法的优势是：

工具架构先稳定
Demo 可以尽早跑通
文章可以持续发布
软著材料可以提前沉淀
专利交底书可以围绕方法闭环展开

---

10. 方法论总结

FIT 模型不是一个公式，而是一个工程系统。

它至少包含：

设计规模统计
工艺与 lambda 数据
温度与 mission profile
模型选择
永久故障计算
瞬态故障计算
分项贡献报告
详细计算追溯

D04_fit_standard_models 的价值是把这些内容拆成清晰、可配置、可对比的工程模块。

后续的 D05_arch_rtl_netlist_flow 会继续解决另一个问题：

同一个设计在 architecture、RTL、netlist 三个阶段，FIT 输入和统计结果如何保持一致？

只有解决了这个问题，FIT 模型才能真正进入完整设计流程。