作者：Darren H. Chen
方向：汽车芯片功能安全分析与故障注入实践
Demo：D06_sp_ep_cone_extract
标签：汽车芯片功能安全SP/EP/Cone结构分析FITDC
Demo 说明
D06_sp_ep_cone_extract的目标是把功能安全分析中最关键的结构对象抽象出来：
Startpoint Endpoint Cone对应的通用工具名称为：
safeic-structure这个工具的作用不是做完整的 EDA 级网表分析，而是建立一个可解释的结构分析原型：
输入 RTL / 简化 netlist / graph 输出 SP、EP、Cone 结构文件 为 FIT contribution、DC 计算和 fault list 生成提供基础在功能安全分析中，如果没有 SP/EP/Cone 这样的结构骨架，FIT、DC、安全机制选择和故障注入都会变成孤立动作，无法形成一条可追溯的证据链。
1. 为什么需要结构骨架
功能安全分析表面上是在算指标：
FIT Diagnostic Coverage SPFM LFM PMHF但这些指标不能凭空计算。它们必须依赖设计结构。
如果只知道一个模块有多少 gate、多少 flop、多少 memory bit，最多只能做粗粒度估算。真正进入芯片级安全分析时，需要回答更细的问题：
哪个状态元素可能成为故障传播起点？ 哪个状态元素输入或输出端口可能成为安全影响点？ 哪些组合逻辑位于故障传播路径上？ 哪个 endpoint 连接的逻辑最多、风险权重最大？ 某个 safety mechanism 到底覆盖了 EP、SP 还是 cone？这些问题都指向同一个核心：
功能安全指标不是只由数量决定，而是由结构连接关系决定。
因此，在 FIT/DC 计算之前，需要先把设计拆成可分析的结构对象。
2. 三个基本对象：SP、EP、Cone
在芯片结构分析中，可以先用三个对象建立统一模型。
| 对象 | 中文含义 | 典型来源 | 安全分析意义 |
|---|---|---|---|
| Startpoint, SP | 起点 | 状态元素输出、黑盒输出、顶层输入 | 故障传播起点 |
| Endpoint, EP | 终点 | 状态元素输入、黑盒输入、顶层输出 | 故障影响观察点 |
| Cone | 组合逻辑锥 | SP 到 EP 之间的组合逻辑 | 故障传播路径和权重来源 |
更直观地看：
Startpoint -> Combinational Cone -> Endpoint例如一个简单路径：
always @(posedge clk) begin r1 <= in; r2 <= (r1 & enable) ^ mask; end可以抽象为：
r1.Q = Startpoint AND/XOR = Cone r2.D = Endpoint如果r1.Q发生随机硬件故障，错误可能通过 AND/XOR 组合逻辑传播到r2.D，并在下一个时钟边沿被r2捕获。这个过程中，r1.Q、组合逻辑、r2.D分别承担不同的功能安全意义。
3. 结构图视角
下面用 Mermaid 表示一个最小结构模型：
这个图里有两个关键点：
Endpoint 在一个阶段是终点 同一个寄存器在下一个阶段又可以成为 Startpoint例如：
Reg2.D 是当前 cone 的 Endpoint Reg2.Q 是下一段 cone 的 Startpoint这也是为什么安全分析不能只看单个寄存器，而要看整个结构传播网络。
4. 为什么 Endpoint 是 FIT/DC 的关键锚点
在功能安全分析中，Endpoint 通常是最重要的锚点。
原因是：
故障最终是否影响安全目标，通常要看它是否传播到某个 endpointEndpoint 可以是：
寄存器输入 latch 输入 黑盒输入 顶层输出如果一个故障只在组合逻辑内部短暂出现，但没有被任何 endpoint 捕获，也没有到达安全相关输出，那么它可能被认为是 masked 或不形成实际安全影响。
反过来，如果一个故障到达了 endpoint，并且该 endpoint 对安全目标相关，那么这个 endpoint 对 FIT/DC 的贡献就需要被认真评估。
这可以理解为：
SP 负责产生或携带错误 Cone 负责传播错误 EP 负责把错误变成可持续状态或可观察输出5. Cone 的作用：为什么组合逻辑也要算权重
有时容易误以为只有寄存器和 memory 才是安全分析对象。实际上，组合逻辑同样重要。
原因是组合逻辑决定了故障传播能力：
一个小 cone 只影响一个 endpoint 一个大 cone 可能影响多个 endpoint 一个高扇出 cone 可能把一个错误扩散到多个功能路径例如：
SP_A -> cone_1 -> EP_1 SP_B -> cone_2 -> EP_2, EP_3, EP_4, EP_5虽然 SP_A 和 SP_B 都只是一个状态元素输出，但 SP_B 后面的传播范围更大，安全风险权重也更高。
结构分析中常见的权重因素包括：
endpoint 数量 fanout 数量 cone 内 gate 数量 是否连接安全相关输出 是否连接 blackbox 是否连接 alarm/checker 路径 是否跨越模块边界6. SP/EP/Cone 与安全机制覆盖范围
不同安全机制覆盖的结构范围不同。
例如：
| 安全机制 | 可能覆盖的对象 | 说明 |
|---|---|---|
| Endpoint parity | EP | 检查寄存器输入或输出的一致性 |
| Duplication checker | EP + Cone | 复制逻辑并比较结果 |
| Lockstep | SP + Cone + EP | 比较两个执行通道 |
| ECC | Memory bits + memory output EP | 保护存储单元和读出数据 |
| End-to-end protection | 跨模块路径 | 保护数据从源到目的的完整性 |
这也是为什么 Diagnostic Coverage 不能只写一个全局百分比。
更合理的方式是：
SM 对 EP 的覆盖率是多少？ SM 对 SP 的覆盖率是多少？ SM 对 Cone 的覆盖率是多少？ SM 是否只在当前 module 内有效？ SM 是否跨越多个 module？这样，DC 计算才可以从“拍脑袋比例”变成结构化推导。
7. D06 Demo 的输入输出设计
D06_sp_ep_cone_extract可以先采用简化输入，不必一开始直接支持完整 Verilog 语法。
推荐输入结构：
D06_sp_ep_cone_extract/ inputs/ design_graph.yaml module_hierarchy.yaml safety_scope.yaml outputs/ sp.csv ep.csv cone.csv structure_graph.json structure_graph.md scripts/ safeic_structure.pydesign_graph.yaml示例：
nodes:-name:top.u_ctrl.r_state.Qtype:reg_q-name:top.u_ctrl.next_state_logictype:comb-name:top.u_ctrl.r_state.Dtype:reg_d-name:top.error_flagtype:outputedges:-from:top.u_ctrl.r_state.Qto:top.u_ctrl.next_state_logic-from:top.u_ctrl.next_state_logicto:top.u_ctrl.r_state.D-from:top.u_ctrl.next_state_logicto:top.error_flag输出sp.csv：
sp_id,node,type,module SP_0001,top.u_ctrl.r_state.Q,reg_q,top.u_ctrl SP_0002,top.input_valid,primary_input,top输出ep.csv：
ep_id,node,type,module,safety_related EP_0001,top.u_ctrl.r_state.D,reg_d,top.u_ctrl,true EP_0002,top.error_flag,primary_output,top,true输出cone.csv：
cone_id,from_sp,to_ep,gate_count,fanout_count CONE_0001,SP_0001,EP_0001,12,1 CONE_0002,SP_0001,EP_0002,18,28. 工具架构设计
safeic-structure可以拆成五个内部步骤：
每一步的职责要单一：
| 步骤 | 作用 |
|---|---|
| Read Design Graph | 读取 RTL/netlist 抽象图 |
| Classify Nodes | 判断节点类型：reg_q、reg_d、comb、memory、port |
| Detect Startpoints | 找状态输出、顶层输入、黑盒输出 |
| Detect Endpoints | 找状态输入、顶层输出、黑盒输入 |
| Trace Cones | 建立 SP 到 EP 的路径和 cone |
| Generate Reports | 输出 CSV/JSON/Markdown |
这种设计的好处是：
后续可以替换前端 parser 核心结构算法可以保持不变 Demo 可以先用 YAML graph 跑通 未来再接 Yosys JSON 或 netlist parser9. 结构分析中的工程边界
第一版 Demo 不建议追求完整商用级能力。
可以先明确边界：
支持同步时序设计 支持寄存器 Q/D 识别 支持顶层输入输出 支持组合逻辑 cone 追踪 暂不支持复杂 generate 层次展开 暂不支持完整 SystemVerilog 语义 暂不支持 analog/mixed-signal 内部结构这样更利于快速落地。
更重要的是，文章和 Demo 要说明一个方法论：
先建立结构分析的统一数据模型，再逐步增强前端解析能力。
这比一开始就试图解析所有 Verilog 语法更稳。
10. 方法论总结
SP/EP/Cone 是汽车芯片功能安全分析的结构骨架。
它们把抽象指标和真实设计连接起来：
FIT 需要知道 endpoint 和结构规模 DC 需要知道安全机制覆盖了 EP、SP 还是 cone Fault list 需要知道哪些节点值得注入 Fault campaign 需要知道故障传播到哪里 Report 需要能够解释为什么某个 fault 被分类为 detected、safe 或 unsafeD06_sp_ep_cone_extract的核心作用就是建立这套结构语言。
当 SP/EP/Cone 被提取出来之后，后续的 Endpoint FIT Contribution、Diagnostic Coverage、Safety Mechanism Selection 和 Fault List Generation 才有了统一的数据基础。
