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.

5

Hi @cgales,

I was trying a generic way of setting the agent in specific mode ( irrespective of the UVM version 1.1 / 1.1d /1.2 being used )

Here is my attempt:: edalink

As per UVM 1.2 source code my expectation was that uvm_config_db#(uvm_active_passive_enum)::set takes precedence ( due to the break statement on line 76 ) over any other setting

However for +VALUE=4 / +VALUE=5 I observe that uvm_config_db#(uvm_bitstream_t)::set takes precedence over uvm_config_db#(uvm_active_passive_enum)::set

My guess is that it comes down to following code

uvm_resource_pool::sort_by_precedence(rq);          // What does this do ?
for (int i = 0; i < rq.size(); i++) begin 
  uvm_resource_base rsrc = rq.get(i);
  uvm_resource#(uvm_active_passive_enum) rap;

  if ($cast(rap, rsrc)) begin
     is_active = rap.read(this);
     break;                                        // Line 76
  end
  else begin

Any suggestions ?

Thanks

6

I am not sure what problem you are trying to solve.

The recommendation is to make active/passive part of your agent’s configuration object and configure it as required along with the rest of your agent configuration (virtual interface handle, behavior, etc.) in your test. Then pass the entire configuration object to your agent using the config_db. Is there a reason you don’t want to follow this recommendation?