rand function in Modelsim 5.7c

[Niko D. Barli]

Hi,

I am trying to use VHDL's RAND function in my test benches.
In Synopsys VCS the function is defined in IEEE.math_real.
However, I couldn't find it in Modelsim 5.7c. Is the function
defined in other package ? Or, is it because Modelsim doesn't
support random generation ?

Best regards,

 

[Jonathan Bromley]

I am trying to use VHDL's RAND function in my test benches.
In Synopsys VCS the function is defined in IEEE.math_real.
However, I couldn't find it in Modelsim 5.7c. Is the function
defined in other package ? Or, is it because Modelsim doesn't
support random generation ?

No, it's because there is no RAND function in the standard
IEEE.math_real package. I guess it was invented by
Synopsys for users' convenience.

The standard random generator in IEEE.math_real is the
UNIFORM procedure. To use it you must provide two
variables of type POSITIVE (note: variables, NOT signals)
to hold the seed values for the generator. You also
provide a REAL variable to hold the random result.
Then, whenever you want a random number, you invoke

UNIFORM(seed1, seed2, rand);

and in "rand" you get a REAL value in the range
0.0 to not-quite 1.0. You can then massage this value
in any way that takes your fancy to get the random
distribution you require. You could probably
use this to re-implement the Synopsys RAND function,
but that gets us into the unhappy land of IMPURE
functions and shared variables...
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

No, it's because there is no RAND function in the standard
IEEE.math_real package. I guess it was invented by
Synopsys for users' convenience.

Here's a math_real compatible source to look at:
http://tech-www.informatik.uni-hamburg.de/vhdl/packages/P1076.2/mathpack.vhd

-- Mike Treseler

 

[Kai Harrekilde-Petersen]

Here's a math_real compatible source to look at:
http://tech-www.informatik.uni-hamburg.de/vhdl/packages/P1076.2/mathpack.vhd

You should always, I repeat, *ALWAYS* implement your own random number
generator functions.

Why? Because then you are able to control which exact random sequence
across platform, OS, libc, tools, date, time, phase of the moon, etc.
Part of this is to remember to ensure that the order that you pick
elements out of a hash (in Perl) are the same every time.

Having the pattern generator run at 23:50 and the pattern checker at
00:05 (because the simulation took 15 minutes) and therefore having
the check fail because you just relied on the output of the date for
the two separate commands is another nice gotcha.

We don't _want_ true randomness. We want something this >< close to
real randomness, but which we can reproduce at our whim, regardless of
where and when we encountered the problem originally.


Kai

 

[Kai Harrekilde-Petersen]

Here's a math_real compatible source to look at:
http://tech-www.informatik.uni-hamburg.de/vhdl/packages/P1076.2/mathpack.vhd

You should always, I repeat, *ALWAYS* implement your own random number
generator functions.

Why? Because then you are able to control which exact random sequence
across platform, OS, libc, tools, date, time, phase of the moon, etc.
Part of this is to remember to ensure that the order that you pick
elements out of a hash (in Perl) are the same every time.

Having the pattern generator run at 23:50 and the pattern checker at
00:05 (because the simulation took 15 minutes) and therefore having
the check fail because you just relied on the output of the date for
the two separate commands is another nice gotcha.

We don't _want_ true randomness. We want something this >< close to
real randomness, but which we can reproduce at our whim, regardless of
where and when we encountered the problem originally.


Kai

 

[Kai Harrekilde-Petersen]

Here's a math_real compatible source to look at:
http://tech-www.informatik.uni-hamburg.de/vhdl/packages/P1076.2/mathpack.vhd

You should always, I repeat, *ALWAYS* implement your own random number
generator functions.

Why? Because then you are able to control which exact random sequence
across platform, OS, libc, tools, date, time, phase of the moon, etc.
Part of this is to remember to ensure that the order that you pick
elements out of a hash (in Perl) are the same every time.

Having the pattern generator run at 23:50 and the pattern checker at
00:05 (because the simulation took 15 minutes) and therefore having
the check fail because you just relied on the output of the date for
the two separate commands is another nice gotcha.

We don't _want_ true randomness. We want something this >< close to
real randomness, but which we can reproduce at our whim, regardless of
where and when we encountered the problem originally.


Kai

 

[Jonathan Bromley]

You should always, I repeat, *ALWAYS* implement your own random number
generator functions.

Why? Because then you are able to control which exact random sequence
across platform, OS, libc, tools, date, time, phase of the moon, etc.
Part of this is to remember to ensure that the order that you pick
elements out of a hash (in Perl) are the same every time.

Kai,
even though you posted this three times, it's still wrong
The whole point of UNIFORM in math_real is that it's
deterministic. It's an integer algorithm and so should be
portable. The pseudo-random sequence is entirely defined by the
initial values you set in the two seed variables (they default
to 1, because they are of type POSITIVE - but you can control it).
Because the seeds are variables, they are local to a process;
any other process using UNIFORM has its own seeds - therefore,
the pseudo-random sequence is immune to the nondeterminism of
process execution order. The only nondeterminism occurs when
you process the REAL result into a weighted distribution of
some discrete type, which will be system-dependent no matter
what you do; but it is emphatically *not* affected by
astrology.

And the random behaviour of UNIFORM has a better pedigree than
anything I could come up with myself - I can't speak for your
mathematical skills, of course.

As far as picking elements out of a Perl hash is concerned,
well, anyone who depends on Perl's hashing algorithm to
get consistent behaviour is asking for trouble
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:[email protected]
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[David Bishop]

You will find the actual source code for the math_real
packages at this URL
http://www.eda.org/vhdl-200x/vhdl-200x-ft/packages/files.html
These can be posted because they are currently up for revision.

If you take a look at the "test_fixed" testbench you will see
an example of how to use the "uniform" function to generate
random numbers.

 

[Kai Harrekilde-Petersen]

Kai,
even though you posted this three times, it's still wrong

Yeah, sorry about that - the triple-post was due to an oscillation
between an operator-error and a software-unfeature. I tried to cancel
the first two posts, but did not succeed.

The whole point of UNIFORM in math_real is that it's
deterministic. It's an integer algorithm and so should be
portable.

And you can repeat the same sequence in both VHDL, Tcl, and Perl?

I mark myself your usage of the word _should_

The pseudo-random sequence is entirely defined
[snippage]

The only nondeterminism occurs when
you process the REAL result into a weighted distribution of
some discrete type, which will be system-dependent no matter
what you do;

In that case, I say: If you want it to be repeatable, stay away from
REAL.

My "phase of the moon" comment was intended as a joke - I'll add some
markup to identify humorous inserts for the humor impaired next time
;-)

And the random behaviour of UNIFORM has a better pedigree than
anything I could come up with myself - I can't speak for your
mathematical skills, of course.

Well, my skills are well enough to get myself into - and out of -
trouble with RNGs thank you.

Actually, it's not ones math skills that matters here. It's an
understanding of what RNGs are and what they aren't, and taking the
point that you should always test the RNG you use against the scenario
you use it in. Knuth and Numerical Recipes [in C] will yield a bunch
of high-quality RNGs, and also teach you why you need to test them.

Being bitten by the RNG in real life will sharpen your paranoia and
cynicism about Other People's RNGs.

I've seen performance models yield incorrect (skewed) results simply
because the RNG that was used was not up to snuff. Sure, it was OK,
but not for the particular job it was supposed to do in the model.

I've also seen an RNG go through a two year process before it passed
the backoff algorithm test at UNH. Actually, it didn't pass: it
didn't fail. According to the guy at UNH we talked to, it was only
the second backoff algorithm they've tested that they couldn't get to
fail their battery of tests.

As far as picking elements out of a Perl hash is concerned,
well, anyone who depends on Perl's hashing algorithm to
get consistent behaviour is asking for trouble

That's right. But most programmers (even very bright and clever ones
that I know) will do that without second thought until someone points
out the problem to them. Or, preferably, they've spent two or three
days debugging a cross-platform inconsistency error. Unfortunately, I
was the one who had to sort it out for them.

My mission was merely to point this out to everyone.

Regards,


Kai

 

[Niko D. Barli]

Hi guys,

Thank you very much for your response.
I think I will use the math_real's uniform function for
my test benches.

# By the way, there is also a problem with the uniform function.
# I cannot find it in math_real package in Synopsys VCS !!
# Building your own random generator probable the best ultimate
# approach ...

Thank you again and regards,