uvm_config_db vs uvm_resource_db, where they come from and what are they good for
The origins According to a story I was told, the origin of the uvm_resource_db stems from the fact that certain simulators (if I remember correctly Mentor's Modelsim/Questa), were unable to cope with the dot-notation. Eg. You could not write m_object.m_field = 1 , instead you'd have to put the field value into uvm_resource_db and pull the value at the "other" side. Uvm_config_db was created so as to simplify issues with namespace collisions. Set and get functions for the config_db accept as a first argument a uvm_component. The component is only used so as to get a full hierarchical name for the object's name, thereby protecting the namespace from being polluted. Eg., an environment that would need to set a field within a agent/scoreboard residing within that environment would pass the set function this as its first argument and the agent/scoreboard's instance name as it's second argument. The component (agent/scoreboard) would be pullin