验证&system verilog笔试题

Posted 2020-12-13 lizhiqing

进程与线程

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

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

 

测试点与测试用例

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

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

 

形式（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都不依赖于具体测试用例。