摘要：安全无危害的生活一直是人类的首要关注点。随着技术的发展以及旨在减轻人类劳动的自动化和机器在人们周围的出现，这些机器变得越来越强大，随着使用便利性的增加，危害也在增加。由于对高功率电气和电子系统的关注，已经制定了安全标准，以限制可能导致生命损失的危害和可能的失效情况。

本研究关注汽车系统的此类危害之一以及安全标准ISO 26262，该标准旨在规范安全危害受限系统的开发。功能安全分析广泛关注汽车用例中此类系统的可能失效，并将失效控制在一定的损害范围内，从而限制功能和运行危害。

电子系统中各种组件的开发和该系统的集成是一个非常复杂的过程，由于高度复杂性，开发过程中出现可能错误的机会也很高。验证侧重于检测和解决此类错误，并在最坏情况下执行系统以验证功能定义是否得到满足。

本研究高度关注高效且强大的验证框架，这些框架高度自动化、可靠，并为给定系统提供最大的验证覆盖范围。

设计的编制采用不同的方法，从文献、过去的经验以及行业对系统用途的要求中收集信息，包括其功能和附加安全系统。

01. 简介

1.1 动机

功能安全是一个适用于所有行业领域的概念，用于实现旨在安全相关系统的多种技术。功能安全的主要动机是在存在故障活动的情况下，以给定的可容忍速率降低崩溃或失效的概率。安全标准基于危害识别和风险分析，为实现E/E.PE系统的功能安全提供了参考生命周期。

1.2 目标

功能安全正在成为工业汽车领域的关键问题，该领域分别有其标准IEC 61508和ISO 26262。这些标准解决了由于随机硬件失效和系统失效导致的电气和电子或可编程设备故障引起的任何危害。ISO 26262规定了确保系统运行、实施、规划、设计和维护以提供所需安全完整性等级（SIL）的需求。根据系统应用中涉及的风险定义了四个SIL，为了防范最高风险，使用SIL 4。

1.3 问题陈述

该系统是根据ISO 26262的功能安全标准开发的，以确保产品满足其功能安全要求。验证和确认模型技术与每个设计阶段一起使用，以确保系统按照给定的安全需求开发。最终产品确保系统使用安全，不会由于系统和硬件失效导致的电气或电子设备故障行为而造成任何危害。

1.4 需求

对于实现，需要以下知识需求：

· 功能安全标准。

· 嵌入式C语言知识。

· Linux脚本。

· 多进程和多线程知识。

· Python和自动化。

1.5 工作范围

工作的主要范围是使用高效和优化的验证和确认技术，将与系统功能失效相关的可观察风险降低到由严重性、暴露程度和可控性评估给出的阈值以下。

02. 文献综述

本节包括功能安全、安全相关系统及其工程的背景。特别是从系统开发的角度强调功能安全的重要性。

2.1 背景

在公共场所、工业、企业或家庭中；都被越来越多的电气和电子设备和系统所包围。其中许多在没有内置安全机制的情况下可能对人类、动物或环境造成伤害，这些安全机制在需要时会完全激活，以将可能的风险降低到可容忍的水平。

功能安全是系统整体安全的一部分，通常侧重于电子和相关软件。它关注与设备或系统功能相关的安全特性，并确保其根据接收到的指令准确运行。在结构建议中，功能安全识别可能导致伤害人类或可能破坏周围环境的危害条件、场景或事件。它启用恢复或保护措施来清除或减少事故的影响。

2.1.1 安全概念的术语和定义

在本文工作的背景下：

· 安全是 “没有不可容忍的风险”

· 风险是 “危害发生的概率和该危害的严重性”的融合

· 伤害是 “对健康、财产或环境的身体伤害或损害”

· 可容忍风险是 “在给定背景下基于周围环境的当前效用而接受的风险”

· 故障是 “一个项目的状态，其特征是无法执行所需的功能”。

2.2 故障、错误和失效

2.2.1 故障

当发生故障时，项目进入故障状态。故障可能发生在两个阶段，即运行时或待机时。

计算值、观测值或测量值或条件与真实值、指定值或理论正确值或条件之间的差异。当系统的性能偏离目标性能时发生。

2.2.2 失效

失效是在特定时间点发生的事件。它可能逐渐发展，也可能作为突然的意外事件发生。失效披露的可能方式不同，可能是按需披露，或在功能测试期间，或通过监控或诊断披露。

2.2.3 失效、故障和错误之间的关系

失效源于错误。当失效发生时，项目处于故障状态。

2.3 失效类别

失效可根据以下方面进行分类：

①. 原因：为了避免未来发生并对维修做出判断。

· 随机失效：在随机时间发生的失效，由硬件中可能的一种或多种退化机制引起。随机硬件失效的特征可能是失效率：

（a） 恒定，意味着组件处于其有用寿命中，其中老化的影响可以忽略不计。

（b）非恒定，意味着组件处于老化阶段的烧入阶段

图2.1：错误、故障和失效之间的关系

图2.2：失效分类

· 系统失效：以确定的方式导致某种原因的故障，只能通过修改设计或制造过程、操作程序、文档或其他相关因素来消除。

（a）当触发条件存在时，系统故障将始终重复。

（b）系统故障可能在任何生命周期阶段引入。

（c）如果正确纠正，理论上失效将永远不会再次出现。

②. 可检测性：区分可能 “自动” 揭示的故障和那些可能隐藏的故障，直到采取特殊措施，如验证测试。

· 已检测：失效一旦发生，操作人员和维护人员立即明显。典型示例是报告为诊断故障或警报的故障。

· 未检测：失效对操作人员和维护人员不立即明显。典型示例是直到组件被要求执行其功能时才隐藏的失效。

2.4 功能安全

功能安全被定义为 “由于E/E系统故障行为引起的危害而不存在不合理的风险”，并且是整个系统安全或产品安全的一部分。这意味着，E/E系统的一个部分的失效可能导致设备损坏、受伤甚至生命损失的事故。功能安全不应与主动安全或被动安全混淆。主动安全是将重点放在避免事故的功能和技术分组。被动安全涵盖旨在减少事故影响的子系统。主动和被动系统都必须具有功能安全性，因为故障行为可能导致事故。

2.4.1 功能安全标准：ISO 26262

功能安全和ASIL（即电子可编程设备和电气的安全完整性）的概念在发布的功能安全标准国际电工委员会ISO 26262《电气/电子/可编程设备的功能安全》中得到满足，该标准深入指导如何从产品的最开始到其系统级别针对功能安全，并提供系统整个生命周期的需求。

该标准的主要目标是安全生命周期、风险和安全功能、安全完整性等级的概念。安全生命周期被描述为一个工程流程，涉及实现功能安全所需的流程。

图 2.3. ISO 26262 的技术需求

该标准是现场应用，已用于工业测量、控制和自动化。它为软件和硬件以及封闭的硬件和系统完整性提供了全面的规范。紧急关闭在确保运行和生产安全方面起着至关重要的作用，这由安全联锁系统SIS提供。类似地，ISO 26262标准适用于道路车辆和自动化，是IEC 61508的修改版。IEC 61508标准中也有子分区，其中特定标准用于特定部门或领域。

· IEC 61511适用于过程工业

· IEC 61513适用于核电站

· IEC 62061适用于机械部门

· IEC 61800-5-2适用于电力驱动系统。

2.4.2 功能安全生命周期

IEC 60518标准生命周期描述了整个生产步骤。该过程从系统概念的基本定义和范围开始，包括系统评估。进一步检查风险和危害，为风险缓解工作提供顶层视图。并选择功能安全系统来减少这种情况。

图 2.4. IEC 61508的生命周期

功能安全系统流程从适当的范围定义及其概念需求规范开始，以定义项目。然后，根据绘制的安全需求，开发硬件和软件设计，最后将两个领域集成到一个功能单元中，并作为整个功能系统进行验证。根据失效和风险分析，引入修改，整个过程从那里重复，以制作准确的功能安全系统。

图2.5. IEC 61508规定的安全系统简化流程

2.4.3 故障避免和故障容错

功能安全标准确保了一个流程，该流程识别可能的故障以消除它，并在运行时识别它。可以通过设计系统使其甚至不发生来避免它。但事实是，并非所有故障都被消除，但可以在运行时检测到，这使系统保持在预定义的安全状态。

下图解释了IEC 61508标准中所述的故障检测和延伸到安全状态的基本流程。最初系统在正常操作中运行，故障出现，其中可以在诊断间隔内使用诊断逻辑注意到故障，并在故障反应时间内将系统置于安全状态。容错系统是即使在导致伤害的危害发生之前也将系统保持在安全状态的系统。

图2.6. IEC 61508的容错流程

必须有清晰的流程来避免故障，并能够在运行时检测故障并将其达到安全状态。技术概念应提及分析故障、避免故障、在安全状态下检测到的残留故障的需求，适用于所有产品的所有配置。

03. FUSA实施

对于ADAS用例，芯片组应按照ISO 26262功能安全标准实施FUSA。

汽车系统中使用的电子设备预计满足某些功能安全需求；这些需求的目标是消除由于故障行为引起的危害对人们造成的不合理风险。这些需求在ISO 26262标准中定义，包括4个不同的安全级别：ASIL-A（需求最轻）到ASIL-D（需求最严格）。ACF的基线需求是满足ASIL-C需求。这些需求可以通过SoC上的硬件功能以及软件和系统级功能的组合来满足。安德森湖平台（The Anderson Lake Platform）预计满足ASIL-D需求。

3.1 安全机制

3.1.1 单点故障

需要检测单点故障并采取缓解措施，以在特定时间段内将系统置于安全状态。从故障发生到检测到故障的时间称为FDTI（故障检测时间间隔），从检测到故障到达到安全状态的时间称为FRTI（故障反应时间间隔）。FDTI和FRTI的总和应小于FTTI（故障容错时间间隔），即如果未激活安全机制，从项目中发生故障到可能发生危害事件的最短时间跨度。

这需要对逻辑电路进行主动、实时的监控和检查，以及错误报告和记录。覆盖单点故障的常见方法（非详尽列表）包括：

· SRAM/RF上的ECC（或奇偶校验）

· DDR接口上的ECC

· 使用BIST（MBIST、PBIST）对阵列进行关机测试

· 定期运行以执行诊断测试的STL（软件测试库）

· 总线、互连和队列/缓冲区上的奇偶校验

· 仲裁检查

· CRC生成并与黄金值比较

· 电压监控：欠压/过压条件

· 时钟监控：频率监控

· PLL 监控：失锁

· 硬件冗余，包括CPU锁步（基于软件或硬件）

3.1.2 潜在故障

潜在故障覆盖本质上是检查检测器 —— 确保覆盖单点故障的安全机制中没有故障。通常，每个钥匙开启/关闭周期运行一次潜在故障检查就足够了，这指的是驾驶员启动/关闭车辆。通常更希望在钥匙关闭时运行这些诊断检查，以避免启动车辆行驶时出现任何额外延迟。

覆盖潜在故障的常见方法（非详尽列表），即检查检测器包括：

· MBIST或PBIST（阵列被视为潜在故障源）

· ECC 和奇偶校验电路的 BIST（自测试）

· 使用基于结构的故障测试（SBFT）进行核心自测试

· 执行诊断测试的STL

- 启动时的配置检查

· ECC和奇偶校验电路的错误注入

· 锁步检测器等检测器的BIST

3.2 FUSA策略

安德森湖平台的主要目标是添加功能安全功能，以支持ASIL-D级自动驾驶系统。根据ISO 26262，平台及其组件（以及SNI）中的功能安全功能对于在系统/项目级别实现ASIL D需求至关重要。ADS的MPFDI假定为钥匙开启到钥匙关闭周期。

ACF处理元件的高级diagram如下所示。这是一个概念性简化diagram，展示了ANL处理元件的关键接口。它不包含所需的每个信号，也未显示所有接口。

出于假定的ANL技术安全概念的目的，ANL处理元件由三个组件组成：

· Ash Creek Falls (ACF)

· Pedro Canyon (PDC)

· Sentinel Island (SNI)

图3.1. FUSA框图

3.2.1 不同级别的FUSA实施

ACF中的FUSA实施分为需要执行的不同级别机制：

核心级别

硬件锁步（HWLS）或紧密耦合锁步（TCLS）涉及将主核心和从核心配对，使得核心对的所有输入都相同。这通过将相同的输入物理路由到两个核心来实现。每个周期都会比较主核心和从核心的输出，以检测核心是否未处于锁步状态。不匹配会被标记为错误。只有主核心的输出被允许继续，而从核心的输出在比较后被丢弃。

芯片级别

需要时钟监控来减轻时钟生成和时钟分配失效。此功能可减少可能使其他安全机制失效的相关失效。

时钟监控器在一段时间（采样窗口）内对目标时钟的脉冲数进行计数。将计数与预期（可编程）值进行比较，并记录结果状态。安全岛可通过消息通道读取计数和状态。

板级

· 安全岛是一个ASIL D微处理器环境，用于运行需要极高可靠运行的安全关键任务。

· 安全岛监控电压、时钟、平台电源状态，并检测和识别非法或超出规格的运行。

· 安全岛与PCH和CPU SOC合作执行功能诊断。

· 安全岛充当内部和外部错误的中央错误收集器。安全岛向外部MCU报告错误。安全岛还对错误报告路径执行诊断并支持错误注入。

3.3 验证控制单元

验证控制单元（VCU）是一个片上可编程微控制器，主要设计用于检测对可生存性和调试有用的微架构事件。在ACF上，它是通过带内PECI（通过x4 PCIE链路）与英特尔安全岛通信的主要代理。

VCU执行以下与安全相关的功能（不包括任何现有调试功能）。后续部分将更详细地扩展每个功能：

· 收集时钟监控数据并根据需求（每个FDTI至少两次）将其传输到安全岛。

· 收集电压监控数据并根据需求（每个FDTI至少两次）将其传输到安全岛。

· 收集崩溃转储（MCA存储体）并根据需求（检测到错误时或可能根据用户需求每个FDTI）将其传输到安全岛。

· 从各种寄存器收集配置数据，以确保ACF配置正确（启动时至少一次，可能根据用户需求每个FDTI）。

· 与PCU和BIOS的邮箱接口。

· 通过向安全岛断言警报引脚来标记错误。

· 阵列测试调度和结果收集。

· 所有核心的结构测试（SBFT）。

安全岛通过x4 PCI链路通过带内PECI消息将数据传输到VCU。消息通过使用供应商定义消息（VDM）的MCTP数据包跨PCIE链路传输。

图3.2. FUSA实施级别

图3.3. 验证控制单元

04. 验证策略

本节讨论单个验证的范围，其中给出了验证策略的定义，并构建了验证框架以满足验证范围。

4.1 验证流程

硅后系统验证旨在验证硅制造缺陷以及集成故障，其中尝试使用考虑所有可能缺陷场景的大量测试用例进行完整验证。这确保交付的产品经过彻底测试，并确保交付高质量产品。

· IP设计和RTL发布，以及子系统微代码的发布

图4.1. 流程流

功能安全需求根据ISO 26262和ASIL标准定义。

· 根据功能需求制定测试规范和测试用例定义

· 构建满足端到端验证（最大覆盖范围）的各种IP的测试计划

· 为涵盖正向、负向和压力测试的所有场景设计测试用例

· 根据测试用例设计在各种环境中开发测试用例和框架

· 测试用例执行、调试并向设计和开发团队提供结果和反馈

4.2 测试用例设计

测试用例旨在验证功能、流程或子功能。测试用例的基本概念是提供与功能定义对应的预期输出的输入，并观察输出，将实际输出与预期输出进行比较将给出测试用例的结果。

功能模块和系统的设计和开发基于一组需求，并且与需求紧密绑定，测试用例基于该需求定义，并在给定的系统和功能模块上执行以验证需求的满足情况。

测试用例设计将包含满足测试用例功能及其进入和退出条件的各种参数，测试用例设计中定义的参数如下：

· 测试用例定义

· 测试用例描述

· 前置条件

· 后置条件

· 测试用例设计

· 验证方法

· 预期结果

· 测试脚本

· 执行记录

4.3 验证范围

作为FUSA验证的一部分，安全模块到芯片的通信是至关重要的部分，芯片包含一个芯片可编程微控制器，该微控制器用作目标CPU上FUSA实施的接口。验证范围是FUSA单元到CPU接口。接口通过以下方式实现：

· GPIO引脚

· IB-PECI，在PCIe线路上实现

验证范围包括：

· SNI VCU事务

· IBPECI通道事务

· 从VCU到SNI的GPIO接口

· VCU BIST执行

· VCU定期检查执行

图4.2. 验证范围

05. 验证框架

硅后验证在调试平台上执行，该平台以仿真环境或具有实际用例的组件形式集成了各种子系统。上电板通常包含集成的子系统和组件，在设计和开发过程中，随着集成朝着实现实际功能的方向发展，执行的依赖性增加。

由于各种子系统和不同环境的集成，需要一个验证框架，该框架满足与其他组件握手的需求，并满足满足测试用例的系统和状态需求的流程。

基于使用不同工具和脚本/编程语言的各种环境，开发和构建了各种验证框架。

5.1 基于PythonSV的验证框架

该验证框架可用于端到端硅后IP验证，也可用于以自动化形式对寄存器值进行抽查。IP的验证旋钮也用于该框架中。

5.1.1 PythonSV

· 在多个项目中使用，整个存储库可访问，因此任何人都可以共享脚本

图5.1. PythonSV控制台

· 通过允许每个人共享跨各种项目和团队开发的不同工具，促进左移

· 它具有用于PythonSv脚本的预硅开发的存根模式，因此它们可以在硅后重用

· 基础访问提供跨不同环境的通用功能，因此代码可以在不同环境中重用测试

· PythonSv允许用户在多个环境中拥有测试内容

· 代码可以在不同阶段和项目中重用

· 它可以与ITPII、OpenIPC、仿真、SVOS等工具一起使用，为大多数用户节省时间和精力

5.1.2 框架架构

框架架构具有各种软件和硬件组件，因此可以访问寄存器组件进行读/写。

· 测试脚本构建在PythonSV环境之上，用于读/写和执行测试用例的逻辑功能

· 使用PythonSV的库集和定义为对象类的组件，将基本参数传递给ITP

· ITP（目标内探针）用于使用目标芯片/硬件的JTAG TAP访问组件硬件

图5.2. 基于PythonSV的验证框架架构

5.1.3 测试用例设计

测试脚本由寄存器读/写命令组成，读取的数据通过逻辑运行进行分析，并进行决策或结果提取。测试脚本流程将是：

· 使用来自PythonSV控制台的命令和参数执行测试用例

· 配置测试用例的前置条件和组件状态

· 根据输入参数访问作为组件类对象的寄存器，以写入逻辑计算或参数中预定义的数据

· 配置控制寄存器以启用功能或进程，并配置组件的控制参数

· 访问作为组件对象的输出寄存器以读取数据并提取结果

· 对多个可能的实例迭代写-配置-读过程

· 将输出与期望输出进行比较，并以通过/失败的形式给出测试结果

图5.3. 测试流程

5.1.4 测试套件

基于PythonSV和Python脚本，为特定IP构建测试套件作为Python模块，将所有独立的IP验证测试用例集成到一个测试套件中。

5.2 FPGA裸机框架

开发自定义C代码并加载以在硬件抽象层之上模拟固件操作。测试和验证用例包括：

· 实现系统验证的测试用例

· VCU和VCODE的边界验证覆盖

· 板载安全模块-VCU接口的GPIO+IBPECI验证覆盖

· 用于验证BIST命令和用于BIST验证的负向验证

5.2.1 IB-PECI通道

平台环境控制接口（PECI）使用单根线进行自时钟和数据传输。“PECI主机” 向处理器发出请求。每个处理器是 “PECI客户端” 并响应请求。PECI没有异步通知的概念，处理器永远不会在PECI总线上发起对话。

有两种选择-英特尔特定VDM（RAVDM）和PCIe上的MCTP。

5.2.2 框架架构

使用Altera Cyclone V FPGA和实现有自定义HAL和BSP的NIOS-II（ARM Cortex）处理器架构，用于PCIe和GPIO功能，在HAL之上实现裸机代码，以发送和接收数据以及对数据和IB-PECI命令执行逻辑运行，以交互和实现测试用例以及调试。

图5.4. FPGA裸机框架

5.2.3 测试用例设计

测试用例通过对VCU上固件的各种API（即VCODE）的IB-PECI命令进行排序来实现，并验证VCODE功能以及BIST执行。

执行流程将根据安全模块固件使用的流程进行：

· 使用各种参数（如API索引、子命令、API数据输入）生成数据包

· 使用HAL级API发送请求数据包并等待响应数据包

· 从响应数据包中提取完成代码和返回的数据，用于逻辑运行和决策

· 对 BIST 或任何其他安全功能的完整序列迭代该流程

· 根据完成情况以及响应数据包中返回的数据对测试结果进行决策

图5.5. BM验证框架套件

图5.6. BM验证框架示例输出

5.3 框架中的回归测试

验证工作的一个关键部分即功能的回归测试，旨在对系统进行极限压力测试或模拟最坏情况场景。

所有已开发的测试框架均实现了功能的回归测试，这对向设计开发团队提供反馈以及验证压力测试需求起着至关重要的作用。验证框架中实现了自动化回归执行功能，可针对各种自定义参数迭代功能测试。同时，也对各类IP和功能进行了测试与数据偏差分析。

06. MCU框架

主控制单元是电路板的安全主控，也被称为SMCU或安全监控器，负责在电路板上实现FUSA。

SMCU 通过以下接口与电路板上的 FUSA 单元连接：

· SPI通信（SMCU为主设备，FUSA单元为从设备）

· 状态GPIO（正常/异常/警报）

SMCU将执行错误转储、分析，并执行启动、关机操作，同时充当FUSA单元的周期性watchdog。当发生错误或功能异常时，SMCU将通过GPIO引脚接收通知，并通过SPI接口向FUSA单元发送命令。在启动和关机状态期间，上电自检结果以及关机BIST结果会以通过/失败状态传达给SMCU。

SMCU将为安全单元（FUSA单元）提供诊断接口。

图6.1. 诊断接口

6.1 MCU的需求

SMCU作为FUSA单元的主控，由于FUSA单元是验证的主要范围，因此需要满足以下需求：

· 完成完整流程

· 集成验证

· 用各种命令触发固件

· 验证安全模块与SMCU的接口（诊断接口）

SMCU的需求至关重要，尽管生产用SMCU可能无法用于验证流程。为满足资源需求，已提出多种方案。

6.2 作为MCU的SPI接口

由于SMCU的高优先级需求，观察到框架需要具备以下特点：

· 半双工SPI接口和GPIO接口

· 模拟MCU动作，并通过SPI发送自定义数据/命令

· 框架应通过USB与通用计算机连接

6.3 作为MCU的Aardvark

6.3.1 Aardvark卡

Aardvark卡是一种I2C和SPI转USB接口，允许用户与Windows和Linux环境连接，并支持与各种嵌入式系统连接，通过I2C或SPI接口发送串行数据。

它允许其连接器上未使用的数据和时钟线用作GPIO。由于这些特性，Aardvark卡最初被选为MCU接口，其GUI可用于通过SPI发送命令。

图6.2. Aardvark GUI

图6.3. Aardvark SPI数据损坏

6.3.2 逻辑电平差异

Aardvark 卡的缺点是安全模块的逻辑电平为1.8V，而Aardvark卡工作在3.3V，这种差异导致观察到SPI接口上的数据损坏。

6.4 带电压转换器的Aardvark

为克服数据损坏的缺点，建议使用TXS0108E电压转换器。该电压转换器可将电压在1.8V和3.3V之间转换。

图6.4. 带电压转换器的Aardvark

这是Aardvark通过4线SPI和3线GPIO接口连接到FUSA单元的框图。

6.5 作为MCU的FT2232H

由于验证团队提出了需要多个GPIO的更高需求，因此建议构建一个基于PCB的MCU卡，该卡具有SPI、UART和GPIO转USB接口，并支持Python自动化以模拟MCU。

FDTI FT2232H IC用作USB转SPI接口和USB转GPIO接口，工作在3.3V逻辑电平，由于存在电压差异，需要电压转换器。

6.5.1 组件

· MIC3490-3.3

· 2x5 pin 10 pin直插式带罩公头IDC插座（或J8H2接头）

· 2x3 6 pin接头（或J8J1接头）

· MIC3490-1.8

· TXS0108E breakout板

· FT2232H芯片

MIC3490-1.8/3.3用于为电压转换器提供参考电压，接头和连接器符合电路板规格。

6.5.2 原理图

图 6.5. MCU原理图

根据上述原理图和物料清单（BOM）制作PCB。

6.5.3 控制流程

SPI主设备始终发起消息事务，由于失效报告的用例，FUSA模块的GPIO信号线连接到SMCU，因此FUSA模块可以通知错误、非错误状态和诊断数据报告。创建Python脚本以实现以下功能，使用的库包括：

· pyfdti

· pyusb

这些库提供了读/写和访问其他硬件参数以及串行通信和GPIO设置/重置/读取的API。SPI数据写入和SPI数据读取需要两个周期的Dword刷新，命令数据包以每次一个Dword的形式传输。

控制流程如下：

· 对于关机启动或作为周期性watchdog，SMCU将启动事务

图6.6. SPI主事务

· 对于错误报告以及状态变化通知，FUSA模块将启动事务，此时MCU将轮询GPIO引脚以获取通知

图6.7. SPI从事务

07. 学习成果与结果

硅后硬件验证有助于实现高质量的设计和开发，并消除集成缺陷。在测试用例失效和功能执行错误期间，调试和调查过程有助于培养逻辑能力以及对任何给定组件进行全面设计的思维方式。

7.1 实证结果

实现测试用例和开发框架后，在子系统的各种版本上执行了大量测试。实证数据如下：

通过开发框架的测试用例，总验证覆盖率正朝着100%迈进。

7.2 基于PythonSV框架的开发成果

· 实现了30个测试用例

· 被多个团队广泛用于调试

· 为基于PythonSV-ITP的测试用例和测试套件开发提供了参考

7.3 FPGA裸机代码框架的开发成果

· 实现了40个测试用例

· 被多个团队广泛用于调试

· 为基于FPGA的PCIe到PECI客户端消息通道开发提供了参考

7.4 MCU框架的开发成果

· 可实现端到端流程的自动化

· 由于采用低成本组件，成本降低了1/50

· 框架被项目中的多个团队采用

08. 结论

本研究旨在进行硅后硬件验证。基于框架的开发和执行过程，可以得出结论：在学习过程中已广泛探索了验证方法的研究和测试构建。已深入理解产品开发生命周期。

通过分析汽车用例中按照ISO 26262标准实现的功能安全，仔细观察和学习了系统上功能安全标准的合规性以及基于FUSA的组件和子系统的开发与验证。

通过开发和实现各种框架，使用这些框架可实现50%及更多的测试用例。可以得出结论：这些框架也可用于具有相同架构的不同用例，其中使用了类似的子系统和组件。

MCU框架的开发侧重于硬件验证框架的低成本开发，以及对FDTI芯片和串行通信协议的深入研究。

本研究还建议构建通用测试套件，以组织验证过程。研究还建议，在开发中关注系统各组件的通用逻辑电平，以避免逻辑电平差异的情况（如果电源管理不是关键问题）。