第1章
与UVM的第一次接触

1.1 UVM是什么

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

现代IC（Integrated circuit，集成电路）前端的设计流程如图1-1所示。通常的IC设计是从一份需求说明书开始的，这份需求说明书一般来自于产品经理（有些公司可能没有单独的职位，而是由其他职位兼任）。从需求说明书开始，IC工程师会把它们细化为特性列表。设计工程师根据特性列表，将其转化为设计规格说明书，在这份说明书中，设计工程师会详细阐述自己的设计方案，描述清楚接口时序信号，使用多少RAM资源，如何进行异常处理等。验证工程师根据特性列表，写出验证规格说明书。在验证规格说明书中，将会说明如何搭建验证平台，如何保证验证完备性，如何测试每一条特性，如何测试异常的情况等。

当设计说明书完成后，设计人员开始使用Verilog（或者VHDL，这里以Verilog为例）将特性列表转换成RTL代码，而验证人员则开始使用验证语言（这里以SystemVerilog为例）搭建验证平台，并且着手建造第一个测试用例（test case）。当RTL代码完成后，验证人员开始验证这些代码（通常被称为DUT（Design Under Test），也可以称为DUV（Design Under Verification），本书统一使用DUT）的正确性。

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

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

1.1.2 验证的语言

验证使用的语言五花八门，很难统计出到底有多少种语言曾经被用于验证，且验证这个词是从什么时候开始独立出现的也有待考证。验证是服务于设计的，目前来说，有两种通用的设计语言：Verilog和VHDL。伴随着IC的发展，Verilog由于其易用性，在IC设计领域占据了主流地位，使用VHDL的人越来越少。基于Verilog的验证语言主要有如下三种。

1）Verilog：Verilog是针对设计的语言。Verilog起源于20世纪80年代中期，并在1995年正式成为IEEE标准，即IEEE Standard 1364TM—1995。其后续版本是2001年推出的，与1995版差异比较大。很多Verilog仿真器中都会提供一个选项来决定使用1995版还是2001版。目前最新的标准是2005年推出的，即IEEE Standard 1364TM—2005，它与2001版的差距不大。验证起源于设计，在最初的时候是没有专门的验证的，验证与设计合二为一。考虑到这种现状，Verilog在其中还包含了一个用于验证的子集，其中最典型的语句就是initial、task和function。纯正的设计几乎是用不到这些语句的。通过这些语句的组合，可以给设计施加激励，并观测输出结果是否与期望的一致，达到验证的目的。Verilog在验证方面最大的问题是功能模块化、随机化验证上的不足，这导致更多的是直接测试用例（即direct test case，激励是固定的，其行为也是固定的），而不是随机的测试用例（即random test case，激励在一定范围内是随机的，可以在几种行为间选择一种）。笔者亲身经历过一个使用Verilog编写的设计，包含有6000多个测试用例。假如使用SystemVerilog，这个数字至少可以除以10。

2）SystemC：IC行业按照摩尔定律快速发展，晶体管的数量越来越多，整个系统越来越复杂。此时，单纯的Verilog验证已经难以满足条件。1999年，OSCI（Open SystemC Initiative）成立，致力于SystemC的开发。通常来说，可以笼统地把IC分为两类，一类是算法需求比较少的，如网络通信协议；另一类是算法需求非常复杂的，如图形图像处理等。那些对算法要求非常高的设计在使用Verilog编写代码之前，会使用C或者C++建立一个算法模型，即参考模型（reference model），在验证时需要把此参考模型的输出与DUT的输出相比，因此需要在设计中把基于C++/C的模型集成到验证平台中。SystemC本质上是一个C++的库，这种天然的特性使得它在算法类的设计中如鱼得水。当然，在非算法类的设计中，SystemC也表现得相当良好。SystemC最大的优势在于它是基于C++的，但这也是它最大的劣势。在C++中，用户需要自己管理内存，指针会把所有人搞得头大，内存泄露是所有C++用户的噩梦。除了内存泄露的问题外，SystemC在构建异常的测试用例时显得力不从心，因此现在很多公司已经转向使用SystemVerilog。

3）SystemVerilog：它是一个Verilog的扩展集，可以完全兼容Verilog。它起源于2002年，并在2005年成为IEEE的标准，即IEEE 1800TM—2005，目前最新的版本是IEEE 1800TM—2012。SystemVerilog刚一推出就受到了热烈欢迎，它具有所有面向对象语言的特性：封装、继承和多态，同时还为验证提供了一些独有的特性，如约束（constraint）、功能覆盖率（functional coverage）。由于其与Verilog完全兼容，很多使用Verilog的用户可以快速上手，且其学习曲线非常短，因此很多原先使用Verilog做验证的工程师们迅速转到SystemVerilog。在与SystemC的对比中，SystemVerilog也不落下风，它提供了DPI接口，可以把C/C++的函数导入SystemVerilog代码中，就像这个函数是用SystemVerilog写成的一样。与C++相比，SystemVerilog语言本身提供内存管理机制，用户不用担心内存泄露的问题。除此之外，它还支持系统函数$system，可以直接调用外部的可执行程序，就像在Linux的shell下直接调用一样。用户可以把使用C++写成的参考模型编译成可执行文件，使用$system函数调用。因此，对于那些用Verilog写成的设计来说，SystemVerilog比SystemC更受欢迎，这就类似于用C++来测试C写成的代码显然比用Java测试更方便、更受欢迎。无论是对算法类或者非算法类的设计，SystemVerilog都能轻松应付。

1.1.3 何谓方法学

有了SystemVerilog之后，是不是足以搭建一个验证平台呢？这个问题的答案是肯定的，只是很难。就像汉语是很优秀的语言一样，自古以来，无数的名人基于它创作出很多优秀的篇章。有很多篇章经过后人的浓缩，变成了一个又一个的成语和典故。在这些篇章的基础上，作家写作的时候稍微引用几句就会让作品增色不少。而如果一个成语都不用，一点语句都不引用，也能写出优秀的文章，但是相对来说比较困难。这些优秀的作品就是汉语的库。同样，SystemVerilog是一门优秀的语言，但是如果仅仅使用SystemVerilog来进行验证显然不够，有很多直接的问题需要考虑，比如：

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

同时，也有一些更高层次的问题需要考虑：

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

读者可以尝试自己回答这些问题，回答的时候不要空想，要把真正的代码写出来。

何谓方法学？方法学这个词是一个很抽象、很宽泛的概念，很难用简单的词语把它描绘出来。当然了，即使是一本专业讲述方法学的书籍，几百多页，看过之后可能依然会觉得不知所云。

在对方法学的理解上，有三个层次：

第一个层次，在刚刚接触到这个概念时，很容易把方法学和世界观、人生观、价值观等词语联系到一起，认为它是一个哲学的词汇。这种想法是不可避免的，而且，从根本上来说，它是正确的。只是这种理解太过浅显，因为方法学的真谛不在于概念本身，而在于其背后所表示的东西。

第二个层次，当初步学习完本书后，读者会觉得自己以前的想法太天真：方法学怎么会有那么神秘？至少从UVM的角度来说，方法学只是一个库。这种理解基本上没错。无论任何抽象的概念，一个程序员要使用它，唯一的方法是把其用代码实现。就如同上面的那些问题，如果能够把它们都完整地规划清楚，那么这就是属于读者自己的验证方法学；如果把思考结果用代码实现，那就是一个包含了验证方法学的库，是读者自己的UVM！

第三个层次，当读者从事验证工作几年之后，对UVM的各种用法信手拈来，就会发现方法学又不仅仅是一个库，库只是方法学的具体实现。从理论上来说，用一个东西表达另外一个东西的时候，只要两者不是一一对应的关系，那么一般会有很多遗漏。自然语言尚且无法完全地表述清楚方法学，而比自然语言更加简单的编程语言，则更加不可能表述清楚了。所以，一个库不能完全地表述清楚一种方法学。在这个阶段，读者再回过头来仔细想想上面的那些问题，想想它们在UVM中的实现，就会为UVM的优秀而拍案叫绝。

关于什么是方法学这个问题，读者可以不必太过于纠结，因为它属于相对高级的东西，在开始的时候追究这个问题只会增加自己学习UVM的难度。把这个问题放在一边，只把它当成一个库，等初步学完本书后再来回味这个问题。

1.1.4 为什么是UVM

在基于SystemVerilog的验证方法学中，目前市面上主要有三种。

VMM（Verification Methodology Manual），这是Synopsys在2006年推出的，在初期是闭源的。当OVM出现后，面对OVM的激烈竞争，VMM开源了。VMM中集成了寄存器解决方案RAL（Register Abstraction Layer）。

OVM（Open Verification Methodology），这是Candence和Mentor在2008年推出的，从一开始就是开源的。它引进了factory机制，功能非常强大，但是它里面没有寄存器解决方案，这是它最大的短板。针对这一情况，Candence推出了RGM，补上了这一短板。只是很遗憾的是，RGM并没有成为OVM的一部分，要想使用RGM，需要额外下载。现在OVM已经停止更新，完全被UVM代替。

UVM（Universal Verification Methodology），其正式版是在2011年2月由Accellera推出的，得到了Sysnopsys、Mentor和Cadence的支持。UVM几乎完全继承了OVM，同时又采纳了Synopsys在VMM中的寄存器解决方案RAL。同时，UVM还吸收了VMM中的一些优秀的实现方式。可以说，UVM继承了VMM和OVM的优点，克服了各自的缺点，代表了验证方法学的发展方向。

在决定一种验证方法学的命运时，有三个主要的问题：

1）EDA厂商支持吗？得到EDA厂商的支持是最重要的。在IC设计中，必然要使用一些EDA工具，因此，EDA厂商支持什么，什么就可能获得成功。目前，三大EDA厂商synopsys、Mentor、Cadence都完美地支持UVM。UVM本身就是这三家厂商联合推出的，读者打开任意一个UVM的源文件，都能在开头看到这三家公司关于版权的联合声明。

2）现在用的公司多了吗？一种方法学，如果本身比较差，不方便使用，那么即使得到了EDA厂商的支持，也不会受到广大验证工程师的欢迎。因此，当方法学刚开始推出时，第一个用户是要冒着很大风险的。但是幸运的是，读者肯定不是这样的“小白鼠”。因为现在市面上很多IC设计公司都已经在使用UVM，并且越来越多的公司开始转向使用UVM，UVM已经得到了市场的验证。

3）有更好的验证方法学出现了吗？没有。UVM是2011年推出的，非常年轻，非常有活力。

1.1.5 UVM的发展史

UVM的前身是OVM，由Mentor和Cadence于2008年联合发布。2010年，Accellera（SystemVerilog语言标准最初的制定者）把OVM采纳为标准，并在此基础上着手推出新一代验证方法学UVM。为了能够让用户提前适应UVM，Accellera于2010年5月推出了UVM1.0EA，EA的全拼是early adoption，在这个版本里，几乎没有对OVM做任何改变，只是单纯地把ovm_*前缀变为了uvm_*。

2011年2月，备受瞩目的UVM1.0正式版本发布。此版本加入了源自Synopsys的寄存器解决方案。但是，由于发布仓促，此版本中有大量bug存在，所以仅仅时隔四个月就又发布了新的版本。

2011年6月，UVM1.1版发布，这个版本修正了1.0中的大量问题，与1.0相比有较大差异。

2011年12月，UVM1.1a发布。

2012年5月，UVM1.1b发布。

2012年10月，UVM1.1c发布。

2013年3月，UVM1.1d发布。

从UVM1.1到UVM1.1d，从版本命名上就可以看出并没有太多的改动。本书所有的例子均基于UVM1.1d。