IC_verification基础知识扫盲

Verify 工作简介
随着IC的门数越来越多。

IC的验证也越来越复杂。

IC需要的从业人员也越来越多，我简单介绍一下IC验证的情况吧，希望对想找IC验证工作的哥们有些帮助。

先说基础知识吧。

除了verilog代码和systemverilog代码，IC验证现在越来越多的用到c语言和C++了。

当然如果会点shell 与perl脚本语言那就更好了。

就verilog而言，验证从业人员真的不需要能非常牛逼的使用这个语言，但是必须要能读懂，帮助designer debug的时候你最好能定位到错误发生的位置。

Systemverilog代码是验证的核心，但是大学或者研究生期间使用该代码的院校还是很少的。

现在各家大公司用的验证环境几乎清一色的都是使用systemverilog搭建的。

其实怎么都感觉systemverilog代码是把C++和verilog代码揉到一起了。

学起来也不是很难的。

C语言和C++就不用多说了，C语言到什么地方都是有用的。

以前验证没有怎么使用太多的C语言，但是现在由于算法越来越复杂，好多东西用C语言实现起来还容易。

所以C 语言在现在的验证工作中用的越来越多了。

而且现在有不少公司都习惯用C语言来写激励了。

这样的激励比较好阅读。

更加接近与以后的开发编写环境。

至于脚本语言，那就没有什么了。

都是在完成验证环境搭建以后用的比较多。

暂时不会也不要紧，一般常用的就那么一点。

这个其实和linux比较类似，基础命令还是要会一点的。

说一下现在验证的概况吧。

现在的IC验证工作都是在一个建立好的平台上做的验证。

现在比较常见的验证平台有VMM和OVM，以前也有AVM不过现在已经合并到OVM中去了。

当然现在市场的主力军还是VMM，但是由于OVM是开源的，所以OVM发展也是很快的。

VMM是synopsys公司主导使用的，想要使用VMM就需要使用synopsys的VCS软件，呵呵这一套软件还是挺贵的啊。

OVM是由Cadence和mentor合作开发的，由于Cadence以前看好的验证语言是systemC，结果在systemverilog这一块稍微有点掉队，于是就和mentor 合作搞起了OVM以抗衡VMM。

Questa是mentor的验证软件，具体没有用过。

感觉图形界面做的不错。

下面就以我熟悉的VMM验证环境来说吧。

其实OVM也是差不多的，大的框架还是相同的。

都还是那些东西。

废话少说上图！！！
测试平台
以上就是现在比较常见的IC验证环境的基本框图了，根据具体情况不同会把一些模块合成一个，也有可能拆分成几个来实现。

但是运行的过程还是相同的。

先拿testcase来说吧，这个东西大家都比较熟悉吧，最初的testcase基本上都是用verilog代码来写的，当然现在还是有用的。

但是verilog代码写的testcase有一些不足之处，首先verilog代码不支持随机处理，不方便用来产生随机激励，其次verilog的层次比较低不适用于较高层次的建模。

Systemverilog出现很好的解决了这些问题。

而且systemverilog能够与c语言很好的连接，systemverilog有一个DPI专门用于连接外部C程序（还支持一些其他的语言）的，很好用。

为适用C语言编写testcase提供了基础，所以现在有不少testcase都是使用C语言来写的。

使用C语言写出来的testcase结构比较紧凑，比较像做嵌入式开发写底层驱动。

发生器（generator）用来解释testcase，其实也就是把testcase翻译成具体的数据包，或者数据码流。

代理这个东西就是把数据分配下去，他与记分板和检测器一起称为功能层。

记分板（scoreboard）用来临时存放一些数据，用于数据的比较。

常与检测器合在一起，共同完成数据的比较，查错。

他们要实现的一个与待测设计相同功能的模块，用于自动比较的。

其实也就是要设计一个能实现相同功能的模块，一般小的模块这部分设计都是由验证工程师自己完成的，如果是复杂的模块由于验证工程师还要关注其他的模块，这块功能可以由其他地方提供，比如一些现成的C语言代码，验证工程师把这个C代码嵌入的验证环境中就可以了，这个地方的实现方式比较多，也是验证的一个精华的地方吧。

主要的debug也就在这个地方实现的。

驱动层（driver）顾名思义，就是用来驱动我们的额待测设计（DUT（device under test，这个名字还是有必要记住的））。

就是把数据包处理成具体的操作激励，也就是那些波形了。

检测器（monitor）用来采集待测设计（DUT）的输出波形，然后传回scoreboard用于和标准结果比较，验证DUT工作是否正确。

断言（assert）是个好东西，但是如果紧紧依靠验证工程师这个东西是没办法用好的，这个东西非常需要设计人员配合。

Assert功能很强大，也很容易上手，能深层次的发掘设计错误，定位很准确，也正是由于这些优点，所以验证工程师不能非常容易的使用它，因为验证工程师一般可以不需要了解太多的设计细节就可以对设计模块进行验证，但是assert需要比较清楚的了解内部信号，才能将内部信号连接到相应的assert上。

建议IC设计工程师学习哦。

对debug很有帮助的哦。

这个模块在有的验证环境中是不使用。

最后说一下覆盖率的问题。

覆盖率分为功能覆盖率，代码覆盖率，还有人为添加的一些覆盖点的覆盖率。

这个其实就是用来衡量验证工作进行到什么程度了。

最容易实现100%的是代码覆盖率，但是如果verilog代码中使用了case的default那就很难实现100%覆盖了。

功能覆盖率就是一些函数的功能，还有状态机的状态覆盖率等等。

然后还有就是验证工程师添加的覆盖点。

一般验证工作完成以后要使用这些东西完成报告的。

这么多了可能有点晕了。

可能想为什么要搞这么复杂啊。

其实这个确实蛮复杂的，环境的搭建好花不少时间。

但是这样做最大的优点就是可以自动完成激励的生成，随机激励，而且要说明的是这里的随机一般是约束随机，而不是一般意义上的随机一般的随机没有针对性，就好比要赋值的时候知道这个设计的最大值只有255，但是你一般的随机可能产生更大的值，而约束随机可以轻松地的把随机值约束在255以内。

Systemverilog的随机还支持权重分配，可以根据验证的需要控制数据按不同的比例出现。

用这样的环境做验证还有一个好处就是可重用，换了DUT只需要更换相应的driver和monitor就可以了，如果是标准总线那么连driver都不要换了，如果输出的接口也是标准的话那就连monitor都不用换了，只要换一下生成正确数据的ref单元（一般在在scoreboard 和检测器中实现，或者在scoreboard之前实现也可以）。

在换一下对应的激励，这个时候你
甚至有一种感觉自己是在做嵌入式开发的驱动。

约束随机，可重用环境，自动比较技术可以说是现在验证工作的灵魂吧。

对了这里没有说着自动对比，现在的验证工程师一般是不看波形的。

波形一般都在检查到错误的时候用来帮助designer定位错误的。

验证工程师都是使用scoreboard或者类似的模块对结果进行自动对比，这样能大大的提高验证的速度。

其实这边也可以看出来验证工程师在将验证环境搭建好了以后会有一部分时间是在等服务器完成仿真的。

好了，差不多就这么多了吧。

能搞明白验证的框架就可以了吧。

细节的东西暂时就不用考虑了。