uvm

report mechanism uvm_report_object.svh :: get_report_verbosity_level(uvm_severity severity=UVM_INFO, string id=""); -> call uvm_report_handler::get_verbosity_level(severity, id); -> severity_id_verbosities(对应function::set_severity_id_verbosity) and id_verbosities(对应function::set_id_verbosity) 其中uvm_info 最终也是调用call 该function来判断是否输出的. 在simulation是会在run_root::new()中调用set_report_verbosity_level_hier(verbosity); uvm_field_* 当定义的member是一个关联数组，且可以是一个bit类型的，可以使用uvm_field_aa_int_key来实现 eg： bit[7:0]mem[bit[63:0]] mem, -》 `uvm_field_aa_int_key(bit[63:0], mem, UVM_DEFAULT) 来源： CSDN 作者： Vinson_Yin 链接：

Reporting 类提供了一组工具用于格式化报告输出 report机制大概包括四个主要的类uvm_report_object，uvm_report_handler， uvm_report_server，uvm_report_catcher， UVM reporting主要的接口是uvm_report_object（这是一个接口类），这是uvm_components的父类。 uvm_report_object通过 内部的function调用 uvm_report_handler的function来执行大部分的工作。 uvm_report_handler存储了对消息的显示和处理的一些配置信息，他对消息的处理进行决策，并对消息进行一些格式化，过滤等。最终消息被将被uvm_report_handler送到uvm_report_server。而uvm_report_catcher实际上就是一个uvm_report_cb，他对特定的uvm_report_object发出的消息进行抓取。 下图是reporting类的继承关系： uvm_report_object: 1. 通过此接口,组件发起发生在仿真过程中的各种message。 Users can configure what actions are taken and what file(s) are output for

在UVM中环境中，在我们执行simulation的过程中，会在命令行添加一些simulation args。比如 ./simv –l vcs_run.log +UVM_TESTNAME=my_test 在UVM世界中，有一个class专门来处理这些参数。这个类就是uvm_cmdline_processor 类的继承关系是： uvm_object->uvm_report_object->uvm_cmdline_processor，这个类与factory相似，均是single模式的类，静态方法get_inst拿到唯一的对象。比如uvm_cmdline_processor cpl= uvm_cmdline_processor::get_inst(); 在这个类中有3个重要的变量（队列） 1：string m_argv[$] //存放所有cmdline参数，m_argv[0]=./simv 2：string m_plus_argv[$]//存放所有cmdline参数中以+为开头的参数 3：string m_uvm_argv[$]//存放所有cmdline参数中以+UVM*，+uvm或者-UVM*，-uvm为开头的参数 比如./simv –l vcs_run.log +UVM_TESTNAME=my_test m_argv[$]有4个参数 m_plus_argv[$]有1个参数 m_uvm

callback机制 callback机制提高代码的可重用性，还用于构建异常的测试用例。 广义的callback机制有post_randomize()，pre_body(),post_body(), pre_do(), mid_do()等，它们提供了额外的接口给用户。 原理 以在driver中提供callback函数接口为例，在发送transaction之前或之后需要对transaction进行处理，于是建立preSend()和postSend()任务，而不同的测试用例希望preSend或postSend进行不同的处理，所以这两个任务不能是Driver类的方法，这样毫无重用性可言，每搭建一个测试用例就需要新的Driver。 解决办法是 建立一个新的专门服务callback机制的类，将preSend()和postSend()放在该类中，之后在Driver中实例化该类，通过层次化引用的方法调用preSend和postSend ，这样就将两个任务和Driver分离开，不同的测试用例只需要重新定义不同的callback类，不需重新定义Driver。 这样还有一个问题，每一个测试用例需要不同的preSend()和postSend()也就是不同的callback类，如果将这些类都放在Driver中实例化的话，也丧失了可重复性

1.UVM通过设置冗余度级别提供了日志的可读性。如果小于等于阈值，就会显示，否则不会显示。默认的是UVM_MEDIUM。 2.get_report_verbosity_level：得到某个component 的冗余度阈值： 在my_driver中设置： 编译报错： 不知道怎么改。。先换到其他位置： 报告： 是 200。 含义是： 3.set_report_verbosity_level：设置某个特定的component 冗余度。 driver里面两个UVM_HIGH 的info。 base_test里设置为UVM_HIGH。仿真，两条都打印。改成UVM_MEDIUM，两条都不打印。 1）由于牵涉到层次引用，要在connect_phase即以后的phase才能调用。 2）如果不牵涉层次引用，如设置当前component的冗余度，可以在connect_phase之前调用 4.set_report_verbosity_level_hier：上一个只能设置一个component，这个可以设置其下所有components： 5.set_report_id_verbosity区分不同的iD冗余度阈值： 6.set_report_id_verbosity_hier：即设置递归，有设置ID： 7.还可以在命令行中设置冗余度： <sim command> +UVM_VERBOSITY=UVM

uvm_report实现中的类图，如下： 　　　　　　 　　1)uvm_component均从uvm_report_object extend而来，其中定义了report_warning，error，info，fatal等方法接口； 　　2)uvm_report_message和uvm_report_handle，是一个中介者的角色，实现调用接口和实现的分离；将report信息， 　　　　打包成一个message的对象；并处理各种severity的override； 　　3)uvm_report_server，实现该message具体的uvm_action； 　　4)uvm_report_catcher，作为访问者，在tb top对某个id，serverity，verbosity的message进行处理，catch或throw； uvm_report_object中实现了report的调用接口，以及report_handle的变量； 　　　　　　 　　　　report_object和report_handle是绑定的关系，两者是互相composite的，object_report提供给用户的有两 类function： 　　　　1)info，warning等调用function，其中verbosity在report_object中是被固定住的。 　　　　　　　　error---

zz: http://bbs.eetop.cn/thread-447424-1-1.html 首先，提一个看似简单的问题：在使用uvm的做验证的时候，经常需要打印信息，比较常用的可能就是`uvm_info 和uvm_report_info之类的了，那么`uvm_info 和 uvm_report_info之间有没有什么区别呢？ 下面是`uvm_info的宏展开： 108 `define uvm_info(ID,MSG,VERBOSITY) 109 begin 110 if (uvm_report_enabled(VERBOSITY,UVM_INFO,ID)) 111 uvm_report_info (ID, MSG, VERBOSITY, `uvm_file, `uvm_line); 112 end 可以看出`uvm_info宏就是调用了uvm_report_enabled function做了一个verbosity_level和action的判断其是否允许进行report操作。关于action和verboisty_level在uvm中可以对其进行很精细的控制，如下面所示： 1)action设置：从上到下，范围由小到大，精细度由高到低，判别优先级由高到低 （severity, id) id -> action severity 2)verbosity设置：从上到下， 范围由小到大

1、RAL的组成 ral是寄存器列表+访问控制的集合。 　　表部分，ral包含了寄存器基本的域、寄存器、页签、多页签的层次组成方式，将多个小的单元包含在一个大的单元里边，再将大的单元包含在更大的单元里边，层层嵌套，组成一个包含多个页签的寄存器表。 　　其中最小的单元是域（uvm_reg_field），然后是寄存器(uvm_reg)，多个寄存器可以组成一个块（uvm_reg_block）相当于一个页签，多个页签可以还可以组成一个更大的页签 　　访问控制部分，ral的uvm_reg_block类中内置了default_map成员，这个类保存了页签中所有寄存器的相对地址、偏移地址、访问权限等信息，同时还提供了do_read()和do_write()函数供调用。在uvm_reg_block中使用default_map.add_reg就可以将寄存器的相对地址等信息保存到map中。如果是页签，则使用ad_submap的方式将偏移地址等信息保存在map中，并修改页签所的偏移地址为add_submap传来的偏移地址。 uvm_reg_block中的每个寄存器（uvm_reg）和每个域（uvm_reg_field）中都要read和write函数，只需要通过类的层层引用就能调用对应寄存器或者域的read和write函数