您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。[imagination]:Imagination2024年分布式功能安全的创新与突破白皮书 - 发现报告
当前位置:首页/行业研究/报告详情/

Imagination2024年分布式功能安全的创新与突破白皮书

信息技术2024-05-01Dan Wilkinsonimagination董***
Imagination2024年分布式功能安全的创新与突破白皮书

WhitePaper 分布式功能安全的创新与突破 作者:DanWilkinson,Imagination技术首席研究员2024年5月 本白皮书阐述了Imagination在未来关键安全产品中即将推出的硬件功能安全方面的创新。这些正在申请专利的技术针对的是需要达到汽车安全完整性等级(ASIL)-B保护级别的处理核,同时力求在面积、功耗和性能成本上达到最佳表现。 它概述了针对CPU和GPU核的全新分布式安全机制(DSM),这些机制能满足ASIL-B安全要求,相较于传统方法,其开销降低了两到三倍。 虽然本文档中的概念主要针对汽车产品,但在工业环境以及大型超规模或超级计算机处理集群中,硬件故障检测同样变得日益重要;所有这些技术都可以推广应用于这些领域。 ASIL-B与ASIL-D的定义 ASIL(AutomotiveSafetyIntegrityLevel,汽车安全完整性等级)简单来说,就是针对车辆特定功能在考虑潜在危险与运行情境下的所需安全风险降低程度。在确定ASIL等级时,ISO26262标准定义了一个风险模型,该模型考虑了多个因素,包括在特定运行情况下遭遇危险的概率、驾驶员在发生故障时对车辆的可控性,以及如果故障导致不良事件时事故的严重性。 相比于ASIL-D级别的开发,ASIL-B级别的开发在设计和开发周期中的要求较低,因为它们旨在减轻不同级别的安全风险。大致而言,ASIL-B级别可以认为是整个控制回路中包含了一名驾驶员,大多数事件一般可通过该驾驶员进行控制;而与ASIL-D级别相关的事件则被认为是不可控的,甚至是全自动化的情况,这就要求车辆控制系统(包括硬件和软件)承担更多的责任,以确保安全。 对于硬件开发,尤其是半导体开发,ISO26262标准允许将开发视为“脱离上下文的安全元素” (SEooC,SafetyElementoutofContext),同时也指出在这个系统层次上的设备面向通用设备,如CPU或GPU核。此外,还有一系列目标硬件架构指标,这些指标实际上是对危险故障检测诊断覆盖率的衡量标准。 目标指标可见表1: 架构指标目标 ASIL-B ASIL-D 备注 单点故障指标(SPFM) ≥90% ≥99% 预期危险故障的诊断覆盖率 潜在故障指标 (LFM) ≥60% ≥90% 预期的诊断覆盖率针对那些未被驾驶员检测到或感知到的危险多点故障 随机硬件故障的概率指标 (PMHF) <10-7/hr <10-8/hr 目标概率可靠性:尽管高可靠性本身并不能确保安全,但所有系统 都应设计为安全失败(fail-safe)。 表1:ASIL-B和ASIL-D开发的架构指标目标 考虑到ASIL-D级别下对危险故障检测极其严苛的要求,通常情况下,根据ISO26262标准的建议,最可行的安全机制一般采用复制冗余的形式,即重复执行工作负载,并结合某种机制来对比结果,以此检测任一路径中可能发生的任何错误。这种方法对永久性和瞬态故障都有极高的鲁棒性。 尽管ASIL-B的要求不像ASIL-D那样严格,但实际上,单点故障检测90%的目标通常已经很难达成,以至于在很多情况下,两次执行并对比输出结果的方法仍然常见。在其他情况下,工程师们可能会退而求其次,认为足够多的故障会自然变得可观察,并且是可控的,从而使故障覆盖率目标得以满足,并据此声称达到了ASIL目标。 对于ASIL-B解决方案,这两种方法逐渐显得不够令人满意:一是由于“运行两次”方法涉及到显著的时间或面积开销,导致车辆OEM不得不无意中要求半导体性能的提升,以支持高级车辆功能;另外,基于主观论证的方法由于其模糊性和在不断变化和复杂的使用场景中的通用性不足,也面临挑战。 本白皮书将重点介绍ImaginationTechnologies提出的新概念,其指出在不增加“运行两次”方法所涉及的面积或时间/功耗开销的情况下,提供符合ASIL-B的解决方案,同时提供可靠的方法来证明已实现所需的故障覆盖水平。 CPU锁步介绍 在传统的汽车双核锁步(DCLS)CPU解决方案中,通常针对ASIL-D要求,方法是仅复制处理核心,而不是复制其基于SRAM的缓存内存和互连,这些内存和互连通过奇偶校验(Parity)和错误更正码 (ECC)——单错误更正和双错误检测(SEC-DED)来保护。给定的工作负载会在两个处理核心上并行运行,并进行周期对周期的输出比较。这种方法的面积增加通常是: CPU处理核的面积翻倍。 因SRAM的ECC保护导致大约15%的面积增加。. 在缓存和CPU核之间的互连上,为了奇偶校验或ECC,除了用于比较两个核心输出结果的名义上的额外逻辑外,面积增加大约5-10%。 GPU工作组保护详解 Imagination为GPU设计的执行两次解决方案略有不同。在我们的GPU工作组保护(WGP)方法中,我们充分利用了GPU包含众多相同处理集群的事实,例如,这允许相同的着色器工作负载在两个独立的核心上并行运行,并比较它们的结果。 Processingcluster Processingcluster L2cache Interconnect L1cache Figure1:GPUMicrostructure L0cache Checksum GPUprocessinglogic L0cache Checksum GPUprocessinglogic 在所有配置下,Imagination的PowerVRGPU都包含多个共享L1缓存的处理集群。如图1所示,L2和L1缓存受到ECC(错误检查和纠正)的保护,而互连则受到Parity(奇偶校验)的保护。 安全关键的工作负载在两个独立的集群上运行,这两个集群共享L1缓存。处理逻辑从L1缓存读取的数据累积的校验和,以及处理逻辑将数据写回L1缓存后的校验和,用于验证两个工作负载的结果是否相同。如果结果不相同,则报告故障。 这对集群面积的影响几乎为零或最小(除了校验和逻辑),但会使使用工作组保护(WGP)的工作负载部分的运行时间翻倍。由于L2和L1缓存内存以及互连在两次运行之间共享(数据不会被两次提取到L2/L1缓存中),因此总体上的功耗和面积影响不会翻倍,但影响仍然显著。具体影响的大小取决于在集群上运行任务的功耗强度。 分布式功能安全:SRAM、总线和处理 分布式安全机制(DSMs)可以定义为用于检测硅设备中硬件错误的硬件或硬件辅助机制,这些机制并不依赖于完整执行或部分重复执行工作负载然后进行比较。 正如术语所指代的,为了达到预期的效果,安全机制分布在核的各个部分,每一个都专注于被测核中某一基本单元的功能层和行为层上的重要表现。因此,与执行两次方法相比,除了在运行时间和功耗开销上的优势之外,这些方法还帮助将故障定位到特定模块或电路(这是DCLS所无法实现的) 。 通常,DSM(分布式安全机制)的设计目的是针对处理核的以下几个方面,考虑其功能和可能的危险故障模式: SRAM: 片上的集成SRAM 总线: 围绕核心搬移数据的数据传输总线(例如,在缓存SRAM和处理流水线之间,或者通过片上网络在两个核心之间),且这些总线并不会改变正在传输的数据。 处理: 所有以某种方式转换数据的所有电路和模块。 对于SRAM(1),我们关心的是保护驻留在SRAM中的数据,既要防范设备寿命期间可能出现的永久性硬件故障,也要应对瞬态错误导致的存储位翻转,比如由偶发辐射或电源噪声引发的错误。长期以来,ECC(错误检查和纠正)和奇偶校验机制已被用于保护数据,它们对此类任务依然非常适合。 对于总线(2),仅仅需要检测在总线上传输过程中被翻转的位。对于这种情况,同样可以实施ECC和奇偶校验,以及诸如循环冗余校验(CRC)等基于包的机制。 一个设计可能通过结合使用ECC、奇偶校验和CRC,保护其约50%的晶体管,因为典型的处理核心预计会将约50%的面积用于SRAM存储器和总线。SRAM与逻辑区域的确切比例会依CPU和GPU的不同以及核心可能的多种配置而变化,并且会根据所使用的工艺技术而有所不同。 真正的挑战在于处理逻辑(3)。由于处理逻辑与总线不同,它会改变数据,因此静态的ECC和奇偶校验机制无法用于控制或检测错误。 这是Imagination着手解决的问题: 如何在不用重复或三倍化工作负载或处理逻辑的情况下,快速检测到处理逻辑中的错误? 一些功能安全解决方案,特别是对于那些SRAM和总线相对于逻辑部分占有较大比例的核,往往只是忽略逻辑部分,寄希望于通过将内存和总线覆盖到一个能检测到99%所有故障的水平,然后通过论证那些未被覆盖的故障可能会导致可检测的错误,以此来声称整个解决方案能够满足ASIL-B的要求。更糟糕的是,有一种观念认为,在DCLS(DualCoreLock-Step)配置中使用两个这样的核可以确定地降低ASIL-D的风险,但这严格来说并不正确。 这是一种无法令人满意的处理方式,因为通常整个解决方案未能达到ASIL-B的目标要求,需要依赖于执行两次的实现来解决;即便无需这样做,客户也必须相信有多少逻辑错误会被检测到的论断——这可能更多是靠运气而非优秀的工程设计。 Imagination在硬件功能安全方面的新方法主要基于一个洞察:现代处理核高度并行化。众所周 知,GPU会实例化许多相同算术逻辑单元(ALU)、纹理处理单元等实体。而即使是CPU,也在不断追求更高的指令并行度,并且越来越多地将专门的处理面积分配给向量单元和矩阵乘法单元。 因此,面对处理逻辑中错误高效检测的挑战,我们的解决方案如下: 安全对(SafetyPairs) 在任何通过多个相同电路实例实现的并行处理中,理论上,通过配对相同的电路实例,对两者运行测试向量并在简单的硬件检查电路(基本上是一组AND门的小型阵列)中比较输出,就可以检测出这些电路中的故障。我们将这样一对电路实例称为安全对。 典型的例子是在GPU线程块或CPU向量单元中,每个ALU都可以与同一块内的另一个相同的ALU配对。另一个例子,对CPU核而言,可能是配备有多个并行运行的指令解码器的多发射流水线的核。 空闲周期盗用(IdleCycleStealing,ICS) 像GPU和CPU向量单元这样的并行算术处理阵列的一个特性是,由于它们的本质以及使用它们的工作负载的性质,它们很少在一个超过几微秒的时间窗口内被完全利用。如果能够检测到安全对没有被任务模式工作负载使用的周期,那么这些空闲周期就可以被“盗用”,用于执行能够检测安全对内任一电路故障的测试向量。 这种安全对方法的一个相关属性是,具有空闲周期检测的安全对中的处理逻辑可以被设计为仅在该逻辑正被或最近被任务模式工作负载激活用过时执行故障查找测试。 安全对的测试向量(TestVectorsforSafetyPairs) 为了保证检测出安全对中的大多数故障,有必要运行多个测试向量,并使用基于原理、可测量的技术(如安全对电路的故障模拟,或自动测试模式生成(ATPG)工具)导出覆盖率最佳的向量集。 由于为每个安全对存储大量测试向量会带来过大的面积开销,因此最好使用线性反馈移位寄存器(LFSR)或类似方法伪随机生成一组向量,预加载种子值。这可以与极小数量的任意“补充”向量结合,以进一步增强覆盖率,这是与成熟的逻辑BIST(内置自测)方法类似的技巧。 最终,设备安全概念规定必须在硬件故障检测的一半时间之内完成所需覆盖率的向量集。通常,对于ASIL-B应用场景,这个限制设定在大约100毫秒左右。因此,如果我们能在每50毫秒内执行完我们所有的安全对向量集,我们就能保证不会发生任何故障,只要该故障被向量集中的至少一个向量所覆盖,它就不会在100毫秒内未被检测和报告。 只要每个安全对中被测试的单元足够小(例如,一个ALU),我们在Imagination的研究表明,通常只需几千个向量即可获得80%-90%的单点故障覆盖率。假设核心以约1GHz的时钟