In UVM 1.2, base/uvm_resource.svh file, class uvm_resource_pool function lookup_name(), I’m seeing the code snippet shown below:
// ensure rand stability during lookup
begin
process p = process::self();
string s;
if(p!=null) s=p.get_randstate();
q=new();
if(p!=null) p.set_randstate(s);
end
First of all I don’t understand why rand stability is a concern here. Between get_randstate/set_randstate pair, there is only a new of uvm_resource_types::rsrc_q_t, which is nothing but a uvm_queue (and systemverilog queue eventually). There is nothing random. Why we need to take care of rand stability? At a similar place in lookup_type function (again newing rsrc_q_t variable), there is no get_randstate/set_randstate pair. Why it is a concern in lookup_name but not a concern in lookup_type?
I feel this get/set_randstate pair in lookup_name is just arbitrarily added without a good reason. Am I correct?
Constructing any class object requires seeding it, even if the class doesn’t contain any random variables. You can still call the randomize() method on that object. Every time you seed an object (or a new process) that selects a number from the random number generator (RNG) in a sequential manner, the get_randstate/set_randstate() pair ensures that the uvm_resource/config_db does not interfere with the random seeding sequence of numbers.
To determine exactly where randstate saving is necessary, especially in the presence of conditional branching, you would need to meticulously follow the flow of the code. I know that the UVM had a number of places that didn’t catch this. UVM 1.2 corrected some, and the UVM 1800.2 corrected a few more.
So issue being seen before so uvm decided to add get_randstate/set_randstate around that new function in lookup_name()? No issue with the new in lookup_type(), so no get_randstate/set_randstate pair added? To be safe, would it be better to add this pair for all constructors or it is too expensive?