psedo random number generator

[krs]

hi friends,

how to write the code for psedo random number generator, i dont know
anything about it,if anyone knows it plzz answer to my question.

bye friends
ravi...

 

[Alexander Gnusin]

"krs" <ravi_krs2003@yahoo.co.in> wrote in message news:<24df3381b81263f2e989d11e57645d41@localhost.talkaboutprogramming.com>...

hi friends,

how to write the code for psedo random number generator, i dont know
anything about it,if anyone knows it plzz answer to my question.

bye friends
ravi...

Verilog has reach set of randomization functions.
Here you may find examples of using probability distribution functions (11.13.8):
http://www-ee.eng.hawaii.edu/~msmith/ASICs/HTML/Book/CH11/CH11.13.htm

However, I found that in practice these functions have limited usage.
It is easier to use basic $random function wrapped into verilog functions.

Here is an example of wrapper module with testing file:

--------------------SOF vc_random.v ---------------------------------
module vc_random ();

reg [0:31] seed;

//================================================================
// Function: returns random integer between given limits (including
// the limits)
// Inputs : low_limit, high_limit
//================================================================
function integer rn;
input d1, d2;
integer d1, d2;

begin
rn = d1 + {$random(seed)} % (d2-d1+1);
end
endfunction

//================================================================
// Function: returns random value between given limits
// Inputs : low_limit, high_limit , slope
// "slope" defines the slope of normal distribution curve
//================================================================
function integer rand;
input d1, d2, slope;
integer d1, d2, slope;
integer i,val;

begin
val = rn(d1,d2);
if (slope > 0)
for (i=0; i<slope; i=i+1) val = rn(val,d2);
else if (slope < 0)
for (i=0; i>slope; i=i-1) val = rn(d1,val);
rand = val;
end
endfunction

endmodule

--------------------EOF vc_random.v ---------------------------------


test file:

--------------------SOF test.v --------------------------------------
`include "vc_random.v"

module test ();

integer s1, s2, s3;
integer n1, n2, n3;
integer i;

vc_random rn ();

initial begin
s1 = 0; s2 = 0; s3 = 0;
rn.seed = 10;

for (i=0; i<100; i=i+1) begin // redefine slopes to see effect on mean vals
n1 = rn.rand(0,100,-1); // more low numbers
n2 = rn.rand(0,100, 0); // normal
n3 = rn.rand(0,100, 2); // more high numbers

$display("n1 = %2d n2 = %2d n3 = %2d",n1, n2, n3);

s1 = s1 + n1;
s2 = s2 + n2;
s3 = s3 + n3;
end

$display("-------------------------");
$display("s1 = %2d s2 = %2d s3 = %2d",
s1/100, s2/100, s3/100);
$finish;
end

endmodule
--------------------EOF test.v --------------------------------------


Regards,
Alexander Gnusin

 

[Sudhir D. Kadkade]

"Alexander Gnusin" <alexg@ottawa.com> wrote in message
news:a504dc86.0404060836.2fc3b0bd@posting.google.com...

Verilog has reach set of randomization functions.
Here you may find examples of using probability distribution functions
(11.13.8):
http://www-ee.eng.hawaii.edu/~msmith/ASICs/HTML/Book/CH11/CH11.13.htm
[snipped example usage of $random]
Regards,
Alexander Gnusin

I don't believe $random, and the other random functions in Verilog are
portable between simulators. If this is important, you are better off
writing a PLI based random number generator.

Regards,
Sudhir

 

[John_H]

Since others are talking about $random, I'll mention something else....

If you're trying to find "pseudo random bit sequences" or find
random-looking numbers from those sequences, do a search for PRBS or LFSR
(the Linear Feedback Shift Register) which are nearly the same thing. The
PRBS patterns are common in telecommunication testing where a flat spectral
response is desired. Xilinx has published LFSR configurations to deliver a
large range of count values, effectively providing a low-logic
implementation of a modulus counter - check their website for an APPnote.

If you have a *specific* pseudo random number generator you need, please
mention what it is. For a 2^15-1 pattern - if memory serves me right - you
just need a 15-bit shift register where you shift in the XOR of the 14th and
15th bit. As long as you initialize the registers with a value other than
0, you count through the other non-zero values in a pseudo random order for
the next 2^15-1 cycles.

"krs" <ravi_krs2003@yahoo.co.in> wrote in message
news:24df3381b81263f2e989d11e57645d41@localhost.talkaboutprogramming.com...

hi friends,

how to write the code for psedo random number generator, i dont know
anything about it,if anyone knows it plzz answer to my question.

bye friends
ravi...

 

[Alexander Gnusin]

"Sudhir D. Kadkade" <Sudhir_Kadkade@SiFR.com> wrote in message news:<g%Bcc.18070$lt2.12784@newsread1.news.pas.earthlink.net>...

I don't believe $random, and the other random functions in Verilog are
portable between simulators.

As far as I know, they are portable between all commonly-used
simulators. All of these functions are part of IEEE 1364 Verilog
standard.
However, I assume that simulators which don't support them may also
exist. It would be interesting to know if anybody has porting problems
with $random (or similar) functions.

Regards,
- Alexander

 

[Larry Doolittle]

Alexander Gnusin wrote:

"Sudhir D. Kadkade" <Sudhir_Kadkade@SiFR.com> wrote:

I don't believe $random, and the other random functions in Verilog are
portable between simulators.

As far as I know, they are portable between all commonly-used
simulators. All of these functions are part of IEEE 1364 Verilog
standard.
However, I assume that simulators which don't support them may also
exist. It would be interesting to know if anybody has porting problems
with $random (or similar) functions.

There is portable, and then there is portable.
AFAIK, the standard does not mandate the specific PRNG sequence.
Anything "pseudorandom" will do.

Within a single simulator, you can seed the PRNG with a known
value, run a simulation, get a result. Then change some of
the non-random processing code in a way that's supposed to be
equivalent, re-run the code with the same seed value, and get
exactly the same result.

That expectation vanishes when you try to use two (nominally
standards conforming) simulators, because their $random output
is not (genarlly) the same, even when given the same seed.

- Larry

 

[Swapnajit Mittra]

Larry Doolittle <ldoolitt@recycle.lbl.gov> wrote in message news:<slrnc771l1.j4r.ldoolitt@recycle.lbl.gov>...

Alexander Gnusin wrote:
"Sudhir D. Kadkade" <Sudhir_Kadkade@SiFR.com> wrote:

I don't believe $random, and the other random functions in Verilog are
portable between simulators.

As far as I know, they are portable between all commonly-used
simulators. All of these functions are part of IEEE 1364 Verilog
standard.
However, I assume that simulators which don't support them may also
exist. It would be interesting to know if anybody has porting problems
with $random (or similar) functions.

There is portable, and then there is portable.
AFAIK, the standard does not mandate the specific PRNG sequence.
Anything "pseudorandom" will do.

Within a single simulator, you can seed the PRNG with a known
value, run a simulation, get a result. Then change some of
the non-random processing code in a way that's supposed to be
equivalent, re-run the code with the same seed value, and get
exactly the same result.

That expectation vanishes when you try to use two (nominally
standards conforming) simulators, because their $random output
is not (genarlly) the same, even when given the same seed.

- Larry

Any two simulators that claim to comply with IEEE Std.1364-2001
*must* have the same $random (and other distributions) implementation.
The algorithm in C is given in the standard (pgs 314-321).

On a different topic, there are arguments how effective the given
algorithms are and how else you can generate better random numbers.
Those who are interested can read Knuth's third revision of the
PNR generator (in Vol 2 of The art of comp programming) or, as the
present trend seems to be, Pierre L'Ecuyer's great works on this.

Regards,
- Swapnajit.

--
=-=-= 100% pure Verilog PLI - go, get it ! =-=-=
Principles of Verilog PLI -By- Swapnajit Mittra
Kluwer Academic Publishers. ISBN: 0-7923-8477-6
http://www.angelfire.com/ca/verilog/

 

[Stephen Williams]

Swapnajit Mittra wrote:

Any two simulators that claim to comply with IEEE Std.1364-2001
*must* have the same $random (and other distributions) implementation.
The algorithm in C is given in the standard (pgs 314-321).

Yeahbut [oh no, the dreaded yeahbut] ...

I chose to use the Mersene twister PRNG because the IEEE1364
code is 64bit-hopeless and I couldn't be bothered to fix it, ...

Synopsys uses their own algorithm that they are not telling for
reasons of their own,

and I don't know about other simulation vendors.

So if you need to rely on the repeatable randomness of $random,
and you are specialty-clued enough to care (most EE types I've
met are not) you will need to ask your vendor about your specific
tool (some will say that they use the published $random implemen-
tation and happiness exists) or "Use the source, Luke."

Within a tool, however, I think you *can* rely on repeatability
of a given random number sequence. Between tools, I wouldn't bet
on it. (1)

Incidentally, you *can* implement your own using VPI.



(1) "It's a joke son..." he says with the best Foghorn Leghorn
imitation he can manage.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

 

[Larry Doolittle]

Swapnajit Mittra wrote:

That expectation vanishes when you try to use two (nominally
standards conforming) simulators, because their $random output
is not (generally) the same, even when given the same seed.

Any two simulators that claim to comply with IEEE Std.1364-2001
*must* have the same $random (and other distributions) implementation.
The algorithm in C is given in the standard (pgs 314-321).

Thanks for the pointer, it actually does me some good now that I
received my back-ordered-forever copy of the standard. This code
smells like a quick hack done by Cadence decades ago. Heck, it's
old enough to use K&R instead of ANSI C function declarations.
It brings up two questions:

1. Has this code been contributed to the public domain, so all
simulators can use it without restriction?

2. How can the standards committee keep a straight face publishing
such obviously non-portable code? I mean, really!

union u_s { float s; unsigned stemp; } u;
/* [chop] */
/* This relies on IEEE floating point format */
u.stemp = (u.stemp >> 9) | 0x3f800000;
c = (double) u.s;

This would get laughed out of the room on comp.lang.c.
C won't even guarantee that float and unsigned have the
same size!

- Larry

 

[Swapnajit Mittra]

Stephen Williams <spamtrap@icarus.com> wrote in message news:<621d8$40746e20$40695902$22473@msgid.meganewsservers.com>...

Swapnajit Mittra wrote:

Any two simulators that claim to comply with IEEE Std.1364-2001
*must* have the same $random (and other distributions) implementation.
The algorithm in C is given in the standard (pgs 314-321).

Yeahbut [oh no, the dreaded yeahbut] ...

I chose to use the Mersene twister PRNG because the IEEE1364
code is 64bit-hopeless and I couldn't be bothered to fix it, ...

[Some good and valid arguments/comments/jokes followed]

As I said earlier, there have been debates on the quality of
the code as well as the effectiveness of the algorithm.

That said, to state the obvious, if someone is not following
the standard for whatever reason, that simulator is not standard
compliant. My comment above was only meant for simulators
who claim to follow the standard. BTW, this is precisely the
reason why the code was included in the standard (so that
there is uniformity of implememtations).

Regards,
- Swapnajit.

--
=-=-= 100% pure Verilog PLI - go, get it ! =-=-=
Principles of Verilog PLI -By- Swapnajit Mittra
Kluwer Academic Publishers. ISBN: 0-7923-8477-6
http://www.angelfire.com/ca/verilog/

 

[Steven Sharp]

Stephen Williams <spamtrap@icarus.com> wrote in message news:<621d8$40746e20$40695902$22473@msgid.meganewsservers.com>...

I chose to use the Mersene twister PRNG because the IEEE1364
code is 64bit-hopeless and I couldn't be bothered to fix it, ...

I filed an erratum/enhancement request about the 64-bit portability
issue with the IEEE a while ago.

Frankly, it isn't that great of a random number generator, but it
*is* the standard. Cadence donated the source code for it because
that is what users wanted. It is the only way to match the golden
results for legacy designs.

Synopsys uses their own algorithm that they are not telling for
reasons of their own,

I have heard that VCS used the Verilog-XL algorithm, reverse-engineered
long before it was donated. There may be legal issues around that.

 

[Swapnajit Mittra]

Larry Doolittle <ldoolitt@recycle.lbl.gov> wrote in message news:<slrnc7asvs.mhv.ldoolitt@recycle.lbl.gov>...

Swapnajit Mittra wrote:

That expectation vanishes when you try to use two (nominally
standards conforming) simulators, because their $random output
is not (generally) the same, even when given the same seed.

Any two simulators that claim to comply with IEEE Std.1364-2001
*must* have the same $random (and other distributions) implementation.
The algorithm in C is given in the standard (pgs 314-321).

Thanks for the pointer, it actually does me some good now that I
received my back-ordered-forever copy of the standard. This code
smells like a quick hack done by Cadence decades ago. Heck, it's
old enough to use K&R instead of ANSI C function declarations.
It brings up two questions:

Larry,

I am not part of IEEE nor am I a lawyer, so do not take this as legal
advice

1. Has this code been contributed to the public domain, so all
simulators can use it without restriction?

AFAIK, donating a code to a standard amounts to releasing
it to the public domain as long as you copy it verbatim and
do it to comply with the standard. As a matter of fact, the
donation was made to ensure everybody has the same random
number generator.

2. How can the standards committee keep a straight face publishing
such obviously non-portable code? I mean, really!

union u_s { float s; unsigned stemp; } u;
/* [chop] */
/* This relies on IEEE floating point format */
u.stemp = (u.stemp >> 9) | 0x3f800000;
c = (double) u.s;

This would get laughed out of the room on comp.lang.c.
C won't even guarantee that float and unsigned have the
same size!

- Larry

I do not know the answer about straight face, but the best
way to get that answer would be to join the committee,
debate it with your peers and convince them about your point.
Unless somebody does that, this will continue to remain as
the standard.

Regards,
- Swapnajit.

--
=-=-= 100% pure Verilog PLI - go, get it ! =-=-=
Principles of Verilog PLI -By- Swapnajit Mittra
Kluwer Academic Publishers. ISBN: 0-7923-8477-6
http://www.angelfire.com/ca/verilog/

 

[Steven Sharp]

Larry Doolittle <ldoolitt@recycle.lbl.gov> wrote in message news:<slrnc7asvs.mhv.ldoolitt@recycle.lbl.gov>...

This code
smells like a quick hack done by Cadence decades ago.

It may actually have been done at Gateway, before it was acquired
by Cadence. And I have heard that it was thrown together over a
weekend. That is irrelevant to the fact that users wanted to have
the same $random as Verilog-XL, for backward compatibility.

Heck, it's
old enough to use K&R instead of ANSI C function declarations.

Of course it is. The whole point is that it is the original
$random function.

1. Has this code been contributed to the public domain, so all
simulators can use it without restriction?

I don't know the legal situation, but the purpose of putting it
into the standard was to allow all simulators to be compatible
with each other and with Verilog-XL.

2. How can the standards committee keep a straight face publishing
such obviously non-portable code? I mean, really!

union u_s { float s; unsigned stemp; } u;
/* [chop] */
/* This relies on IEEE floating point format */
u.stemp = (u.stemp >> 9) | 0x3f800000;
c = (double) u.s;

This would get laughed out of the room on comp.lang.c.
C won't even guarantee that float and unsigned have the
same size!

As the person who extracted this code to provide it to the IEEE, I
was quite embarassed by how awful it was. I actually added the
comment in your excerpt about being dependent on the floating point
format when I extracted it, as a warning to anyone using it. But
they wanted the algorithm, and we gave it to them.

If you would like to volunteer your time to rewriting this code
in a way that would be portable and still be guaranteed to give
identical results, and donate it back to the IEEE, feel free.

 

[Stephen Williams]

Larry,

Steven Sharp wrote:

As the person who extracted this code to provide it to the IEEE, I
was quite embarassed by how awful it was. I actually added the
comment in your excerpt about being dependent on the floating point
format when I extracted it, as a warning to anyone using it. But
they wanted the algorithm, and we gave it to them.

If you would like to volunteer your time to rewriting this code
in a way that would be portable and still be guaranteed to give
identical results, and donate it back to the IEEE, feel free.

Good idea!

If you do this, I'll gladly integrate it back into Icarus Verilog
implementations of $random. In fact, there are a whole host of
functions related to random distributions that are not implemented
that I think you would be able to implement. Getting the whole set
checked off would be a GOOD thing.

If we can get source for the whole suite of random distribution
functions cleaned and shaken out in Icarus Verilog, we can present
the fixed version to the IEEE1364 comittee. It sounds like if you
make then produce the same numbers as the existing functions, Steven
may be convinced to help us champion it.


The existing Mersenne Twister random number generator can be moved
to $mt_random or some such. Or can be activated by command line
switch.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

 

[David Jones]

In article <4076EBE2.1080301@icarus.com>,
Stephen Williams <spamtrap@icarus.com> wrote:

The existing Mersenne Twister random number generator can be moved
to $mt_random or some such. Or can be activated by command line
switch.

The problem with the Mersenne Twister is that it is GPL, and therefore
incompatible with many simulation environments.

I am aware of at least one commercial concern, that at one time, was in
violation of the GPL on this issue.

 

[glen herrmannsfeldt]

Steven Sharp wrote:

(snip)

2. How can the standards committee keep a straight face publishing
such obviously non-portable code? I mean, really!

union u_s { float s; unsigned stemp; } u;
/* [chop] */
/* This relies on IEEE floating point format */
u.stemp = (u.stemp >> 9) | 0x3f800000;
c = (double) u.s;

This would get laughed out of the room on comp.lang.c.
C won't even guarantee that float and unsigned have the
same size!

It also assumes that they byte order for unsigned and float
are the same, and probably that unsigned has (at least)
32 bits. Do you then subtract the float value with
the hex representation 0x3f800000?

How about? (u.stemp >> 9 ) / 8388608e0;

-- glen