做车规芯片的同行应该都有体会架构评审时DFMEA聊得火热一谈到FMEDA就安静了不少。倒不是大家不愿意做而是FMEDA这个活“想快很快想细很深”——一张Excel表填了两周最后认证审核员一句“lambda来源是什么”“DC为什么取80%”就能让你全部重来。Synopsys这些年围绕半导体可靠性和功能安全发布了不少报告与白皮书核心解决的正是FMEDA里最容易被扯皮的两个问题芯片级的失效率到底取多少失效模式按什么比例分。这篇文章我就用我自己做车规MCU和SoC安全分析时的思路把Synopsys报告里那套逻辑、FMEDA的底层公式、表格怎么拆、工具怎么配合完整地拆一遍。内容偏实操适合正在做功能安全量化分析、或者准备给芯片补ISO 26262材料的工程师参考。1. 为什么车规芯片绕不开FMEDASynopsys报告到底解决哪一步1.1 FMEDA在ISO 26262里的真实位置先把框架理清楚。ISO 26262对随机硬件失效提出了两类要求一类是定性的即通过安全机制把单点故障、残余故障、双点故障控制在可接受范围内另一类是定量的要用数字去证明“这个芯片在生命周期内因为随机硬件失效导致的安全目标违背概率足够低”。FMEDAFailure Modes, Effects and Diagnostic Analysis就是连接这两者的桥梁。项目里很多人把FMEDA和FMEA混着讲。FMEA是定性分析侧重于“失效模式-原因-影响-对策”关注的是关系梳理FMEDA则是在FMEA基础上给每个失效模式分配失效率λ、诊断覆盖率DC然后把它们“数值化”。你可以把FMEA看作一张关系图FMEDA是这张图上的每个节点都标上了速率和覆盖度。ISO 26262-5里要求的SPFM、LFM、PMHF本质上都来自FMEDA的计算输出。没有FMEDA你没法说清楚这颗芯片凭什么满足ASIL B或者ASIL D没有FMEDA你也没法跟TÜV、SGS这类审核机构解释清楚安全机制到底覆盖了多少硬件故障。所以在实际项目中FMEDA往往和功能安全手册、安全分析报告一起成为芯片流片前必须冻结的交付物。1.2 Synopsys报告提供的是“公共底座”说到Synopsys很多人的第一反应是VCS、Design Compiler、PrimeTime这些EDA工具。但Synopsys在功能安全领域还输出过一个非常关键的东西半导体器件的可靠性失效模型和失效率参考数据。芯片设计公司自己拿不到足够多的量产失效统计数据尤其是早期项目晶圆厂给的数据往往只覆盖工艺良率不覆盖“运行阶段随机失效”。Synopsys这类报告的价值是在行业积累的基础上给出了一套可以复用的框架不同芯片模块标准单元逻辑、SRAM、寄存器堆、PLL、IO、LDO的失效模式大致分几类每类占比多少失效率怎么按面积和工艺修正诊断机制对某些失效模式的覆盖效果如何评估。这套东西不是你直接抄答案的而是给自己一个合理起点至少不用从零开始拍脑袋。我习惯把Synopsys报告当“标定工具”先按它推荐的模型建立Base FIT和失效模式比例再结合自家芯片的面积、温度、电压工况修正最后通过故障注入或仿真结果去修正DC。这样产出的FMEDA逻辑链条完整审计时也容易讲清楚。2. 三个底层公式是FMEDA的地基2.1 单位换算FIT、ppm、MTBF和寿命之间的关系FMEDA里所有指标的计算都绕不开失效率λ。芯片行业最常用的单位是FIT全称Failures In Time1 FIT表示每10的9次方小时约11.4万年平均发生1次失效。之所以用这个单位是因为芯片失效概率很低用百分比表示太小用FIT表示阅读起来更直观。失效率换算很多人会搞混。假设某个功能模块的失效率λ等于50 FIT如果车辆一年运行8760小时那它一年内发生失效的期望次数就是50×8760×10^-9 0.000438也就是0.0438%的年失效概率。如果这颗芯片设计寿命是15年每天运行2小时那么总暴露小时是15×365×210950小时失效期望是50×10950×10^-9 0.0005475但如果按全天24小时算总暴露小时变成15×365×24131400小时失效期望就会变成0.00657两者相差约12倍。这个差距直接决定了你算PMHF时能不能过10 FIT的线。所以做FMEDA第一步不是打开Excel而是先定义清楚mission profile每天跑几小时、生命周期多少年、运行温度和待机温度如何。这个不定所有λ都是浮动的。MTBF也常被拿来做对标但MTBF本质上是1/λ只适用于指数分布假设对芯片早期失效和磨损失效阶段并不完全适用。工程上更严谨的做法是给早期失效、寿命期失效、退化期分别建模型FMEDA一般取寿命期相对稳定的失效率区间。2.2 SPFM、LFM、PMHF目标指标和计算口径ISO 26262里最容易被挂在嘴边的三个指标是SPFM、LFM和PMHF它们其实是三种视角SPFMSingle Point Fault Metric衡量的是单点故障和残余故障的控制程度计算方式是1减去“未被覆盖的单点故障失效率加残余故障失效率”除以“安全相关失效率总和”。LFMLatent Fault Metric衡量的是潜在双点故障的控制程度重点是那些“本身不立即导致安全问题但如果第二个故障到来就会出事”的失效。PMHFProbabilistic Metric for Random Hardware Failures则是用失效率的绝对值去衡量整个安全目标违背概率通常给ASIL D做定量论证用。公式层面一般可以写成下面这些形式具体写法不同报告可能略有差异但物理含义一致SPFM 1 - (λ_SPF λ_RF) / λ_relatedLFM 1 - λ_MPF_L / (λ_MPF_D λ_MPF_L)SFF (λ_safe λ_SU λ_MPF_D) / (λ_safe λ_SU λ_SPF λ_RF λ_MPF_D λ_MPF_L)PMHF ≈ λ_SPF λ_RF λ_MPF_L工程简化单位FIT注意SPFM这里的分母λ_related是“与这个安全目标相关的所有失效”不是整颗芯片的所有失效。如果你把安全无关的失效率也塞进分母结果会虚高或者虚低完全看你怎么凑。审核员最喜欢抓的就是这个分母口径问题我们后面会专门讲。在目标值上常见参考值是ASIL B要求SPFM≥90%、LFM≥60%ASIL C要求SPFM≥97%、LFM≥80%ASIL D要求SPFM≥99%、LFM≥90%。PMHF通常按ASIL D小于10 FIT、ASIL B/C小于100 FIT的量级来控制具体以产品安全概念和认证策略为准。这个“模糊”是有原因的因为不同安全目标、不同任务剖面会导致参考值差异工程上一定要先跟功能安全经理确认清楚。2.3 DC诊断覆盖率怎么算Case A/C的直觉诊断覆盖率DC算错是FMEDA最容易翻车的地方。DC的严格定义是安全机制能够检测到的失效率占潜在可检测失效率的比例。单个失效模式对应的DC λ_detected / λ_total_for_that_mode。日常生活中理解DC可以想象一个防盗门。门锁能拦住一部分入侵者但拦不住撬窗进来的也拦不住伪装成快递员的。防盗门的“覆盖率”绝不是100%也不是只算“开锁”这一种入侵方式。DC要针对失效模式来谈对一个stuck-at-0故障覆盖率可能是95%对两个bit同时翻转可能只有40%对全芯片电源短路可能是0%。如果你拿一个笼统的DC去算所有模式结果一定是错的。ISO 26262里还有一个概念叫Case A和Case C很多人看到就头疼。简单说Case A指的是双点故障能在安全机制检测后及时暴露Case C指的是故障处于潜伏状态等第二个相关故障到来才暴露。这对FMEDA的影响是同一个双点故障在不同架构下要分的类不一样分配的DC也不一样。比如带lockstep和ECC的CPU如果MBIST只在开机自检时跑那运行期间出现的RAM故障就可能是Case C如果RAM有实时ECC校验那故障就可能是Case A。这个选择和你的诊断周期、安全状态定义强相关不要硬套。3. 手把手做一张Synopsys风格FMEDA表3.1 第一步划分分析边界并确定Base FIT拿到芯片设计先不要急着填表先把分析边界画清楚。通常一颗车规SoC可以按功能安全分析粒度分成几个层级顶层是芯片级往下是安全相关IP和独立模块再往下是子模块和信号。FMEDA颗粒度太粗交不了差太细工作量巨大且容易陷入过度分析。我的经验是至少细化到SRAM、Register File、标准单元逻辑块、时钟生成模块、复位模块、IO接口、电源监控模块这一级别。Base FIT的确定是第一个技术活。Synopsys报告提供的失效模型一般会按模块类型给参考失效率。实际使用时我会先按门数或面积估算基础失效率再乘上工艺与温度修正系数。不同模块的失效率差异很大。逻辑门的主要失效模式是stuck-at和时序相关失效内存类是bit翻转和固定位故障PLL是失锁和频率偏差IO是静电损伤和ESD退化LDO是输出电压漂移。工程上可以先按一个基准面积密度折算。比如一个面积为2.5平方毫米的安全相关逻辑区域如果按工艺库给定的百万门失效率参考值再折算面积可以得出一个Base FITSRAM和寄存器堆又要单独按bit数和失效率模型算。这里最忌“拍一个总FIT”因为后面所有失效模式比例都基于这个源头不准全表白做。3.2 第二步给每个失效模式分配比例Base FIT确定后下一步是把每个模块的失效率按失效模式拆开。这个过程最依赖Synopsys这类报告的经验数据因为不同模块的失效模式分布差异很大。以SRAM为例我一般按这样的比例分配单bit翻转soft error可能占40%50%stuck-at-0占15%20%stuck-at-1占15%20%address decoder故障占5%10%sense amplifier偏置漂移等模拟性失效占5%10%。具体数字来自失效模型库和实际memory compiler的可靠性数据不是随意凑的。逻辑模块的失效模式分配方式又不一样。标准单元逻辑主要按stuck-at-0、stuck-at-1、时序故障、桥接故障来拆。纯组合逻辑里桥接故障和时序故障容易被低估但这些在高性能车规SoC里恰恰可能是主要风险源。分配比例时还要注意一个细节软错误soft error跟硬失效hard fault在FMEDA里的处理方式不同。软错误可以用系统级故障注入或中子测试数据来建模硬失效则更依赖工艺失效率数据。如果你在FMEDA里把两者混成一个λ后面做诊断措施分析时会对不上。3.3 第三步安全机制与故障分类失效模式分好之后就要开始给每个失效模式匹配安全机制并做故障分类。ISO 26262里常见的分类是Safe、SUSafe with no detection、SPFSingle Point Fault、RFResidual Fault、MPF_DMultiple Point Fault Detected、MPF_LMultiple Point Fault Latent以及Safety-related but not relevant之类的情况。“Safe”不是指没有故障而是指故障本身不会导致安全目标被违背。例如一个功能模块完全冗余失效后由另一路接管且接管过程符合安全状态要求这种故障可以分类为Safe。但这里有个陷阱Safe类故障不是你想归就归的必须要有证据比如架构上的冗余设计、安全机制可以在规定时间内完成切换。没有证据支撑审核员可以直接把你的Safe改成SPF。分类时还有一组容易混淆的概念SU和Safe有什么区别SU是Safe中的一类特指安全故障本身没有被诊断检测但因为故障性质无害所以不影响安全。很多工具表里会用Safe-SU之类的组合标记。实际操作时我建议表格里设立两个独立字段一个是“故障类别”一个是“诊断覆盖状态”这样审计时关系更清晰。3.4 第四步汇总计算并对照指标所有失效模式分类后就可以汇总计算了。以项目中一个简化过的安全相关模块为例假设这个模块总失效率是90 FIT并且全部与一个安全目标相关。经过分类后各类型失效率如下表基线所示故障类别失效率(FIT)说明Safe / SU70.0冗余接管、安全状态切换不会违背安全目标SPF1.0没有安全机制覆盖的单点故障RF0.5有安全机制但残余未被检测的部分MPF_D15.0双点故障已被诊断检测并在诊断窗口内响应MPF_L3.5双点故障当前处于潜伏状态合计90.0所有与该安全目标相关的失效带入公式SPFM 1 - (1.0 0.5) / 90 98.33%LFM 1 - 3.5 / (15.0 3.5) 81.08%PMHF ≈ 1.0 0.5 3.5 5.0 FITSFF (70 15) / 90 94.44%这个基线结果很典型PMHF能过ASIL D的10 FITSPFM也接近ASIL D的99%但LFM只有81%过不了ASIL D的90%。也就是说这颗模块的双点故障潜伏问题比单点问题更严重。针对这个问题如果增加一个周期性的自检机制把一部分MPF_L转成MPF_D同时加大硬件冗余让RF进一步下降改进后的结果可能如下故障类别改进后失效率(FIT)与原值对比Safe / SU71.0冗余逻辑和诊断逻辑让安全故障占比更高SPF0.3冗余覆盖了部分单点故障RF0.2诊断覆盖率提升残余更少MPF_D17.5自检机制把潜伏故障转为已检测故障MPF_L1.0潜伏故障大幅减少合计90.0总量不变改进后SPFM 1 - (0.3 0.2) / 90 99.44%LFM 1 - 1.0 / (17.5 1.0) 94.59%PMHF ≈ 0.3 0.2 1.0 1.5 FIT这才满足ASIL D的整体要求。这里可以看到三条指标不是同向变化的有时候SPFM过了但LFM差得远设计就得往诊断检测方向补。这种“指标不达标就找原因再针对性加机制”的迭代过程才是FMEDA设计的常态。3.5 第五步做一张可审计、可追踪的FMEDA表最后说下表格本身。一张合格的FMEDA表至少要有这些列分析模块名称、功能安全目标关联、失效模式、失效模式占比、失效率计算过程和结果、对应安全机制、诊断覆盖率DC、故障类别分类Safe/SPF/RF/MPF_D/MPF_L、诊断周期、安全状态定义、证据文件编号、备注。强烈建议把“失效率计算过程”单独拉一个sheet。比如SRAM那一行你写“总FIT34.5”后面就要有对应表格显示这是根据多少个bit、哪个工艺失效率模型、什么温度修正系数算出来的。没有这个细节任何一行数字被审核员要求解释时都要现翻资料。我自己的习惯是把FMEDA表格做成“半工具化”的用公式关联失效率和分类列最后SPFM/LFM/PMHF直接自动算出。每次改动只动源头数据指标自动更新这样版本迭代时不会因为手改漏了导致汇总对不上。再配合Git做版本记录每次修改填写修改原因审计时整个演进过程一目了然。4. 实际项目中用Synopsys工具链怎么配合FMEDA4.1 故障注入帮你拿DC依据而不是空口取DCDC是整个FMEDA里最容易被质疑的数字。很多团队喜欢对着安全机制“估计”一个DC比如看门狗80%、ECC 95%、lockstep 99%。审核机构现在越来越不吃这一套他们会要求你拿出故障注入或仿真数据来支撑DC。Synopsys工具链在这个环节能帮上大忙。你可以在RTL阶段用故障注入工具把某个信号置成固定值或翻转值然后观察安全机制是否触发、是否进入安全状态、失效是否在规定时间内暴露。这个过程不需要等芯片回来就能提前把DC的底数测出来。实际项目中我会先把FMEDA里识别出的关键失效模式做成一个故障清单然后按清单在RTL上跑故障注入统计每种模式下安全机制的检出率。这里的关键教训是故障注入的结果要和FMEDA表格里的失效模式一一对应。你不能只在FMEDA里写“SM1覆盖率90%”然后故障注入报告里完全找不到SM1对应的测试条目。对应关系越清晰后续认证沟通成本越低。4.2 结构覆盖率不等于诊断覆盖率DFT工具在车规项目里也很重要但很多人踩过同一个坑把结构测试覆盖率当成DC用。比如TestMAX跑出来某个模块的stuck-at覆盖率是99%就把FMEDA里对应安全机制的DC写成99%这通常是错的。原因很简单结构测试覆盖率衡量的是可测性不等于安全机制在系统运行期间能实际检出故障。一个故障在DFT模式下可以被扫描链抓出来但在运行模式下如果没有对应的自检机制它可能就是潜伏故障。FMEDA里的DC必须对应落实到“运行时的诊断机制”而不是“生产测试时的可测性”。我的经验是DFT覆盖率可以作为DC的上界判断依据但不能直接等同。如果非要参考必须在FMEDA表的备注里写明“该值来自DFT覆盖率仅作为设计能力评估运行时DC以故障仿真结果为准”。这样写虽然保守但比误导审核员风险低得多。4.3 DC不是你说了算报告与审计的闭环最后再说一下“证据闭环”这件事。FMEDA归根到底是给认证审核用的所以从第一版开始就要考虑“这个数字有没有出处”。我见过太多项目FMEDA做到后期才想起来补文件补起来非常痛苦。建议在项目初期就建立这样的证据目录安全机制清单与规格说明每个安全机制对应到RTL实现模块诊断覆盖率报告里面是每个机制的故障注入或仿真结果失效率来源资料包括工艺库提供的可靠性数据或Synopsys等报告的相关章节FMEDA主表每一步计算都能追溯回上面的资料安全分析结论写明是否满足项目安全目标。闭环的逻辑是FMEDA表格里的每一行要么来自设计文档要么来自仿真报告要么来自外部标准数据不允许出现无源之水。如果某一行确实只能拍脑袋那建议先按最保守的数值填然后后续补充真实数据来修正。审核时的主动权在你这边的感觉跟被追问到现场翻文档是完全两回事。5. 避坑点与经验总结六个容易翻车的地方5.1 失效率来源混用导致数量级偏差FMEDA里最常见的问题是同时用了多种失效率标准却没人注意到它们的口径根本不同。IEC 62380、SN 29500、MIL-HDBK-217这些标准的模型假设、环境因子、置信区间都不一样算出来的λ可能相差几倍甚至十几倍。特别是同一个模块如果你在安全分析里用了IEC 62380在PMHF里又换了SN 29500最后汇总的指标完全没意义。我踩过这个坑后现在项目里会强制规定所有模块只能用同一套失效率标准和同一套修正因子所有来源必须在材料清单里列全。哪怕标准本身存在争议至少内部一致审核员也好追溯。5.2 “运行小时”和“日历小时”被混为一谈PMHF的单位讨论里最微妙的就是时间基数。很多团队算PMHF时用日历小时乘以一个λ但λ本身是基于运行小时定义出来的也有人反过来用运行小时算但λ却是基于日历小时给出的最后指标结果完全失真。正确做法是先看失效率模型是怎么定义的。如果是基于“上电运行小时”的模型那PMHF计算里的暴露时间就该用运行小时如果是基于“日历寿命”的模型就要用校准后的日历寿命。一个折中策略是在FMEDA附录里明确写明“本项目PMHF按每天X小时运行、生命周期Y年、总暴露Z小时计算”这样别人复核的时候不会产生歧义。5.3 把软件层的DC直接算进硬件FMEDA软件安全机制的作用越来越重要比如CPU自检程序、内存读写测试、看门狗喂狗逻辑。但把软件诊断覆盖当成硬件DC直接写进FMEDA是很多从系统级转过来的人常犯的错误。FMEDA的核心分析对象是硬件失效模式。软件DTCDiagnostic Test Coverage可以说明某个硬件失效能被软件检测出来但软件本身有执行周期存在诊断窗口。比如自检程序每10毫秒跑一次如果故障发生在自检结束后的第9毫秒那真正被检测到的时间就要等下一个周期。在FMEDA里如果要求诊断窗口内的覆盖率就不能简单把软件诊断周期当成完全实时的机制需要把诊断周期对DC的影响折算进去。5.4 Memory故障不要只用字级覆盖率安全机制对Memory的覆盖是个重灾区。很多人写“SRAM使用ECCDC 95%”这是过度简化的典型。一个标准SEC-DED ECC对单bit错误的检测和纠正覆盖可以接近100%但对双bit错误的检测概率虽然高纠正能力却是0%。更关键的是多bit错误或地址线故障单个ECC往往无法处理。所以Memory部分的FMEDA应该按失效模式粒度拆分对单bit翻转、双bit翻转、固定位故障、地址解码故障、写使能故障分别评估DC而不是一句话带过。作者以前做过一个含大容量SRAM的模块用字级故障统计SPFM能到95%但拆到bit级和地址线级后SPFM直接掉到85%因为地址线故障几乎没有被ECC覆盖到。这个差距如果不拆出来流片后功能安全验证会很难补。5.5 安全相关与安全无关部分没有物理隔离FMEDA计算里把安全无关部分踢出分母的动机是合理的——它们不参与安全目标自然不该影响SPFM。但前提是安全无关部分真的不会影响安全相关部分。有些芯片设计里安全相关模块和安全无关模块共用同一个时钟源、同一条总线、同一个电源域。这种情况下即使你把安全无关模块的失效全部标记为“no safety related”它的失效也可能通过共因路径传导到安全相关模块。审核员对这类问题非常敏感一旦发现没有隔离证据整个FMEDA都会被质疑。实践上我会在FMEDA里对每一类“安全无关”失效加一个额外说明证明它与安全相关部分在物理上是隔离的或者在设计中存在监控保护。如果有条件最好在架构阶段就做电源域和时钟域的隔离这样FMEDA做起来省心很多。5.6 共因失效不在单点指标里的“坑”双点故障有一个很隐蔽的陷阱你以为两个通道都失效才算事故但实际上两个通道可能因为同一个共因同时失效。比如两个冗余通道共用同一个LDOLDO输出异常会导致两个通道同时挂掉。从FMEDA单点指标看LDO的故障分摊到两个通道里每个通道的指标都很好看但整体安全目标是失效的。共因失效CAFCommon Cause Failure需要在FMEDA里单独分析。通道A和通道B各自的双点失效组合不等于整体评估结束还要检查两个通道是否存在任何共享的资源、共享的时钟、共享的电源、共享的复位路径。只要有共享资源就要评估该资源的失效如何被安全机制检测或者把该资源本身作为单点故障纳入指标计算。这一步很考验设计理解深度但如果真的认真做了能提前发现不少架构层面的安全隐患。做FMEDA最怕的不是公式不会而是表格里每一个数字都经不起追问。我自己的做法是每次给单元格填数之前先问自己一句“这个数明天有人问的时候我能不能三句话说清楚来源”如果不能就先不填。芯片功能安全不是做给审核员看的而是做给未来每一个因为软件误诊而不敢跑高速的驾驶员看的。数据严谨一点比什么都重要。