Configuring agent in Active / Passive mode

UVM
, , ,
1

Hi Forum,

I have a few questions on configuring agent component to active / passive mode

(1) UVM LRM says

“The default implementation shall return UVM_PASSIVE, unless overridden via the configuration database.“

I went through the source code for UVM where within the virtual class uvm_agent

I observe uvm_active_passive_enum is_active = UVM_ACTIVE;

Hence by default every agent is in active mode

(Q1) Doesn’t this conflict with the above LRM quote ?

(2) I observe that build_phase() of the virtual class uvm_agent has a logic to retrieve configuration for the enum variable is_active ( Refer source_code )

Assume that there are multiple set from same level of hierarchy during build_phase() ,

(Q2) Wouldn’t the multiple if conditions within the for loop result in an implicit precedence ?

The 1st if condition looks for setting via type uvm_active_passive_enum followed by type uvm_integral_t , followed by uvm_bitstream_t, followed by int,followed by int unsigned and then finally of type string

Assume there are 6 calls to set from same level of hierarchy (one of each of the 6 types above)

(Q3) Would the set via type uvm_active_passive_enum take effect over the other 5 types ?

(Q4) From a simulation performance perspective, wouldn’t it be better not to call super.build_phase(phase) from user’s agent class ? There could be multiple agent’s in a Tb and each agent would iterate through the logic

User should have their own logic to fetch any configuration object for is_active

This would ensure that the set needs to be a certain type to take effect

Thanks

2

Which version documentation are you referring to? The latest IEEE UVM standard (1800.2-2020) states:

The default implementation shall return UVM_ACTIVE, unless overridden via the configuration database. An agent developer may override this behavior if a more complex algorithm is needed to determine the active/passive nature of the agent.

As for using the build_phase(), my guess is that the code is trying to accept several different ways that users may try to configure this value. Since it is a binary value, there could be several possible ways to configure this field.

The best approach is to add this field to your agent’s configuration object. You can then do a single config_db read to get all the required configuration data for your agent.

3

I am referring to IEEE Std 1800.2-2017

image
image1820×777 86.9 KB

Using this approach shouldn’t the call to super.build_phase be discouraged in user’s agent class ?

Although the logic in uvm_agent::build_phase() executes in 0-time, would there really be significant performance benefits without the call to super.build_phase() ? ( assuming the number of agent components is in triple digits )

4

The latest LRM has been updated to reflect the current implementation.

I wouldn’t expect a significant impact by calling super.build_phase(), but you could try an experiment and see if there is a difference in your environment.