In reply to manning999:
Right on! That is where I was headed. You might have…
package test_params_pkg;
parameter BUS1_DATAW = 64;
parameter BUS2_DATAW = 512;
//...
endpackage
And then you pipe those values into each instantiation of your wrapper modules, which in turn pipe down to your BFM module. Then the concrete object provides only a (non-parameterized) functional API to the transactors. This is the first time it’s really clicked for me; sweet! thanks for poking my brain.
So that only difference that leaves is where, and with what the database is populated. I believe you are letting your protocol wrapper modules self-populate the concrete class handles into the database.
uvm_config_db #( BusType_abstract_c )::set(
null , “uvm_test_top”, “BUS_API_H”, BusType_concrete_c ) ;
Using this setup, my test_base would perform a db get(), and populate a handle in an agent configuration object.
So far so good. The parameters themselves though, I don’t believe you need to use the database to deliver these to their final destination. Your same parameter package can be shared with your test, which can simply inject them into your agent’s config object (which then gets put into db).
I’m always looking for ways to skimp out of using the database for performance (not that it makes much difference for a bunch of one-shot parameters).