解读

面试官想确认三件事：

1. 你是否把“安全机制”当成独立功能域，而非简单在原有覆盖率里“顺带”带过；
2. 你是否知道国内车规/工规/国密/等保对“安全”有量化指标，而不仅是“功能对就行”；
3. 你是否能把“覆盖率”拆成可落地的SystemVerilog/UVM指标，并给出sign-off阈值。
   回答时要先给“安全机制”划范围，再给出“三类覆盖率”+“两类阈值”+“一个闭环流程”，最后落到项目里程碑。

知识点

1. 安全机制分类（ISO 26262 DIA阶段国内普遍采用）：
   – 硬件安全机制：ECC、Parity、Lock-step、CRC、 watchdog、MBIST、LBIST、DFT、POR、Clock/Reset Monitor、地址保护区、TEE隔离。
   – 信息安全机制：国密SM2/SM3/SM4、AES-GCM、TRNG、PUF、密钥生命周期管理、抗侧信道、抗故障注入。
2. 覆盖率三维模型：
   – 功能覆盖率（functional covergroup）—— 把“故障注入+安全响应”当交叉覆盖点；
   – 故障覆盖率（fault cover）—— 面向ISO 26262 Part-5的DC/DFA，要求单点故障覆盖率≥99%，潜在故障≥90%；
   – 代码覆盖率（line/FSM/branch/toggle）—— 安全模块独立达到100% line+branch，toggle ≥ 98%，FSM 100%状态+转移。
3. 国内合规阈值：
   – 车规ASIL-D：安全机制相关covergroup必须≥95% 自动采样，剩余5%写分析报告并评审；
   – 国密二级：加解密通路covergroup≥98%，TRNG熵值在线检测covergroup 100%；
   – 等保2.0：密钥清零触发条件必须100%覆盖，且写入“不可绕过”断言。
4. 验证流程：
   安全需求→安全covergroup→故障注入用例→覆盖率收集→差距分析→增补用例/形式验证→回归→安全签收会议（需质量部、功能安全经理、信息安全经理三方签字）。

答案

“安全机制验证的覆盖率要求”在国内芯片项目里分三步收敛：
第一步，独立建档。把安全机制从普通功能中剥离，单独建立safety_island或crypto_top层级，配套独立coverage model。
第二步，设定量化阈值：

1. 功能覆盖率——对每条安全需求建立covergroup，采用“故障模式×安全响应×修复时间”三维交叉，ASIL-D等级要求自动bin覆盖率≥95%，剩余5%必须提交不可达分析并经功能安全经理评审；
2. 故障覆盖率——依据ISO 26262 DFA，对单点故障注入≥99%，剩余1%写FMEDA justification；对潜在故障采用双点故障注入，覆盖率≥90%；
3. 代码覆盖率——安全模块独立收，line+branch 100%，FSM状态与转移100%，toggle 98%以上，未达标部分用形式工具（JasperGold VC Formal）做可达性证明。
   第三步，闭环签字。所有coverage报告、故障注入日志、形式验证证明汇总到《安全验证签收报告》，由质量部、功能安全、信息安全三方评审后方可进入tape-out checklist。
   以上流程既满足ISO 26262 ASIL-D，也覆盖国密二级和等保2.0的国内合规要求。

拓展思考

1. 如果项目同时要求“低功耗”与“安全”，低功耗状态可能关闭部分安全监测，如何定义covergroup才能既保证低功耗模式100%覆盖，又不漏掉安全机制被误关闭的风险？
2. 对于RISC-V + TEE架构，安全世界/非安全世界切换由软件触发，硬件仅提供入口监控，covergroup如何采样“软件恶意跳过监控”这一场景？是否需要引入形式验证的“信息流”证明？
3. 国内正在推进的“汽车芯片安全认证”试点，要求把故障覆盖率数据与FMEDA工具链打通，未来验证团队需要直接输出故障列表到DFA平台，如何改造现有UVM环境，实现fault list → covergroup → FMEDA的自动闭环？