Seed for UVM_SEQUENCE_ITEM

UVM
, , ,
1

Hi All,

Usually during verification, if we want to generate some scenario then we will use seed seen in log file,like that is it possible that whenever i do randomization for sequence_item,i will get seed/provide seed,so whenever i want can use again.

Thank you in Advance !!!

2

In reply to Hardik:

You usually specify a global seed when starting the simulator. I don’t see any scenario where it would be useful to manipulate the seed on a per call to randomize basis. Not only this, but if done incorrectly it can really impact random stability.

3

In reply to Tudor Timi:

Yes,I agree that if done incorrectly it can really impact random stability.

And about scenario,in our protocol i need to re-transmit same transaction in some specific condition and in order to do that right now i will store all transaction and on top that i have some logic,which will say that which one need to re-transmit.

So now i don’t want to store using queue or by any other mean just because i have more then 10,000 transactions.

4

What you can do is get the randstate of the process from where you call randomize() on the transaction and store that. Whenever you need to re-generate this transaction you spawn a new process and set its randstate to the one you saved:


task some_task(); 
  string rand_state; 
  process p = process::self(); 
  rand_state = p.get_randstate(); 
  
  // here you would call your first randomize() ...
  // you would save rand_state instead of the randomized transaction
endtask


// this task regenerates a trans based on the rand_state
// - not sure if it has to be a task or a function with a
//   return value would do
task regen(transaction trans, string rand_state);
  process p = process::self();
  p.set_randstate(rand_state); 
  trans.randomize(); // should yield the same result as the first time
endtask


// somewhere else
// fork it off to have a new process
fork
  regen(trans, rand_state)
join

This code is just off the top of my head. You need to figure out the exact details. I’m not sure how this would affect random stability, but I’m guessing if you fork a new process when you want to re-generate you should be fine.

5

In reply to Hardik:

I think I get what you mean, you want to store the state of the random number generator so you can just regenerate the transaction based on that. Pretty cool idea for a compression scheme :D

6

In reply to Tudor Timi:

Thanks … it’s working… :D