UVM

UVM模型

《UVM实战》主要介绍UVM的使用。全书详尽介绍了UVM的factory机制、sequence机制、phase机制、objection机制及寄存器模型等的使用。此外，本书还试图引导读者思考UVM为什么要引入这些机制，从而使读者知其然，更知其所以然。本书以一个完整的示例开篇，使得读者一开始就对如何使用UVM搭建验证平台有总体的概念。针对没有面向对象编程基础的用户，本书在附录中简要介绍了面向对象的概念及SystemVerilog中区别于其他编程语言的一些特殊语法。

UVM预先定义好一个类uvm_component，driver、monitor、model、scoreboard等都要从这个类来派生出来。通过这种形式，把driver、monitor、model、scoreboard等组织在一棵树上，这样UVM就可以方便的执行后面的操作了，这些都是树上的节点，整个UVM验证平台的各个部分就如同一棵倒置的树，如下图所示：

在上图中，出现了sequencer，它是UV吗中独有的一个概念，driver负责向DUT发送数据，那么这些数据怎么来的呢？sequencer正是用于产生这些数据的，一个sequencer通过启动一个sequence，从sequencer获取数据，并把这些数据的发送转交给driver。这种功能划分让driver不再关注数据的产生，从而只负责数据的发送，智能更加清晰，更容易使用。上图中出现的另外的组件就是In_agent和Out_agent，他们是UVM中的agent，所谓的agent其实只是简单的把driver和monitor封装起来，负责跟DUT交互的。

1. 正如这个图片所展示的，UVM是除了DUT（待验证模块）的其他所有部分。其中，sequencer产生sequence（图上没画），sequence产生transaction。transaction，类似于软件中的一个package。在硬件中，以一个transaction为单位进行传输，一个完整的transaction传输结束，才拉高或拉低电平

2. 通过UVM的专门的类型——port把数据给driver。driver通过interface把产生的激励（也就是transaction）输入DUT。同时，DUT的输出也是和interface相连接的。一个monitor（monitor after）监测driver吐给DUT的输入，一个monitor（monitor before）监测DUT吐出来的输出。

3. 这里，看到一个agent把整个monitor、sequencer、driver都装起来了。这个agent实现的功能是转换。因为整个UVM都是systemverilog的，并且理论上是仿真的，都不是“硬件”。DUT在这里是真正的“硬件”。两者之间不能直接通信，只能通过一个agent，来对协议进行转换。不过，我们可以不用管agent怎么实现的。在开发的时候，只要把相关的模块连接好就行了。

4. reference model的工作在这个例子中，实际是在monitor after里面实现的。reference model完成的工作是，把DUT做的事完全的再做一遍。reference model接入monitor采到的输入激励，按照DUT的逻辑，产生一个结果。

5. 同样通过port，把reference model产生的结果同monitor before采到的数据都丢到scoreboard上。在scoreboard上，我们会对两个结果进行比较。如果两个结果一致，则为正确。如果不一致，则为错误。