探讨一下在UVM中典型的验证平台

验证平台顾名思义就是为了验证而存在的。普通意义上来说，如果是IP验证，当验证人员拿到设计的某模块的RTL代码（DUT，Design Under Test），设计文档之后，就会根据文档，基于自己的理解去着手写验证计划，提取功能点，准备搭建验证平台（其实大多数情况下，是迭代上一代的验证平台），开始写验证的case（成熟的公司也很可能是继承上一代的验证case，进行改动或者增加）。所以，验证平台可以看做是一个“测试机器”，专门是为了测试RTL代码以及功能的正确性，找出其中“躲藏”的bug，千里之堤溃于蚁穴，芯片的流片失败，可能只是其中的一个小小bug。

形象一点来说，RTL代码你可以想象成一根弯弯绕绕的水管，现在的情况是，你不知道这根水管通不通，能不能顺利的把水从这头送到那头。那怎么办，找另一根有水的管子，和这根管子接上，再观察这根管子的出口有没有水出来即可。同样的道理，验证平台就相当于一根有水的管子，把它和DUT的输入端口（input）连起来就可以了，这个“水”就相当于激励。

为了找出bug，我们就需要这样一个测试平台，能够发送激励，也就是数据（data），对代码进行检验，为什么要叫做激励，我想，可能是想激励DUT努力工作吧。这里就涉及到激励发生器。比如说，我们要验证一个加法器。加法器都知道，它的功能就是实现a+b=c，这样的运算。激励发生器负责产生a和b的值，DUT负责运算出c的值，验证平台通过对照c的值来判定DUT的代码是否正确。

上面这段描述，就涉及UVM里面几个重要的知识点：

· Driver，负责产生，发送激励（后面会将产生和发送分开）；

· Scoreboard就像是一个质检员，负责把样品和合格品进行对比；

· monitor负责进行数据收集、以及发送给scoreboard；

· 正确与否我们需要一个参照，这个就是所谓的reference model。

这四个部分就可以组成UVM中简单的验证平台，如图所示：

但是有一天，driver说我不干了，我干的事情太多了。所以，就要把driver的功能进行拆分，俗话说，术业有专攻嘛，driver就负责发送激励，而不再产生激励。把功能拆分之后，另一个好处就是，复用程度更高。针对不同的case，往往只是激励的不同，拆分之后，我们不再需要每次都改变driver。如此一来，这么一拆分，就有了UVM中，经典的验证平台，如下图所示。

有的同学可能会说，怎么没有sequence？请记住，sequence不属于验证平台的任何一个部分。在这个经典的验证平台中，其实是没有产生激励的部分了。这就相当于，你给DUT这根管子接了一根没水的新管子，你需要在这根新管子上再接一根有水的管子。这样的好处是什么呢，还是复用。这样，你的验证平台就不需要怎么改动了，只要每次去切换那根有水的管子，也就是sequence。在实际的工作当中，针对一个项目，会有很多很多的sequence，但是验证平台的组件，基本上对于一个项目来说，是不动的。