In reply to robert.liu:
After going through the LRM “random stability” section one can easily has this big picture: every thread and object(class instance) has its own local RNG. During some operations like executing $urandom in a thread or calling randomize on an object, the current state of RNG will be sampled and used for that specific operation and RNG will switch to its next state after the operation is completed. This understanding should be enough in most cases to write a constraint random test framework.
My question is that, the LRM is unclear on the RNG update method. We don’t know on what the simulator depends to update the RNG. This causes some confusing in the following code:
…
var_a = $urandom_range( value_1, value_2 );
program register with value of var_a;
…
obj = new;
obj.randomize();
send out the obj to uvm driver
…
We run this code snippet twice. All remains the same except the value of value_1, value_2. And we need to have the same result of obj.randomize.
Here we can have two possibilities:
- Simulator implementation just update the RNG based on the current RNG state only, the obj randomization would generate the same result sine the obj RNG is the same.
- Simulator implementation references some information of $urandom_range randomization to generate next state of the RNG, the obj would have different value.
Other than using save/restore randstate around the $urandom_range call, is there any other good idea regarding maintaining the random stability?
What about using std::randomize(var_a) with {var_a inside {[var_1:var_2}} I don’t remember exactly but there’s a paper about random stability suggesting using this instead of $random and $urandom_range
HTH,
-R