【汽车芯片功能安全分析与故障注入实践 22】Macro-level Safety Synthesis：实例级冗余、Lockstep 与证据驱动的受保护设计生成

作者：Darren H. Chen

方向：Automotive Safe-IC / Functional Safety / EDA Automation / Safety Synthesis

demo：D22_macro_level_safety_synthesis

标签：汽车芯片、功能安全、ISO 26262、Safety Synthesis、Lockstep、TMR、Fault Campaign、FMEDA、EDA自动化、证据链闭环

01. D22 在 Safe-IC 工具链中的位置

D22 承接 D21 的 safety synthesis readiness 结果，进入真正的 macro-level safety synthesis 阶段。

D21 的核心任务是回答：

哪些模块、实例、子系统或 IP 边界已经具备安全机制插入条件？

D22 的核心任务进一步变成：

如何根据前序安全分析证据，在实例级插入冗余类安全机制，并生成可追溯、可验证、可进入后续 fault campaign 的受保护设计？

在完整 Safe-IC flow 中，D22 位于如下位置：
D01-D08

Safety Analysis Inputs

FIT / DC / Fault List
D09-D14

Fault Campaign Context
D14
D15-D20

FMEDA / Evidence / Closure
D21

Safety Synthesis Readiness
D22

Macro-level Safety Synthesis
D23

Micro-level Safety Synthesis
D24

Post-insertion Validation
D25

Safety Synthesis Testbench
D26+

Fault Campaign / Final DC / Closure

D22 不是单纯"复制一个模块"。真正的工程问题包括：

哪些实例值得保护；
采用 duplication、triplication、lockstep 还是 voter；
插入边界如何确定；
comparator / voter / alarm 如何连接；
对时钟、复位、扫描、黑盒、memory、DFT、低功耗约束有什么影响；
如何把插入动作映射回 FIT contribution、failure mode、safety mechanism、FMEDA item；
如何给后续 fault campaign 和 ISO 26262 closure 留下证据。

02. Macro-level Safety Synthesis 的工程定义

Macro-level Safety Synthesis 是在较粗粒度的结构边界上插入安全机制。

这里的 macro 并不是指 memory macro，也不是物理版图中的 macro block，而是相对 micro-level 而言的"实例级 / 模块级 / 子系统级"保护方式。

典型保护对象包括：

对象	说明	典型安全机制
module instance	一个模块实例	duplication、triplication
IP wrapper	已封装 IP 边界	lockstep、comparator
subsystem	子系统级逻辑	lockstep cluster
safety island	安全域边界	redundant island、alarm aggregation
controller block	状态控制模块	duplicate + compare
datapath block	关键数据路径模块	lockstep / TMR / voter

Macro-level 的特征是：

以实例边界为操作对象，通过结构复制、比较、投票或报警路径插入，提高随机硬件故障下的检测或容错能力。

与 micro-level 不同，macro-level 不需要逐个寄存器、逐条数据路径进行细粒度改写，因此更适合快速建立安全保护骨架，也更适合在客户不希望暴露完整设计源码的合作场景中落地。

03. D22 的输入与输出关系

D22 不应该孤立运行。它必须继承 D01-D21 的证据成果。

3.1 输入来源

D01-D04

Design / FIT / Structural Blocks
D22

Macro-level Safety Synthesis
D05-D08

Database / Safety Exploration / Fault List
D09-D14

VCD / Alarm / Fault Campaign Result
D15-D20

FMEDA / Closure / Regression Gate
D21

Synthesis Readiness Plan

D22 的主要输入包括：

输入类别	示例文件	工程含义
design package	`filelist.f`, `top_name`, `include_dirs`	待保护设计
clock/reset definition	`clocks.json`, `resets.json`	判断实例是否可安全复制
target instance list	`protected_instances.csv`	D21 选出的候选保护实例
safety mechanism plan	`safety_mechanism_plan.yaml`	每个候选对象采用的保护策略
FIT contribution	`fit_contribution.csv`	决定保护优先级
failure mode map	`failure_mode_map.csv`	建立失效模式与保护机制关系
FMEDA model	`fmeda_items.csv`	关联 part / sub-part / failure mode
evidence manifest	`d21_evidence_manifest.json`	记录证据来源
tool config	`flow_config.yaml`	控制引擎路径、运行模式、输出目录

3.2 输出目标

D22 的输出不只是新的设计文件，而是一组完整的 engineering deliverables：

输出类别	示例文件	用途
protected design	`protected_top.v` 或 `protected_design.f`	后续验证、综合或 fault campaign 输入
wrapper logic	`safety_wrapper.v`	封装冗余实例和比较逻辑
comparator/voter logic	`comparator_blocks.v`, `voter_blocks.v`	安全机制实现
alarm logic	`alarm_aggregation.v`	报警汇聚与输出
insertion report	`macro_insertion_report.csv`	记录插入动作
traceability matrix	`safety_traceability_matrix.csv`	证据链关联
equivalence plan	`equivalence_check_plan.md`	后续等价检查计划
handoff package	`d22_to_fault_campaign_handoff.json`	交给 fault campaign
closure notes	`d22_closure_notes.md`	ISO 26262 closure 说明

04. RTL 与结构网表在 D22 中的处理差异

D22 既可以处理较高抽象层级的设计描述，也可以处理综合后的结构化设计描述。两种输入形态都可用于 macro-level 插入，但工程重点不同。

4.1 抽象层级差异

维度	高抽象设计描述	结构化设计描述
设计语义	更清楚	更弱
模块层次	通常较完整	可能被优化、flatten 或 rename
控制逻辑识别	更容易识别 FSM、状态寄存器	需要依赖命名、库单元和结构模式
客户敏感度	高	相对低
插入方式	可读性较好	更像 post-synthesis ECO
验证重点	源级回归、综合一致性	结构一致性、等价检查、库映射
合作交付	需要更高信任	更容易被客户接受

在真实工程合作中，客户往往不愿交付完整高抽象设计描述，因为其中包含架构意图、协议处理、状态机组织、异常路径和核心 IP 实现细节。结构化设计描述虽然可读性较差，但暴露的信息少，更适合作为外部合作、工具评估、post-synthesis safety hardening 的输入。

4.2 插入目标没有本质变化

无论输入形态如何变化，macro-level 插入的核心目标都保持一致：

text 复制代码

target instance
    -> duplicate / triplicate
    -> compare / vote
    -> alarm / correction
    -> evidence
    -> validation
    -> fault campaign handoff

变化的是识别方式、约束方式和验证方式。

05. 高抽象输入模式的特点

当输入设计保留较完整的模块层次和行为语义时，D22 的优势是：

容易识别模块职责；
容易理解 clock/reset 意图；
容易生成可读 wrapper；
容易与原始 testbench、assertion、coverage 关联；
对 D23 micro-level 插入更友好；
可在综合前完成架构级安全增强。

适合场景包括：

场景	说明
自研芯片团队内部使用	设计团队可以直接修改源设计
安全机制早期探索	插入后可以重新综合评估面积、功耗、时序
控制逻辑保护	FSM、状态寄存器、协议控制路径语义清楚
与 micro-level 插入联动	D23 可进一步做寄存器级保护
平台化设计	工具链可形成可复用编码规范和 wrapper 模板

这种模式的主要挑战是客户通常需要开放更多设计细节，因此在对外合作中需要 NDA、数据隔离、权限控制和最小必要输入原则。

06. 结构化输入模式的特点

当输入是综合后的结构化设计描述时，D22 的工作更接近：

post-synthesis safety ECO + structural protection insertion + evidence package generation

其优势是：

客户不必暴露完整设计源码；
更适合外部合作方完成安全增强；
插入结果更接近真实实现；
便于与 gate-level fault campaign 衔接；
更符合 tape-out 前安全收敛流程；
可直接面向已有 IP 或历史设计做安全加固。

其挑战是：

挑战	说明
层次可能被破坏	flatten、rename、uniquify 会影响实例定位
语义较弱	需要依赖命名规则、库模型、层次报告
时钟复位识别更严格	必须明确 clock/reset pins
scan/DFT 影响更敏感	复制实例可能影响 scan chain 和 test mode
等价验证更关键	需要 netlist-to-netlist 或 wrapper-level equivalence plan
物理影响更直接	面积、扇出、布线、时序影响更接近后端问题

因此，结构化输入模式必须建立更严格的 artifact contract。

07. D22 的统一内部抽象

为了同时支持不同输入形态，D22 不应直接把输入文件当作文本处理，而应构建统一的内部设计模型。
Design Files
Parser / Import Adapter
Design Graph
Instance Boundary Model
Port / Clock / Reset Model
Connectivity Model
Protection Planner
Macro Safety Synthesis Engine
Protected Design
Reports / Evidence

统一内部模型至少需要包含：

内部对象	内容
instance node	实例名、模块类型、层次路径
port node	port 方向、宽度、连接关系
clock domain	clock source、clock pin、domain id
reset domain	reset polarity、reset pin、sync/async 类型
blackbox boundary	memory、analog、encrypted IP、3rd-party IP
safety candidate	保护对象、保护原因、目标机制
evidence link	FIT、failure mode、FMEDA item、D21 readiness id

统一抽象的价值在于：

不把工具链绑定在某一种输入形态上，而是把安全机制插入建立在 design graph、instance boundary 和 evidence traceability 之上。

08. Macro-level 安全机制总览

D22 重点覆盖实例级冗余机制。常见机制包括：

安全机制	类型	目标
Instance Duplication	detection	复制一个实例，通过比较输出检测错误
Lockstep	detection	两个实例同步执行，比较关键输出或状态
Instance Triplication	correction	三个实例并行，通过 voter 纠正单点错误
TMR	correction	Triple Modular Redundancy，适合高可靠目标
Comparator Wrapper	detection	输出不一致时产生 alarm
Voter Wrapper	correction	三路输出多数投票
Alarm Aggregator	detection/control	汇聚多个 comparator alarm
Safety Wrapper	integration	封装原实例、冗余实例和安全逻辑

这些机制可分为两类：
Macro-level SM
Fail-safe Detection
Fail-operational Correction
Duplication
Lockstep Compare
Alarm Output
Triplication
TMR Voter
Corrected Output

Fail-safe 侧重发现故障并进入安全状态；fail-operational 侧重在故障发生后继续提供正确输出。汽车芯片中通常需要根据 ASIL、系统安全目标、FTTI、架构冗余设计和成本约束选择合适机制。

09. Instance Duplication

Instance Duplication 是最常见的 macro-level 机制。

基本结构如下：
Inputs
Original Instance
Duplicated Instance
Comparator
Alarm
Functional Outputs

其特点是：

维度	说明
故障处理方式	检测
输出策略	原实例输出仍作为功能输出
报警策略	原实例与复制实例输出不一致时触发 alarm
成本	约增加一个目标实例面积，加 comparator/alarm 逻辑
优点	实现简单，证据链清晰
局限	不能自动纠正错误，需要系统进入安全状态

适合对象：

控制模块；
安全相关状态控制器；
关键协议桥；
关键配置寄存器控制块；
FIT contribution 高但无需 fail-operational 的实例。

10. Lockstep

Lockstep 是一种同步冗余执行机制。

两个实例在相同时钟、复位、输入刺激下运行，并在关键边界进行比较。
Clock
Instance A
Instance B
Reset
Inputs
Cycle-by-cycle Comparator
Lockstep Alarm

Lockstep 的关键点不是简单复制，而是：

两个通道是否严格同步；
比较点放在输出、状态还是协议边界；
是否需要 delay alignment；
是否需要 reset alignment；
alarm 是否要 latch；
不一致后是否进入 safe state；
是否存在 common cause failure 风险。

Lockstep 更适合：

对象	原因
processor-like core	输入输出同步性强，适合比较
controller cluster	状态转换一致性可检查
safety island	具备明确边界
关键 control plane	故障应快速报警
低延迟安全机制	可做到 cycle-level detection

11. Instance Triplication 与 TMR

Instance Triplication 通过三路实例和多数投票实现 correction。
Inputs
Instance 0
Instance 1
Instance 2
Voter
Corrected Output
Optional Disagreement Alarm

TMR 的目标是：

当三个通道中有一个发生错误时，通过多数投票保持输出正确。

其工程代价明显高于 duplication：

维度	Duplication	Triplication / TMR
通道数量	2	3
输出处理	compare + alarm	vote + corrected output
故障能力	检测	单故障纠正
面积成本	中	高
功耗成本	中	高
验证复杂度	中	高
适用目标	fail-safe	fail-operational

在汽车芯片中，TMR 并不是越多越好。若系统层已有冗余、复位恢复或安全降级机制，duplication + alarm 可能更经济。若安全目标要求持续运行，或停机本身不可接受，TMR 才更有价值。

12. Comparator 的设计要点

Comparator 是 D22 中最常见的附加逻辑。

它不仅是一个 != 判断，还需要处理：

问题	工程考虑
比较宽度	全输出比较还是关键输出比较
比较时机	combinational compare 或 registered compare
X/Z 处理	仿真 unknown 是否忽略
reset window	reset 后多少周期内不比较
valid 信号	只有 valid 时比较
mask 策略	某些 debug/test 输出不比较
alarm latch	alarm 是否保持
alarm clear	clear 条件由软件、复位还是安全管理单元控制
CDC	alarm 是否跨时钟域
DFT	scan/test mode 下是否屏蔽

一个成熟的 comparator policy 通常包含：

yaml 复制代码

comparator_policy:
  compare_scope: selected_outputs
  compare_timing: registered
  reset_mask_cycles: 4
  valid_signal: out_valid
  ignore_signals:
    - debug_status
    - test_observe
  alarm_latch: true
  alarm_clear: reset_only
  test_mode_mask: true

13. Voter 的设计要点

Voter 是 TMR 的核心。

对于单 bit 输出，多数投票可以表示为：

text 复制代码

voted = (a & b) | (a & c) | (b & c)

对于 bus 输出，可以逐 bit 投票，也可以按字段投票。工程上需要特别注意：

问题	说明
bus-level consistency	每一 bit 投票可能产生不存在的组合状态
protocol output	valid/ready/data 之间需要一致性
sideband signal	error、last、id、user 等字段不能割裂
temporal alignment	三路输出必须同周期对齐
alarm output	voter 应报告通道分歧
degraded mode	是否支持隔离故障通道
voter protection	voter 本身是否成为单点故障

对于复杂协议接口，简单逐 bit voter 可能不够，需要 protocol-aware voter。
Channel 0 Output
Protocol-aware Voter
Channel 1 Output
Channel 2 Output
Corrected Protocol Output
Disagreement / Degraded Alarm

14. Alarm Aggregation

Macro-level 插入后会产生多个 alarm。D22 需要生成统一的 alarm aggregation 结构。
alarm_inst_a
Alarm Aggregator
alarm_inst_b
alarm_inst_c
top_safety_alarm
alarm_status_register

Alarm aggregation 的工程价值是：

将分散的 comparator alarm 统一管理；
给系统安全管理单元提供明确接口；
给 fault campaign 提供观察点；
给 FMEDA 提供 safety mechanism 证据；
给软件诊断提供状态寄存器；
给 ISO 26262 closure 提供可追溯的失效响应路径。

典型输出包括：

text 复制代码

alarm_id
source_instance
mechanism_type
failure_mode
alarm_signal
latched
clear_condition
observe_point
fmeda_item

15. 黑盒、Memory 与第三方 IP 边界处理

Macro-level 插入时经常遇到 memory、模拟宏、加密 IP、供应商 IP 或不可展开模块。

处理原则：

对象	推荐策略
memory macro	不直接复制内部逻辑，优先 wrapper-level protection 或 ECC
analog/mixed-signal block	作为 blackbox 处理，通过边界 alarm 建模
encrypted IP	通过端口级 wrapper 或 instance-level duplication
CPU core	可采用 lockstep，但需要接口和复位严格约束
bus fabric	可进行关键子模块保护，避免全局复制导致面积爆炸
safety island	可作为整体保护对象

需要输出 blackbox boundary report：

text 复制代码

instance_path,module_type,reason,protection_mode,assumption,evidence_id
u_top.u_sram,sram_2p,macro_memory,wrapper_only,memory_ecc_required,EVID-021
u_top.u_adc,ams_adc,analog_blackbox,boundary_alarm,analog_safety_manual_required,EVID-022

这类报告对合作项目非常重要，因为它说明：

哪些对象被保护，哪些对象未被直接改写，哪些对象依赖外部 safety manual 或系统级假设。

16. D21 到 D22 的证据驱动机制选择

D22 的 protection plan 不应靠人工拍脑袋，而应由 D21 的 readiness 结果和 D01-D20 的证据链驱动。
FIT Contribution
Protection Selection
Failure Mode Map
FMEDA Item
Instance Criticality
Clock/Reset Readiness
Blackbox Constraints
Duplication / Lockstep / Triplication

示例规则：

条件	建议机制
instance FIT contribution 高，系统可进入 safe state	duplication + comparator + alarm
instance FIT contribution 高，要求持续运行	triplication + voter + alarm
两个通道可同步执行	lockstep compare
instance 边界清楚但内部不可见	wrapper-level duplication
输出协议复杂	protocol-aware comparator
memory 相关失效占比高	handoff to ECC / memory protection
clock/reset 不满足条件	D22 gate fail，返回 D21 修正输入

17. Macro Safety Synthesis Engine 的工具架构

D22 demo 中的核心引擎采用如下逻辑架构：
Safe-IC Flow Scripts
Input Collector
Evidence Loader
Design Import Adapter
Protection Planner
Macro Safety Synthesis Engine
Wrapper Generator
Comparator/Voter Generator
Alarm Aggregator Generator
Report Generator
FuSa Evidence Database
Closure Package

各模块职责：

模块	职责
Input Collector	收集设计文件、约束、D21 输出
Evidence Loader	读取 D01-D20 证据
Design Import Adapter	建立实例、端口、连接图
Protection Planner	决定插入策略
Macro Safety Synthesis Engine	执行实例级插入
Wrapper Generator	生成保护 wrapper
Comparator/Voter Generator	生成比较和投票逻辑
Alarm Aggregator Generator	生成 alarm 汇聚逻辑
Report Generator	生成证据报告
Evidence Database Connector	记录闭环证据

18. 插入前检查：Readiness Gate

在执行真正的插入前，需要先跑 readiness gate。

典型检查项包括：

检查项	PASS 条件
target instance exists	所有目标实例能在设计中定位
port direction resolved	输入输出端口方向明确
clock domain resolved	目标实例时钟可识别
reset domain resolved	目标实例复位可识别
blackbox rule resolved	不可展开对象有处理策略
alarm path available	顶层或 safety manager 有 alarm 接口
naming rule clean	复制实例命名不会冲突
evidence link complete	每个保护目标都有 evidence id
handoff ready	可生成 D23 / D24 / fault campaign handoff

readiness gate 输出示例：

json 复制代码

{
  "demo_id": "D22",
  "stage": "macro_level_safety_synthesis",
  "gate_status": "PASS",
  "checked_instances": 5,
  "ready_instances": 4,
  "blocked_instances": 1,
  "blocking_reason": [
    {
      "instance": "u_top.u_legacy_ip",
      "reason": "clock_domain_unresolved"
    }
  ]
}

19. 插入策略文件

D22 demo 建议使用 YAML 描述 macro protection policy。

yaml 复制代码

demo_id: D22
top_module: safeic_demo_top

default_policy:
  reset_mask_cycles: 4
  alarm_latch: true
  test_mode_mask: true

targets:
  - instance: u_top.u_ctrl
    mechanism: lockstep
    compare_points:
      - ctrl_state
      - safety_cmd
      - alarm_req
    alarm_name: alarm_ctrl_lockstep

  - instance: u_top.u_bus_guard
    mechanism: duplication
    compare_points:
      - bus_error
      - access_grant
    alarm_name: alarm_bus_guard_dup

  - instance: u_top.u_actuator_cmd
    mechanism: triplication
    voter_points:
      - actuator_cmd
      - actuator_valid
    alarm_name: alarm_actuator_tmr

这种 policy 的价值在于：

可审查；
可版本管理；
可复现；
可被 CI 调用；
可与证据数据库关联；
可被客户按 instance 粒度审批；
可为后续工具定制提供接口。

20. 输出设计文件组织

D22 生成的设计文件建议按如下结构组织：

text 复制代码

outputs/
  protected_design/
    protected_filelist.f
    safeic_demo_top_protected.v
    safety_wrapper/
      u_ctrl_lockstep_wrapper.v
      u_bus_guard_dup_wrapper.v
      u_actuator_cmd_tmr_wrapper.v
    safety_cells/
      safeic_comparator.v
      safeic_bus_comparator.v
      safeic_tmr_voter.v
      safeic_alarm_aggregator.v

protected_filelist.f 是后续工具统一入口。

示例：

text 复制代码

./safety_cells/safeic_comparator.v
./safety_cells/safeic_bus_comparator.v
./safety_cells/safeic_tmr_voter.v
./safety_cells/safeic_alarm_aggregator.v
./safety_wrapper/u_ctrl_lockstep_wrapper.v
./safety_wrapper/u_bus_guard_dup_wrapper.v
./safety_wrapper/u_actuator_cmd_tmr_wrapper.v
./safeic_demo_top_protected.v

这样后续 D24、D25、fault campaign、final DC 都可以使用统一的 protected design package。

21. Traceability Matrix

D22 的核心价值之一是生成 traceability matrix。

text 复制代码

safety_goal
  -> failure_mode
    -> fmeda_item
      -> target_instance
        -> safety_mechanism
          -> inserted_logic
            -> alarm_signal
              -> validation_artifact
                -> fault_campaign_result

示例表：

evidence_id	instance	failure_mode	mechanism	inserted_logic	alarm	next_validation
EVID-D22-001	u_top.u_ctrl	control corruption	lockstep	u_ctrl_lockstep_wrapper	alarm_ctrl_lockstep	D24 regression
EVID-D22-002	u_top.u_bus_guard	unsafe grant	duplication	u_bus_guard_dup_wrapper	alarm_bus_guard_dup	D25 testbench
EVID-D22-003	u_top.u_actuator_cmd	wrong command	triplication	u_actuator_cmd_tmr_wrapper	alarm_actuator_tmr	fault campaign

没有 traceability，插入动作只是设计修改；有 traceability，插入动作才成为可审计的 safety work product。

22. 与 FMEDA 的关系

FMEDA 需要回答：

什么失效模式被覆盖；
由哪个 safety mechanism 覆盖；
覆盖率如何估计；
最终 fault campaign 证明结果如何；
residual FIT 如何计算；
SPFM / LFM 是否满足目标。

D22 提供的是"机制实现证据"。
FMEDA Failure Mode
Target Instance
Macro Safety Mechanism
Inserted Logic
Alarm / Voter
Fault Campaign
Final DC / SPFM / LFM

FMEDA 中的 safety mechanism 不应只是表格中的一行文字，而应能追溯到真实插入逻辑、真实 alarm 信号、真实验证结果。

23. 与 Fault Campaign 的关系

D22 输出必须服务于后续 fault campaign。

Fault Campaign Engine 需要知道：

内容	来源
protected design filelist	D22
alarm list	D22 alarm report
observe points	D22 comparator/voter/critical outputs
fault target scope	D21/D22 instance map
blackbox handling	D22 blackbox report
safety mechanism map	D22 trace matrix
expected detection behavior	D22 mechanism policy

D22 应生成：

json 复制代码

{
  "handoff_id": "D22_TO_FAULT_CAMPAIGN",
  "protected_filelist": "outputs/protected_design/protected_filelist.f",
  "top_module": "safeic_demo_top_protected",
  "alarm_list": "outputs/reports/alarm_list.csv",
  "observe_points": "outputs/reports/observe_points.csv",
  "mechanism_map": "outputs/reports/safety_traceability_matrix.csv"
}

这使 fault campaign 不再依赖人工整理输入，而是直接接收 synthesis 阶段产生的机器可读 handoff package。

24. 与 ISO 26262 Closure 的关系

ISO 26262 closure 不是某个工具跑完就结束，而是多个工作产品之间形成闭环。

D22 在 closure 中承担以下角色：

Closure 问题	D22 回答
安全机制是否真实存在	protected design 与 wrapper 文件
机制覆盖哪个失效模式	traceability matrix
机制插入是否符合策略	macro insertion report
机制 alarm 是否可观察	alarm connectivity report
机制是否可验证	validation handoff
是否可进入 final DC	fault campaign handoff
是否可审计	evidence manifest

D22 的成熟度体现在：

每一个插入动作都能从分析证据追溯到设计变更，再追溯到验证结果，最后进入 FMEDA 和 final DC。

25. 等价检查与结构一致性验证

安全机制插入会改变设计结构，因此必须规划验证策略。

对于 fail-safe duplication：

原功能输出应保持与原始实例一致；
duplicated instance 不应影响功能输出；
comparator alarm 仅作为安全输出；
test mode/reset window 下 compare 行为应符合策略。

对于 TMR：

输出由 voter 产生；
单通道错误时 voted output 应保持正确；
三通道一致时 voter 不应改变功能行为；
disagreement alarm 应正确触发。

建议输出 equivalence_check_plan.md：

text 复制代码

1. Baseline functional outputs unchanged under no-fault condition.
2. Added alarm outputs are excluded from pure functional equivalence.
3. Reset mask window is modeled as allowed difference.
4. Test-mode masking is modeled explicitly.
5. Voter output equivalence is checked against single golden channel under no-fault condition.
6. Single-channel injected mismatch is checked by safety assertion.

26. CI Gate

D22 demo 应支持 CI 化。
Run D22
Readiness Gate
Protected Design Generated
Report Generated
Trace Matrix Complete
Handoff Package Complete
CI PASS

CI gate 可以包括：

Gate	条件
input gate	D21 输出存在
design gate	top module 与 filelist 有效
policy gate	所有 target instance 有机制
insertion gate	protected design 生成成功
alarm gate	每个机制有 alarm 或 voter status
trace gate	每个插入动作有 evidence id
handoff gate	D24/D25/fault campaign handoff 完整
closure gate	manifest 可复现

输出示例：

json 复制代码

{
  "ci_status": "PASS",
  "gates": {
    "input_gate": "PASS",
    "policy_gate": "PASS",
    "insertion_gate": "PASS",
    "alarm_gate": "PASS",
    "trace_gate": "PASS",
    "handoff_gate": "PASS"
  }
}

27. Demo21 到 Demo22 的延续关系

Demo22 继续使用 D01-D21 的输出数据，尤其是 D21 生成的：

text 复制代码

D21_safety_synthesis_readiness/
  outputs/
    candidate_protection_plan.csv
    synthesis_readiness_gate.json
    safety_traceability_seed.csv
    d21_evidence_manifest.json
    d21_to_d22_handoff.json

Demo22 不重新发明 candidate list，而是消费 D21 的 handoff：
D21 Handoff
D22 Evidence Loader
Macro Protection Planner
Protected Design Generator
Reports + Evidence

这种连续性体现工具链平台能力：

每个 demo 都不是孤立脚本，而是一个可积累、可追溯、可审计的安全工程流水线阶段。

28. Demo22 目录规划

Demo22 建议目录如下：

text 复制代码

D22_macro_level_safety_synthesis/
  README.md
  scripts/
    run_demo.csh
    setup_env.example.csh
    run_macro_synthesis_template.csh
  tools/
    d22_macro_synthesis.py
    d22_report_utils.py
  config/
    flow_config.yaml
    macro_protection_policy.yaml
    readiness_rules.yaml
    artifact_contract.yaml
  inputs/
    previous_outputs/
      D01_to_D20_exports/
      D21_safety_synthesis_readiness/
    design/
      design_filelist.f
      top_design_placeholder.v
    constraints/
      clocks.json
      resets.json
      blackbox_instances.csv
      protected_instances.csv
    library/
      stdcell_mapping.json
      library_placeholder.md
  outputs/
    protected_design/
    reports/
    evidence/
    handoff/

29. Demo README 的运行方式

README 中建议给出如下环境变量：

csh 复制代码

setenv SAFEIC_FLOW_HOME /path/to/automotive-safeic-practice
setenv SAFEIC_PREVIOUS_OUTPUTS /path/to/D01_D21_outputs
setenv MACRO_SAFETY_SYNTHESIS_ENGINE /path/to/macro_safety_synthesis_engine
setenv FUSA_EVIDENCE_DATABASE /path/to/fusa_evidence_database

setenv SAFEIC_D22_TOP_MODULE safeic_demo_top
setenv SAFEIC_D22_FILELIST ./inputs/design/design_filelist.f
setenv SAFEIC_D22_POLICY ./config/macro_protection_policy.yaml
setenv SAFEIC_D22_RUN_MODE dryrun
setenv SAFEIC_D22_OUTPUT_DIR ./outputs

运行入口：

csh 复制代码

csh scripts/run_demo.csh

dry-run 模式下 demo 应完成：

text 复制代码

[1] load D21 handoff
[2] load macro protection policy
[3] inspect target instances
[4] generate macro insertion plan
[5] generate protected design placeholders
[6] generate comparator/voter/alarm templates
[7] generate traceability matrix
[8] generate D22 evidence manifest
[9] generate D22 to D23/D24/fault campaign handoff

real-engine 模式下，则通过 MACRO_SAFETY_SYNTHESIS_ENGINE 调用真实插入引擎。

30. Demo22 预期输出

text 复制代码

outputs/
  protected_design/
    protected_filelist.f
    safeic_demo_top_protected.v
    safety_wrapper/
      u_ctrl_lockstep_wrapper.v
      u_bus_guard_dup_wrapper.v
      u_actuator_cmd_tmr_wrapper.v
    safety_cells/
      safeic_comparator.v
      safeic_tmr_voter.v
      safeic_alarm_aggregator.v

  reports/
    macro_insertion_plan.csv
    macro_insertion_report.csv
    target_instance_readiness.csv
    port_mapping_report.csv
    clock_reset_mapping_report.csv
    alarm_connectivity_report.csv
    safety_traceability_matrix.csv
    equivalence_check_plan.md
    netlist_or_source_handling_notes.md
    ci_gate.json

  evidence/
    d22_evidence_manifest.json
    d22_closure_notes.md

  handoff/
    d22_to_d23_handoff.json
    d22_to_d24_validation_handoff.json
    d22_to_fault_campaign_handoff.json

其中 netlist_or_source_handling_notes.md 用于记录本次输入形态对插入策略的影响，例如：

层次是否完整；
实例名是否稳定；
是否存在 flatten；
是否需要 blackbox；
是否需要 library mapping；
是否需要 source-level regression；
是否需要 structure-level equivalence。

31. D22 的工具定制能力

D22 很适合体现 Safe-IC Flow Owner / EDA Automation Platform Builder 的能力，因为它天然需要工具定制：

定制点	价值
instance selection rule	支持不同客户的安全策略
comparator template	支持不同协议、不同 valid/mask 规则
voter template	支持 bit-level、field-level、protocol-level voter
alarm policy	支持不同 safety manager 接口
naming convention	适配客户网表命名和层次规则
library mapping	适配不同工艺库
blackbox rule	适配 memory、AMS、encrypted IP
evidence schema	适配客户 FMEDA 模板
handoff format	适配后续 fault campaign 和 CI

这类能力不是单点脚本，而是平台化 EDA automation 的核心。

32. 工程风险与处理策略

D22 风险主要集中在结构变更和证据不一致。

风险	后果	处理策略
target instance 找不到	插入失败	D21 readiness gate 前置检查
clock/reset 识别错误	lockstep 不可靠	clock/reset mapping report
comparator 比较点选错	false alarm 或漏报	compare point policy + review
voter 粒度不当	protocol 被破坏	protocol-aware voter
alarm 未连接	fault campaign 无法分类	alarm connectivity gate
blackbox 假设不清	FMEDA 无法闭环	blackbox assumption report
结构优化影响实例名	traceability 断裂	stable naming + mapping table
DFT 模式未处理	scan/test 失败	test_mode_mask policy
等价策略不清	signoff 风险	equivalence check plan

33. D22 与 D23 的边界

D22 解决的是 macro-level protection：

实例复制；
lockstep wrapper；
triplication；
voter；
comparator；
alarm aggregation；
protected design package；
macro-level evidence。

D23 进入 micro-level protection：

register duplication；
parity；
ECC；
state machine protection；
endpoint protection；
startpoint/cone 细粒度保护；
control/state structure protection。

两者关系如下：
D22 Macro-level
Protect Big Contributors
Build Alarm / Wrapper Structure
D23 Micro-level
Close Remaining Critical Registers
Optimize Area / Coverage

D22 先解决高贡献实例的结构性保护，D23 再补齐细粒度残余风险。

34. D22 与 D24/D25 的边界

D22 输出受保护设计，但并不代表验证完成。

D24 应关注：

插入后 functional regression；
no-fault 行为一致性；
wrapper 连接完整性；
alarm reset/test mode 行为；
equivalence-ready package。

D25 应关注：

safety synthesis testbench；
fault activation stimulus；
alarm observation；
voter mismatch scenario；
protected design simulation harness。

D22 Protected Design
D24 Post-insertion Validation
D25 Safety Synthesis Testbench
Fault Campaign

D22 的目标是"生成可验证对象"，不是替代验证。

35. 一条成熟的 D22 工程主线

一个成熟的 D22 执行过程如下：

text 复制代码

1. Load D21 readiness handoff
2. Load D01-D20 evidence exports
3. Import design package
4. Resolve target instances
5. Resolve clock/reset domains
6. Resolve blackbox/memory boundaries
7. Load macro protection policy
8. Select duplication / lockstep / triplication
9. Generate wrapper structure
10. Generate comparator/voter/alarm logic
11. Generate protected design package
12. Generate insertion report
13. Generate traceability matrix
14. Generate equivalence check plan
15. Generate D23/D24/fault campaign handoff
16. Update evidence manifest
17. Run CI gate

这条主线体现了从"分析证据"到"设计变更"再到"验证闭环"的完整安全工程链路。

36. 总结

D22 的重点不只是实例级冗余，而是建立一个可复现、可追溯、可验证、可审计的 macro-level safety synthesis flow。

工程上需要同时考虑：

不同设计输入形态的处理差异；
客户合作场景下的最小必要输入；
instance boundary 的稳定识别；
duplication、lockstep、TMR 的机制选择；
comparator、voter、alarm 的模板化生成；
blackbox、memory、DFT、clock/reset 的约束处理；
protected design package 的标准化输出；
traceability matrix 与 FMEDA 的关联；
fault campaign handoff；
ISO 26262 closure 证据链。

D22 的最终交付不应只是一份修改后的设计文件，而应是一套完整的 safety synthesis evidence package：

text 复制代码

Protected Design
+ Macro Insertion Report
+ Alarm Connectivity Report
+ Traceability Matrix
+ Equivalence Check Plan
+ Fault Campaign Handoff
+ Closure Notes
+ Evidence Manifest

只有做到这一点，macro-level safety synthesis 才真正从"代码插入"升级为"汽车芯片功能安全工具链能力"。