UVM学习笔记(1) 初识UVM框架

         上一篇文章发出去,才发现排版好丑,发现排版确实很影响人的胃口,不过是技术笔记类的文章,不做纠结了,以后写文章再不废话了

         ============================= 割==============================

    验证基础

         真是不想多废话,选了个标题都弄了10分钟,格式好费时间,又废话了。

         我接触验证的时间和我上班的时间一样,到目前为止,马上到三年了,验证给我最初的印象就是帮别人测试东西的,非常没有技术含量,简直可以说是擦屁股的,做好了,和我没关系,我漏了bug,都是我的锅,哪有这么坑的工作让我做。我入门第一天,我师父问我,你想做设计还是想做验证呢,我说设计啊,多有创意,我师父说,啊,设计的名额已经满了,我是做验证的,所以你也来做验证吧,我屮艸芔茻,心中一万只草泥马奔过,你都定了还问个毛线啊,咋办,那就验呗。咋验?不会,是不是要被开除了,可能吧


                         

           

         一个简单的验证平台。大概就是这样的。一个人发号施令,翻译成中国话和英文,分别送给不同的人,自己消化了再拿出来比对一下到底是不是一样的,咦,怎么有点恶心

        

         好吧,我还是简单的陈述一下什么是验证,什么是我所认为的验证:以高级语言为参考模型,对verilog构建的时序模块进行检查、比对、校验的一种质量保证活动。高级语言,说白了就是C++一类,可以面向对象又或者比较容易实现数据结构的语言类型,听说有人拿Perl、makefile写验证环境,真是个变态。验证的基本框架就是上图所示,至于各个芯片的情况不同,验证环境的结构多少是有些变化的,比如我现在的B模块,是个数据环,比对完了还不行,还要拿出来继续用,还要送回到RM,构成了一个数据环,因此,验证环境并不是一成不变的,而是可以进行多种多样的优化,我们不以写得漂亮为目的,也不是以找了多少bug为目的,以保证芯片代码最后没有问题为目的,发现了1000个bug又能怎么样呢,最后漏一个,就是实打实的一个,管你发现了多少,该废还是要废,你可以按部就班的梳理测试点,也可以鸟枪法,总之bug到处都是,然而能做的完美的却又没有多少个。

         跑题了,写着写着就像吐槽,单纯的做个技术狗还真不容易,好了,验证的基础其实需要在实践中慢慢体会,是一种比较死板又可灵活的套路,不会一成不变,接下来,我们就该请出主角,UVM,来初步认识一下什么是个UVM。

  UVM基础

UVM的全程为,Universal Verification Methodology,意为通用验证方法学,前身是OVM,貌似是mentor弄的一套东西,本质上,验证方法学只是对systemverilog进行一些常用类的封装,按照一套统一的流程,进行验证活动,经过多次对比之后,发现方法学只是各个验证公司间博弈的产物,eetop上有人说过真正牛逼的验证应该是自己有一套合适的验证方法,鉴于他的名字已经叫“通用”了,所以应该对各个验证结构来说是比较通用的。

UVM_PHASE

UVM的流程核心是phase,phase的中文意思是相,跟VMM1.1的九步法比起来,是要繁琐很多,但是用起来才发现这些隔离的phase是非常方便对于仿真的精确控制的,粗略来说,分为头4、尾4共8个function类型的phase,只干事,不消耗时间,中间有一个run_phase还有个4x3个小phase,run_phase和这12个phase是并行的,只是run_phase自己独成一派,而其他的12个就要乖乖的顺序执行了,用一些伪代码来表示这个过程更加明确一些
fork
    begin
        run_phase();
    end
    begin
        phase1();
        phase2();
        ……
        phase12();
    end
join_none

核心流程对于理解各个组件之间的仿真顺序至关重要,现在我们知道了phase这个玩意儿,就要说说UVM中包含的验证组件了,其实还有更重要的一个机制对于phase的控制非常精细,这个就是uvm_objection,不过这个在这里讲的话可能没什么概念,后面我们再说

UVM_OBJECT

在我一开始搭建demo的过程中,遇到了如下组件,是非常常见
agent、driver、monitor、sequencer、sequence、rm、checker、scoreboard
其实这些组件与VMM所构建的验证环境大同小异,而这些组件的老家全都是uvm_object,作为一个对象存在,何为object?我个人理解为一个事实存在的实体,一个对象,这个object可能会随着时间的推进,消失或者重建,更类似于指针使用过程中的instance,刚刚接触UVM的人可能都把这个和uvm_component分不清楚,至少我是这样的,uvm的书中大多有基类继承关系的介绍,而component是object的娃,于是在各个组件的使用过程中,可以有如下体会: component伴随仿真的生命周期存在,而object是根据使用需要来决定是否存在,暂且这么理解,在我搭建环境的时候,在一个叫config聚合类的东西里继承于Object,就是一个集中从cmdline中获取config value的cfg类,这个继承于uvm_object,说来也比较合理,cfg的配置变量在使用的时候才会被实例化,这里顺带要提到一个要注意的地方,就是uvm_config_db#set(……)的使用,uvm_object在环境中是没有一席之地的,也就是说,我不能通过env.xxx.xxx.xx来索引到一个object组件,他不能成为环境中的一份子,所以,我们如果想对某个object中的某个变量进行set的话,就要对这个object整体进行set,uvm_object可玩性不高,因为他是一个非常基本的类,所以他的子孙非常多,但是自己的可玩性比较低,感觉就跟我们本科生上班一样,说是可塑性高,实际上就是说你啥都不会,哈哈。或许我对uvm_object的见解比较低,这个我们就暂且先聊这么多。


你可能感兴趣的:(UVM)