功能安全（Functional Safety, FuSa）领域的DFMEA（Design Failure Mode and Effects Analysis，设计失效模式与影响分析）是一种以预防为主的系统化、结构化风险管理方法，它通过分析失效模式并优化来降低风险。在芯片验证领域可以参考DFMEA方法论，在思考问题时会更全面。芯片验证经常会假设RTL某项功能可能会出现问题，并构造激励去捕获，这与DFMEA的思路有异曲同工之妙。
DFMEA分析过程是沿着逻辑链层层递进，可以简化如下：
失效模式分析
从DUT的接口、结构、配置、新特性和复杂功能点等方面拆分为一个个特性点，然后开始分析其可能失效模式**(Failure mode)** 。考虑失效模式可以将特性结合More、Less、Early、Late、No、Partial、Permanent、Unintend等关键字去思考，结构化拆解出可能得失效模式。然后对每一个失效模式评估可能存在的影响**(Potential Effect)** ，其实就是会导致更上层次的失效模式了。对失效模式有个评分（1~10分），评分大小表征失效的严重程度(Severity)，数字越大越严重。
有了失效模式，我们就要反推回去，哪些可能的原因**(Potential causes)**会导致该失效模式真的发生了呢？原因通常是下一层次的失效模式引发的，这可能就需要往下继续分解了。当然原因可能是内部或外部触发的，比如错误输入条件、配置和引用等，环境的干扰和工艺制造相关问题等。
失效模式存在严重程度的评估，也存在出现概率(Occurrence)的评估，也是1-10分，值越大出现概率越大。如果一个失效模式很严重，但几乎不可能发生，那总的来说问题也不大。反之，如果一个失效模式很轻微，但很经常发生，那问题其实蛮大的。
预防措施
既然提出了一系列失效模式，那肯定要想办法去解决或减少这些失效模式的发生。首先是预防措施(Prevention Measures)，阻止这些失效发生。一般可以从根源解决掉，或打断原因和失效之间的链条。常见的预防措施有：
- 多复用已被证明过的模块或技术
- 冗余设计，比如DFT
- 复盘过往项目的教训
- 使用简单和成熟的方式去设计
- 设计审查
- 使用行业标准
- 使用自动化流程
有预防措施只是正向的分析解决办法，还需要检测手段(Detection Measures)去检查该特性确实不会有失效发生，我们有多大可能检测不出来该失效场景，同样也会有1-10的评分，数字越大表示心底越没底。常见的检查措施有：
- 仿真验证
- Formal验证
- RTL代码审查
- 等价性检查
- 原型验证
- 波形审查
- 举一反三
- 压力测试
- 验证方案审查
在分析完这些失效模式后，可以把Security、Occurrence和Detection Measures的评分相乘起来得到一个总的值，叫做R.P.N。数值越大表示表示需获得更多的关注，采取特定的方式去解决该失效模式。
举个例子，Core发起一笔load指令去地址A处读取一笔数据，它的失效模式可能有从错误的地址读取数据、数据错的、数据没有返回、数据多返回几笔、数据少返回、数据提前返回、数据延迟返回、数据没有完全返回等，根据这些失效模式去推测哪些模块出错可能会导致它们发生的。再对这些模块进行重点审查来预防，当然最后还是要落实到有什么手段可能更有信心探测出来，也就是验证。
其实对于一个特性验证来说，验证Owner要时常想我是如何完整验证这个模块的，对于这个模块的失效模式我是否需要增加更多的手段来保证它不会发生，在历史项目中是否有发生验证遗漏，后面是如何解决的。有逻辑、结构化去思考。
