UVM(2)-config机制、消息管理

沉淀！

已于 2023-06-27 11:16:32 修改

阅读量299

点赞数

文章标签：学习

于 2023-06-24 21:19:08 首次发布

本文链接：https://blog.csdn.net/2301_76431006/article/details/131366025

版权

接上一节的内容，继续探讨config机制和消息管理相关知识。

一、config机制

在验证环境的创建过程build phase中，除了组件的实例化，配置也是必不可少的。
在底层创建之前，完成配置！！！

1、概述

2、interface传递

interface传递可以很好地解决了连接硬件世界和软件世界
而在之前SV验证模块中，虽然SV可以通过层次化的interface的索引来完成了传递，但是这种方式不利于软件环境的封装和复用
UVM的uvm_config_db使得接口的传递和获取彻底分离开来。

说明：简单理解就是uvm_config_db做为一个容器，然后把要传递的interface在run_test()之前set进这个容器中，然后在底层的build_phase阶段get到放进容器的interface即完成了传递，相比于sv中接口的传递来说：1、减少了层层传递，UVM中可以随意层次之间传递；2、SV中传递建立在底层创建之后，而UVM恰恰相反，在底层创建之前，完成传递即可。

在实现接口传递的过程中需要注意:

接口传递应该发生在run test()之前。这保证了在进入build phase之前virtuali nterface已经被传递到uvm_config_db中。

用户应当把interface与virtual interface的声明区分开来，在传递过程中的类型应当virtual interface，实际接口的句柄

3、变量设置

在各个test中，可以在build phase对底层组件的变量加以配置，进而在环境例化之前完成配置，使得环境可以按照预期运行

其余和接口传递一样。

4、object传递

在test配置中，需要配置的参数不只是数量多，而且可能还分属于不同的组件。
那么如果对这么多层次中的变量做出类似上面的变量设置，那会需要更多的代码，容易出错还不易于复用，甚至底层组件的变量被删除后，也无法通过uvm_config db::set()得知配置是否成功。
然而如果将每个组件中的变量加以整合，首先放置到一个uvm_obiect中，再对中心化的配置对象进行传递，那么将会更有利于整体环境的修改维护。

细节把控：

先set再create
set和get成对出现，先set再get，且set和get必须发生在组件里面
传递的类型必须保持一致（如ppt中例子为-uvm_object），
路径也需要一致
5、总结

6、建议

二、消息管理

1、消息方法

在UVM环境中或者环境外，只要有引入uvm pkg，均可以通过下面的方法来按照消息的严重级别和冗余度来打印消息。

四个消息函数有若干共同的信息，它们是严重级别(severity) 、冗余度(verbosity) 、消息ID、消息、文件名和行号：
严重级别: 从函数名本身也可以得出，这四个严重级别分别是UVM_INFO、UVM_WARNING、UVM_ERROR、UVM_FATAL。不同的严重级别在打印的消息中也会有不同的指示来区别，同时仿真器对不同严重级别消息的处理方式也不一样。例如对于UVM FATAL的消息，默认情况下仿真会停止。
消息ID:该ID可以是任意的字符串，用来标记该消息。这个标记会同消息本身打印出来，同时不同的标记也可以用来进行消息处理。
消息: 即消息文本的主体
冗余度:冗余度与消息处理中的过滤直接相关。冗余度的设置如果低于过滤的开关那么该消息会打印出来，否则不会被打印出来。但是无论信息是否会被打印出来，这都与对消息采取的其它措施没有关系，例如仿真停止。（UVM_HIGH表示最重要的一个关系（能够打印更全的消息））
文件名和行号：这些信息用来提供消息发生时所在的文件和行号。用户可以使用默认值，而UVM后台会自动填补它们原本的文件名和行号，同时也在打印时将文件名和行号输出。

2、消息处理

3、消息宏

如果要做自定义的消息处理方式，用户可以通过uvm_report_object类提供的方法进行配置。
uvm_report_object类是间于uvm_obiect类与uvm_component类之间的中间类，它的主要功能是完成消息打印和管理。
UVM也提供了一些宏来对应上面的消息方法用户也可以使用这些宏来处理消息

4、消息机制

（1）仿真停止控制

消息处理是由uvm_report_handler类来完成的，而每一个uvm_report_object类中都有一个uvm_report_handler实例
上面的uvm_report_object消息处理方法或者uvm_component消息处理方法，都是针对于这些uvm_report_handler做出的配置。
除了上面的常见使用方法，用户还可以做出更高级的消息控制。例如，当UVM_ERROR出现之后，仿真默认会停止，这是由于设置了即UVM_ERROR的处理方式是UVM_COUNT数量达到上限 (默认为1)，即停止仿真。可以通过set_max_quit_count来修改UVM_COUNT值

（2）回调函数

消息用户在处理信息时，还希望做出额外的处理，这时回调函数就显得很有必要了，uvm_report_object类提供了下面的回调函数满足用户更多的需求:

说明：

report_hook()函数通过结合消息管理时的UVM_CALL_HOOK参数，结合用户自定义的回调函数，就可以实现更丰富的配置。
这样用户在调用回调函数时，首先会调用report_hook()函数，接下来才按照severity级别来选择更细致的回调函数report_SEVERITY_hook()。
默认情况下，report_hook()函数返回值为1，进而再转入report_SEVERITY_hook（）函数
如果report_hook()函数由用户自定义且返回0的话，那么后续report_SEVERITY_hook()函数不会执行。

下面我们需要完成实验0和1对uvm(1)、(2)所提到的知识进行巩固。