UVM print

UVM print_config不显示值(UVM print_config does not display values)

我正在尝试调试一些传统的UVM代码，但无法弄清楚发生了什么。 无论如何，在我努力的过程中，我遇到了这个函数 - print_config（1），它应该递归地打印出配置数据库。 出于某种原因，当我获得层次结构时，打印输出不会显示存储的值。 我只得到：

# resources that are visible in uvm_test_top.env.raster_stroke_agent.driver.sqr_pull_port # vif [/^.*\.env\.raster_stroke_agent\..*$/] : ? # - # th_testset_path [/^.*$/] : ? # - # th_testset_name [/^.*$/] : ? # - # th_testset_exp_path [/^.*$/] : ? # - # th_number_of_images [/^.*$/] : ? # - # th_cgs_red_lut_cfg_file_name [/^.*$/] : ? # - # th_cgs_green_lut_cfg_file_name [/^.*$/] : ? # - # th_cgs_blue_lut_cfg_file_name [/^.*$/] : ?

为什么我会得到？ 而不是实际值？

编辑：所以我遇到的基本问题是在尝试读取字段“testset_name”时，我得到了不同的值。 所以这是它的结构：

基本测试：set_config_string（“ ”，testset_name，“ABC”）子测试：set_config_string（“ ”，testset_name，“JFK”）孙子测试：set_config_string（“*”，testset_name，“XYZ”）

现在，当我尝试从序列中访问此变量时，我得到“ABC”。 如果我拿出孙子测试“set_config_string”，我得到“JFK”。

我不应该得到“XYZ”吗？

更奇怪的是print_config打印输出：

# resources that are visible in uvm_test_top.env.raster_stroke_agent.driver # vif [/^.*\.env\.raster_stroke_agent\..*$/] : ? # - # th_testset_path [/^.*$/] : ? # - # th_testset_name [/^.*$/] : ? # - # th_testset_exp_path [/^.*$/] : ? # - # th_number_of_images [/^.*$/] : ? # - # testset_path [/^uvm_test_top\..*$/] : ? # - # testset_name [/^uvm_test_top\..*$/] : ? # - # testset_name [/^uvm_test_top\..*$/] : ?

为什么同一组件下的testset名称有2个条目???

I am trying to debug some legacy UVM code and cannot figure out what is happening. Anyway, during my efforts, I came across this function - print_config(1) which should print out the config database recursively. For some reason, while I get the hierarchy, the printout does not show the values stored. I only get:

# resources that are visible in uvm_test_top.env.raster_stroke_agent.driver.sqr_pull_port # vif [/^.*\.env\.raster_stroke_agent\..*$/] : ? # - # th_testset_path [/^.*$/] : ? # - # th_testset_name [/^.*$/] : ? # - # th_testset_exp_path [/^.*$/] : ? # - # th_number_of_images [/^.*$/] : ? # - # th_cgs_red_lut_cfg_file_name [/^.*$/] : ? # - # th_cgs_green_lut_cfg_file_name [/^.*$/] : ? # - # th_cgs_blue_lut_cfg_file_name [/^.*$/] : ?

Why do I get the ? instead of actual values?

EDIT: So the basic problem I am having is while trying to read the field "testset_name" I get different values. so this is how it is structured:

base test: set_config_string ("", testset_name, "ABC") child test: set_config_string ("", testset_name, "JFK") grandchild test: set_config_string ("*", testset_name, "XYZ")

Now when I try to access this variable from sequence, I get "ABC". If I take out grandchild test "set_config_string", I get "JFK".

Shouldn't I be getting "XYZ"?

What is even more strange is the print_config printout:

# resources that are visible in uvm_test_top.env.raster_stroke_agent.driver # vif [/^.*\.env\.raster_stroke_agent\..*$/] : ? # - # th_testset_path [/^.*$/] : ? # - # th_testset_name [/^.*$/] : ? # - # th_testset_exp_path [/^.*$/] : ? # - # th_number_of_images [/^.*$/] : ? # - # testset_path [/^uvm_test_top\..*$/] : ? # - # testset_name [/^uvm_test_top\..*$/] : ? # - # testset_name [/^uvm_test_top\..*$/] : ?

Why are there 2 entries for testset name under the same component???

最满意答案

我猜测testset_name有2个条目，因为你对该组件做了2个set_config_string（...，“testset_name”，...）。

本文https://www.doulos.com/knowhow/sysverilog/uvm/easier_uvm/configuration/提到从最高级别的层次结构调用set_config_ *获胜。 在你的情况下，两个（或所有3个）调用都处于同一级别的层次结构中，因此我假设最后一个调用获胜。 最后一个意味着最后一个调用（可能是你的子类中你在构建阶段调用set_config_ *，但在基类中你在end_of_elaboration阶段调用它;我假设end_of_elaboration中的那个会赢 - 解释所以我们不要混淆继承和调用顺序的概念）。 调用get_config_ *时也要小心，因为如果你在end_of_elaboration中再次设置它，但是在构建中获取它，那么第二个集合将没有任何效果。

本文http://www.verilab.com/files/configdb_dvcon2014.pdf也非常了解配置数据库。 它建议通过在模拟器调用中添加plusarg + UVM_CONFIG_DB_TRACE来调试它的另一种方法。 这将显示设置和发生的确切顺序，这可能比print_config()更有帮助。

I'm guessing there are 2 entries for testset_name because you do 2 set_config_string(..., "testset_name", ...) to that component.

This article https://www.doulos.com/knowhow/sysverilog/uvm/easier_uvm/configuration/ mentions that the call to set_config_* from the highest level of hierarchy wins. In your case both (or all 3) calls are at the same level of hierarchy, so I would assume that the last one wins. Last one means the one that is called last (it may be the case that in your child class you call set_config_* in your build phase, but in the base class you call it in end_of_elaboration phase; I assume the one from end_of_elaboration would win - explanation so we don't mix up the concepts of inheritance and order of calls). Also take care when the get_config_* is called, because if you set it again in end_of_elaboration, but get it in build, then the second set will not have any effect.

This paper http://www.verilab.com/files/configdb_dvcon2014.pdf is also pretty good in understanding the config DB. It suggests another way of debugging it by adding the plusarg +UVM_CONFIG_DB_TRACE to your simulator call. This will show you the exact order in which sets and gets happen, which might be more helpful than print_config().