《UVM实战》——1.1节UVM是什么

目录

第1章

1.1 UVM是什么

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

1.1.2 验证的语言

1.1.4 为什么是UVM

1.1.5 UVM的发展史


 

本节书摘来自华章社区《UVM实战》一书中的第1章,第1.1节UVM是什么,作者 张 强

第1章

与UVM的第一次接触

1.1 UVM是什么

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

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

《UVM实战》——1.1节UVM是什么_第1张图片

当设计说明书完成后,设计人员开始使用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在其中还包含了一个用于验证的子集,其中最典型的语句就是initialtaskfunction纯正的设计几乎是用不到这些语句的。通过这些语句的组合,可以给设计施加激励,并观测输出结果是否与期望的一致,达到验证的目的。

       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来进行验证显然不够,有很多直接的问题需要考虑,比如:

  1. 验证平台中都有哪些基本的组件,每个组件的行为有哪些?
  2. 验证平台中各个组件之间是如何通信的?
  3. 验证中要组建很多测试用例,这些测试用例如何建立、组织的?
  4. 在建立测试用例的过程中,哪些组件是变的,哪些组件是不变的?
  5. 同时,也有一些更高层次的问题需要考虑:
  6. 验证平台中数据流与控制流如何分离?
  7. 验证平台中的寄存器方案如何解决?
  8. 验证平台如何保证是可重用的?

      读者可以尝试自己回答这些问题,回答的时候不要空想,要把真正的代码写出来。
     何谓方法学?方法学这个词是一个很抽象、很宽泛的概念,很难用简单的词语把它描绘出来。当然了,即使是一本专业讲述方法学的书籍,几百多页,看过之后可能依然会觉得不知所云。
在对方法学的理解上,有三个层次
第一个层次,在刚刚接触到这个概念时,很容易把方法学和世界观、人生观、价值观等词语联系到一起,认为它是一个哲学的词汇。这种想法是不可避免的,而且,从根本上来说,它是正确的。只是这种理解太过浅显,因为方法学的真谛不在于概念本身,而在于其背后所表示的东西。
第二个层次,当初步学习完本书后,读者会觉得自己以前的想法太天真:方法学怎么会有那么神秘?至少从UVM的角度来说,方法学只是一个库。这种理解基本上没错。无论任何抽象的概念,一个程序员要使用它,唯一的方法是把其用代码实现。就如同上面的那些问题,如果能够把它们都完整地规划清楚,那么这就是属于读者自己的验证方法学;如果把思考结果用代码实现,那就是一个包含了验证方法学的库,是读者自己的UVM!
第三个层次,当读者从事验证工作几年之后,对UVM的各种用法信手拈来,就会发现方法学又不仅仅是一个库,库只是方法学的具体实现。从理论上来说,用一个东西表达另外一个东西的时候,只要两者不是一一对应的关系,那么一般会有很多遗漏。自然语言尚且无法完全地表述清楚方法学,而比自然语言更加简单的编程语言,则更加不可能表述清楚了。所以,一个库不能完全地表述清楚一种方法学。在这个阶段,读者再回过头来仔细想想上面的那些问题,想想它们在UVM中的实现,就会为UVM的优秀而拍案叫绝。
关于什么是方法学这个问题,读者可以不必太过于纠结,因为它属于相对高级的东西,在开始的时候追究这个问题只会增加自己学习UVM的难度。把这个问题放在一边,只把它当成一个库,等初步学完本书后再来回味这个问题。

1.1.4 为什么是UVM

      在基于SystemVerilog的验证方法学中,目前市面上主要有三种。
(1)VMM(Verification Methodology Manual),这是Synopsys在2006年推出的,在初期是闭源的。当OVM出现后,面对OVM的激烈竞争,VMM开源了。VMM中集成了寄存器解决方案RAL(Register Abstraction Layer)。

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

转自:https://yq.aliyun.com/articles/117852?t=t1

 

你可能感兴趣的:(System,Verilog)