数字IC验证入门与总结（一）

前言

时代的一粒灰，落在个人头上，就是一座山。

1、UVM主要框架及基本组成

  UVM实战-白皮书对于新手入门芯片验证真的是非常的友好，因此感谢前人的付出与努力。
  UVM（Universal Verification Methodology），通用验证方法学，一种基于System Verilog的验证方法学。 首先对于一个验证平台DUT(Design Under Test)，我们主要的任务就是需要验证基于不同的激励DUT输出的是否满足设计需求。在FPGA设计的时候，根据功能肯定需要设计一个子模块，设计完成后我们需要设计一个testbench去进行功能仿真，从而验证这个module的功能是否正常。同样在在进行芯片的DUT验证时我们也需要这样一个testbench去产生激励，那就是driver。
  当然给了激励信号后如何判断是否正确呢？这个时候就是去观测DUT的输出结果，接收子模块的输出叫做monitor。接收到输出之后就需要去判断DUT的输出结果是否符合预期，那么就需要一个标准的模块去提供参考输出，这个模块就是reference model。得到DUT的输出和参考模型的输出就需要对比两个模块的输出是否一致，这样一个叫做得分板（scoreboard）的就被需要了。最终，我们将driver、monitor、reference model、scoreboard封装在一个环境env（environment）中。这样一个简单的验证环境就被搭建起来。环境框图如图1所示：

图1 UVM 验证环境

2、Driver模块

  在整个验证的环境中，driver可以比作为手枪，那么DUT可以比作为目标。信号的产生、驱动协议也在driver中实现。因此把driver拆分为sequence、sequencer、driver。Sequence被称为弹夹用于实现信号的产生。Sequencer被称为弹簧用于信号的传递。
Driver 就是手枪，用于发射信号。所有的东西都有了之后，还差一个核心的东西那就是子弹，子弹由一个名叫Seqence_item的类去完成。那么这四个部分完成了DUT激励的驱动时序以及驱动。
  同时，driver 模块也需要去监视是否发送成功，因此添加了monitor模块。将equence、sequencer、driver、monitor封装在一起由此引入了agent的概念。

图2 agent模块

  Driver的组成是一个类，其派生自UVM中的类— uvm_driver 。uvm_driver又来自于类uvm_component。任何类都会有一个new函数，同时也需要一个super.new去继承父类的new。