[sv-ec] RE: 0003139: Need to document which API calls affect random stability

Hi Tom,

I'm going to assume that a UVM user only cares about thread stability as no UVM API call should be changing the seed of the current object (except reseed() perhaps).

From Section 18.14, the constructs that will change the RNG seed of the current thread are:

fork
object construction
$urandom/_range
process.srandom()
process.set_randstate()

Dave
Mentor Graphics

From: vip-tc@lists.accellera.org [mailto:vip-tc@lists.accellera.org] On Behalf Of Alsop, Thomas R
Sent: Wednesday, August 07, 2013 11:18 AM
To: sv-ec@eda.org
Cc: vip-tc@lists.accellera.org
Subject: [vip-tc] 0003139: Need to document which API calls affect random stability

Hi sv-ec team,

The UVM committee is trying to document the cases where API's either protect or do not protect against random instability.  In order to do this we need a list of constructs that will change the value of the random state.   The mantis ticket on this is 3139.  In our discussions today, we noted that object construction and forking of processes will impact rand state.  Are there other cases that you know of that we need to look at?

Thanks, -Tom


http://www.eda.org/svdb/view.php?id=3139

The Reference Manual needs to document which methods affect random stability so that the user can take the necessary steps to ensure random stability where they need it.

For example, since set_config_* constructs a configuration object, is uses up a RNG for the current thread. For the user to code around that, the need to do something like

process p;
string s;
      p = process::self();
      s = p.get_randstate();
      set_config_int(...);
      p.set_randstate(s);

If the standard say that an API method does not affect random stability, then the implementer will have to do something similar inside the method to insure that guarantee.

Dave

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.