EDK : FSL macros defined by Xilinx are wrong

[Jonathan Bromley]

On Fri, 25 Jan 2008 10:40:11 -0800,
Dwayne Dilbeck wrote:

I usually use a maximal LFSR to obtain psuedo random numbers.

The following link will give you some good information.
www.xilinx.com/ipcenter/catalog/logicore/docs/lfsr.pdf

I like Appendix B wich lists the tap points up to 168bits for a maximal
length LFSR.

The following would generate psudeo random 64 bit numbers starting with seed
value 1.

entity generator is
port (
clk:in bit;
aut bit_vector(63 downto 0));
end;


achitecture processflow of generator is
begin
CLKEDrocess
variable temp:bit_vector(63 downto 0) :=
X"0000_0000_0000_0001";
begin
temp := temp(63 downto 0 ) & (temp(63) xor temp(62) );
a <= temp;
wait until (clk = '0');
end process
end

aaargh.... note that this gives you one pseudo-random BIT per
clock cycle.... but the 64-bit words are painfully strongly
correlated from one cycle to the next. You need to clock
your N-bit LFSR for at least N cycles before pulling the
next N-bit value from it.

Even then, the random numbers aren't brilliantly random
(or at least that's what I am led to understand - I don't
have a particularly good grip on the somewhat scary math)
but LFSRs are indeed a good source of quasi-random stuff
for non-critical applications. Just remember to clock
them enough times!
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[glen herrmannsfeldt]

Jonathan Bromley wrote:

On Fri, 25 Jan 2008 10:40:11 -0800,
Dwayne Dilbeck wrote:

I usually use a maximal LFSR to obtain psuedo random numbers.

The following link will give you some good information.
www.xilinx.com/ipcenter/catalog/logicore/docs/lfsr.pdf

I like Appendix B wich lists the tap points up to 168bits for a maximal
length LFSR.

The following would generate psudeo random 64 bit numbers starting with seed
value 1.

entity generator is
port (
clk:in bit;
aut bit_vector(63 downto 0));
end;

achitecture processflow of generator is
begin
CLKEDrocess
variable temp:bit_vector(63 downto 0) :=
X"0000_0000_0000_0001";
begin
temp := temp(63 downto 0 ) & (temp(63) xor temp(62) );
a <= temp;
wait until (clk = '0');
end process
end

aaargh.... note that this gives you one pseudo-random BIT per
clock cycle.... but the 64-bit words are painfully strongly
correlated from one cycle to the next. You need to clock
your N-bit LFSR for at least N cycles before pulling the
next N-bit value from it.

It doesn't look like a very good one, either. You want
one based on a primitive polynomial

http://en.wikipedia.org/wiki/Primitive_polynomial

which is sort of related to a prime number. There is a good
explanation in "Numerical Recipes" including some primitive
polynomials. The CRC32 polynomial has been well studied,
and should have pretty good properties. For 64 bits you could
use multiple LFSR of different lengths and generate a new value
in much less than 64 cycles.

-- glen

Even then, the random numbers aren't brilliantly random
(or at least that's what I am led to understand - I don't
have a particularly good grip on the somewhat scary math)
but LFSRs are indeed a good source of quasi-random stuff
for non-critical applications. Just remember to clock
them enough times!

 

[FPGA]

On Jan 25, 4:51 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

Jonathan Bromley wrote:
On Fri, 25 Jan 2008 10:40:11 -0800,
Dwayne Dilbeck wrote:
I usually use a maximal LFSR to obtain psuedo random numbers.
The following link will give you some good information.
www.xilinx.com/ipcenter/catalog/logicore/docs/lfsr.pdf
I like Appendix B wich lists the tap points up to 168bits for a maximal
length LFSR.
The following would generate psudeo random 64 bit numbers starting with seed
value 1.
entity generator is
port (
   clk:in bit;
   aut bit_vector(63 downto 0));
end;
achitecture processflow of generator is
begin
  CLKEDrocess
           variable temp:bit_vector(63 downto 0) :> >>X"0000_0000_0000_0001";
  begin
               temp := temp(63 downto 0 )  & (temp(63) xor temp(62) );
              a <= temp;
              wait until (clk = '0');
   end process
end
aaargh.... note that this gives you one pseudo-random BIT per
clock cycle.... but the 64-bit words are painfully strongly
correlated from one cycle to the next.  You need to clock
your N-bit LFSR for at least N cycles before pulling the
next N-bit value from it.

It doesn't look like a very good one, either.  You want
one based on a primitive polynomial

http://en.wikipedia.org/wiki/Primitive_polynomial

which is sort of related to a prime number.  There is a good
explanation in "Numerical Recipes" including some primitive
polynomials.  The CRC32 polynomial has been well studied,
and should have pretty good properties.  For 64 bits you could
use multiple LFSR of different lengths and generate a new value
in much less than 64 cycles.

-- glen



Even then, the random numbers aren't brilliantly random
(or at least that's what I am led to understand - I don't
have a particularly good grip on the somewhat scary math)
but LFSRs are indeed a good source of quasi-random stuff
for non-critical applications.  Just remember to clock
them enough times!- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

I am very thankful to everyone for their feedback. I am a beginner in
this field and this forum has helped me a long way. I am thankful to
everyone who put in their valuable time to advise others. I appreciate
it.

 

[Jonathan Bromley]

On Tue, 29 Jan 2008 02:23:35 -0800 (PST),
Tricky <Trickyhead@gmail.com> wrote:

I created this function specifically for testbenches:

--min and max can be swapped quite happily
procedure rand_int( variable seed1, seed2 : inout positive;
min, max : in integer;
result : out integer) is
variable rand : real;
begin
uniform(seed1, seed2, rand);
result := integer(real(min) + (rand * (real(max)-real(min)) ) );
end procedure;

Ahem... if you'd read my correction to my own post, you
might have spotted that this is in fact wrong...
Your function's probability of getting exactly "max"
or "min" is only half the probability of getting any
other values in the range. To see why, consider this:

max = 3, min = 0
So real(max) - real(min) = 3.0
and rand is in the range 0.0 ... 1.0 (not quite 1.0)
so rand*(real(max)-real(min)) is in range 0.0 ... 3.0

The conversion integer(some_real) rounds to the nearest whole
number, so...

0.0 .... 0.5 rounds to 0
0.5 .... 1.5 rounds to 1
1.5 .... 2.5 rounds to 2
2.5 .... 3.0 rounds to 3

Clearly the integers 0 and 3 have only a "width" of 0.5,
whereas all the other values have a "width" of 1.0 and
thus the edge values have only half the probability.

My solution yields a uniform integer distribution.
Note also that I used "floor()" from math_real to
be sure that there's no risk of getting (max+1).

Getting these probability distribution things just
right is often quite a bit of work. That's why I
and many others are unimpressed with the argument
that "VHDL random generation is just as good as
SystemVerilog's constraint solver because you can
write whatever you need in VHDL". The better
solution to this problem, surely, is...

rand int N;
constraint N_uniform { N inside {[min:max]}; }

or whatever is the right syntax in your chosen
testbench automation language. Traditional
procedural languages just don't cut it for
smart randomization.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[vhdlguy@gmail.com]

On 2007łâ12żů13ŔĎ, żŔŔü12˝Ă46şĐ, "koce" <bojan_1....@yahoo.com> wrote:

Can U, please, send me a byteblasterII schematic file if U have it.
Thank U!
Bojan

--
Message posted usinghttp://www.talkaboutelectronicequipment.com/group/comp..arch.fpga/
More information athttp://www.talkaboutelectronicequipment.com/faq.html

Hello
You can get very low cost ByteBlaster II at http://fpgaguy.110mb.com
It is only $36.95. You do not need to make byteblaster II.
Save your time and money.

 

[RCIngham]

Have you got access to a simulator? Why not try it with a few obvious
cases?

I have defined two functions as below

function complexMult (a_i,a_q,b_i,b_q: signed) return complex is
variable a,b : complex;
variable result : complex;
begin
assert a_i = a_q report "Error : complexMult - a_i and a_q are not
of equal length."
severity error;

assert b_i = b_q report "Error : complexMult - a_i and a_q are not
of equal length."
severity error;

a.i := a_i;
a.q := a_q;
a.max := a_i'length;
b.i := b_i;
b.q := b_q;
b.max := b_i'length;
result := complexMult(a,b);
return result;
end function complexMult;

function complexMult (a,b: complex) return complex is
variable result : complex;
begin
result.max := maxVal(a.max,b.max) + 1;
result.i := ((a.i * b.i) - (a.q * b.q));
result.q := ((a.i * b.q) + (b.i * a.q));
return result;
end function complexMult;

I am not sure if i can use the same record type for result and inputs
a and b. Note that a and b can be of different lengths. Output
"result" is going to be max(a'length, b'length) + 1 .. I add a one for
the overflow and underflow that can be generated from the addition and
subtraction.

In the simulation , for eg : if a'length = 10 and b'length =5 then I
want result'length = 11. I am trying to do this by not declaring
different record types for input and outputs. Can i do this? If so,
should the testbench be described as follows

a.max <= 10;
a.i <= ".. 10 bits ...";
a.q <= " .. 10 nits...";
b.max <= 10;
b.i <= ".. 5 bits ...";
b.q <= " .. 5 bits...";

Please give your feedback

 

[RCIngham]

Hello All,

I am using the UNIFORM procedure in VHDL to generate random numbers.
UNIFORM generates random numbers in the range 0.1 to 0.99999. I wish
to generate random signed and unsigned numbers of variable
widths(integer range). I would like to get some ideas on how I should
scale this data? Right now, when i convert the real output from real
to integer to signed, it just gives me an output of wither 0 or 1 .
Your comments would be appreciated

Thank you

Actually it returns reals in the range 0.0 to 1.0 (exclusive), that is it

can return 0.0, but not 1.0.

As a previous reply states, you need to multiply the returned value by a
(real type) scaling factor before conversion to unsigned, and remember to
offset if converting to signed.

 

[Anuja]

On Feb 4, 10:01 am, "RCIngham" <robert.ing...@gmail.com> wrote:

Hello All,

I am using the UNIFORM procedure in VHDL to generate random numbers.
UNIFORM generates random numbers in the range 0.1 to 0.99999. I wish
to generate random signed and unsigned numbers of variable
widths(integer range). I would like to get some ideas on how I should
scale this data? Right now, when i convert the real output from real
to integer to signed, it just gives me an output of wither 0 or 1 .
Your comments would be appreciated

Thank you

Actually it returns reals in the range 0.0 to 1.0 (exclusive), that is it
can return 0.0, but not 1.0.

As a previous reply states, you need to multiply the returned value by a
(real type) scaling factor before conversion to unsigned, and remember to
offset if converting to signed.

Thank you very much everyone.

 

[RCIngham]

Jim Granville wrote:

Ray Andraka wrote:

Sky465nm@trline5.org wrote:

LFSRs are fine for a psuedo-random sequence. If it needs to be
truely random however (such as with crypto), an LFSR is not suitable

because the output is predictable given the history. If you do use

an LFSR, take only one bit per clock of the LFSR, as the bits are
highly correlated in the shift register.




Maybe one could exploit gated clocks, signal races, metastability
etc.. to
get randomness without resorting to hardware? (like transistor white

noise).



I think Jenny tried using ring oscillators to get a seed, but found
that given enough time the ring oscillators sync'ed up thanks to
parasitics. I was hoping she'd post here and maybe provide a link to

her thesis.


That would always be a risk, but you could use multiple ring-osc, and
run them one at a time ?

I did find them to be very good thermometers

Targeting the metastable window would be another approach, but that
seems to be very narrow.
Be interesting to see plots of time/aperture width ..

-jg



I think one approach she was looking at was a high order LFSR seeded by
a state machine that divined the phase difference between a pair of ring

oscillators. The idea was to obtain a random seed before the ring
oscillators got a chance to sync up, and then use the LFSR to get the
random sequence. The seeding is necessary to get a random start point
in the LFSR. Still, that doesn't give a true random. I know she was
looking for techniques that would pass a battery of randomness tests,
and very few approaches actually did. I'll give her a call to try to
get her to speak up here, and maybe put her thesis up on the 'net
somewhere.

Have 'hash functions' been investigated? E.g.:

http://www.cris.com/~Ttwang/tech/inthash.htm
(Converting the code in the reference from Java to VHDL isn't difficult,
but I am not allowed to post my version).

For instance, use an LFSR to generate the inputs to the hash function, and
use the output of the hash function as the 'random'.

But the referenced article does suggest using the Mercenne Twister...

 

Hello Guys,

I found an interesting website at www.calculatoredge.com an online
engineering calculator for formula and equations you can solve at
click of a button, If you like this website send links to your
friends and engineering group members.

Tom

You "found" an interesting web site and your e-mail address just
happens to be based on the the same name?

 

[Mike Treseler]

FPGA wrote:

I dont understand why it behaves so.

Variables update immediately.
Signals don't update until they see a wait.

-- Mike Treseler

 

[FPGA]

On Feb 25, 12:07 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

FPGA wrote:
I would like to know how the initialisation of seed values would
affect the output of the procedure of UNIFORM. I have looked at
UNIFORM but I am not able to understand the significance of the seed
values.

You initialize the seed values once. After that, they are modified by the
calls to uniform. You should not change the seed values anymore. Unless you
want to repeat the generated random values. Because that is what the seed
value guarantees: initialize them with the same values as before, and
uniform will generate the exact same numbers as before.

I have written a process to generate random signed vectors. In my
case, i specify that the random number be in range min and max.
When I change the seed values, I still get the same sequence of random
numbers.

Are you sure?

I am very sure. I my top level, I have defined SEED1 and SEED2 (of
type positive) as signals and then assigned them to S1 , S2 of type
positive.

I am not sure if this is how it should behave.
All I have done is converted the real to signed using rand <> > toSigned((real(min) + (rand1 * (real(max)-real(min)));
How do I simulate this process. I am getting random numbers, but I
would like to write a test bench which would check for all possible
scenarios and worst cases.

Something like:

  use std.textio.all;
  ...
  process is
    variable l: line;
    variable rand : integer; (or signed())
    variable seed1, seed2: integer;
  begin
    seed1 := 123;
    seed2 := 5678;
    for i in 1 to 1000 loop
      rand := your random function, calling uniform()
      write(l, rand);
      writeline(output, l);
    end loop;
    wait;
  end process;

--
Paul Uiterlindenwww.aimvalley.nl
e-mail addres: remove the not.

 

[FPGA]

On Feb 25, 12:07 pm, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

FPGA wrote:
I would like to know how the initialisation of seed values would
affect the output of the procedure of UNIFORM. I have looked at
UNIFORM but I am not able to understand the significance of the seed
values.

You initialize the seed values once. After that, they are modified by the
calls to uniform. You should not change the seed values anymore. Unless you
want to repeat the generated random values. Because that is what the seed
value guarantees: initialize them with the same values as before, and
uniform will generate the exact same numbers as before.

I have written a process to generate random signed vectors. In my
case, i specify that the random number be in range min and max.
When I change the seed values, I still get the same sequence of random
numbers.

Are you sure?

I am not sure if this is how it should behave.
All I have done is converted the real to signed using rand <> > toSigned((real(min) + (rand1 * (real(max)-real(min)));
How do I simulate this process. I am getting random numbers, but I
would like to write a test bench which would check for all possible
scenarios and worst cases.

Something like:

  use std.textio.all;
  ...
  process is
    variable l: line;
    variable rand : integer; (or signed())
    variable seed1, seed2: integer;
  begin
    seed1 := 123;
    seed2 := 5678;
    for i in 1 to 1000 loop
      rand := your random function, calling uniform()
      write(l, rand);
      writeline(output, l);
    end loop;
    wait;
  end process;

--
Paul Uiterlindenwww.aimvalley.nl
e-mail addres: remove the not.

I just commented my signals SEED1,SEED2 in the top level. I
initialised the values of SEED1, SEED2 within the process (not taking
as signal inputs as before). Now, I see that I am getting different
sequence for different values of SEED1, SEED2. Why would this happen?
Shouldnt it behave the same if I have SEED1, SEED2 as signals and then
within process I have variable S1,S2 initialised to signal SEED1,
SEED2
I dont understand why it behaves so.

 

[FPGA]

On Feb 26, 4:06 am, Paul Uiterlinden <puit...@notaimvalley.nl> wrote:

FPGA wrote:
process steps (save file, recompile, re-run simulation)?
Is there a bug in your scaling process?
I have saved, recompiled and rerun simulation. The strange thing is, I
am getting the same sequence if I output uniform in real format even
after I change the initialisation of Seed1 and Seed2.
uniform(S1,S2,rand1);
 rand_real <= rand1;

I am not sure why this is happening.
SEED1 <= 10;--1 ;
SEED2 <= 20;--2147483647 ;

Use variables for SEED1 and SEED2, or make sure there is a wait after
assigning the signals.

Signals are only updated after a delta delay. So if you do:

SEED1 <= 10;--1 ;
SEED2 <= 20;--2147483647 ;
uniform(SEES1,SEED2,rand1);

then uniform uses the values of SEED1 and SEED2 from *before* the
assignment.

--
Paul Uiterlindenwww.aimvalley.nl
e-mail addres: remove the not.

Thanks a bunch guys. I appreciate your help.

 

[RCIngham]

Hello all,

I have a bunch of functions I would like to synthesize on Quartus.
These are going to be part of a library. I would like to get resource
utilization of each function. The functions are generic.
My questions are
1) Do I have to write an entity for the synthesis of each function or
Can I just pasts individual functions in a .vhdl file to get the
resource estimation of each function
2) Since the functions are generic, would we get resource estimation
for worst case resources used? eg : if i have a generic function for
an adder, would it estimate resource utilization for a 1 bit adder or
maximum possible adder.

Thanks a bunch

In VHDL, you need an entity+architecture with the inputs and outputs of

the function(s) connected to top-level inputs and architectures, otherwise
the synthesizer/mapper/etc. functions will discard your logic.

If you want to run several functions through in parallel, they can share
inputs, but this might not give you enough information on each individual
function.

 

[Jim Lewis]

FPGA,

I just commented my signals SEED1,SEED2 in the top level. I
initialised the values of SEED1, SEED2 within the process (not taking
as signal inputs as before). Now, I see that I am getting different
sequence for different values of SEED1, SEED2. Why would this happen?
Shouldnt it behave the same if I have SEED1, SEED2 as signals and then
within process I have variable S1,S2 initialised to signal SEED1,
SEED2
I dont understand why it behaves so.

Your simulator should have reported an error when you declared SEED1
and SEED2 as signals as uniform requires them to be variables.

Jim

 

[Mike Treseler]

FPGA wrote:

It did not report error. I had assigned the signals to variables
within the process and then passed then to uniform. I am not sure if
its a good idea to assign signals to variables (is it a big NO ?)

This is a matter of style.
If the signal is used for nothing else, I would eliminate it.

-- Mike Treseler

 

[FPGA]

On Feb 26, 11:34 am, Jim Lewis <j...@synthworks.com> wrote:

FPGA,

I just commented my signals SEED1,SEED2 in the top level. I
initialised the values of SEED1, SEED2 within the process (not taking
as signal inputs as before). Now, I see that I am getting different
sequence for different values of SEED1, SEED2. Why would this happen?
Shouldnt it behave the same if I have SEED1, SEED2 as signals and then
within process I have variable S1,S2 initialised to signal SEED1,
SEED2
I dont understand why it behaves so.

Your simulator should have reported an error when you declared SEED1
and SEED2 as signals as uniform requires them to be variables.

Jim

It did not report error. I had assigned the signals to variables
within the process and then passed then to uniform. I am not sure if
its a good idea to assign signals to variables (is it a big NO ?)

 

In comp.arch.fpga bart <bart.borosky@latticesemi.com> wrote:

Lattice is holding a webcast today, "Interfacing High Sample Rate ADCs
to FPGAs." The presenter will be Shyam Chandra, from our mixed-signal
marketing group.

If you're interested, the event takes place live at 11am Pacific,
18:00 GMT. In addition, you will be able to view this webcast archive
on-demand, at your convenience, within 24 hours after the live event
takes place.

You can register by clicking:
http://www.latticesemi.com/corporate/webcasts/interfacinghighsamplerate.cfm
Bart Borosky, Lattice .

It's unfortunate that the webcast requires a propietary win32 plugin
installation. Rather then just provide a plain straightforward video url.

 

[bart]

It's unfortunate that the webcast requires a propietary win32 plugin
installation. Rather then just provide a plain straightforward video url.

i'll send your feedback to our third-party service provider, Saba/
Centra. thanks for the input. ~bart