Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 30325

Article: 30325
Subject: Re: pseudo random numbers
From: "luigi funes" <fuzzy8888@hotmail.com>
Date: Mon, 02 Apr 2001 23:48:23 GMT
Links: << >>  << T >>  << A >>

Jörg Ritter ha scritto nel messaggio
<3AC850A3.6E2A36B@informatik.uni-halle.de>...
>Hello,
>
>has someone expierience with generating (pseudo) random numbers in
>FPGA's (XC4000XLA series) ?
>
>My first idea was to use maximal length sequences (shift registers
>having maximum possible period for an r-stage shift register)
>
>Is there another source of randomness of the FPGA istself which can be
>used ?
>
>thanks
>Joerg
>

Linear Feed Back Shift Registers (LFSR) are very simple and generally very
poor random bits generators.
You can combine 3 different LFSR to get better randomness.
If you need numbers and not only bits, you can use a cryptographical
algorithm. For example, DES can generate very good pseudorandom
sequences.

Luigi




Article: 30326
Subject: Re: pinout in text format for Virtex-E XCV200E
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 03 Apr 2001 08:50:56 +0900
Links: << >>  << T >>  << A >>
Hi, Laurance.

From the shell promt, type "partgen -v xcv200e-fg456".  This will 
give you a file "v200efg456.pkg" which descries every in, it's location,
the closest CLB, etc.

For details about the format, look at 
http://toolbox.xilinx.com/docsan/3_1i/data/common/dev/chap03/dev03003.htm

Hope this helps,
-Kent


"Laurence McCotter" <mccotter@tality.com> writes:
> Can anyone help me out - I am looking for a pinout in text format for the
> Virtex-E XCV200E-FG456 device. (or better still a symbol!!)
> I plan to import the text file into ORCAD using the 'Generate Part' command
> to create the symbol from the pin table file. I have asked 2 of Xilinx FAEs
> by email  for this file last week and so far no reply!
> Thanks

Article: 30327
Subject: Re: pseudo random numbers
From: Ray Andraka <ray@andraka.com>
Date: Tue, 03 Apr 2001 01:10:34 GMT
Links: << >>  << T >>  << A >>
Actually, as long as you take one bit at a time, the randomness of an LFSR is
quite good, but the sequencer feedback polynomial as well as the current state
can be discovered by looking at the most recent bits, which makes it lousy for a
cryptographic application where knowing the sequence allows one to decipher the
encypted data.  Using 3 LFSRs in combination obfuscates the sequence enough to
make discovery of the generating function much harder.  If it is an encryption
you are after, then true enough a single LFSR is not sufficient. But the problem
stems from the ability to infer the polynomial and current state, not from the
apparent randomness of the bits.

luigi funes wrote:
> 
> Jörg Ritter ha scritto nel messaggio
> <3AC850A3.6E2A36B@informatik.uni-halle.de>...
> >Hello,
> >
> >has someone expierience with generating (pseudo) random numbers in
> >FPGA's (XC4000XLA series) ?
> >
> >My first idea was to use maximal length sequences (shift registers
> >having maximum possible period for an r-stage shift register)
> >
> >Is there another source of randomness of the FPGA istself which can be
> >used ?
> >
> >thanks
> >Joerg
> >
> 
> Linear Feed Back Shift Registers (LFSR) are very simple and generally very
> poor random bits generators.
> You can combine 3 different LFSR to get better randomness.
> If you need numbers and not only bits, you can use a cryptographical
> algorithm. For example, DES can generate very good pseudorandom
> sequences.
> 
> Luigi

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 30328
Subject: Re: pseudo random numbers
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Tue, 03 Apr 2001 13:27:40 +1000
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Eric Pearson wrote:
> >
> > Hello Joerg...
> >
> > I've been looking into the same thing. Here's a clear paper with
> > good coverage and references.
> >
> > http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Papers/D5_Chu_P.pdf
> >
> > As to other forms of built in randomness...
> >
> > I think that metastability and propagation delay are two factors avaliable
> > which
> > have some randomness to them.
> 
> You might have a very difficult time hitting the metastability in an FPGA.  The
> window is very small, and the only time you can seem to hit it consistently is
> when you don't want to :-(

Hi Ray,

One way is to have an IBUF feeding an inverter, feeding a FF, feeding an
OBUF.

You then connect up an analog single pole low pass filter (i.e. a series
resistor and a cap to ground) from the output pin of the OBUF to the
input pin of the IBUF.

Feedback holds the voltage at the IBUF input at something close to the
threshold voltage.

The output will have a "duty cycle" determined by Voh, Vol and the input
threshold voltage.

It won't make cryptograhic strength random numbers though, because it's
too sensitive to PSU noise and crosstalk from other logic on the die,
but it could be ok for seed generation.

Oh, and it won't work too well as a metastability generator if the IBUF
has any hysteresis, as the oscillation frequency will then be determined
by Voh, Vol, Vt+ and Vt-.

(I've seen schematics of this configuration in books, but I've never
built one.)

Regards,
Allan.


 
> For sampling an oscillator, I mentioned before that if both your system clock
> and your oscillator are reasonably stable, then the results of sampling will be
> periodic. (the sum of a finite set of periodic signals is also periodic).  You
> lose the random distribution.  Also worth noting, is it seems an ring oscillator
> implemented in the FPGA might tend to lock to a system clock because of the
> changes in local supply voltage due to currents drawn on the clock edges
> elsewhere in the FPGA.  These two reasons are why I suggested using the phase
> difference between an oscillator and the system clock just once on start-up to
> initialize an LFSR rather than attempting to use it all the time.
> 
>  If a oscillator were made (3 inverters), then
> > build a random number by sampling this output at a widely space interval,
> > there should
> > be a degree of randomness.
> >
> > The key problem would be guaranteed startup of the oscillator (help!), else
> > the number
> > wouldn't be very random.
> >
> > Eric Pearson
> > Carde Systems
> > Waterloo, Ontario
> > YAFC
> >
> > Jörg Ritter <ritter@informatik.uni-halle.de> wrote in message
> > news:3AC850A3.6E2A36B@informatik.uni-halle.de...
> > > Hello,
> > >
> > > has someone expierience with generating (pseudo) random numbers in
> > > FPGA's (XC4000XLA series) ?
> > >
> > > My first idea was to use maximal length sequences (shift registers
> > > having maximum possible period for an r-stage shift register)
> > >
> > > Is there another source of randomness of the FPGA istself which can be
> > > used ?

Article: 30329
Subject: Timing Error
From: Qian <qianz@cae.wisc.edu>
Date: Mon, 2 Apr 2001 20:19:18 -0800
Links: << >>  << T >>  << A >>
I tried to implement my VHDL program by Xilinx Foundation 3.li
however in my Place & Route step I got error information about timing constraint like
"
ERROR:Par:54 - PAR: At least one timing constraint is impossible to meet
   because component delays alone exceed the constraint.  A physical timing
   constraint summary follows.  This summary will also show minimal delays for
   nets in the paths.  These delays will not cause par to terminate.  If you
   wish to see the paths which have errors caused only by logic delay then set
   the environement variable "PAR_ZEROFLOORS" before runing PAR or the Timing
   Analyzer.  Setting this environment variable will effect the behavior of
   place and route in a negative way so if you set this variable please reset it
   after the problem is resolved and before running PAR again.
   Please use the Timing Analyzer (GUI) or the TRCE (command line) to identify
   the problem paths.  For more information about the Timing Analyzer, consult
   the Xilinx Timing Analyzer Reference manual; for more information on TRCE,
   consult the Xilinx Development System Reference Guide "TRACE" chapter.

Asterisk (*) preceding a constraint indicates it was not met.

--------------------------------------------------------------------------------
  Constraint                                | Requested  | Actual     | Logic 
                                            |            |            | Levels
--------------------------------------------------------------------------------
  TS_N870 = PERIOD TIMEGRP "N870"  20 nS    |            |            |      
  HIGH 10 nS                                |            |            |      
--------------------------------------------------------------------------------
* TS_CLK = PERIOD TIMEGRP "CLK"  20 nS   HI | 20.000ns   | 24.742ns   | 18   
  GH 10 nS                                  |            |            |      
--------------------------------------------------------------------------------
  TS_P2P = MAXDELAY FROM TIMEGRP "PADS" TO  | 20.000ns   | 11.374ns   | 3    
  TIMEGRP "PADS" 20 nS                      |            |            |      
--------------------------------------------------------------------------------
* TS_0 = MAXDELAY FROM TIMEGRP "N870" TO TI | 10.000ns   | 27.188ns   | 17   
  MEGRP "PADS" 10 nS                        |            |            |      
--------------------------------------------------------------------------------
  OFFSET = IN 20 nS  BEFORE COMP "CLK"      | 20.000ns   | 17.622ns   | 16   
--------------------------------------------------------------------------------
* OFFSET = OUT 20 nS  AFTER COMP "CLK"      | 20.000ns   | 24.097ns   | 16   
--------------------------------------------------------------------------------

3 constraints not met.
"

Could anyone tell me how to solve that?
Thanks a lot!

Article: 30330
Subject: Re: pseudo random numbers
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Tue, 03 Apr 2001 04:53:16 -0000
Links: << >>  << T >>  << A >>

>The problem with using more than one bit from an LFSR is that all the other bits
>are related by time (they are just time shifted copies), therefore, even if you
>space the selected bits out and/or shuffle them, you still get spectral coloring
>in your random number.  The one way around that is to space the bits far enough
>apart that the correlation is not a factor within your sample interval.  That,
>however requires a large number of bit delays, at which point it is usually more
>economical to use multiple LFSRs that are identical except the seeds (and the
>seeds are spaced far apart). Another solution involves clocking the LFSR n times
>to generate an n bit random value using successive outputs.

Why not use multiple LFSRs that are not identical?

If you have several identical LFSRs with different seeds, you
get the same max-length of a single LFSR.  The pattern will
be diffeerent if you can reload with a different seed but the
length will be the same.

If you have LFSRs with different sizes, I think the lengths
multiply.  (I'm not good enough at math to be able to back
that up.  There may be some restrictions.)


-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 30331
Subject: Re: Parallel Port EPP
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Tue, 03 Apr 2001 05:37:28 -0000
Links: << >>  << T >>  << A >>

>It doesn't have to be a kludge of any sort.

Your right.  It's good clean asynchrnous logic interfacing to
synchronous logic.  Thanks for the correction.

What term should I have used?  It's not hard if you are
familiar with that type of problem, but there traps waiting
if you aren't.  The tools and textbooks generally don't support
it as well as they do pure synchronous designs...

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 30332
Subject: to add macro in the design
From: Manjunathan <mnathan@logiceastern.com>
Date: Tue, 3 Apr 2001 00:40:45 -0800
Links: << >>  << T >>  << A >>
hello everybody !!!!

       i have a doubt in instantiation a macro , macro which belong to virtex-e device and package of say A.

if i want to instantiate this macro in same device but different package,is it possible to do so? 

if yes,what is the command or procedure to add ?

 i did this procedure to add the macro,

  1) i created a macro of design A.

  2) i created a new sheet for design B.

  3) then i went to tool bar to add the macro,i clicked the add macro(even i have selected the reference component also) .

  4) then it showed me ,the design is added but iam unable to see the
     design in the new sheet.

 and also i would like to know why i can't see the design?

 

thanks in advance

regards,
Manjunathan.

Article: 30333
Subject: Re: some info. on FPGA
From: "news.hinet.net" <cmlin4@winbond.com.tw>
Date: Tue, 3 Apr 2001 16:51:35 +0800
Links: << >>  << T >>  << A >>
http://www.icdiy.org/forums_list.php?sid=2

IC design & FPGA


"hanshu" <hanshu@arch.cs.pku.edu.cn> wrote in message
news:9a9vbr$4qc$1@sunlight.pku.edu.cn...
> Hello everyone
>
> I need some information on the basic introduction of FPGA.Please give me
> some advise .
>
>
>



Article: 30334
Subject: Re: some info. on FPGA
From: Srinivasan Venkataramanan <srini@realchip.co.in>
Date: Tue, 03 Apr 2001 14:50:28 +0530
Links: << >>  << T >>  << A >>
Hi,
	Check out http://www.optimagic.com/ and http://www.fpga-guru.com

Srini

hanshu wrote:
> 
> Hello everyone
> 
> I need some information on the basic introduction of FPGA.Please give me
> some advise .

-- 
Srinivasan Venkataramanan (Srini)
ASIC Design Engineer,
Chennai (Madras), India

Article: 30335
Subject: Re: xapp258 question
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 03 Apr 2001 11:27:26 +0200
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> writes:

> yorams@hywire.com wrote:
> 
> >  Hi.
> > I have read xilinx application note xapp258 and I have the following
> > question:
> >
> > <snip>
> > the following might occur
> >
> > path between bit i of counter to its synchronizer is: epsilon;
> > path between bit j of counter to its synchronizer is: epsilon + Tcyc;
> >
> > under these condition the synchronizer can sample false value of the gray
> > counter and thus give false full or empty flag.
> >
> >
> > Is it possible ?
> > Can it be avoided ?
> >
> 
> The idea behind using Grey counters is that they make the problem
> you mention disappear.  If you transfer the Grey value from one
> clock domain to the other, and you do it at the most awkward moment,
> right as the Grey counter increments, you will not transfer garbage
> ( which might happen with a binary counter ), since adjacent Grey
> values only differ by one bit. So you transfer either the old or the
> new value.  Either one is as good as the other at that particular
> moment.

Peter, I understood his comments as what happens if the skew of the
counter bits is larger than the cycle time. Unlikely, but
theoretically possible.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 30336
Subject: Re: Please help a poor student with virtexe
From: "Frederic Darre" <darre@irit.fr>
Date: Tue, 3 Apr 2001 11:49:21 +0200
Links: << >>  << T >>  << A >>
Thanks for your help, the problem is a incompatibility with USB and Windows
2000.
I see you working for xilinx, can you tell me if a doc for vhdl can be found
on the site.
And one question :
I use a virtexe and a avnet demo board , if i want to switch-on a segment by
pusging a button did i have to specify the digit (because they have 4 digit
with 7 segment) ?



Article: 30337
Subject: RC4/ARC4 on an FPGA.
From: "Matt Hayes" <matthewhayes9000@hotmail.com>
Date: Tue, 3 Apr 2001 12:57:22 +0100
Links: << >>  << T >>  << A >>
I'm aware that quite a number of people believe that the RC4 algorithm isn't
particularly suited to hardware but the idea interests me nonetheless.

I have performed a few websearches but can't really find the answers I am
looking for.

In particular, I would like to know:
a) what rates of data throughput have been achieved by RC4 implementations
on an FPGA? what is the fastest ever?
b) if it is possible to purchase a fast RC4/ARC4 IP Core and what throughput
rates can be expected.

Thanks,

   Matt.



Article: 30338
Subject: Re: Timing Error
From: Ray Andraka <ray@andraka.com>
Date: Tue, 03 Apr 2001 12:06:24 GMT
Links: << >>  << T >>  << A >>
For the first one, you need to reduct the number of logic levels between
flip-flops, or reduce the delay by floorplanning.  You did not mention the logic
family, so I can't tell if the 18 reported logic levels are carry chain elements
or something else.  If it is just carry chain, the likely cause of the long
delay is a driving function into the carry chain that is geographiclly far away,
is driving a heavy load, or both.  Floorplanning will alleviate problems due to
routing delays, but can do nothing for logic delays.

For the other two constraints, the most effective thing to do is to register
your I/O.  If you can't for some reason, you chould floorplan those pins and the
logic back to the register(s) driving them to keep the routing dealys short.  I
strongly encourage you to register both inputs and outputs whereever possible. 
Doing so not only makes it easy to meet your I/O timing, but it also keeps it
consistent and predictable across PAR runs.

Xilinx has a timing wizard, as well as an application note that gives you
additional guidelines for improving the timing of your design.



Qian wrote:
> 
> I tried to implement my VHDL program by Xilinx Foundation 3.li
> however in my Place & Route step I got error information about timing constraint like
> "
> ERROR:Par:54 - PAR: At least one timing constraint is impossible to meet
>    because component delays alone exceed the constraint.  A physical timing
>    constraint summary follows.  This summary will also show minimal delays for
>    nets in the paths.  These delays will not cause par to terminate.  If you
>    wish to see the paths which have errors caused only by logic delay then set
>    the environement variable "PAR_ZEROFLOORS" before runing PAR or the Timing
>    Analyzer.  Setting this environment variable will effect the behavior of
>    place and route in a negative way so if you set this variable please reset it
>    after the problem is resolved and before running PAR again.
>    Please use the Timing Analyzer (GUI) or the TRCE (command line) to identify
>    the problem paths.  For more information about the Timing Analyzer, consult
>    the Xilinx Timing Analyzer Reference manual; for more information on TRCE,
>    consult the Xilinx Development System Reference Guide "TRACE" chapter.
> 
> Asterisk (*) preceding a constraint indicates it was not met.
> 
> --------------------------------------------------------------------------------
>   Constraint                                | Requested  | Actual     | Logic
>                                             |            |            | Levels
> --------------------------------------------------------------------------------
>   TS_N870 = PERIOD TIMEGRP "N870"  20 nS    |            |            |
>   HIGH 10 nS                                |            |            |
> --------------------------------------------------------------------------------
> * TS_CLK = PERIOD TIMEGRP "CLK"  20 nS   HI | 20.000ns   | 24.742ns   | 18
>   GH 10 nS                                  |            |            |
> --------------------------------------------------------------------------------
>   TS_P2P = MAXDELAY FROM TIMEGRP "PADS" TO  | 20.000ns   | 11.374ns   | 3
>   TIMEGRP "PADS" 20 nS                      |            |            |
> --------------------------------------------------------------------------------
> * TS_0 = MAXDELAY FROM TIMEGRP "N870" TO TI | 10.000ns   | 27.188ns   | 17
>   MEGRP "PADS" 10 nS                        |            |            |
> --------------------------------------------------------------------------------
>   OFFSET = IN 20 nS  BEFORE COMP "CLK"      | 20.000ns   | 17.622ns   | 16
> --------------------------------------------------------------------------------
> * OFFSET = OUT 20 nS  AFTER COMP "CLK"      | 20.000ns   | 24.097ns   | 16
> --------------------------------------------------------------------------------
> 
> 3 constraints not met.
> "
> 
> Could anyone tell me how to solve that?
> Thanks a lot!

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 30339
Subject: Re: pseudo random numbers
From: Ray Andraka <ray@andraka.com>
Date: Tue, 03 Apr 2001 12:17:02 GMT
Links: << >>  << T >>  << A >>
YOu could use LFSRs that are not identical.  The trouble there is in building a
bunch of them.  Not all LFSRs have feedback that is limited to 4 terms (to make
the feedback 1 LUT) and use taps that are convenient to access when using SRL16
or CLB RAM for the shift register.  If the length of the LFSR is long enough,
then the probability of randomly chosen seeds being close enough in the sequence
to be correlated over your observation period is pretty low...provided you don't
use a similar LFSR to pick your seeds.  I personally like the 129 bit LFSR
because it satisfies all the criteria above (depending on your application's
observation window).

FOr a given LFSR, the pattern will be the same regardless of the seed, just
shifted in time.  The object is to use a large enough LFSR that the shift in
time between outputs is large enough to not correlate within your observation
window.

For using a pair of LFSRs, the length multiplies if the individual lengths are
relatively prime.  FOr more than 2 or three, that gets to be a difficult
criteria to meet.

Hal Murray wrote:
> 
> >The problem with using more than one bit from an LFSR is that all the other bits
> >are related by time (they are just time shifted copies), therefore, even if you
> >space the selected bits out and/or shuffle them, you still get spectral coloring
> >in your random number.  The one way around that is to space the bits far enough
> >apart that the correlation is not a factor within your sample interval.  That,
> >however requires a large number of bit delays, at which point it is usually more
> >economical to use multiple LFSRs that are identical except the seeds (and the
> >seeds are spaced far apart). Another solution involves clocking the LFSR n times
> >to generate an n bit random value using successive outputs.
> 
> Why not use multiple LFSRs that are not identical?
> 
> If you have several identical LFSRs with different seeds, you
> get the same max-length of a single LFSR.  The pattern will
> be diffeerent if you can reload with a different seed but the
> length will be the same.
> 
> If you have LFSRs with different sizes, I think the lengths
> multiply.  (I'm not good enough at math to be able to back
> that up.  There may be some restrictions.)
> 
> --
> These are my opinions, not necessarily my employeers.  I hate spam.

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 30340
Subject: Analog programable devices
From: "Fredrik Theander" <fredrik.theander@mbox301.swipnet.se>
Date: Tue, 3 Apr 2001 18:12:05 +0200
Links: << >>  << T >>  << A >>
Hi

I'm a student currently working on my exam thesis . The topic is a study
over programable analog devices. I have found three manufactures of devices

Anadigm
Lattice ispPAC familiy
Zetrex TRAC

I wonder if anyone else knows about anymore manufactures of analog
programable devices.

regards
Fredrik Theander




Article: 30341
Subject: Re: xapp258 question
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 03 Apr 2001 09:55:07 -0700
Links: << >>  << T >>  << A >>


Magnus Homann wrote:

> Peter Alfke <peter.alfke@xilinx.com> writes:
>
> > yorams@hywire.com wrote:
> >
> > >  Hi.
> > > I have read xilinx application note xapp258 and I have the following
> > > question:
> > >
> > > <snip>
> > > the following might occur
> > >
> > > path between bit i of counter to its synchronizer is: epsilon;
> > > path between bit j of counter to its synchronizer is: epsilon + Tcyc;
> > >
> > > under these condition the synchronizer can sample false value of the gray
> > > counter and thus give false full or empty flag.
> > >
> > >
> > > Is it possible ?
> > > Can it be avoided ?
> > >
> >
> > The idea behind using Grey counters is that they make the problem
> > you mention disappear.  If you transfer the Grey value from one
> > clock domain to the other, and you do it at the most awkward moment,
> > right as the Grey counter increments, you will not transfer garbage
> > ( which might happen with a binary counter ), since adjacent Grey
> > values only differ by one bit. So you transfer either the old or the
> > new value.  Either one is as good as the other at that particular
> > moment.
>
> Peter, I understood his comments as what happens if the skew of the
> counter bits is larger than the cycle time. Unlikely, but
> theoretically possible.
>

Thanks, and I apologize for my simplistic answer.
But, as I have said in a recent seminar:
Do NOT delegate all your decisions to the synthesis tool and the automatic
placement tools. The existence ( and evolving quality ) of these tools should
not prevent us from using good engineering judgement.
One should always throw a leery eye at any asynchronous interface.

Peter Alfke, Xilinx



Article: 30342
Subject: salary info for FPGA/HardwareEng's
From: salary_guide@hitechsalary.com
Date: Tue, 03 Apr 2001 19:00:32 GMT
Links: << >>  << T >>  << A >>
--_NextPart_00009078-00001855-010A7083-65D5
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I'm sure you might be interested to know that salaries are still on the rise.
Our Engineering SALARY CALCULATOR has been updated and improved to give you a much better results based on:
- 2001 salary data
- MORE specific selections for almost every function, title and industry
- Geographies now include individual cities throughout - US and Canada

www.hitechsalary.com


GNR - Career Counselors

--_NextPart_00009078-00001855-010A7083-65D5--

Article: 30343
Subject: Re: No inputs on XC9536XL
From: Arthur <Arthur.yang@atxilinx.com>
Date: Tue, 3 Apr 2001 11:02:04 -0800
Links: << >>  << T >>  << A >>
Hello Kolja -

Try this piece of Abel out. It still requires an input, but in this case, it doesn't matter what you have tied to it and the output will always be a '1'.
*****

module jc2_top
Title 'jc2_abl'

Declarations

din pin ; 
dout pin;

u2, u3  node istype 'keep';

Equations

u2 = din ;
u3 = ! din;
dout = u2 # u3;

end jc2_top

*****

In the next release of software, a design with no inputs will result in a warning as opposed to an error.

Best Regards,
Arthur

Article: 30344
Subject: Atmel FPSLIC devices
From: Chris Eilbeck <chris@yordas.demon.co.uk>
Date: Tue, 3 Apr 2001 20:20:38 +0100
Links: << >>  << T >>  << A >>
These look rather good, having a AVR microcontroller core and upto 40K 
gates on one device.  I'm not familiar with the Atmel FPGAs but I have 
used Xilinx XC4000 before.  Could someone give me a simple comparison of 
the two families.

Ta

Chris
-- 
Chris Eilbeck                             mailto:chris@yordas.demon.co.uk

Article: 30345
Subject: Re: pseudo random numbers
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Tue, 03 Apr 2001 19:47:47 GMT
Links: << >>  << T >>  << A >>
There's no reason you can't make an LFSR that spits out n bits per cycle,
the equivalent to using the single random bit on n successive cycles.  CRC
generators, which are very similar to LFSRs, are often required to do this.
If you have to generate, say, a 16-bit CRC on 40 mega-longword-per-second
data, there's no way you can run a classic CRC generator at 40MHz * 32.  The
CRC generator in this case would operate at 40MHz, looking at 32 bits at a
time.  The output data bits end up being an XOR of some combination of the
16 current CRC bits and the 32 data bits comprising the next data longword.

Using this same idea you could have, say, a 128-bit LFSR that shifts 8 bits
per cycle and would produce 8 random bits per cycle.  Figuring out where to
put the taps for the wide XORs is the hard part.  You could just use the CRC
generator.  If you ran a 32-bit counter into the CRC generator described
above, you would get a 16-bit output where I think all the bits would be
random and not related to each other.  There are places on the web that will
generate such a CRC generator for you.


"Ray Andraka" <ray@andraka.com> wrote in message
news:3AC8CF3B.1DAD2C65@andraka.com...
>
>
> Nicolas Matringe wrote:
> >
> > Ray Andraka wrote:
> > [...]
> > > Use only one bit at a time from the LFSR though, the other bits
> > > are time shifted copies of the first bit.
> >
> > What about shuffling the bits? Or using only some bits from a large
> > LFSR?
> > Just a thought but I find it interesting...
>
> The problem with using more than one bit from an LFSR is that all the
other bits
> are related by time (they are just time shifted copies), therefore, even
if you
> space the selected bits out and/or shuffle them, you still get spectral
coloring
> in your random number.  The one way around that is to space the bits far
enough
> apart that the correlation is not a factor within your sample interval.
That,
> however requires a large number of bit delays, at which point it is
usually more
> economical to use multiple LFSRs that are identical except the seeds (and
the
> seeds are spaced far apart). Another solution involves clocking the LFSR n
times
> to generate an n bit random value using successive outputs.
>
>  For some applications, such as memory testing, the spectral coloring may
not be
> a factor, so less care is needed.  If you are trying to model noise
however,
> then you'll want to be careful about correlations between bits.
>
>
> > --
> > Nicolas MATRINGE           IPricot European Headquarters
> > Conception electronique    10-12 Avenue de Verdun
> > Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
> > Fax +33 1 46 52 53 01      http://www.IPricot.com/
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>



Article: 30346
Subject: Re: pseudo random numbers
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 03 Apr 2001 14:03:38 -0700
Links: << >>  << T >>  << A >>
Ray,

On another note altogether, I need to have a reference to a book that has all of the
maximal length sequence ploynomials for all LFSR (PRS) generators up to 32 bits (or
more),

Austin

Ray Andraka wrote:

> There are no random sources inherent in the FPGA, although you could conceivably
> use the phase difference between the internal oscillator in the 4Kparts and an
> external clock.  I'd prefer to use the linear feedback shift register (LFSR)
> with a long enough sequence to make it random over a long interval.  That can be
> done very compactly in the 4K using CLB ram (see the xilinx app note on LFSRs, I
> think it is XAPP152).  Use only one bit at a time from the LFSR though, the
> other bits are time shifted copies of the first bit.  A 129 bit LFSR only takes
> 13 LUTs to implement and at 40 MHz will take thousands of years before it
> repeats.  Of course at start-up it will start out with the same value, so the
> sequence is always the same.  That is good for debug, but may be bad for your
> system.  In that case, you need to seed the 129 bits with a random value on
> startup (if you seed it serially, the LFSR is still the same size).  The random
> seed has to be generated by something external to the FPGA since the FPGA is
> always the same on startup.  One possibility, which I mentioned above is to use
> the random relationship of the internal oscillator and an external clock to seed
> the LFSR.
>
>  I'd use the internal oscillator phase relationship to seed an LFSR rather than
> directly for two reasons: 1) The instantaneous phase relationship will be
> random, but a time series will be periodic, and 2) non-repeatability of the
> phase makes debug difficult.  (The LFSR can be forced to a particular start
> state for debug).
>
> Jörg Ritter wrote:
> >
> > Hello,
> >
> > has someone expierience with generating (pseudo) random numbers in
> > FPGA's (XC4000XLA series) ?
> >
> > My first idea was to use maximal length sequences (shift registers
> > having maximum possible period for an r-stage shift register)
> >
> > Is there another source of randomness of the FPGA istself which can be
> > used ?
> >
> > thanks
> > Joerg
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com


Article: 30347
Subject: Re: pseudo random numbers
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 03 Apr 2001 14:27:26 -0700
Links: << >>  << T >>  << A >>
Well, right here at Xilinx we have XAPP052 listing all lengths up to 168, and I also
found them in a book:
Applied Cryptography by Bruce Schneier (Wyley 1996) page 376 and 377.
I am in the process of cross-checking ( terminology is slightly different, but concept
is the same).

Peter Alfke
============================
Austin Lesea wrote:

> Ray,
>
> On another note altogether, I need to have a reference to a book that has all of the
> maximal length sequence ploynomials for all LFSR (PRS) generators up to 32 bits (or
> more),
>
> Austin
>


Article: 30348
Subject: Re: pseudo random numbers
From: Ray Andraka <ray@andraka.com>
Date: Tue, 03 Apr 2001 21:46:52 GMT
Links: << >>  << T >>  << A >>
Austin,

I haven't looked that hard for such a list (I haven't seen one in my travels). 
I usually use the one in your App note 052: It has one maximal length sequence
for each length to something like 168 bits.  You might ask Peter Alfke (I think
he wrote that note) if any of his references has a table like you are looking
for.



ALso, on this thread someone mentioned using a parallel output LFSR.  Yes, you
can do that, reducing the polynomials isn't too bad, you basically wind up with
n parallel shift registers with the feedback feeding from other shift register
outputs.  



Austin Lesea wrote:
> 
> Ray,
> 
> On another note altogether, I need to have a reference to a book that has all of the
> maximal length sequence ploynomials for all LFSR (PRS) generators up to 32 bits (or
> more),
> 
> Austin
> 
> Ray Andraka wrote:
> 
> > There are no random sources inherent in the FPGA, although you could conceivably
> > use the phase difference between the internal oscillator in the 4Kparts and an
> > external clock.  I'd prefer to use the linear feedback shift register (LFSR)
> > with a long enough sequence to make it random over a long interval.  That can be
> > done very compactly in the 4K using CLB ram (see the xilinx app note on LFSRs, I
> > think it is XAPP152).  Use only one bit at a time from the LFSR though, the
> > other bits are time shifted copies of the first bit.  A 129 bit LFSR only takes
> > 13 LUTs to implement and at 40 MHz will take thousands of years before it
> > repeats.  Of course at start-up it will start out with the same value, so the
> > sequence is always the same.  That is good for debug, but may be bad for your
> > system.  In that case, you need to seed the 129 bits with a random value on
> > startup (if you seed it serially, the LFSR is still the same size).  The random
> > seed has to be generated by something external to the FPGA since the FPGA is
> > always the same on startup.  One possibility, which I mentioned above is to use
> > the random relationship of the internal oscillator and an external clock to seed
> > the LFSR.
> >
> >  I'd use the internal oscillator phase relationship to seed an LFSR rather than
> > directly for two reasons: 1) The instantaneous phase relationship will be
> > random, but a time series will be periodic, and 2) non-repeatability of the
> > phase makes debug difficult.  (The LFSR can be forced to a particular start
> > state for debug).
> >
> > Jörg Ritter wrote:
> > >
> > > Hello,
> > >
> > > has someone expierience with generating (pseudo) random numbers in
> > > FPGA's (XC4000XLA series) ?
> > >
> > > My first idea was to use maximal length sequences (shift registers
> > > having maximum possible period for an r-stage shift register)
> > >
> > > Is there another source of randomness of the FPGA istself which can be
> > > used ?
> > >
> > > thanks
> > > Joerg
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com

Article: 30349
Subject: Re: pseudo random numbers
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 03 Apr 2001 15:29:37 -0700
Links: << >>  << T >>  << A >>
Ray,

Thanks.  As you can see, 14 cubes away, Peter found a book in another cube 6 cubes from
that....

Sigh.

Even so, there are even better books that list every maximal length sequence generator
polynomial (read feedback taps) for any given length register.  For a 12 bit LFSR, there
are >500 maximal length sequences that are all different.

These get used for spread spectrum communications (each transmitter has its own sequence
so it can be despread at the receiver in the presence of other transmitters and
interference -- this is how GPS works, for eample).

I was looking for this having nothing to do with "random" numbers, just to solve the
spread spectrum code generation issue,

Thanks,

Austin

Ray Andraka wrote:

> Austin,
>
> I haven't looked that hard for such a list (I haven't seen one in my travels).
> I usually use the one in your App note 052: It has one maximal length sequence
> for each length to something like 168 bits.  You might ask Peter Alfke (I think
> he wrote that note) if any of his references has a table like you are looking
> for.
>
> ALso, on this thread someone mentioned using a parallel output LFSR.  Yes, you
> can do that, reducing the polynomials isn't too bad, you basically wind up with
> n parallel shift registers with the feedback feeding from other shift register
> outputs.
>
> Austin Lesea wrote:
> >
> > Ray,
> >
> > On another note altogether, I need to have a reference to a book that has all of the
> > maximal length sequence ploynomials for all LFSR (PRS) generators up to 32 bits (or
> > more),
> >
> > Austin
> >
> > Ray Andraka wrote:
> >
> > > There are no random sources inherent in the FPGA, although you could conceivably
> > > use the phase difference between the internal oscillator in the 4Kparts and an
> > > external clock.  I'd prefer to use the linear feedback shift register (LFSR)
> > > with a long enough sequence to make it random over a long interval.  That can be
> > > done very compactly in the 4K using CLB ram (see the xilinx app note on LFSRs, I
> > > think it is XAPP152).  Use only one bit at a time from the LFSR though, the
> > > other bits are time shifted copies of the first bit.  A 129 bit LFSR only takes
> > > 13 LUTs to implement and at 40 MHz will take thousands of years before it
> > > repeats.  Of course at start-up it will start out with the same value, so the
> > > sequence is always the same.  That is good for debug, but may be bad for your
> > > system.  In that case, you need to seed the 129 bits with a random value on
> > > startup (if you seed it serially, the LFSR is still the same size).  The random
> > > seed has to be generated by something external to the FPGA since the FPGA is
> > > always the same on startup.  One possibility, which I mentioned above is to use
> > > the random relationship of the internal oscillator and an external clock to seed
> > > the LFSR.
> > >
> > >  I'd use the internal oscillator phase relationship to seed an LFSR rather than
> > > directly for two reasons: 1) The instantaneous phase relationship will be
> > > random, but a time series will be periodic, and 2) non-repeatability of the
> > > phase makes debug difficult.  (The LFSR can be forced to a particular start
> > > state for debug).
> > >
> > > Jörg Ritter wrote:
> > > >
> > > > Hello,
> > > >
> > > > has someone expierience with generating (pseudo) random numbers in
> > > > FPGA's (XC4000XLA series) ?
> > > >
> > > > My first idea was to use maximal length sequences (shift registers
> > > > having maximum possible period for an r-stage shift register)
> > > >
> > > > Is there another source of randomness of the FPGA istself which can be
> > > > used ?
> > > >
> > > > thanks
> > > > Joerg
> > >
> > > --
> > > -Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search