Monitor / driver bus functional model (BFM)

UVM
14

You can certainly import the test package, and the env can assign the values to each agent instance without going through the config DB. Probably would look something like


class my_env extends uvm_env;
    :
    my_agent m_agent1;
    my_agent m_agent2;
    :
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);

        m_agent1.dataw = BUS1_DATAW;
        m_agent2.dataw = BUS2_DATAW;
        :
    endfunction : build_phase
    :
endclass : my_env

With the config DB, you can encapsulate the agent/bus configuration in an object. Passing it through the config DB only involves passing the object handle, so I think that any performance impact is very negligible. The object can also have methods to provide an API to the agent for using the param values to configure itself, separating intimate knowledge of the parameter set at the bus interface from the configuration knobs of the agent. I believe this sort of approach can offer greater flexibility, scalability, and resuability.

Not saying one way is more correct than the either. It all depends on the user’s particular needs. I personally lean more towards object-oriented methods.