IC_verification基本知识点.docVIP

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）是个好东西，但是如果紧紧依靠验证工程师这个东西是没办法用好的，这个东西非常需要设计人员配合。Asse