savin_123的个人空间 https://blog.eetop.cn/1519763 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

UVM验证平台中的常用机制(总结&概述)

热度 3已有 6226 次阅读| 2019-3-16 12:35 |个人分类:IC验证|系统分类:芯片设计

天气: 晴朗
心情: 平静
    一个完整的UVM验证平台应该具有一些基本功能:产生并驱动激励,与DUV行为一致的理想参考模型reference_model(golden_model),监测并收集DUV和reference_mode的输入/输出信号,比较并判断DUV和reference_mode的输出是否一致且符合预期结果,等。这些基本的功能由相应的组件来完成。那么,这些组件之间是如何可靠、高效的完成验证工作的?或者说,UVM方法学中有哪些特有的机制可以保证验证平台自动的、可靠的并且高效率的完成验证工作呢?这篇内容将对一些常见的UVM机制进行一些简单的总结。
    常见的UVM机制:
    1.field_automation机制
    对field_automation最直观的感受是,他可以自动实现copy、compare、print等三个函数。当使用uvm_field系列相关宏注册之后,可以直接调用以上三个函数,而无需自己定义。这极大的简化了验证平台的搭建,尤其是简化了driver和monitor,提高了效率。   
    2.config_db机制
    config_db机制在UVM验证平台中主要用于参数传递。它们通常都是成对出现的,set函数是寄信,而get函数是收信。函数格式如下:
    uvm_config_db# (Type)::set(this,"inst_path","field",value); //将value寄送给 “field(字段)”
    uvm_config_db# (Type)::get(this,"","field",field)      //field将接收参数的传递
    结果得到:field = value;   
    所谓“字段”,是变量名包含的内容。在set和get函数中为第三个参数,字段在set和get中必须保持一致,才能保证参数的正确传递。例如要将参数值10,传递给int类型的变量data,则:
    uvm_config_db# (int)::set(this,"env.i_agt.drv","dat",10); //将10寄送给env组件中的成员变量“data”
    uvm_config_db# (int)::get(this,"","dat",data)      //字段“dat”保持一致,成员变量data将接收参数的传递
    结果得到:data = 10;   
    3.objection机制
    UVM中通过objection机制来控制验证平台的关闭,需要在drop_objection之前先raise_objection。验证在进入到某一phase时,UVM会收集此phase提出的所有objection,并且实时监测所有objection是否已经被撤销了,当发现所有都已经撤销后,那么就会关闭此phase,开始进入下一个phase。当所有的phase都执行完毕后,就会调用$finish来将整个验证平台关掉。如果UVM发现此phase没有提起任何objection,那么将会直接跳转到下一个phase中。
    UVM的设计哲学就是全部由sequence来控制激励生成,因此一般情况下只在sequence中控制objection。另外还需注意的是,raise_objection语句必须在main_phase中第一个消耗仿真时间的语句之前。
    4.factory机制
    factory机制的优势在于其具有重载功能。重载并不是factory机制的发明,只是factory机制的重载与这些重载都不一样。要想使用factory机制的重载功能,必须满足以下要求:
    1) 无论是重载的类(parrot)还是被重载的类(bird),都要在定义时注册到factory机制中。
    2) 被重载的类(bird)在实例化时,要使用factory机制的方式进行实例化,而不能使用传统的new的方式。
    3) 最重要的是,重载的类(parrot)要与被重载的类(bird)有派生关系。重载的类必须派生自被重载的类,被重载的类必须是重载类的父类。
    4) component与object之间互相不能重载。虽然uvm_component是派生自uvm_object,但是这两者根本不能重载。因为,从两者的new参数的函数就可以看出来,二者互相重载时,多出来的一个parent参数会使factory机制无所适从。
    当然,factory机制的实现被集成在了一个宏中:uvm_component_utils。这个宏最主要的任务是,将字符串登记在UVM内部的一张表中,这张表是factory功能实现的基础。只要在定义一个新的类时使用这个宏,就相当于把这个类注册到了这张表中。这样,factory机制可以实现:根据一个字符串自动创建一个类的实例,并且调用其中的函数(function)和任务(task),这个类的main_phase就会被自动调用。
    5.callback机制
    在UVM验证平台中,callback机制最大的用处就是提高验证平台的可重用性。很多情况下,验证人员期望在一个项目中开发的验证平台能够用于另外一个项目。但是,通常来说,完全的重用是比较难实现的,两个不同的项目之间或多或少会有一些差异。如果把两个项目不同的地方使用callback函数来做,而把相同的地方写成一个完整的env,这样重用时,只要改变相关的callback函数,env可完全的重用。
    除了提高可重用性外,callback机制还用于构建异常的测试用例,VMM用户会非常熟悉这一点。只是在UVM中,构建异常的测试用例有很多种方式,如factory机制重载,而callback机制只是其中的一种。
    6.phase机制
    在不同的时间做不同的事情,这就是UVM中phase的设计哲学。但是仅仅划分成phase是不够的,phase的自动执行功能才极大方便了用户。当new语句执行完成后,后边的connect语句肯定就会自动执行。现引入phase概念,将前面的new的部分包裹进build_phase里面,把后边的connect语句包裹进connect_phase里边,很自然的,当build_phase执行结束后就应该自动执行connect_phase。
    phase的引入在很大程度上解决了因代码顺序杂乱可能会引起的问题。遵循UVM的代码顺序划分原则(如build_phase做例化工作,connect_phase做连接工作等),可以在很大程度上减少验证平台开发者的工作量,使其从一段杂乱的工作中解脱出来。
    UVM中的phase按照其是否消耗仿真时间($time打印出的时间)的特性,可以分成两大类:一类是function_phase,如产生build_phase、connect_phase等,这些phase都不消耗仿真时间,通过函数来实现;另一类是task_phase,如run_phase等,他们消耗仿真时间,通过任务来实现。给DUT施加激励、监测DUT的输出都是在这些phase中完成的。
    所有的phase按照以下顺序自上而下自动执行:
    build_pase
    connect_phase
    end_of_elaboration_phase
    start_of_simulation_phase
    *run_pase*
    extract_phase
    check_phase
    report_phase
    final_phase

    其中,*run_phase*按照以下顺序自上而下执行:
    pre_reset_phase
    reset_phase
    post_reset_phase
    pre_configure_phase
    configure_phase
    post_configure_phase
    pre_main_phase
    main_phase
    post_main_phase
    pre_shutdown_phase
    shutdown_phase
    post_shutdown_phase

    7.sequence机制
    sequence机制用于产生激励,它是UVM中最重要的机制之一。sequence机制有两大组成部分:sequence和sequencer。在整个验证平台中sequence处于一个比较特殊的位置。sequence不属于验证平台的任何一部分,但是它与sequencer之间有着密切的关系。只有在sequencer的帮助下,sequence产生的transaction才能最终送给driver;同样,sequencer只有在sequence出现的情况下才能体现出其价值,如果没有sequence,sequencer几乎没有任何作用。除此之外,sequence与sequencer还有显著的区别。从本质上说,sequencer是一个uvm_component,而sequence是一个uvm_object。与my_transaction一样,sequence也有其生命周期。它的生命周期比my_transaction要更长一点,其内部的transaction全部发送完毕后,它的生命周期也就结束了。
    8.通信机制TLM1.0
    UVM中,通常使用TLM(Transaction Level Modeling)实现component之间transaction级别的通信。TLM现在已经发展到TLM2.0,是对TLM1.0的扩展。但是TLM1.0足以满足大多数完整的验证平台的通信要求,所以主要学习TLM1.0。关于TLM1.0通信机制,后续将会详细介绍。


点赞

发表评论 评论 (4 个评论)

回复 yqjykn 2019-3-20 11:00
不错,加油,继续~
回复 zwyw 2019-3-22 11:11
callback是我目前最难理解的一部分,一直也没做过相关的case,能不能详细介绍一下?
回复 savin_123 2019-3-29 08:40
zwyw: callback是我目前最难理解的一部分,一直也没做过相关的case,能不能详细介绍一下?
后续每一个机制都会详细介绍的哦
回复 八个向日葵 2021-3-23 11:40
有个问题:connect_phse的执行顺序不是自下而上的吗?

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 4

    粉丝
  • 2

    好友
  • 0

    获赞
  • 4

    评论
  • 480

    访问数
关闭

站长推荐 上一条 /1 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-5-3 03:44 , Processed in 0.026705 second(s), 16 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部