【汽车芯片功能安全分析与故障注入实践 02】一个功能安全验证项目需要哪些输入文件？

作者： Darren H. Chen
方向： 汽车芯片功能安全分析与故障注入实践
Demo： D02_input_package
标签： 汽车芯片 功能安全 输入文件 Fault List Alarm List VCD FMEDA

Demo 说明

D02_input_package 的目标是建立一个标准化的功能安全验证输入包。

第一篇文章已经搭好了最小闭环，但如果没有清晰的输入文件边界，后续 FIT 计算、DC 计算、故障列表生成、VCD 上下文提取和故障注入都会变得不可复现。

本 Demo 对应的通用工具名称为：

text 复制代码

safeic-inputcheck

它的作用是检查一个功能安全验证项目的输入是否完整、路径是否正确、基础格式是否可读，并生成输入检查报告。

1. 为什么输入包比工具本身更重要

很多工程项目的问题不是算法跑不出来，而是输入定义不清楚。

功能安全验证尤其如此，因为它不是只读一个 RTL 文件就能完成，而是要同时连接多类证据：

text 复制代码

设计结构证据
+ 可靠性模型输入
+ 安全机制配置
+ 运行上下文波形
+ 故障模型
+ alarm / observe point
+ 报告与数据库

如果输入文件缺失、路径不统一、命名混乱，后续分析会出现三个问题：

text 复制代码

结果不可复现
结果不可解释
结果无法对比

因此，一个功能安全验证项目首先要定义输入包，而不是急着写算法。

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

设计输入回答的是：

text 复制代码

我要分析哪个设计？
这个设计由哪些 HDL 文件组成？
顶层模块是什么？
当前阶段是 architecture、RTL 还是 gate-level netlist？

一个最小设计输入包可以是：

text 复制代码

inputs/
  rtl/
    toy_counter.v
    alarm_checker.v
  filelist.f
  design.yaml

filelist.f 示例：

text 复制代码

./rtl/toy_counter.v
./rtl/alarm_checker.v

design.yaml 示例：

yaml 复制代码

top: toy_counter_top
language: verilog
stage: rtl

设计输入的关键不是文件多复杂，而是能被工具稳定解析，并能明确绑定到一个 top module。

4. 时钟与运行输入：为什么需要 clkdef 和 VCD

功能安全故障注入依赖运行上下文。

如果不知道时钟、复位和仿真时间窗口，就无法判断：

text 复制代码

故障在哪个时间注入？
故障是否跨越有效时钟边沿？
alarm 是否按时触发？
状态是否和 golden trace 不一致？

因此，需要定义时钟和波形输入。

clkdef.clk 可以简化为：

text 复制代码

clk 10ns rising
reset_n active_low

sim.vcd 则来自 golden simulation：

text 复制代码

inputs/
  sim/
    golden.vcd

在本系列实践中，VCD 会被视为 safety context，而不只是波形查看文件。
RTL Simulation
Golden VCD
VCD Context Extractor
State Activity
Compare Window
Alarm Timing

5. 安全分析输入：FIT setup 与 Safety Mechanism Library

安全分析输入回答的是：

text 复制代码

用什么可靠性模型？
默认工艺类型是什么？
温度与 mission profile 如何设置？
有哪些安全机制？
每种安全机制覆盖哪些结构区域？

一个简化的 fit_inputs.yaml 可以是：

yaml 复制代码

fit_standard: simplified_iec62380
mission_profile: passenger_compartment
temperature_ja: 65
manufacturing_year: 2026
default_process: MOS.ASIC.STDCELL

一个简化的 sm_library.yaml 可以是：

yaml 复制代码

parity_check:
  description: endpoint parity checker
  coverage:
    endpoint: 0.90
    startpoint: 0.00
    cone: 0.00

dup_compare:
  description: duplicated logic comparator
  coverage:
    endpoint: 0.90
    startpoint: 0.00
    cone: 0.90

这类文件不应该隐藏在脚本里。它们应该成为可审查、可版本管理、可对比的工程输入。

6. 故障注入输入：Fault List、Alarm List 和 Observe Points

故障注入至少需要三个核心文件。

6.1 Fault List

fault.list 定义在哪里注入什么故障。

示例：

text 复制代码

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

可以约定四列：

text 复制代码

fault_node fault_value inject_time duration

其中：

text 复制代码

SA0 / 0：stuck-at 0
SA1 / 1：stuck-at 1
-1：永久故障
正整数 duration：瞬态故障持续时间

6.2 Alarm List

alarm.list 定义哪些信号代表安全机制检测到了故障。

示例：

text 复制代码

top.u_checker.alarm_error
top.u_checker.parity_error
top.u_checker.timeout_error

6.3 Observe Points

observe_points.list 定义额外观察点。

示例：

text 复制代码

top.out_valid
top.out_data[0]
top.u_bus.resp_error

alarm 和 observe point 的区别是：

text 复制代码

alarm：安全机制明确报警
observe point：故障是否传播到指定可观察位置

7. Manifest：把输入包变成可复现项目

如果只靠命令行参数传递所有文件，项目很快会变乱。

因此需要一个统一的 manifest.yaml。

示例：

yaml 复制代码

project: automotive_safeic_practice_d02
demo: D02_input_package

design:
  top: toy_counter_top
  filelist: inputs/filelist.f
  stage: rtl

simulation:
  clkdef: inputs/clkdef.clk
  golden_vcd: inputs/sim/golden.vcd

safety:
  fit_inputs: inputs/fit_inputs.yaml
  sm_library: inputs/sm_library.yaml
  failure_modes: inputs/failure_modes.yaml

fault_campaign:
  fault_list: inputs/fault.list
  alarm_list: inputs/alarm.list
  observe_points: inputs/observe_points.list

outputs:
  report_dir: outputs

safeic-inputcheck 不需要理解所有复杂算法，只需要根据 manifest 检查文件是否存在、格式是否基本正确。

8. D02 Demo 的工具架构

D02_input_package 的核心工具是 safeic-inputcheck。

它的输入是：

text 复制代码

manifest.yaml
inputs/*

它的输出是：

text 复制代码

outputs/input_check.rpt
outputs/input_manifest.normalized.json
outputs/missing_files.csv
outputs/demo_summary.md

架构如下：
manifest.yaml
safeic-inputcheck
filelist.f
clkdef.clk
fit_inputs.yaml
fault.list
alarm.list
observe_points.list
golden.vcd
input_check.rpt
normalized_manifest.json
missing_files.csv
demo_summary.md

检查项可以分为三层：

层级	检查内容
L1	文件是否存在
L2	文件是否为空、是否可读
L3	文件是否包含必要字段或必要列

9. 输入检查不是形式主义

输入检查看起来简单，但它是后续所有分析的基础。

例如：

text 复制代码

fault.list 中的节点在设计中不存在
alarm.list 中的信号没有出现在 VCD 中
top module 与 filelist 不匹配
fit_inputs.yaml 缺少 process
observe_points.list 中写了 bus vector，但工具要求拆 bit

这些问题如果等到 fault campaign 阶段才发现，调试成本会非常高。

因此，输入检查应该放在所有工具之前。

完整流程是：
pass
pass
pass
fail
Input Package
Input Check
Design Statistics
FIT/DC Analysis
Fault Campaign
Fix Input Package

10. 方法论总结

一个功能安全验证项目的第一步，不是写复杂算法，而是建立标准输入包。

输入包要做到：

text 复制代码

完整
可读
可检查
可版本管理
可复现
可对比

D02_input_package 的目标就是把输入包工程化。

当输入包统一后，后续模块就可以稳定串联：

text 复制代码

safeic-designstats
safeic-bfr
safeic-structure
safeic-dc
safeic-faultgen
safeic-vcdctx
safeic-campaign
safeic-classify
safeic-report

因此，D02 的价值不在于算法复杂，而在于把项目从"脚本堆叠"变成"工程流程"。