【汽车芯片功能安全分析与故障注入实践 02】一个功能安全验证项目需要哪些输入文件？
作者：Darren H. Chen
方向：汽车芯片功能安全分析与故障注入实践
Demo：D02_input_package
标签：汽车芯片功能安全输入文件Fault ListAlarm ListVCDFMEDA
Demo 说明
D02_input_package的目标是建立一个标准化的功能安全验证输入包。
第一篇文章已经搭好了最小闭环，但如果没有清晰的输入文件边界，后续 FIT 计算、DC 计算、故障列表生成、VCD 上下文提取和故障注入都会变得不可复现。
本 Demo 对应的通用工具名称为：
safeic-inputcheck它的作用是检查一个功能安全验证项目的输入是否完整、路径是否正确、基础格式是否可读，并生成输入检查报告。
1. 为什么输入包比工具本身更重要
很多工程项目的问题不是算法跑不出来，而是输入定义不清楚。
功能安全验证尤其如此，因为它不是只读一个 RTL 文件就能完成，而是要同时连接多类证据：
设计结构证据 + 可靠性模型输入 + 安全机制配置 + 运行上下文波形 + 故障模型 + alarm / observe point + 报告与数据库如果输入文件缺失、路径不统一、命名混乱，后续分析会出现三个问题：
结果不可复现 结果不可解释 结果无法对比因此，一个功能安全验证项目首先要定义输入包，而不是急着写算法。
2. 功能安全验证输入的五大类
从工程角度看，汽车芯片功能安全分析与故障注入至少需要五类输入。
| 类别 | 代表文件 | 作用 |
|---|---|---|
| 设计输入 | RTL、netlist、filelist、top | 定义被分析对象 |
| 时钟与运行输入 | clkdef、reset、VCD/FSDB | 定义运行上下文 |
| 安全分析输入 | FIT setup、lambda、mission profile、SM library | 支撑 FIT/DC 和安全机制建模 |
| 故障注入输入 | fault.list、alarm.list、observe_points.list | 支撑 fault campaign |
| 项目管理输入 | manifest、session、config、output path | 支撑可复现流程 |
这五类输入构成了后续所有 Demo 的基础。
3. 设计输入：RTL、Netlist、Filelist 和 Top
设计输入回答的是：
我要分析哪个设计？ 这个设计由哪些 HDL 文件组成？ 顶层模块是什么？ 当前阶段是 architecture、RTL 还是 gate-level netlist？一个最小设计输入包可以是：
inputs/ rtl/ toy_counter.v alarm_checker.v filelist.f design.yamlfilelist.f示例：
./rtl/toy_counter.v ./rtl/alarm_checker.vdesign.yaml示例：
top:toy_counter_toplanguage:verilogstage:rtl设计输入的关键不是文件多复杂，而是能被工具稳定解析，并能明确绑定到一个 top module。
4. 时钟与运行输入：为什么需要 clkdef 和 VCD
功能安全故障注入依赖运行上下文。
如果不知道时钟、复位和仿真时间窗口，就无法判断：
故障在哪个时间注入？ 故障是否跨越有效时钟边沿？ alarm 是否按时触发？ 状态是否和 golden trace 不一致？因此，需要定义时钟和波形输入。
clkdef.clk可以简化为：
clk 10ns rising reset_n active_lowsim.vcd则来自 golden simulation：
inputs/ sim/ golden.vcd在本系列实践中，VCD 会被视为 safety context，而不只是波形查看文件。
5. 安全分析输入：FIT setup 与 Safety Mechanism Library
安全分析输入回答的是：
用什么可靠性模型？ 默认工艺类型是什么？ 温度与 mission profile 如何设置？ 有哪些安全机制？ 每种安全机制覆盖哪些结构区域？一个简化的fit_inputs.yaml可以是：
fit_standard:simplified_iec62380mission_profile:passenger_compartmenttemperature_ja:65manufacturing_year:2026default_process:MOS.ASIC.STDCELL一个简化的sm_library.yaml可以是：
parity_check:description:endpoint parity checkercoverage:endpoint:0.90startpoint:0.00cone:0.00dup_compare:description:duplicated logic comparatorcoverage:endpoint:0.90startpoint:0.00cone:0.90这类文件不应该隐藏在脚本里。它们应该成为可审查、可版本管理、可对比的工程输入。
6. 故障注入输入：Fault List、Alarm List 和 Observe Points
故障注入至少需要三个核心文件。
6.1 Fault List
fault.list定义在哪里注入什么故障。
示例：
top.u_counter.state_reg[0] SA0 100 -1 top.u_counter.state_reg[1] SA1 100 -1 top.u_counter.valid_reg 1 200 5可以约定四列：
fault_node fault_value inject_time duration其中：
SA0 / 0：stuck-at 0 SA1 / 1：stuck-at 1 -1：永久故障 正整数 duration：瞬态故障持续时间6.2 Alarm List
alarm.list定义哪些信号代表安全机制检测到了故障。
示例：
top.u_checker.alarm_error top.u_checker.parity_error top.u_checker.timeout_error6.3 Observe Points
observe_points.list定义额外观察点。
示例：
top.out_valid top.out_data[0] top.u_bus.resp_erroralarm 和 observe point 的区别是：
alarm：安全机制明确报警 observe point：故障是否传播到指定可观察位置7. Manifest：把输入包变成可复现项目
如果只靠命令行参数传递所有文件，项目很快会变乱。
因此需要一个统一的manifest.yaml。
示例：
project:automotive_safeic_practice_d02demo:D02_input_packagedesign:top:toy_counter_topfilelist:inputs/filelist.fstage:rtlsimulation:clkdef:inputs/clkdef.clkgolden_vcd:inputs/sim/golden.vcdsafety:fit_inputs:inputs/fit_inputs.yamlsm_library:inputs/sm_library.yamlfailure_modes:inputs/failure_modes.yamlfault_campaign:fault_list:inputs/fault.listalarm_list:inputs/alarm.listobserve_points:inputs/observe_points.listoutputs:report_dir:outputssafeic-inputcheck不需要理解所有复杂算法，只需要根据 manifest 检查文件是否存在、格式是否基本正确。
8. D02 Demo 的工具架构
D02_input_package的核心工具是safeic-inputcheck。
它的输入是：
manifest.yaml inputs/*它的输出是：
outputs/input_check.rpt outputs/input_manifest.normalized.json outputs/missing_files.csv outputs/demo_summary.md架构如下：
检查项可以分为三层：
| 层级 | 检查内容 |
|---|---|
| L1 | 文件是否存在 |
| L2 | 文件是否为空、是否可读 |
| L3 | 文件是否包含必要字段或必要列 |
9. 输入检查不是形式主义
输入检查看起来简单，但它是后续所有分析的基础。
例如：
fault.list 中的节点在设计中不存在 alarm.list 中的信号没有出现在 VCD 中 top module 与 filelist 不匹配 fit_inputs.yaml 缺少 process observe_points.list 中写了 bus vector，但工具要求拆 bit这些问题如果等到 fault campaign 阶段才发现，调试成本会非常高。
因此，输入检查应该放在所有工具之前。
完整流程是：
10. 方法论总结
一个功能安全验证项目的第一步，不是写复杂算法，而是建立标准输入包。
输入包要做到：
完整 可读 可检查 可版本管理 可复现 可对比D02_input_package的目标就是把输入包工程化。
当输入包统一后，后续模块就可以稳定串联：
safeic-designstats safeic-bfr safeic-structure safeic-dc safeic-faultgen safeic-vcdctx safeic-campaign safeic-classify safeic-report因此，D02 的价值不在于算法复杂，而在于把项目从“脚本堆叠”变成“工程流程”。