Jump to content
Sign in to follow this  
bughound

Random stability issue with `uvm_info and changing verbosity

Recommended Posts

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.

 

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...