【汽车芯片功能安全分析与故障注入实践 06】Startpoint、Endpoint、Cone：安全分析的结构骨架

作者： Darren H. Chen
方向： 汽车芯片功能安全分析与故障注入实践
Demo： D06_sp_ep_cone_extract
标签： 汽车芯片 功能安全 SP/EP/Cone 结构分析 FIT DC

Demo 说明

D06_sp_ep_cone_extract 的目标是把功能安全分析中最关键的结构对象抽象出来：

text 复制代码

Startpoint
Endpoint
Cone

对应的通用工具名称为：

text 复制代码

safeic-structure

这个工具的作用不是做完整的 EDA 级网表分析，而是建立一个可解释的结构分析原型：

text 复制代码

输入 RTL / 简化 netlist / graph
输出 SP、EP、Cone 结构文件
为 FIT contribution、DC 计算和 fault list 生成提供基础

在功能安全分析中，如果没有 SP/EP/Cone 这样的结构骨架，FIT、DC、安全机制选择和故障注入都会变成孤立动作，无法形成一条可追溯的证据链。

1. 为什么需要结构骨架

功能安全分析表面上是在算指标：

text 复制代码

FIT
Diagnostic Coverage
SPFM
LFM
PMHF

但这些指标不能凭空计算。它们必须依赖设计结构。

如果只知道一个模块有多少 gate、多少 flop、多少 memory bit，最多只能做粗粒度估算。真正进入芯片级安全分析时，需要回答更细的问题：

text 复制代码

哪个状态元素可能成为故障传播起点？
哪个状态元素输入或输出端口可能成为安全影响点？
哪些组合逻辑位于故障传播路径上？
哪个 endpoint 连接的逻辑最多、风险权重最大？
某个 safety mechanism 到底覆盖了 EP、SP 还是 cone？

这些问题都指向同一个核心：

功能安全指标不是只由数量决定，而是由结构连接关系决定。

因此，在 FIT/DC 计算之前，需要先把设计拆成可分析的结构对象。

2. 三个基本对象：SP、EP、Cone

在芯片结构分析中，可以先用三个对象建立统一模型。

对象	中文含义	典型来源	安全分析意义
Startpoint, SP	起点	状态元素输出、黑盒输出、顶层输入	故障传播起点
Endpoint, EP	终点	状态元素输入、黑盒输入、顶层输出	故障影响观察点
Cone	组合逻辑锥	SP 到 EP 之间的组合逻辑	故障传播路径和权重来源

更直观地看：

text 复制代码

Startpoint  ->  Combinational Cone  ->  Endpoint

例如一个简单路径：

verilog 复制代码

always @(posedge clk) begin
  r1 <= in;
  r2 <= (r1 & enable) ^ mask;
end

可以抽象为：

text 复制代码

r1.Q       = Startpoint
AND/XOR    = Cone
r2.D       = Endpoint

如果 r1.Q 发生随机硬件故障，错误可能通过 AND/XOR 组合逻辑传播到 r2.D，并在下一个时钟边沿被 r2 捕获。这个过程中，r1.Q、组合逻辑、r2.D 分别承担不同的功能安全意义。

3. 结构图视角

下面用 Mermaid 表示一个最小结构模型：
Primary Input
Combinational Cone
Reg1.Q / SP
Reg2.D / EP
Primary Output / EP
Reg2.Q / SP in next stage

这个图里有两个关键点：

text 复制代码

Endpoint 在一个阶段是终点
同一个寄存器在下一个阶段又可以成为 Startpoint

例如：

text 复制代码

Reg2.D 是当前 cone 的 Endpoint
Reg2.Q 是下一段 cone 的 Startpoint

这也是为什么安全分析不能只看单个寄存器，而要看整个结构传播网络。

4. 为什么 Endpoint 是 FIT/DC 的关键锚点

在功能安全分析中，Endpoint 通常是最重要的锚点。

原因是：

text 复制代码

故障最终是否影响安全目标，通常要看它是否传播到某个 endpoint

Endpoint 可以是：

text 复制代码

寄存器输入
latch 输入
黑盒输入
顶层输出

如果一个故障只在组合逻辑内部短暂出现，但没有被任何 endpoint 捕获，也没有到达安全相关输出，那么它可能被认为是 masked 或不形成实际安全影响。

反过来，如果一个故障到达了 endpoint，并且该 endpoint 对安全目标相关，那么这个 endpoint 对 FIT/DC 的贡献就需要被认真评估。

这可以理解为：

text 复制代码

SP 负责产生或携带错误
Cone 负责传播错误
EP 负责把错误变成可持续状态或可观察输出

5. Cone 的作用：为什么组合逻辑也要算权重

有时容易误以为只有寄存器和 memory 才是安全分析对象。实际上，组合逻辑同样重要。

原因是组合逻辑决定了故障传播能力：

text 复制代码

一个小 cone 只影响一个 endpoint
一个大 cone 可能影响多个 endpoint
一个高扇出 cone 可能把一个错误扩散到多个功能路径

例如：

text 复制代码

SP_A -> cone_1 -> EP_1
SP_B -> cone_2 -> EP_2, EP_3, EP_4, EP_5

虽然 SP_A 和 SP_B 都只是一个状态元素输出，但 SP_B 后面的传播范围更大，安全风险权重也更高。

结构分析中常见的权重因素包括：

text 复制代码

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 不能只写一个全局百分比。

更合理的方式是：

text 复制代码

SM 对 EP 的覆盖率是多少？
SM 对 SP 的覆盖率是多少？
SM 对 Cone 的覆盖率是多少？
SM 是否只在当前 module 内有效？
SM 是否跨越多个 module？

这样，DC 计算才可以从"拍脑袋比例"变成结构化推导。

7. D06 Demo 的输入输出设计

D06_sp_ep_cone_extract 可以先采用简化输入，不必一开始直接支持完整 Verilog 语法。

推荐输入结构：

text 复制代码

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.py

design_graph.yaml 示例：

yaml 复制代码

nodes:
  - name: top.u_ctrl.r_state.Q
    type: reg_q
  - name: top.u_ctrl.next_state_logic
    type: comb
  - name: top.u_ctrl.r_state.D
    type: reg_d
  - name: top.error_flag
    type: output
edges:
  - from: top.u_ctrl.r_state.Q
    to: top.u_ctrl.next_state_logic
  - from: top.u_ctrl.next_state_logic
    to: top.u_ctrl.r_state.D
  - from: top.u_ctrl.next_state_logic
    to: top.error_flag

输出 sp.csv：

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：

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：

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,2

8. 工具架构设计

safeic-structure 可以拆成五个内部步骤：
Read Design Graph
Classify Nodes
Detect Startpoints
Detect Endpoints
Trace Cones
Generate Structure Reports

每一步的职责要单一：

步骤	作用
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

这种设计的好处是：

text 复制代码

后续可以替换前端 parser
核心结构算法可以保持不变
Demo 可以先用 YAML graph 跑通
未来再接 Yosys JSON 或 netlist parser

9. 结构分析中的工程边界

第一版 Demo 不建议追求完整商用级能力。

可以先明确边界：

text 复制代码

支持同步时序设计
支持寄存器 Q/D 识别
支持顶层输入输出
支持组合逻辑 cone 追踪
暂不支持复杂 generate 层次展开
暂不支持完整 SystemVerilog 语义
暂不支持 analog/mixed-signal 内部结构

这样更利于快速落地。

更重要的是，文章和 Demo 要说明一个方法论：

先建立结构分析的统一数据模型，再逐步增强前端解析能力。

这比一开始就试图解析所有 Verilog 语法更稳。

10. 方法论总结

SP/EP/Cone 是汽车芯片功能安全分析的结构骨架。

它们把抽象指标和真实设计连接起来：

text 复制代码

FIT 需要知道 endpoint 和结构规模
DC 需要知道安全机制覆盖了 EP、SP 还是 cone
Fault list 需要知道哪些节点值得注入
Fault campaign 需要知道故障传播到哪里
Report 需要能够解释为什么某个 fault 被分类为 detected、safe 或 unsafe

D06_sp_ep_cone_extract 的核心作用就是建立这套结构语言。

当 SP/EP/Cone 被提取出来之后，后续的 Endpoint FIT Contribution、Diagnostic Coverage、Safety Mechanism Selection 和 Fault List Generation 才有了统一的数据基础。