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?
The basic problem I am having is while trying to read the field "testset_name", I get different values. 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???
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().