一些数字设计及验证的笔试题汇总,仅供参考。
目录
2、描述soc/ip验证之间的区别,以及验证二者之间的侧重点
3、描述从芯片spec到tapeout的整个过程,重点介绍哪些步骤需要验证,以及所需的文件和验证重点
6、请描述一下code coverage和function coverage的区别,为什么需要这些coverage?
8、在验证中,一种常用的方法是将输入激励同时给参考模型及被测试设计,然后比较他们的响应以确定设计是否符合预期,请问在比较其响应时需要注意什么?
9、请画图来显示一个常见的验证环境的结构,并对结构中的每个组成部分进行简短描述
1、介绍一下常用的EDA验证工具和debug工具
Synopsys、Cadence、Mentor Graphics是EDA工具软件厂商全球三大巨头,分别采用前缀S-(Synopsys),C-(Cadence)和M-(Mentor)来表示。
动态验证方法依赖于仿真器(Simulator),包括S-VCS,C-Incisive & Xcelium,M-Questasim。
硬件加速模拟器(emulator),包括S-Zebu,C-Palladium,M-Veloce。
形式验证工具(formal),包括S-VC Formal,C-Jasper,M-Questa Formal。
仿真调试工具(debug),包括S-Verdi,C-SimVision,M-Questa Visualizer Debug。
2、描述SOC / IP验证之间的区别,以及验证二者之间的侧重点
SOC和IP从独立性来看,前者较后者更为独立,往往具备更加完整的功能。SOC会由多个IP、子系统和其它系统模块构成,从层次来看,IP是构成SOC的重要组成部分。在验证SOC时,首先需要确保其IP级别都完成了验证,而在系统级别需要验证各个模块之间的交互和协调情况、集成连线情况,测试用例会更加真实,当然,仿真速度也下降很快,一般需要做门级仿真。在IP级验证时,如果是内部IP,那么需要就接下来的运用场景(配置情况),展开重点性的验证,如果是向外部提供的IP,那么需要针对其参数配置展开更为全面细致的验证工作,所以其特点不但是要求验证每一项功能,而且是每一项功能在不同配置下的行为是否是正确的。
3、描述从芯片spec到tapeout的整个过程,重点介绍哪些步骤需要验证,以及所需的文件和验证重点
(1)从spec到模块级RTL时,除了RTL文件,还需要寄存器文件来生成寄存器模型,构建UVM验证环境,主要验证每一项RTL功能。
(2)从模块到子系统时,除了之前的文件,如果在子系统级别需要模拟电源域开关,那么还需要UPF,如果子系统单独综合且较为独立,可能还需要做门级仿真,那么需要综合网表和SDF文件,验证的重点将是子系统的各项完整功能。
(3)在系统级别时,除了系统级的RTL仿真,也需要进行UPF仿真和门级仿真,因此也需要对应的UPF文件、网表和SDF文件,验证的重点是各个子系统之间的交互和协调情况、集成连线情况。
4、下列关于代码覆盖率描述错误的是
A. 代码覆盖率包括语句覆盖率
B. 代码覆盖率包括条件覆盖率
C. 代码覆盖率包括功能覆盖率
D. 代码覆盖率到达百分百说明代码bug已消除
答案:CD
代码覆盖率和功能覆盖率是独立的两种覆盖率,代码覆盖率100%只能表明代码经过了充分的执行,但是代码中是否有bug以及bug是否会被发现,取决于验证环境中的监测点是否监测了关键信号以及对这些信号的判断是否正确。
5、以下断言在哪个时钟沿开始的时序可以判决成功
property test_seq_2;
@(posedge clk) $rose(start) |->
##3 ((a##2 b)[*2]) ##2 stop;
endproperty
assert property(test_seq_2);
将在第21个时钟沿判决成功。
属性test_seq_2表示的是,在start拉高后的第2拍(用的是|->3),要求 “a为高且再2拍后b为高” 的序列重复两次,即(a##2b)[*2]可以等同于(a##2b ##1 a##2b),在最后一次b为高的2拍后,stop应该为高。这个属性的判决将在从11拍被激发,而在21拍(而不是20拍)在采样到stop为1时,判决成功。
6、请描述一下code coverage和function coverage的区别,为什么需要这些coverage?
因为没有任何一种单一的覆盖率可以完备地去衡量验证过程。
即使我们可以达到100%的代码覆盖率,但这并不意味着100%的功能覆盖率。原因在于代码覆盖率并不是用来衡量设计内部的功能运转,或者模块之间的互动,或者功能时序的触发等。代码覆盖率可以通过仿真器完成自动收集。
类似地,我们即便达到了100%功能覆盖率,也可能只达到了90%的代码覆盖率。原因可能在于我们疏漏了去测试某些功能,或者一些实现的功能并没有被描述。功能覆盖率需要通过人为定义,与拆分的待测功能点做一一映射。
从上述关于代码覆盖率和功能覆盖率简单的论述就可以证明,如果想要得到全面的验证精度,我们就需要多个覆盖率种类的指标。
7、以下关于验证的描述,正确的是
A. SystemVerilog区别于verilog的一个重要特性是其具有所有面向对象语言的特性:封装继承和多态
B. UVM是synopsys, cadence, mentor等EDA厂商联合发布的验证平台
C. 验证平台使用checker监测DUT行为,只有知道DUT的输入输出信号变化之后,才能根据这些信号变化来判断DUT的行为是否正确
D. SystemVerilog,Verilog,systemC,uvm都是验证常用的硬件语言
答案:AB
选项C中,监测DUT行为的组件是monitor;选项D中的UVM并不是一种语言,而是基于SystemVerilog之上的验证方法学。选项B,UVM是Accellera推出的验证平台标准,不过背后的推动实际上仍然是基于三家EDA巨头厂商的统一意见。
8、在验证中,一种常用的方法是将输入激励同时给参考模型及被测试设计,然后比较他们的响应以确定设计是否符合预期,请问在比较其响应时需要注意什么?
如果参考模型是非时序的,则主要比较数据内容。如果参考模型有时序模拟,那么还应该比较实际输出数据和期望输出数据在时序上的差异。
对于一些数据可能经过重组,而无法通过单一参考模型来比较的情况,除了在比较数据完整性方面需要考虑,还需要针对数据重组、打包、排序等设计功能设置独立的检查机制,确保所有设计功能都得到监测和检查。
对于比较数据时的调试需要注意,无论比较成功还是失败,都应该打印必要的比较信息,便于调试。打印的信息中,应该有消息源、数据比较信息、失败信息可能原因等。如果比较失败,一般需要停止仿真,便于在比较失败现场进行调试。
9、请画图来显示一个常见的验证环境的结构,并对结构中的每个组成部分进行简短描述
测试平台(testbench)是整个验证系统的总称。它包括验证结构中的各个组件、组件之间的连接关系、测试平台的配置和控制。从更系统的意义来讲,它还包括编译仿真的流程、结果分析报告和覆盖率检查等。
测试平台的各个组件之间是相互独立的。验证组件与设计之间需要连接,而验证组件之间也需要进行通信。验证环境也需要时钟和复位信号的驱动。
Stimulator(激励发生器)是验证环境的重要部件,在一些场合中,它也被称为driver(驱动器)、BFM(bus function model,总线功能模型),或者generator(发生器)。Stimulator的主要职责是模拟与DUT相邻设计的接口协议,只需要关注于如何模拟接口信号,使其能够以真实的接口协议来发送激励给DUT。
Monitor(监测器)的主要功能是用来观察DUT的边界或者内部信号,并且经过打包整理传送给其它验证平台的组件,例如checker(比较器)。从监测信号的层次来划分monitor的功能,它们可以分为观察DUT边界信号和观察DUT内部信号。
Checker / Scoreboard(比较器)都应当是最需要时间投入的验证组件了,它肩负了模拟设计行为和功能检查的任务。Checker一般会缓存从各个monitor收集到的数据,也可能会将DUT输入接口侧的数据汇集给内置的reference model(参考模型)。
10、通用验证过程中,需要执行的关键步骤?
(1)阅读功能描述文档
(2)准备验证计划
(3)提取验证功能点
(4)绘制验证结构
(5)实现验证环境
(6)构建测试用例
(7)定义功能覆盖率
(8)发现缺陷和验证设计修复
(9)回归测试
(10)收集覆盖率
(11)分析覆盖率、修改或添加测试用例
(12)最终全面通过回归测试和完成100%覆盖率要求(某些特殊情况覆盖率不要求达到100%,需要看具体要求)
11、什么是断言?断言在验证中的作用是什么?请阐述断言的分类及各自的含义
断言是设计的属性的描述。如果一个在仿真中被检查的属性不像我们期望的那样表现,那么这个断言将失败。如果一个被禁止在设计中出现的属性在仿真过程中发生,那么这个断言也将失败。一系列的属性可以从设计的功能描述中推知,并且被转换成为断言。这些断言可以在功能仿真中不断地被监视。
断言可以分为即时断言和并发断言。即时断言是基于仿真事件的语义,它的表达式的求值就像在过程块中其它表达式一样。即时断言本质不是时序相关的,而是立即被求值。并发断言是基于时钟周期,它是基于时钟周期的,它会在时钟边缘根据调用的变量采样值计算测试表达式。
12、在验证工作中,对于激励或者配置的随机化,在进行随机过程中需要注意哪些方面?
(1)如果激励或者配置已经有约束,那么在随机化时可能会添加外部约束(内嵌约束 with{ }),那么应该保证外部约束和类原有约束不发生冲突从而使得导致随机化失败。
(2)对于一些随机化失败的场景,应该从仿真日志中获得调试信息,理解哪些约束发生了冲突。
(3)无论是激励还是配置,都应该与测试功能点有关,应当避免与测试目的无关的、相违背的随机数据产生。
(4)在同一个仿真、或者不同的仿真中,都可以变化随机约束,使得之前的覆盖率可以影响并驱动新的随机数据,继而不断提高覆盖率。
(5)配置的随机化应该只在build_phase中完成,避免仿真过程中对配置做二次随机,从而发生不可预期的情况。