Reason for putting virtual interfaces and is_active in agent config objects?

Many of the UVM guidelines recommend putting virtual interface handles in an agent’s configuration object. I’ve done this many times, it works fine. I’ve also made many very simple agents that have zero configuration. In the case of those agents, inventing a config object solely for containing the virtual interface handle, is extra code for seemingly no benefit.

Also, despite the uvm_agent already having an is_active variable, many guidelines also recommend replacing it with an is_active in the config class.

So I’ve played around with these in my agents. I’ve made agents that put the vif and is_active in the config class. I’ve made agents without config classes at all, they get the vif directly and use the built-in is_active. I’ve made agents that directly get the vif, use the built-in is_active, and also use a config class to contain other config variables.

Despite the usage differences, I’ve never encountered any limitations with any of these approaches. So I presume the recommendations are really just for creating uniform agents? Or does someone have a usage example, where putting vif and/or is_active in the config class actually enabled something that would otherwise not be possible, or at least much more difficult?

In reply to warnerrs:

Putting everyting inside a configuration object requires only one config_db set() and get(), This is at least a 50% reduction of the number of set() and get() calls,

Also, as you mentioned, uniform agents can go a long way in saving time as you don’t have to remember which agent uses which method.