{"id":16625,"date":"2021-10-27T00:40:00","date_gmt":"2021-10-27T04:40:00","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/?p=16625"},"modified":"2026-03-27T08:47:50","modified_gmt":"2026-03-27T12:47:50","slug":"the-configuration-database-in-pyuvm","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2021\/10\/27\/the-configuration-database-in-pyuvm\/","title":{"rendered":"The configuration database in pyuvm"},"content":{"rendered":"\n\n\n

The configuration database<\/h1>\n\n

In the previous post in the Python for Verification Series<\/a> we discussed how pyuvm<\/strong> implemented TLM 1.0<\/a>. Now we turn our attention to some of the UVM\u2019s utilities and how we use them in Python. The first of these is the UVM configuration database.<\/p>\n\n

The configuration database as defined in the IEEE 1800.2 specification is very complicated. It includes a uvm_resource_db<\/code> that handles storing data of different types with the uvm_config_db<\/code> as a user interface for the uvm_resource_db<\/code>.<\/p>\n\n

None of this was necessary for pyuvm<\/code> since there are no types, so I refactored it and named it ConfigDB<\/code> to avoid confusion with the SystemVerilog version. In this post we\u2019ll examine ConfigDB()<\/code>.<\/p>\n\n

What is the ConfigDB()<\/code>?<\/h2>\n\n

The ConfigDB<\/code> class is a singleton database that stores objects using keys. It is much like a Python dictionary except that the keys must be strings and we can control the visibility to the data using the UVM hierarchy.<\/p>\n\n

In this blog post I refer to the configuration database as the ConfigDB()<\/code> as a reminder that we always call the ConfigDB<\/code> class (using parentheses) to get the handle to the singleton.<\/p>\n\n

Basic Setting and Getting<\/h2>\n\n

We\u2019ve already seen the most basic use of ConfigDB()<\/code> in the Python and the UVM<\/a> introductory blog post. We call our UVM testbench using a cocotb<\/strong> test. The test takes the dut<\/code> argument and uses it to create an instance of TinyAluBFM<\/code> then it stores the bfm<\/code> in the ConfigDB()<\/code> using the label BFM<\/code>:<\/p>\n\n

@cocotb.test()\nasync def test_alu(dut):\n    bfm = TinyAluBfm(dut)\n    ConfigDB().set(None, \"*\", \"BFM\", bfm)\n    await bfm.startup_bfms()\n    await uvm_root().run_test(\"AluTest\")<\/code><\/pre>\n\n
We see here that the pyuvm<\/strong> version of ConfigDB()<\/code> is much simpler than the SystemVerilog one since we don\u2019t have to deal with parameterized types or a litany of static function calls. Instead we simply say ConfigDB().set()<\/code>.<\/p>\n\n
We get the BFM from ConfigDB()<\/code> in, for example, the Driver<\/code> class. Here we get the bfm<\/code> in the connect_phase()<\/code>:<\/p>\n\n
class Driver(uvm_driver):\n    def connect_phase(self):\n        self.bfm = ConfigDB().get(self, \"\", \"BFM\")\n\n    async def run_phase(self):\n        while True:\n            command = await self.seq_item_port.get_next_item()\n            await self.bfm.send_op(command.A, command.B, command.op)\n            self.logger.debug(f\"Sent command: {command}\")\n            self.seq_item_port.item_done()<\/code><\/pre>\n\n
This approach of using None, '*<\/code> when setting the data and self, \"\"<\/code> when getting the data is how we store global data. We\u2019ll now look at storing data at specific places in the hierarchy.<\/p>\n\n
UVM hierarchical control<\/h2>\n\n
We use the ConfigDB()<\/code> instead of a dictionary so that we can instantiate the same component class in different parts of the testbench, and have them retrieve different data using the same label. That way we don\u2019t have to modify the code or somehow pass the label to the object. <\/p>\n\n
The ConfigD()<\/code> uses a combination of a handle to a UVM component and a string to create a UVM path both to store data in the ConfigDB()<\/code> and to retrieve it. The first two arguments to both the set()<\/code> and get()<\/code> functions are the component and the string path. Here is how this applies to the above call to set()<\/code>:<\/p>\n\n
    ConfigDB().set(None, \"*\", \"BFM\", bfm)<\/code><\/pre>\n\n
The UVM component in this case is set to None<\/code>. This gives us an empty base path of \"\"<\/code>. The path string in this case is \"*\"<\/code> and so this means we store \"BFM\"<\/code> with the path \"*\"<\/code>, which matches everything. <\/p>\n\n
The call to get()<\/code> looks like this:<\/p>\n\n
self.bfm = ConfigDB().get(self, \"\", \"BFM\")<\/code><\/pre>\n\n
In this case the self<\/code> variable contains an instance of the Driver<\/code>. The get()<\/code> function uses get_full_name()<\/code> on the self<\/code> variable to get the path to driver: \"uvm_test_top.env.driver\"<\/code>. Then it concatenates the string in the second argument (\"\"<\/code>) to add nothing to the base path.<\/p>\n\n
Finally the ConfigDB()<\/code> uses the Python fnmatch<\/code> function to see if the path in set()<\/code> matches the path in get()<\/code>. u\"*\"<\/code> matches uvm_test_top.env.driver<\/code> and so we read the data.<\/p>\n\n
We use this system to store different data, say different BFMs, in different parts of the testbench hierarchy. Here is a simple example:<\/p>\n\n
We create a simple component that pulls a message out of the ConfigDB()<\/code> and logs it:<\/p>\n\n
class MsgLogger(uvm_component):\n\n    def build_phase(self):\n        self.msg = ConfigDB().get(self, \"\", \"MSG\")\n\n    async def run_phase(self):\n        self.raise_objection()\n        self.logger.info(self.msg)\n        self.drop_objection()<\/code><\/pre>\n\n
Now we\u2019ll instantiate this component in two places.<\/p>\n\n
class MsgEnv(uvm_env):\n    def build_phase(self):\n        self.loga = MsgLogger(\"loga\", self)\n        self.logb = MsgLogger(\"logb\", self)<\/code><\/pre>\n\n
Finally we\u2019ll use the ConfigDB()<\/code> to pass two different messages:<\/p>\n\n
class LogTest(uvm_test):\n\n    def build_phase(self):\n        self.env = MsgEnv(\"env\", self)\n        ConfigDB().set(self, \"env.loga\", \"MSG\", \"AAAAA\")\n        ConfigDB().set(self, \"env.logb\", \"MSG\", \"BBBBB\")<\/code><\/pre>\n\n
We\u2019ve used self<\/code> as the context object. The LogTest<\/code> object will be instantiated with the name uvm_test_top<\/code> so that will be the base path for storing the data. If we ever use LogTest<\/code> as part of a larger testbench the ConfigDB()<\/code> will work same way because self<\/code> would generate the full path to the place we were instantiated.<\/p>\n\n
In this case, the self<\/code> path is uvm_test_top<\/code> and we use the path string in the second argument to create uvm_test_top.env.loga<\/code> and uvm_test_top.env.logb<\/code>. Now each instance of MsgLogger<\/code> will get a different message:<\/p>\n\n
INFO: testbench.py(12)[uvm_test_top.env.loga]: AAAAA\nINFO: testbench.py(12)[uvm_test_top.env.logb]: BBBBB<\/code><\/pre>\n\n
Path overrides<\/h3>\n\n
One can imagine a situation where a UVM components sets a value in the ConfigDB()<\/code> at a place in its hierarchy, but then gets instantiated inside another component that sets a different value to the same path.<\/p>\n\n
The IEEE 1800.2 UVM specification describes what to do in this situation: If the components set the configuration values in the build_phase()<\/code> function then the higher level component\u2019s set()<\/code> overrides the lower level component\u2019s set()<\/code>.<\/em><\/p>\n\n
For example, let\u2019s have the environment set a value for loga<\/code>:<\/p>\n\n
class MsgEnv(uvm_env):\n    def build_phase(self):\n        self.loga = MsgLogger(\"loga\", self)\n        self.logb = MsgLogger(\"logb\", self)\n        ConfigDB().set(self, \"loga\", \"MSG\", \"AAAENVAAA\")<\/code><\/pre>\n\n
This means that \"AAAENVAAA\"<\/code> is set for uvm_test_top.env.loga<\/code>. Remember, however that LogTest<\/code> has set a different value (\"AAAAA\"<\/code>) to the same path.<\/p>\n\n
class LogTest(uvm_test):\n\n    def build_phase(self):\n        self.env = MsgEnv(\"env\", self)\n        ConfigDB().set(self, \"env.loga\", \"MSG\", \"AAAAA\")\n        ConfigDB().set(self, \"env.logb\", \"MSG\", \"BBBBB\")<\/code><\/pre>\n\n
The result? The test wins since it is the higher level component.<\/p>\n\n
INFO: testbench.py(12)[uvm_test_top.env.loga]: AAAAA\nINFO: testbench.py(12)[uvm_test_top.env.logb]: BBBBB<\/code><\/pre>\n\n
Debugging the ConfigDB()<\/code><\/h2>\n\n
The ConfigDB()<\/code> has several debugging mechanism. One comes from the UVM specification. You can set the ConfigDB().is_tracing<\/code> class variable to True<\/code>:<\/p>\n\n
@cocotb.test()\nasync def log_msgs(dut):\n    \"\"\"Exercise hierarchy storage\"\"\"\n    ConfigDB().is_tracing = True\n    await uvm_root().run_test(\"LogTest\")\n    print(ConfigDB())\n    assert True<\/code><\/pre>\n\n
Now the ConfigDB()<\/code> will print out all the set()<\/code> and get()<\/code> operations. Notice that we see both set()<\/code> calls using the same path.<\/p>\n\n
# CFGDB\/SET Context: uvm_test_top  --  uvm_test_top.env.loga MSG=AAAAA\n# CFGDB\/SET Context: uvm_test_top  --  uvm_test_top.env.logb MSG=BBBBB\n# CFGDB\/SET Context: uvm_test_top.env  --  uvm_test_top.env.loga MSG=AAAENVAAA\n# CFGDB\/GET Context: uvm_test_top.env.loga  --  uvm_test_top.env.loga MSG=AAAAA\n# CFGDB\/GET Context: uvm_test_top.env.logb  --  uvm_test_top.env.logb MSG=BBBBB<\/code><\/pre>\n\n
And as final bonus, you can print ConfigDB()<\/code> as we see in the last line of the test. This gives the database. You can see how the ConfigDB()<\/code> has prioritized the two conflicting values:<\/p>\n\n
# PATH                : FIELD     : DATA                          \n# uvm_test_top.env.loga: MSG       : {999: 'AAAAA', 998: 'AAAENVAAA'}\n# uvm_test_top.env.logb: MSG       : {999: 'BBBBB'}<\/code><\/pre>\n\n
Summary<\/h2>\n\n
In this blog post we examined the ConfigDB()<\/code>, a refactored Python version of the uvm_config_db<\/code> and the uvm_resource_db<\/code>. We saw how to store values globally and at a specific location in the UVM hierarchy. <\/p>\n\n
We also saw how the UVM specification defined the response to conflicting values for a given key with the same path, and the prioritization behavior that happens only in the build_phase<\/code>.<\/p>\n\n
Finally we saw how to debug the ConfigDB()<\/code> using the is_tracing<\/code> variable and the print()<\/code> function<\/p>\n","protected":false},"excerpt":{"rendered":"
The configuration database In the previous post in the Python for Verification Series we discussed how pyuvm implemented TLM 1.0….<\/p>\n","protected":false},"author":74314,"featured_media":16629,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[984,1,981,10],"tags":[606,902,971,787,790,791],"industry":[],"product":[],"coauthors":[947],"class_list":["post-16625","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cocotb","category-news","category-pyuvm","category-tips-tricks","tag-multilanguage-uvm","tag-python","tag-pyuvm","tag-uvm","tag-uvm-config","tag-uvm-configuration-database"],"featured_image_url":"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2021\/10\/pyuvmconfigdb.png","_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16625","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/users\/74314"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/comments?post=16625"}],"version-history":[{"count":5,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16625\/revisions"}],"predecessor-version":[{"id":16650,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16625\/revisions\/16650"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media\/16629"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=16625"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=16625"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=16625"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=16625"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=16625"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=16625"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}