我正在尝试调试一些遗留的 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”字段时，我得到了不同的值。这是它的结构：
base test: set_config_string ("*", testset_name, "ABC")
child test: set_config_string ("*", testset_name, "JFK")
grandchild test: 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\..*$/] : ?
为什么同一个组件下有 2 个测试集名称条目？？？
我猜 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 中再次设置它，但在 build 中获取它，那么第二次设置将不会有任何效果。
这篇论文 http://www.verilab.com/files/configdb_dvcon2014.pdf 在理解配置数据库方面也非常好。它建议通过将 plusarg +UVM_CONFIG_DB_TRACE 添加到模拟器调用中来调试它的另一种方法。这将向您显示设置和获取发生的确切顺序，这可能比
print_config()