UVM实战

第一章：与UVM的第一次接触

UVM是什么

验证在现代IC流程中的位置

设计说明完成后，设计人员使用Verilog把特性列表转换成RTL代码，验证人员使用验证语言（SystemVerilog为例）搭建验证平台，并且建造测试用例。当RTL代码完成后，验证人员验证这些代码（通常被称为DUT（Design Under Test））。

验证主要保证从特性列表到RTL转变的正确性，包括但不限于以下几点：

- DUT行为表现是否与特性列表中的一致
- DUT是否实现了所有特性列表中列出的特性
- DUT对于异常状况的反应是否与特性列表和设计规格说明书中的一致，如中断是否置起。
- DUT是否足够稳健，能够从异常状态

验证的语言

验证使用的语言各式各样，主要有两种通用的设计语言：Verilog和VHDL。随着IC的发展，Verilog占据了主流地位。基于Verilog的验证语言主要有以下三种。

1）Verilog：Verilog是针对设计的语言，其中包括一个验证的子集，经典的语句有initial、task、function。通过这些语句可以给设计施加激励，并观察输出结果是否与期望一致。而存在的问题就是没有一些随机化的测试。

2）SystemC，非算法自己管理内存，容易泄露，基本不用。

3）SystemVerilog，Verilog的扩展集，兼容Verilog具有面向对象语言的特性：封装、继承和多态，同时还为验证提供了一些独有的特性，比如约束（constraint）、功能覆盖率（functional coverage）。有DPI接口，可以把C/C++的函数导入SystemVerilog。并且本身提供内存管理机制，不用担心内存泄漏的问题。除此之外，它还支持系统函数$system可以直接调用外部的可执行程序。

何为方法学

有了SystemVerilog后，还不足以搭建一个验证平台。还需要考虑很多问题：

- 验证平台中有暗些基本的组件，每个组件的行为有哪些？
- 验证平台中各个组件之间是如何通信的？
- 验证中要组建很多测试用例，这些测试用例如何建立、组织的？
- 建立测试用例的过程中，哪些组件是变的，哪些组件是不变的？

还有一些更高层次的问题需要考虑：

- 验证平台中数据流和控制流如何分离？
- 验证平台中的寄存器方案如何解决？
- 验证平台如何保证是可重用的？

什么是方法学？分三个层次，这里无需纠结大师境界，先放在这里，学完之后再回头看看。

为什么是UVM

在基于System Verilog的验证方法学中，目前市面上主要有三种，VMM（Verification Methodology Manual），当初闭源，后来与OVM竞争激烈，开源了。集成了寄存器解决方案RAL（Register Abstraction Layer）

OVM（Open Verification Methodology），Candence和Mentor推出的，开源，但是没有寄存器解决方案，后来推出了RGM。不过这两个没有变成一部分，使用RGM需要单独下载。现在已停止更新，后来被UVM替代。

UVM（Universal Verification Methodology），几乎完全继承OVM，并且采纳了寄存器解决方案RAL。

一个验证方法学想要成功，有三个主要的问题：

1）EDA厂商支持吗？工具一定要上游厂商支持才有意义，三大EDA厂商synopsys、Mentor、Cadence都完美地支持UVM。UVM本身就是这三家厂商联合推出的，读者打开任意一个UVM的源文件，都能在开头看到这三家公司关于版权的联合声明。

2）现在用的公司多吗？如果一种方法学本身不好用，就算厂商支持，工程师/开发者也不愿意用。

3）有更好的验证方法学出现了吗？UVM是2011年推出的，非常年轻，非常有活力。（现在已经是2022年了，VMM和OVM分别是2006年和2008年推出的，这么来看，UVM已经11岁了，其实不算非常年轻了hhh）

UVM的发展史

这里不详细介绍版本更新。

学习UVM之后能做什么

前端，要么设计要么验证呗。

验证工程师

验证工程师主要从本书学会如下内容：

- 如何用UVM搭建验证平台，sequence、factory、callback、register model等。
- 验证的基本常识
- UVM的高级功能，如何灵活地使用sequence机制、factory机制等。
- 怎么写代码才能保证可重用性（真的很重要，不要给别人一坨屎山。）
- 同一件事有多种实现方式，知道之间的优缺点，权衡利弊知道哪种最合适。
- OVM的用法遗留问题。