SoC设计****中功能安全的一个核心是发现故障并进行上报给一个安全处理单元FSI或安全MCU过ISO26262认证然后这个安全单元进行决策怎么进行挽救处理。当然这个是从系统提供的技术来说具体的功能安全分析要根据业务去做。按照机制跟策略分离的方法我们从SoC设计角度出发提供各种安全机制就是本文讨论的内容。然后实际操作的时候由专业功能安全人员根据功能安全的需求从技术上有可用的接口然后再根据业务进行策略设计。1. 故障上报能力我们还是以主流的Orin设计介绍这个上报的安全单元就是安全MCU是SoC外部的。安全单元为什么需要在SoC外部搞安全MCU安全MCU是传统车上使用很久的东西例如英飞凌的TCXXX系列闭源你想集成到SoC那是不可能的除非英飞凌自己搞个SoC。SoC的技术则是从手机上学来的走的arm高通的开源路子很容易攒出来但是没有经历过太多实战考验需要一定的时间来做到传统的安全MCU。这只是其中一方面硬件独立的安全MCU本身就有天然的安全特性。1.1 SoC上报给安全MCU上报给安全MCU的故障分为两类主动上报FSI汇总SoC内部的故障信息通过SPI、PIN上报给安全MCU被动上报FSI的心跳机制给安全MCU上报或者卡死时停止响应安全MCU安全MCU去做业务时发现发生故障时也可能通路故障了例如SPI需要协议的这种那就通过PINGPIO来做兜底的上报。为了安全FSI跟安全MCU的SPI通信也需要加强从软件上需要增加数据包CRC校验从硬件上需要增加GPIO发送SPI数据前需要拉GPIO对方感知到要做SPI业务且对方准备好了才开始回复进行下一步通信。为了安全PIN也需要一次使用两根且电平相反连接因为PIN可能受到电磁干扰或者开路短路故障。1.2 SoC内部各IP上报给FSI汇总故障的种类分为软件故障通过软件通路上报SoC内部的核间通信技术硬件故障FSI中的FCCU监测到的硬件故障通过SOC_ERROR引脚触发FCCU中断进行处理然后FCCU将错误通过软件通知到外部安全MCU监视器再进行功能安全处理。FCCU可以通过NOC总线跟其他IP通信FCCU本来就是FSI的硬件有些严重的故障例如电压异常/高温等会不经过FSI的软件处理直接上报给安全MCU。大多数的硬件故障会先触发FSI的中断然后由FSI的软件去进一步处理。2. 故障分类及常见处理对于FSI搜集的故障要进行处理的时候需要进行分类普通故障各种wdt超时、exception、assert、通信故障、存储故障、机制失效等致命故障高温、高压、SoC损坏对于处理要看业务那些重要就归为致命故障重点还是要保障业务比如SoC主要做图像识别那摄像头、信号传输及处理NPU、ISP等这一条通路上的IP的优先级都是非常高必要的时候甚至可以按致命重启整个SoC来恢复。对于普通故障FSI运行正常时通过SPI上报给安全MCU。举几个例子A核硬件例如STL检查失败ECC故障等这时A核的硬件已经损坏无法满足一些业务例如在汽车上不能自动驾驶了那么通过SPI上报给安全MCU安全MCU进行刹车限速提示驾驶员接管方向盘自己开对于SoC可以进行重启恢复。同理A核的软件异常其他核的软硬件异常也是一样的。FSI的异常时硬件R核异常、软件exception或看门狗超时这时候不能通过SPI协议上报了只能通过硬件的PIN进行上报安全MCU。安全MCU还做出相关的业务措施来保证人员的安全。FSI的SPI控制器异常时这时也不能SPI通信了也是通过PIN进行上报安全MCU各种IP的WDT看门狗触发的异常一般把看门狗分为两级第一级的时候尝试自己恢复自己恢复不了再触发第二级就需要上报了。3. 防止故障的一些保护措施3.1 寄存器保护寄存器的值需要保持正确性为了防止某些寄存器的值改变可以使用冗余、ECC/CRC校验、周期回读等策略保证值的正确寄存器需要防止误操作我们在写代码时可能会误操作别的模块的寄存器这样就需要加一个lock寄存器这样就会防止误操作的错误需要操作的时候需要明文规定unlock。3.2 看门狗两级看门狗第一级的时候尝试自己恢复自己恢复不了再触发第二级就需要上报了。3.3 复位这个可以和看门狗配合使用IP有复位自己的能力。3.4 时钟保护只在系统启动时使用外部晶振之后需要使用PLL再经过CRU输出给各个IP。对于FSI比较重要可以单独使用一个外部晶振进行隔离保护。还有其他一些监测保护措施。3.5 电源保护对电压进行检测并异常上报。3.6 ISTIn-System-Test涉及执行结构化的ATPG自动测试模式生成向量即确定性扫描压缩和逻辑内建自测试LBIST以及在钥匙开启和/或关闭期间执行一组全面的MBIST存储器内建自测试算法以确定通过或失败状态。IST可以覆盖适用于较低几何FinFET技术的所有故障模型。挑战在于将这些向量的执行转化为一个完全独立的功能特性该特性可以在汽车系统的整个使用寿命中反复使用同时满足测试时间和功率预算的要求。IST架构的主要目标可以分为以下几类•高品质测试**** 为了达到最高的ASIL安全级别被测设计DUT需要具有非常高的永久性测试覆盖率。期望测试支持一套全面的故障模型以便检测较低几何FinFET设计中的缺陷。•低延迟**** 高品质测试模式是通过最短可能的测试时间和小巧的测试数据量实现的最高测试覆盖率来衡量的。•架构灵活性**** 架构应完全可扩展以适应不同的时钟频率和数据速率满足功率、存储和延迟要求。它还应该支持不同的设计配置。•TDP热设计功率预算**** 需要确保在IST执行过程中保持在功能性TDP的限制范围内。•调试和诊断**** 架构应支持所有模式的调试和诊断并为现场返回提供可追溯性。参考https://www.ctfiot.com/152148.html3.7 STL汽车的功能安全标准如ISO26262要求使用硬件和软件技术对潜在的故障进行现场测试。基于**软件自检SBST的软件测试库STL**是一种灵活的潜伏故障测试解决方案可替代基于可测试性设计DfT特征的硬件方法。STL可以被集成到任务操作系统中并在空闲时间定期执行。然而在为基于多核处理器的人工智能芯片开发STL时彻底优化故障分级过程和用适当的软件模块管理STL的执行是至关重要的。3.8 efuse保护对应一些数据需要做双重备份。3.9 增加调试手段这个存在于整个生命流程中主要有debug可以支持exception打印串口打印JTAG中断调试等gdb支持等手段trace更高级的CPU控制流状态跟踪monitor监控是否有故障ramdump把log保存下来利于出问题时分析接口测试对各种IP的接口进行命令健壮性测试3.10 编译器功能安全程序需要安全除了代码就是编译器可以决定。编译器作为影响程序安全性非常重要的因素。一些好的编译器都是商用的免费的也就是gcc。针对不同行业标准要求国内在安全关键领域的编译器主要有两种解决方案一是直接向国外购买被这些领域高度认可的编译器这些编译器均有相关行业标准的认证无论是在安全性还是在各类优化方面都很有代表性如Absint公司经过形式化验证的CompCert编译器、风河公司Diab编译器等。另一来源是获得业界认可的开源编译器如GCC和LLVM通过对其限定或改造如关闭某些优化选项、限定版本、改造前端对语言特性进行约束、增加某些静态检查功能、以及插入运行时检查代码等等来适应行业内部的安全性需求。CompCert**通过形式化验证的编译器绝对安全可靠**CompCert是一个高度可信的C语言编译器。CompCert提供了数学证明机制以验证编译生成的代码与源代码之间的正确性。该编译器被认为是目前最可靠的C语言编译器之一其代码生成质量和正确性已经得到了广泛的验证和认可。尽管CompCert是一个开源项目但它并不是免费的。其开源许可证允许用户查看和研究代码但商业使用需要购买商业许可。详细的许可信息可以在CompCert官方网站上找到。https://compcert.org/publi.html综上就是对SoC内部所有的IP进行安全分析加强主打一个为了安全不差钱。后记今年以来工作比较忙更新的也比较少但是我又回来了继续高质量免费分享程序员的奇怪知识。之前功能安全的都快写不下去了本人是软件程序员对底层技术有些兴趣这个功能安全算是软硬结合吧大部分是自己不擅长的。文中具体到每一个小的知识点在硬件或者专业的功能安全看来都是巨大的一堆技术和方案这里算是科普吧具体的设计可能多种技术一块用或者根据场景进行取舍。本篇作为功能安全入门的结束希望对广大程序员在知识面上得到扩展遇到相关问题的时候可以多一些思考。“啥都懂一点啥都不精通干啥都能干干啥啥不是专业入门劝退堪称程序员杂家”。欢迎各位有自己公众号的留言申请转载纯干货持续更新欢迎分享给朋友、点赞、收藏、在看、划线和评论交流公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io
功能安全入门-SoC设计漫谈
发布时间：2026/5/19 14:32:24
SoC设计****中功能安全的一个核心是发现故障并进行上报给一个安全处理单元FSI或安全MCU过ISO26262认证然后这个安全单元进行决策怎么进行挽救处理。当然这个是从系统提供的技术来说具体的功能安全分析要根据业务去做。按照机制跟策略分离的方法我们从SoC设计角度出发提供各种安全机制就是本文讨论的内容。然后实际操作的时候由专业功能安全人员根据功能安全的需求从技术上有可用的接口然后再根据业务进行策略设计。1. 故障上报能力我们还是以主流的Orin设计介绍这个上报的安全单元就是安全MCU是SoC外部的。安全单元为什么需要在SoC外部搞安全MCU安全MCU是传统车上使用很久的东西例如英飞凌的TCXXX系列闭源你想集成到SoC那是不可能的除非英飞凌自己搞个SoC。SoC的技术则是从手机上学来的走的arm高通的开源路子很容易攒出来但是没有经历过太多实战考验需要一定的时间来做到传统的安全MCU。这只是其中一方面硬件独立的安全MCU本身就有天然的安全特性。1.1 SoC上报给安全MCU上报给安全MCU的故障分为两类主动上报FSI汇总SoC内部的故障信息通过SPI、PIN上报给安全MCU被动上报FSI的心跳机制给安全MCU上报或者卡死时停止响应安全MCU安全MCU去做业务时发现发生故障时也可能通路故障了例如SPI需要协议的这种那就通过PINGPIO来做兜底的上报。为了安全FSI跟安全MCU的SPI通信也需要加强从软件上需要增加数据包CRC校验从硬件上需要增加GPIO发送SPI数据前需要拉GPIO对方感知到要做SPI业务且对方准备好了才开始回复进行下一步通信。为了安全PIN也需要一次使用两根且电平相反连接因为PIN可能受到电磁干扰或者开路短路故障。1.2 SoC内部各IP上报给FSI汇总故障的种类分为软件故障通过软件通路上报SoC内部的核间通信技术硬件故障FSI中的FCCU监测到的硬件故障通过SOC_ERROR引脚触发FCCU中断进行处理然后FCCU将错误通过软件通知到外部安全MCU监视器再进行功能安全处理。FCCU可以通过NOC总线跟其他IP通信FCCU本来就是FSI的硬件有些严重的故障例如电压异常/高温等会不经过FSI的软件处理直接上报给安全MCU。大多数的硬件故障会先触发FSI的中断然后由FSI的软件去进一步处理。2. 故障分类及常见处理对于FSI搜集的故障要进行处理的时候需要进行分类普通故障各种wdt超时、exception、assert、通信故障、存储故障、机制失效等致命故障高温、高压、SoC损坏对于处理要看业务那些重要就归为致命故障重点还是要保障业务比如SoC主要做图像识别那摄像头、信号传输及处理NPU、ISP等这一条通路上的IP的优先级都是非常高必要的时候甚至可以按致命重启整个SoC来恢复。对于普通故障FSI运行正常时通过SPI上报给安全MCU。举几个例子A核硬件例如STL检查失败ECC故障等这时A核的硬件已经损坏无法满足一些业务例如在汽车上不能自动驾驶了那么通过SPI上报给安全MCU安全MCU进行刹车限速提示驾驶员接管方向盘自己开对于SoC可以进行重启恢复。同理A核的软件异常其他核的软硬件异常也是一样的。FSI的异常时硬件R核异常、软件exception或看门狗超时这时候不能通过SPI协议上报了只能通过硬件的PIN进行上报安全MCU。安全MCU还做出相关的业务措施来保证人员的安全。FSI的SPI控制器异常时这时也不能SPI通信了也是通过PIN进行上报安全MCU各种IP的WDT看门狗触发的异常一般把看门狗分为两级第一级的时候尝试自己恢复自己恢复不了再触发第二级就需要上报了。3. 防止故障的一些保护措施3.1 寄存器保护寄存器的值需要保持正确性为了防止某些寄存器的值改变可以使用冗余、ECC/CRC校验、周期回读等策略保证值的正确寄存器需要防止误操作我们在写代码时可能会误操作别的模块的寄存器这样就需要加一个lock寄存器这样就会防止误操作的错误需要操作的时候需要明文规定unlock。3.2 看门狗两级看门狗第一级的时候尝试自己恢复自己恢复不了再触发第二级就需要上报了。3.3 复位这个可以和看门狗配合使用IP有复位自己的能力。3.4 时钟保护只在系统启动时使用外部晶振之后需要使用PLL再经过CRU输出给各个IP。对于FSI比较重要可以单独使用一个外部晶振进行隔离保护。还有其他一些监测保护措施。3.5 电源保护对电压进行检测并异常上报。3.6 ISTIn-System-Test涉及执行结构化的ATPG自动测试模式生成向量即确定性扫描压缩和逻辑内建自测试LBIST以及在钥匙开启和/或关闭期间执行一组全面的MBIST存储器内建自测试算法以确定通过或失败状态。IST可以覆盖适用于较低几何FinFET技术的所有故障模型。挑战在于将这些向量的执行转化为一个完全独立的功能特性该特性可以在汽车系统的整个使用寿命中反复使用同时满足测试时间和功率预算的要求。IST架构的主要目标可以分为以下几类•高品质测试**** 为了达到最高的ASIL安全级别被测设计DUT需要具有非常高的永久性测试覆盖率。期望测试支持一套全面的故障模型以便检测较低几何FinFET设计中的缺陷。•低延迟**** 高品质测试模式是通过最短可能的测试时间和小巧的测试数据量实现的最高测试覆盖率来衡量的。•架构灵活性**** 架构应完全可扩展以适应不同的时钟频率和数据速率满足功率、存储和延迟要求。它还应该支持不同的设计配置。•TDP热设计功率预算**** 需要确保在IST执行过程中保持在功能性TDP的限制范围内。•调试和诊断**** 架构应支持所有模式的调试和诊断并为现场返回提供可追溯性。参考https://www.ctfiot.com/152148.html3.7 STL汽车的功能安全标准如ISO26262要求使用硬件和软件技术对潜在的故障进行现场测试。基于**软件自检SBST的软件测试库STL**是一种灵活的潜伏故障测试解决方案可替代基于可测试性设计DfT特征的硬件方法。STL可以被集成到任务操作系统中并在空闲时间定期执行。然而在为基于多核处理器的人工智能芯片开发STL时彻底优化故障分级过程和用适当的软件模块管理STL的执行是至关重要的。3.8 efuse保护对应一些数据需要做双重备份。3.9 增加调试手段这个存在于整个生命流程中主要有debug可以支持exception打印串口打印JTAG中断调试等gdb支持等手段trace更高级的CPU控制流状态跟踪monitor监控是否有故障ramdump把log保存下来利于出问题时分析接口测试对各种IP的接口进行命令健壮性测试3.10 编译器功能安全程序需要安全除了代码就是编译器可以决定。编译器作为影响程序安全性非常重要的因素。一些好的编译器都是商用的免费的也就是gcc。针对不同行业标准要求国内在安全关键领域的编译器主要有两种解决方案一是直接向国外购买被这些领域高度认可的编译器这些编译器均有相关行业标准的认证无论是在安全性还是在各类优化方面都很有代表性如Absint公司经过形式化验证的CompCert编译器、风河公司Diab编译器等。另一来源是获得业界认可的开源编译器如GCC和LLVM通过对其限定或改造如关闭某些优化选项、限定版本、改造前端对语言特性进行约束、增加某些静态检查功能、以及插入运行时检查代码等等来适应行业内部的安全性需求。CompCert**通过形式化验证的编译器绝对安全可靠**CompCert是一个高度可信的C语言编译器。CompCert提供了数学证明机制以验证编译生成的代码与源代码之间的正确性。该编译器被认为是目前最可靠的C语言编译器之一其代码生成质量和正确性已经得到了广泛的验证和认可。尽管CompCert是一个开源项目但它并不是免费的。其开源许可证允许用户查看和研究代码但商业使用需要购买商业许可。详细的许可信息可以在CompCert官方网站上找到。https://compcert.org/publi.html综上就是对SoC内部所有的IP进行安全分析加强主打一个为了安全不差钱。后记今年以来工作比较忙更新的也比较少但是我又回来了继续高质量免费分享程序员的奇怪知识。之前功能安全的都快写不下去了本人是软件程序员对底层技术有些兴趣这个功能安全算是软硬结合吧大部分是自己不擅长的。文中具体到每一个小的知识点在硬件或者专业的功能安全看来都是巨大的一堆技术和方案这里算是科普吧具体的设计可能多种技术一块用或者根据场景进行取舍。本篇作为功能安全入门的结束希望对广大程序员在知识面上得到扩展遇到相关问题的时候可以多一些思考。“啥都懂一点啥都不精通干啥都能干干啥啥不是专业入门劝退堪称程序员杂家”。欢迎各位有自己公众号的留言申请转载纯干货持续更新欢迎分享给朋友、点赞、收藏、在看、划线和评论交流公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io
