Config_db :
1. The config_db is not much more than an associative array that stores values or object handles.
2. The keys for these associative arrays is the string name. (Important)
3. With the uvm_component class, that string name(discussed in point2) is built up into a pathname(discussed in point 4) with hierarchy.
4. The path name when you set() a value into the config_db is matched up with the pathname you get() from the config_db.
Note: Set and get are inbuilt function and config_db is used to access the values, object handles and interfaces in top-down the hierarchy in the testbench.
Factory Registration:
1. Factory registration is similar to the uvm_config_db::set(), except that you are defining a set of static methods and properties.
1. Factory registration is similar to the uvm_config_db::set(), except that you are defining a set of static methods and properties.
2. Instead of storing an object of the registered class type into an associative array, you are storing a proxy object that will be used to construct the registered class type.
3. The create() method gets called to do the construction of the requested type. The create method looks up overrides using the same pathname string matching used by the config_db.
4.To summarize, we use the factory to select which class objects or their overrides(extensions) get constructed. Then you use the config_db to store and retrieve handles to objects so that they can be shared.
Note: as discussed in point 3, "factory override" provide the facility to override a class by instance or by type.
