2024年1月27日下午，SASETECH第十九期**“芯片功能安全开发实践”**成功举办。年末将至，大家在百忙之中抽出时间积极参加，远道而来，在深圳相约，聚焦于芯片功能安全开发的技术痛点和实操难点。
01 开放会议空间
本次以“芯片功能安全开发实践”为主题。继续沿用开放空间形式，分为自我介绍、开放空间介绍和讨论原则说明、议题介绍、讨论交流、议题总结等环节。
02 本期议题分享
在自我介绍结束之后，来自纽创信安的功能安全经理张汉雨老师组织大家围绕“硬件和软件安全机制的开发和实现”、“安全机制覆盖的失效模式分析，诊断覆盖率分析和计算”、“瞬态失效对系统设计的影响分析和相应的安全机制设计”、“DFMEA在车载芯片开发中遇到的痛点和应对”设定的四大议题展开讨论。
Clause1：硬件和软件安全机制的开发和实现
1、硬件安全机制-Data Parity 存储和搬运
Q1：如何开发和实现的？
A1：芯片开发中，在架构设计环节就需要考虑数据流的FuSa保护，从初始位置传输到目标位置的搬运和数据的存储可以考虑使用data parity的方式，其诊断覆盖率一般在90%及以下。
Q2：从芯片上电到下电需要考虑哪些因素。
A2：在芯片上下电过程中需要考虑CPU启动前后的区别，数据传输过程中的路径和最终消费的位置，error信息的存储和上报。
2、 硬件安全机制-Lock step
Q3：如何开发和实现的。
A3：lockstep对designer的开发和FuSa DC值比较友好，但有面积和功耗开销。
Q4：从芯片上电到下电需要考虑哪些因素。
A4：同时需要考虑reset释放后DFF中的dirty数据是否会引起compare 误报error。
3、软件安全机制-readback
Q5：如何开发和实现的。
A5：在register bank中，config和status register 需要对其永久性失效进行看护；
对config reg ，软件写入后周期性readback可以看护其永久性失效；
对status reg，软件周期性readback可以确保硬件在其正确的工作状态中。
Q6：从芯片上电到下电需要考虑哪些因素。
A6：在芯片从上电到下电过程中需要考虑CPU启动前后的保护范围和软件readback周期性设置的合理性。
4、软件安全机制-timeout
Q7：如何开发和实现的。
Q8：从芯片上电到下电需要考虑哪些因素。
A7/8：有些超时失效与业务时间强相关，有些超时失效需在硬件timeout基础上增加外部软件timeout，硬件timeout阈值可固定或可配，需要考虑理论超时上限时间和硬件timeout的硬件开销。
Clause2：安全机制覆盖的失效模式分析，诊断覆盖率分析和计算
Q1：以DMA失效模式之一：搬运了错误的数据为例，有哪些安全机制可以覆盖，其DC分析与计算?
A1：搬运了错误的数据需要具体展开为两种失效，一：丢帧；二：帧内数据损坏。
对于丢帧，可以考虑对帧计数的counter进行dual logic设计 DC值一般为99%；
帧内数据损坏，可以考虑使用parity/ECC等方法 DC值一般为parity不高于90%，ECC 99%（基于一定假设下）。
Q2：以Clock Generator失效模式之一：输出错误的时钟为例，有哪些安全机制可以覆盖，其DC分析与计算?
A2：输出错误的时钟需要具体展开为两种失效，一：no clock output；二：clock frequency out ofrange clock monitor 需要检测时钟的有无 同时检测其频率范围。
Clause3：瞬态失效对系统设计的影响分析和相应的安全机制设计
1、Register瞬态失效
● CONFIG Register--寄存器锁、奇偶校验，TMR；
● Status Register--只读寄存器，软件readback；
● Data Register--parity/ECC。
2、Memory瞬态失效
● Index ；
● Store可采用安全机制：基于一定假设的ECC。
Clause4：DFMEA在车载芯片开发中遇到的痛点和应对
开发痛点：
① 芯片层级多，分析颗粒度难以把握；
② 功能日益复杂，失效模式复杂度增加；
③ DFMEA团队协作中低效执行与维护。
●措施：梳理主功能表、经典模块化、Designer和FUSA Engineer业务分工；
● 需要经验丰富的执行者；
● 需要对安全分析进行库的积累；
● 考虑使用工具进行管理。
03 议题总结
针对实际问题和过往经验，以答题解惑的形式展开讨论。在此次讨论中，我们围绕议题进行了深入探讨，分析了问题的根源，提出了切实可行的解决方案。正对现有的行业需求和发展痛点，更加切实的感受到芯片功能安全开发需要在知识沉淀和经验共享中持续探索。
注：素材转自SASETECH
