RISC 处理器功能安全验证平台设计(了解Z01X工具的使用)

1. 功能安全验证平台结构

图示为功能安全验证平台结构,包括观测点设置、选取恰当的激励模式、 故障状态设置、故障位置设置、故障仿真变量设置、覆盖率定义等模块。

2. 具体设计

文中[1]是给RISC 处理器的Main CPU 模块进行注错。接下来是功能安全验证平台各个模块的具体的设计

2.1 设置观测点

一般情况下是将待测设计顶层的所有输出端
口或者待测设计的顶层某些代表处理器内部出现错误的信号设置为观测点。
观察点位置一般设置在待测设计层级结构的内部,检测点位置一般设置在待测设计顶层。

2.1.1 设置方法

  • 第一种方法:$fs_strobe()系统函数
    Z01X 提供了$fs_strobe()系统函数在验证平台中设置观测点,将要观测的文件
    或者信号写入$fs_strobe()系统函数中。一般情况下是将①待测设计顶层的所有输出端
    口或者②待测设计的顶层某些代表处理器内部出现错误的信号设置为观测点,这两种情
    况分别为:$fs_strobe(design_top)和$fs_strobe(design_top.a,design_top.b,design_top.c,
    design_top.d,design_top.e)。
    理论上,将待测设计顶层的所有输出端口设置为观测点时,可以检测到更多的故障即最终的覆盖率分数更高;但是如果将待测设计顶层某些代表处理器内
    部出现错误的信号设置为观测点时,会节约资源。
    在设置的观测点上,Z01X 判断故障是否传播到观测点进
    而判断故障的状态。故障的状态由两个字符表示,两个字符没有各自
    的含义,它们共同表示故障的状态,比如DD 表示该故障已经传播到设置的观测点即该故障已被待测设计的安全机制检测到。
  • 第二种方法:系统任务组合
    此外,Z01X 也提供了很多的系统任务组合使用来设置观测点,该方法中两个字符有各自的含义,第一个字符表示观察点观察到故障的状态,判断故障是否传播到验证平台设置的观察点的位置,比如design_top.module_a.single_a;第二个字符表
    示检测点检测到故障的状态,判断故障是否传播到验证平台设置的检测点的位置,例如design_top.a。在第二种方法中,对于故障的状态,
    观察点的故障状态:N(Not Detected)、P(Potentially Detected)、D(Detected)
    检测点的故障状态: N(Not Detected)、P
    (Potentially Detected)、D(Detected)

    观察点和监测点的状态组合表示故障的状态:则一个故障的状态有如下9 种可能,即NN、NP、ND、PN、PP、PD、DN、DP、DD。例如DD 表示此故障在观察点被观察到了,在检测点也被检测到了,所以状态设置为DD。

    2.1.2 系统函数

  • $fs_compare():比较列出的信号的GM 和FM 值,如果值相同返回0,如果值不同返回1;
  • $fs_drop_status():将指定状态分配给故障并将
    其从故障仿真中删除;
  • $fs_set_status():将状态分配给故障并继续模拟故障;
  • $fs_default_status():为 $fs_drop_status()或 $fs_set_status():没有设置状态的所有故
    障分配一个状态;
  • $fs_get_status():使模拟器获得故障的当前状态。

    2.2 产生激励

    2.2.1 vcd 和evcd

    Z01X 运行逻辑仿真和故障仿真时支持vcd 和evcd 格式的激励。
    evcd 是扩展的vcd 激励模式,属于一种波形文件的激励模式。

    2.2.2 Verilog Testbench

    Verilog Testbench 是逻辑仿真和故障仿真支持的激励格式。当使用Testbench 作为
    激励时,提供给 DUT 的数据和产生的期望激励值由 Verilog Testbench 控制。在使用
    Verilog Testbench 作为验证平台时,需要为每个新测试重新编译设计,这就需要为每
    个测试用例搭建各自的验证平台,工作量繁冗,限制了故障仿真的进程。

2.3 注入故障类型设置

2.3.1 故障类型

常见的故障有永久故障(stuck at)、瞬态故障(transient)。Z01X 工具可以模拟注入以下两种故障类型:永久故障(stuck at 0 或stuck at 1)和瞬态故障。

永久故障

最常见的故障模型是永久故障(“stuck at 0”和“stuck at 1”),在故障仿真过程中,永久故障模型会将门的输入或输出永久地保持为零或一的状态。使用Z0IX 故障生成工具可以创建单个故障,Z01X 通过标准故障格式提供了多点固定建模。有六种可以建模的永久故障:

  • 输入类型故障,使 Verilog 代码的输入信号永久地固定在一个水平上(0 或1);
  • 输出类型故障,使Verilog 代码的输出信号永久地固定在一个水平上(0 或1);
  • 网络类型故障,使Verilog 代码的网络信号永久地固定在一 个水平上(0 或1);
  • 连续赋值类型故障,仅在连续赋值语句的输出上设置这种使信号永久地固定为0 或1 的故障;
  • 变量类型故障,将错误放置在reg、logic、bit 和byte 类型的变量上,仅在过程语句中使用的变量不会自动启用以生成故障(要启用这些变量,必须在编译期间添加+fault+var 选项);
  • 列表类型故障,将故障放置在reg、logic、bit
    和byte 数组类型的位上。

stuck at 故障类型常见的故障位置如下,常见的位置有输入端口、输出端口和网络连接位置

瞬态故障

另外一种常见的故障模型是瞬态故障,瞬态故障是突然发生然后消失的故
障,它们可能会随机出现,并且不会导致永久性硬件损坏。瞬态故障模型包括三种故障类型:
①瞬态切换,用于功能安全和安保应用程序,通
过反转故障位置的GM 值,在指定的循环时间使故障位置信号位翻转;
②瞬态一,用于安全应用程序,在指定的时间段内将故障设置为一;
③瞬态零,用于安全应用程序,在指定的时间段内将故障设置为零。

2.3.2 故障状态设置

2.3.3 常见故障状态

DD(Dropped Detected),指示故障已被检测到指定的最大次数,故障状态被设置
为DD,并将此故障从故障仿真中丢弃,不再进行故障仿真。
PD(Dropped Potential),指示故障已到达可能检测到的指定的最大次数。一般情
况下,若一个故障为PD 状态,则认为该故障已被检测到,对于此故障具体的处理应
该遵从故障覆盖率的定义。
ND(Not Detected),表明在某个具体的时刻,在设置的观察点上,GM 与FM 的
行为没有什么不同。如果当GM 的值未知且已知FM 的值时,也将该故障标记为ND
状态。故障管理器会选择状态为ND 的故障进行故障仿真,如果在故障仿真结束后未
将故障设置为DD、PD 等代表已经被检测到的状态时,此故障状态将保留为ND。
NO(Not Observed),表示无法观察到故障,因为工作负载阻止了该故障位置的
变化传播到观察点。
NC(Not Controlled),表示无法控制的故障,由故障管理器选择的不可控制的故
障将被分类为NC。当信号(注入故障)在仿真期间从未触发并且在整个仿真中保持
0 或 1 时,会产生此类故障,生成此类故障需要运行启用了可测试性的故障管理器。
此外,工具定义了不同的状态组,某些含义相近的状态可以归为 一个状态组,例如检测状态组(Detected Group)包括DT(Detected)、DD(Dropped
Detected)、DE(Detected Error)、DF(Detected $finish/$stop)等状态。通过使用内置的状态组,可以引用属于该组的所有故障状态。

3. 故障仿真变量设置

对故障仿真过程的相关变量进行设置,比如添加激励、设置每个故障的最大仿真次数、设置故障仿真并行数量等。这些参数的设置可以更好地控制故障仿真过程,并且能产生更多利于验证人员调试的信息。

3.1 相关变量的设置

故障管理器通过可执行的paper.fmsh
文件运行,paper.fmsh 文件是Z01X 工具做功能安全验证故障仿真时的一个必备的脚
本,提供批处理和命令行接口以及Linux 环境和故障管理器的交互。使用paper.fmsh
的语法为:`$Z01XHOME/bin/fmsh -load
在 paper.fmsh 脚本文件中,有两种可用的基本操作类型:
一种是运行一个命令, 该命令根据语法直接执行;
另一种是设置一个变量,这个变量将确定Z01X 故障仿真时的环境参数。
示例如下:

3.2 覆盖率定义

一般情况下,覆盖率部分收集两种覆盖率:
①故障覆盖率:故障覆盖率等于检测到的故障数占总的故障数的比重;
②测试覆盖率:测试覆盖率等于检测到的故障数占总的故障减去不可测的故障的比重。

默认的覆盖率公式为:`Test coverage=(DD+DT)/(all_faults-UG)100%;Fault coverage=(DD+DT)/all_faults 100%
其中,DD 表示Dropped Detected,即已被检测到最大次数的故障的数量;DT 表示已被检测到至少一次但是没有到达最大次数的故障的数量;UG 表示不可测的故障数量.

4.功能安全验证故障仿真和结果分析

4.1 功能安全验证流程

功能安全验证流程为设计功能安全验证平台、编译、逻辑仿真、故障仿真、对比分析故障仿真结果、基于ISO26262 标准检测有安全机制保护的RISC 处理器的安全性。

4.2 故障仿真结果

reference:
[1]秦笑. 基于ISO26262的RISC处理器功能性安全验证[D].西安电子科技大学,2020.

来自广东
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇