Random stability issue with `uvm_info and changing verbosity

[bughound]

I've encountered a rather nasty issue with the UVM 1.2 BCL where changing the `uvm_info verbosity from UVM_NONE to UVM_LOW for the same random seed yields different simulation results.

 

Mantis bug logged here:

https://accellera.mantishub.com/view.php?id=5482

 

This is not good practice, BUT - It is possible for the random stability to be affected, for example, if within the `uvm_info macro, a function is called that allocates a new object or randomizes, thus altering the RNG.

 

Example:

 

`uvm_info("SOME_ID", $psprintf("Some number is: %0d", get_some_number()), UVM_LOW)

 

function int get_some_number();

  some_object obj = new();

  get_some_number = $urandom;

endfunction

 

I understand that some effort has been put in to revamping the message reporting mechanism from 1.1 to 1.2, as well as improving the random stability with the insertion of get/set_randstate guards.

 

If this is something that is completely unavoidable in UVM, then it might be a good idea to add this to the UVM User Guide as an example of bad coding.

 

 

 

[dave_59]

You really have to understand the random stability issue when you write any SystemVerilog code, this includes the people writing the UVM BCL. And UVM has its own seeding mechanism that is on top of the SystemVerilog mechansim, which makes it even mmore complicated.

 

The person that wrote get_some_number() has to provide assurance to the person writing  code that calls get_some_number() that it will or will not disturb the RNG. Perhaps we need a methodology similar to Manual object Clone on write (MoCow); leave it up to the routine that disturbs the RNG to decide if they need to preserve it.

 

Note that there has to be a careful balance between random stability and random diversity. If for some absurd reason you do need to call $urandom inside get_some_number, then preserving the RNG won't work because you could have multiple `uvm_info calls and you would want each $urandom call to produce a different random number.

[cristian_amiq]

Speaking of random stability, there are a few random stability issues in UVM, for example look for SVTB.15.7.1.rootCause - Do not use new() without get_randstate() or SVTB.15.7.2.rootCause - Do not use fork without get_randstate() here: http://dvteclipse.com/uvm-verissimo/UVM_1_2_RELEASE/index.html

 

The rules above are some Verissimo SystemVerilog Testbench Linter rules that check random stability, and the link above is one of the HTML reports from Verissimo continuous runs (every 6 hours) on various UVM branches. All branches are here: http://dvteclipse.com/uvm-verissimo/index.html

[bughound]

This turned out to be a simulator bug with random stability (see the bug report in the URL above).