Subject: RE: $sv-ec Proposal for Random Constraints for SV-extension
From: Mehdi Mohtashemi (Mehdi.Mohtashemi@synopsys.com)
Date: Wed Nov 20 2002 - 16:59:23 PST
Hi Adam,
Here is my response to your questions, hope it helps clarify the points.
1. rand and randc:
The description of unique that you give is very close to what randc does, with two
exceptions, a randc variable is not only unique, but it is also random. That is, using
your description, a randc variable IS a random variable (i.e., rand) and it is also
unique (rand unique). The type randc can be thought of as a short-hand for rand unique.
The other main difference is that a randc variable, like all rand variables, can be part
of other constraints.
Now, the 'stepping' and 'sequence' functions or operators that you mention may be a
good procedural enhancement to the randomly step through a sequence.
There may be other functions that are useful in a procedural context, such as
walking_1, etc. However, randc is a declarative way to accomplish a similar thing
when randomize() is called, as discussed above. Note that randomize() function call
will consider all randc variables and solve them in one sweep.
2 Section 19, Random functions.
The $urandom() function in the SystemVerilog proposal does accept an optional seed,
which is exactly the same as $random in Verilog. If the seed is not specified, $urandom
will generate a random number without re-seeding the number generator. The biggest
difference between $random and $urandom is that $urandom is thread stable, that is,
each thread contains its own $urandom number generator while $random is global (there
is only one $random number generator in the entire system). Thus, passing a seed to
$urandom will re-seed that particular thread and affect all of its children, while passing a
seed to $random will affect all numbers generated by $random in any thread.
As for re-seeding a simulation run, it is sufficient to call $srandom once at the start of the
program. That call will affect all other random numbers generated by $urandom,
randomize, etc...
Please note that $srandom allows users to re-seed the simulation and reproduce the
same stream of random numbers even under certain changes to the test code.
Regards,
- Mehdi Mohtashemi
mehdi@synopsys.com
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of Adam
Krolnik
Sent: Wednesday, November 20, 2002 9:09 AM
To: Mehdi Mohtashemi
Cc: sv-ec@eda.org
Subject: Re: $sv-ec Proposal for Random Constraints for SV-extension
Good morning Mehdi;
I have a few questions for you about the proposal.
1. Rand vs randc type modifiers.
I have referred to the 'randc' functionality as 'unique'. Maybe this would be
an easier to explain. The functionality is the same. Choose a number uniquely,
do not reselect a number until all numbers have been chosen. Then start over.
So you have random, and unique selection methods. Why do you not include these
models as functional operations.
stepping (through a list of elements.)
sequence (initial value, expression to compute new value each time called.)
These are useful with setting up things in a declarative fashion (similar to
the random value setup.)
Section 19. Random functions.
I am somewhat confused on how the random functions work. The current verilog model
requires one to use $random() and pass in a seed with each call to obtain values
derived from that random stream. If one uses another seed value, a different
stream is created. Is this the same model for these functions? Or do they
use the seed from the current thread/object unless specified otherwise.
Why does $urandom() accept a seed value? You may have answered this above.
If one wanted to seed a given run by passing in a value so that each simulation
would be different if the seed is different, what would one have to do
so that each user of random numbers would have a base of this seed? Would only
one $srandom() call be sufficient? Or would each object/thread have to do this?
Thanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 17:01:36 PST