跳至主要內容

A2-功能向量时序电路故障模拟

iEDA大约 9 分钟

1. 问题背景

故障模拟(fault simulation)是芯片测试的重要步骤,是测试向量生成系统(ATPG)和故障诊断的重要组成部分,主要用于模拟故障电路的行为,评估测试向量对电路内部可能存在的故障的检测能力。简单来说,故障模拟就是通过比较无故障电路和故障电路在特定测试向量下的逻辑仿真结果,来确定被测故障能否被检测到。

芯片在制造过程中,不可避免地会受到各种不可控因素的影响,导致制造出来的芯片存在各种缺陷。对于存在于芯片内部的缺陷,为了能够采用故障模拟等自动化方式检测缺陷,以及能够量化对缺陷的检测质量,通常会将缺陷抽象为各种故障模型,如固定型故障(stuck-at fault)、跳变延时故障(transition delay fault)、路径延时故障(path delay fault)等。其中,最为常用的故障模型是固定型故障。如图1所示,假设该与门的输入节点b存在stuck-at-1(缩写为SA1)故障,当我们同时对节点a、b施加激励(a=1,b=0)时,节点c的预期输出为“0”,但由于该故障的存在,节点c实际输出为“1”,也就代表着节点b处的SA1故障被测试向量(a=1,b=0)检测到了,这也就是故障模拟的一个简单流程。

功能向量属于测试向量的一种,它是在电路的功能运行条件下生成的一种向量,用于测试电路的内部状态,并检测电路可能存在的制造缺陷。与结构测试向量(也称扫描向量)不同的是,功能向量本质上是时序向量,在时间轴的不同时钟周期上有不同的向量输入值,且电路内部节点的逻辑状态依赖于前面时钟周期输入的仿真结果。这也就意味着,对于功能向量的故障模拟来说,无法采用常用于结构测试向量模拟的位并行方法。同时,功能向量可能涵盖数万甚至上百万个时钟周期的电路运行过程,这也导致了针对功能向量的故障模拟十分耗时。

本问题针对门级时序电路的单固定型故障,使用功能向量进行故障模拟,要求参赛队伍能够选取合适的算法,并尽可能采用并行模拟等性能优化方法,提供高性能的功能安全性评估。图2给出了功能向量的门级故障模拟简单流程示意图。

2. 问题描述

2.1 描述

本问题需要参赛队伍结合对功能向量和故障模拟的理解,设计一个C++程序,该程序应能读取问题方提供的门级网表、ATPG library、故障列表和功能向量等文件,并通过对文件进行正确的解析和处理,完成对功能向量的故障模拟。程序输出为检测到的故障列表和未检测到的故障列表。

其中,参赛队伍需要完成以下几点:

(1)正确读入网表文件,并结合ATPG
library的信息,将标准单元网表转化为适合进行仿真的网表结构。

(2)正确读入故障列表文件,结合故障列表的信息,在网表中正确的位置插入对应的故障。

(3)正确读入功能向量文件,获取对应输入节点的激励,和输出节点的预期响应。

(4)进行无故障电路的逻辑模拟,获取电路内部节点在对应时钟节点的无故障仿真值。

(5)进行故障模拟,在对应时钟节点测量电路输出节点的实际响应,根据预期响应和实际响应的对比结果,确定故障是否能被当前的功能向量所检测到。

(6)根据故障模拟的结果,分别输出检测到的故障列表和未检测到的故障列表。

本问题允许参赛队伍结合算法的具体需求,使用多线程进行并行加速。考虑到参赛队伍的开发硬件环境不一致,为了公平起见,本问题限制最大使用的线程数量为4。

2.2 问题Case

问题共建方为参赛队伍提供问题Case用于验证和优化设计的程序,下面是对所提供的文件的简单实例。

(1)Verilog平面化网表

平面化的网表由一个module构成,定义了电路的输入节点、输出节点和实例化的标准单元等信息。问题共建方为参赛队伍提供了已开源的Verilog网表parser,供参赛队伍参考使用,同时也允许参赛队伍使用自己开发的parser。

图3给了一个例子。

(2)ATPG library

本问题提供的ATPG library采用JSON(JavaScript Object Notation)格式。JSON是一种简单的数据交换格式,已被证明很有用并足够简单。举例来说,通过如下的方式来表示一个AOI单元,其他单元也是采用相同的结构来表示。

图4给出了ATPG library的JSON描述示例,每个标准单元包含3个属性:name,signals和sim_primitives。

name:数组形式,包含多个相同逻辑功能但驱动能力不同的单元名;
signals:包含三种类型的信号,input,output和wire;
sim_primitives:一个或多个自定义单元,每个自定义单元包括两个属性,sim_type和connection,分别表示单元的类型和连接关系,在connection中第一个信号是输出,其余是输入。

(3)故障列表

故障列表的格式十分简单,仅包含了故障类型(sa0或sa1)、故障检测状态(NP、DT、ND或--,其中NP表示not analyzed,DT表示detected,ND表示not detected,--表示当前故障与上述故障为等价故障。在输入故障列表中,所有故障均为NP状态)和故障位置(标准单元的实例化名字和对应引脚名字)。

图5给出了一个简单实例,其中包含三个故障,分别位于实例化的标准单元g84的Y引脚和A引脚,以及电路输入节点blif_reset_net,且这三个故障为等价故障。

(4)功能向量

本问题的功能向量采用VCD(Value
Change Dump)文件格式进行表示,VCD文件是标准波形文件,在数字电路模拟中用来记录指定电路节点信号值变化,记录了整个仿真的信息。需要说明的是,对于功能向量的故障模拟,如果测量信号仿真值的时钟节点不同,有可能会导致检测到的故障不同。 为了保证结果的一致性,要求参赛队伍统一按照以下方式检测故障: 在有电路输入节点的仿真值发生变化的时候,测量对比一次电路输出节点的仿真值,并以该对比结果判断故障是否被检测到。

如图6的例子是一个VCD文件的节选,需要分别在5ns、10ns、15ns处测量电路输出节点的仿真值并作对比。VCD文件的格式说明请直接参考其标准定义文件。

2.3 输出文件

本问题要求参赛队伍的程序在完成故障模拟之后输出两份文件,一份存储检测到的故障列表,另一份存储未检出到的故障列表。输出文件的格式应与问题共建方提供的问题Case中故障列表的格式保持一致。

2.4 环境

建议参赛队伍的开发环境和运行环境,C++使用兼容C++20版本,并在Linux系统环境下进行开发。下述给出参考的软件环境。

• gcc 10.3.0

• g++ 10.3.0

• cmake 3.13.4

3. 评分标准

问题共建方为本问题准备了测试案例,将从测试案例中筛选并提供一部分案例给参赛队伍评估算法的质量;其余案例只作评分用途,不开放给参赛队伍。

测试评分:每个测试案例独立评分,遵循同样的评分标准。

(1)本问题的故障检测结果以商用EDA工具的结果为golden结果,如果参赛队伍输出的结果与golden结果存在差异,则认为存在差异的故障检测失败。每出现一个存在差异的故障(等价故障按一个故障计算),则在计分基础上加0.01分。当存在差异的故障数量超过100个或超过总故障列表的1%时,则认为参赛队伍对当前案例的故障模拟失败,那么在该案例的评分为n(n为参赛队伍的数量)。

(2)案例通过条件(1)的情况下,假设参赛队伍有n支,则按程序总运行时间进行排序,第1名计1分,第2名计2分,以此类推,最后一名计n分。另外,对于单个测试案例的运行时间设置2小时的上限,超过2小时则结束程序的运行,并认为参赛队伍对当前案例的故障模拟失败,且在该案例的评分为n。

(3)案例通过条件(1)的情况下,如果存在运行时间相同的情况,则按分数相同,名次递增的规则评分。例如有2支队伍的运行时间相同且都是最快完成故障模拟的,则这2支队伍在评分上都是计1分,第3个队伍计3分。

对评分案例集中的每个案例进行评分后,总得分为单个案例得分的加权求和,其中单个案例的权重系数与该案例的规模成正相关。总计分越低的队伍,排名越高。

其他评分:设计文档质量,开源代码规范性等。