Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. LuigiArticle: 30326
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! > ThanksArticle: 30327
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.comArticle: 30328
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
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>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
>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
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: 30333http://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
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), IndiaArticle: 30335
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.seArticle: 30336
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
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
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.comArticle: 30339
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.comArticle: 30340
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 TheanderArticle: 30341
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, XilinxArticle: 30342
--_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
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, ArthurArticle: 30344
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.ukArticle: 30345
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
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.comArticle: 30347
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
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.comArticle: 30349
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:
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