Basically, if there's anything that I need/want to do at simulation time-zero and UVM time-zero, then extending the uvm_top class would allow for that.
This actually came up when I was trying to register a global report-server. Because I cannot extend uvm_root and I cannot guarantee instantiation order of global variables, then some messages were reported by UVM classes and a 3rd party VIP class instance prior to my report-server registration. My post processing scripts will miss that because they expect a specific formatting.
Even though this was for the global report-server, I think it stands for any functionality requiring UVM time-zero to execute. In my environment, I created an extensible proj_root class globally instantiated:
`define PROJ_ROOT_CLASS proj_root
class proj_root; ... endclass
const `PROJ_ROOT_CLASS proj_top = `PROJ_ROOT_CLASS::get();
I can extend proj_root to a new class that handles some time-zero activity know that it will be instantiated by redefining PROJ_ROOT_CLASS macro.
It seems like UVM could do something similar while guaranteeing uvm_top purity (to some extent) by just using the macro at the function call:
const uvm_root uvm_top = `UVM_ROOT_CLASS::get();
This would mean that the const variable itself would still be const at uvm_root scoping, but now I get to synchronize my time-zero activities with UVM time-zero.
I suppose the alternative would be to add hooks (do_local_configure?) in uvm_root to allow UVM time-zero activity, but I think class extension would be more general-case.
Sorry for the very long explication delay.