验证&system verilog笔试题

进程与线程

1、system verilog中，进程之间的同步不可以采用（Semaphore），可以采用（Event, Mailbox, Fork/join）.

解析：Semaphore是一种线程仲裁结构，不能用关于内部事件同步。

 

测试点与测试用例 & 覆盖率

1、测试用例是用来覆盖测试点的，一个用例只能覆盖一个测试点（错误）。

解析：用例和测试点不是一一对应的。一个用例可以用来覆盖多个测试点。一个测试点有时候也需要多个用例来覆盖。比如测试FIFO的两个测试点：1.空信号生成 2.满信号生成，使用一个测试用例，在复位之后发出FIFO深度相同数量的写数据，不进行读。一个用例就能同时检测到空信号和满信号覆盖两个测试点。

 2、下面关于代码覆盖率描述错误的是（AB）

A．代码覆盖率达到百分之一百说明代码bug已消除

B．代码覆盖率包括功能覆盖率

C．代码覆盖率包括条件覆盖率

D．代码覆盖率包括语句覆盖率

解析：覆盖率是衡量设计验证完成程度的指标，并不是验证的目的。任何覆盖率达到100%并不代表芯片bug已消除。代码覆盖率包括行覆盖率、条件覆盖率、状态机覆盖率和翻转覆盖率。功能覆盖率反映开发出来的需要覆盖的功能点覆盖的比例。断言覆盖率测量断言被触发的频繁程度。

 

形式（formal verification）验证

1、（形式验证）是一张系统验证手段，通过它来判断两个设计是否等价，从而判断一个设计在修改前后的功能是否保持一致。

解析：形式验证formality主要应用在：1. RTL与综合网表的比对。因为主要的测试用例都是基于RTL，RTL修改简单，迭代速度快，是一切功能的源头。保证了RTL仿真的正确性加上RTL与网表的形式验证，基本可以保证RTL测试过的测试点在网表阶段没有问题。2. 网表与网表比对：物理实现各阶段网表功能一致性（综合->时钟树->布局布线->TIMING/DRC ECO）。如果有功能ECO，保证ECO之后的网表功能与ECO之前的网表一致也是必不可少的，因为基于网表的修改风险较大，也更不可控，人为确认不够稳。

2、形式验证(formalverification)不存在验证覆盖率的问题，其目的是为了比较两个design的功能，并确认他们的功能是否100%相等。（正确）

解析：形式验证的基本流程是通过切割电路，划分出一系列的比较点。在划分出比较点之后，工具会对两个design的所有比较点进行match，有match不上的点则无法进行比较。然后进行两个design的比较。有比不过的点，则比较失败。因此如果将所有的比较点比较通过作为验证成功的标志，那么需要保证所有的比较点都能match上，并且进行了比较。Formal要求match的比例达到100%，但这里并不存在覆盖率这一说。

随机验证 & 功能验证 & 动态验证

1、为保证充分性，随机验证的输入不能带有约束条件，必须使用全随机（错误）。

解析：如果全随机，会大量消耗验证及其资源，正确的做法是通过约束条件使随机值落在验证测试点感兴趣的区域，减少无谓的机器资源消耗。

2、在异步设计中对跨时钟处理的信号，功能验证时一般需要考虑以下哪些因素（信号高电平有效还是低电平有效、信号变化的最小宽度、时钟频率），不需要考虑的是（相位和抖动）。

解析：功能验证关注会影响功能并且不需要借助门级延迟等信息就可以判断对错的点。高低电平肯定是可以检测的。信号变化的最小宽度，在低频采高频的场景下功能仿真可以仿出漏采现象。时钟频率也是功能验证需要关注并且可以控制的，不同时钟频率的跨时钟域是否有频率不同导致的功能与预期不一致，这些是可以测到的。

3、下面属于动态验证范畴的是（modelsim仿真、后仿），不属于的是（形式验证、STA）。

解析：所谓动态验证即验证结果依赖于向量输入，动态改变。形式验证和STA都不依赖于具体测试用例。

 DFT

1、以下哪些活动属于DFT的内容（Boundary SCAN，MBIST，DC SCAN，AC SCAN ）。

 

verlog，system verilog & UVM

1、以下关于Venlog的描述，正确的是（无）

A.SystemVerilog是提供给验证使用的，因此其不能被综合。（可被综合）

B.SystemVerilog中可以用logic代替Verilog中的wire和reg信号类型。（在部分条件下可以代替）

C.Verilog语言中的function语言不可被综合。（可以综合）

D.在Verilog中，定义成reg的信号会被综合成触发器。（在组合逻辑中不被综合为触发器）

E.Verilog中，如果case的条件不写完整，将会导致综合时出现锁存器（Latch）。（在时序逻辑中不综合成锁存器）

 

2、一下关于验证的描述，正确的是（B）

A．验证平台使用checker检测DUT的行为，只有知道DUT的输入输出信号变化之后，才能根据这些信号变化来判定DUT的行为是否正确

B．SystemVerilog区别于verilog的一个重要特征是其具有面向对象语言的特性：封装、继承和多态

C．UVM是Synopsys、Cadence、Mentor等EDA厂商联合发布的验证平台

D．Verilog，SystemVerilog，SystemC,，UVM都是验证常用的硬件语言

解析：

选项A：验证平台中实现监测DUT行为的组件是monitor。Checker是根据DUT的输出来判断DUT的行为是否与预期相符合，比对数据来源于RM（reference model）和o_agent的monitor。

选项C：VMM由Synopsys于2006年推出，OVM由Cadence和Mentor于2008年推出，UVM（Universal VerificationMethodology）由Accellera推出于2011年推出，得到Synopsys、Cadence、Mentor的支持。

选项D：UVM不是语言，是一个以SystemVerilog类库为主体的验证平台开发框架

 UVM代码题

1、下面是两种情况下的UVM代码： 

第一种情况：

task my_case0::main_phase(uvm_phase phase);
  for(int i = 0; i < 10; i++) begin
     #10;
     `uvm_info("case0", "phase is executed", UVM_LOW)
   end
endtask 

task my_case0::run_phase(uvm_phase phase);
  phase.raise_objection(this);
   #100;
  phase.drop_objection(this);
endtask


第二种情况：
task my_case0::main_phase(uvm_phase phase);
  phase.raise_objection(this);
   #100;
  phase.drop_objection(this);
endtask

task my_case0::run_phase(uvm_phase phase);
  for(int i = 0; i < 10; i++) begin
     #10;
     `uvm_info("case0", "phase is executed", UVM_LOW)
   end
endtask

请问上述两段代码"phase is executed"分别输出了几次？
第一种情况打印信息输出0次，第二种情况打印信息输出10次

解析：

UVM中通过objection机制来控制验证平台的关闭。在进入到某一phase的时候，UVM会收集此phase提起的所有的objection（raise_objection），并且实时监测所有的objection是否已经撤销了（drop_objection），当发现所有的objection都已经撤销后，那么就会关闭此phase，开始进入下一个phase。当所有的phase都执行完毕后，就会调用$finish来把整个的验证平台关掉。如果UVM发现此phase没有提出任何objection，那么将会直接跳转到下一个phase中。

在drop_objection语句之前必须先调用raise_objection语句，raise_objection和drop_objection总是成对出现。rasie_objection语句必须在phase中第一个消耗仿真时间的语句之前。

对于run_phase，与其他动态运行的phase是并行运行的，如果12个动态运行的phase有objection被提起，那么run_phase则不需要raise_objection就可以自动运行。

第一种情况中main_phase没有提起任何objection，不理会操作，直接跳到post_main_phase,时刻还是为0。因此"phaseis executed"输出0次

第二种情况中main_phase提起延时100ns的objection，run_phase则开始并行运行其for循环操作，因此"phase is executed"输出10次