功能安全Functional Safety, FuSa领域的DFMEADesign 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分值越大出现概率越大。如果一个失效模式很严重但几乎不可能发生那总的来说问题也不大。反之如果一个失效模式很轻微但很经常发生那问题其实蛮大的。预防措施既然提出了一系列失效模式那肯定要想办法去解决或减少这些失效模式的发生。首先是预防措施(PreventionMeasures)阻止这些失效发生。一般可以从根源解决掉或打断原因和失效之间的链条。常见的预防措施有多复用已被证明过的模块或技术冗余设计比如DFT复盘过往项目的教训使用简单和成熟的方式去设计设计审查使用行业标准使用自动化流程有预防措施只是正向的分析解决办法还需要检测手段(DetectionMeasures)去检查该特性确实不会有失效发生我们有多大可能检测不出来该失效场景同样也会有1-10的评分数字越大表示心底越没底。常见的检查措施有仿真验证Formal验证RTL代码审查等价性检查原型验证波形审查举一反三压力测试验证方案审查在分析完这些失效模式后可以把Security、Occurrence和Detection Measures的评分相乘起来得到一个总的值叫做R.P.N。数值越大表示表示需获得更多的关注采取特定的方式去解决该失效模式。举个例子Core发起一笔load指令去地址A处读取一笔数据它的失效模式可能有从错误的地址读取数据、数据错的、数据没有返回、数据多返回几笔、数据少返回、数据提前返回、数据延迟返回、数据没有完全返回等根据这些失效模式去推测哪些模块出错可能会导致它们发生的。再对这些模块进行重点审查来预防当然最后还是要落实到有什么手段可能更有信心探测出来也就是验证。其实对于一个特性验证来说验证Owner要时常想我是如何完整验证这个模块的对于这个模块的失效模式我是否需要增加更多的手段来保证它不会发生在历史项目中是否有发生验证遗漏后面是如何解决的。有逻辑、结构化去思考。