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
Hi all, I support Peter's position that junction temperature is the real measurement point. It's the silicon that howls and dies when it gets too hot, not the air just above the case, so for me I want to know params at junction temps not air temps. BTW, which ambient are we talking about here, the one 1mm, 10mm or 50mm from the chip body, the fan exhaust temperature or etc, etc. Working from the case temp is, i think, the most accurate way of assessing thermal & tech params and Xilinx support that by publishing appropriate thermal figures. The current data book has figures for both theta-jc and theta-ja on all packages so junction temps are easy to calculate. Alternatively, by placing a low mass probe on the case you can find out what the junction is doing and measure the cooling effectiveness of airflow or increased heatsinking. I feel that ambient temp reporting is just so much finger in the air, it's valid for the precise conditions used in the test and no <real> other. Dave McLeod -- dmacArticle: 19876
It's bad enough now. Hell, if everyone starts writing decent code I don't stand a chance of looking like a genius anymore! ;-) Andy. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19877
> i was at a seminar a couple of years ago about the security of > satellite tv encryption systems. the presenter had a slide of a > hacker's garage (in germany), showing a second-hand electron > microscope (i forget how much it was, but surprisingly cheap). this > guy had burnt the top off the processor on the security card, attached > probes to an internal data bus, watched it in operation, and broken > the algorithm, all by himself. it sounded pretty straightforward. If you are interested in that sort of attackdevice security, be sure to read this paper. It helps to be a hardware geek, but software people (and even managers) should be able to understand this. It's fun and well done. So good that I save this from a Usenet posting. ------- Research Announcement We recently published the following paper, which should be of interest to those concerned about smartcard hardware security: Oliver K<F6>mmerling, Markus G. Kuhn: Design Principles for Tamper-Resistant Smartcard Processors. Proceedings of the USENIX Workshop on Smartcard Technology (Smartcard '99), Chicago, Illinois, USA, May 10-11, 1999, USENIX Association, pp. 9-20, ISBN 1-880446-34-0. (This work received the "USENIX Association Best Student Paper Award".) Various non-invasive cryptanalysis techniques against smartcards, which have been publicised as "Differential Fault Analysis", "Differential Power Analysis", etc., have received considerable attention recently. However, these are not the attack techniques that have been used by pirates to break practically all types of smartcard processors that are fielded in millions of conditional-access systems. We show in our paper how invasive microprobing techniques are a far more powerful and universally applicable threat to smartcard security, which processor architecture elements simplify attacks significantly, and what designers could quite easily do to make it more difficult. Unlike fault and current analysis techniques, microprobing attacks do not depend on any prior knowledge or guessing of the implemented cryptographic algorithms. Microprobing gives the attacker not only access to cryptographic keys, but also leads to full disassembler listings of the extracted security software. Availability of the full smartcard software then often allows the design of fast and simple non-invasive glitch and current analysis attacks, which -- unlike DPA-style attacks -- do not require many hundred seconds of protocol interactions. Such very fast non-invasive attacks can then be performed inconspicuously in a Trojan card terminal together with a normal transaction and without giving the card holder a chance to notice them. They form a serious additional threat over microprobing even for applications such as digital signature and banking cards, which do not rely on global keys stored in the card. Microprobing attacks can be carried out by skilled technicians starting with an investment of little more than ten thousand euros and they can then be repeated at rather low cost. Our paper not only describes the range of attack techniques that have been used in the past to break numerous commercially fielded security systems. We also suggest a number of lowest-cost countermeasures that will help to make many of these attacks considerably more challenging to perform. Some of these we believe to be new, while others have already been implemented in products but are either not widely used or the implementations we found had design flaws that allowed us to circumvent them more easily than would have been necessary. Online version of the paper: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf Presentation slides with more photos: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf [Important note to avoid misunderstandings: Our paper does *not* provide any comparative evaluation of the security mechanisms of specific products and it should not be quoted to that effect. We present a few interesting vulnerabilities in the security mechanisms of one commercial smartcard processor that we named. This processor is of particular interest primarily, because it features comparatively advanced security features not found in most other products. The reader should understand that in spite of the vulnerabilities that we outline, unmentioned competing products are not necessarily more secure. Indeed, many of them do not have these advanced security mechanisms implemented and are easier to break. Much easier.] Markus Kuhn -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> -- These are my opinions, not necessarily my employers.Article: 19878
XACT is/was the old place and route software. You can't buy it from Xilinx anymore. The 4000E series is supported with the current Foundation and Alliance tools however. Depending on the size of the 4000E series part, you may be able to use the student edition of the software. rmeenaks@olf.com wrote: > In article <387F648E.BC085735@olf.com>, > Ram Meenakshisundaram <rmeenaks@olf.com> wrote: > > Hi, > > > > I have a custom made transputer+DSP56K+XC4000E board that I want to > > start doing some simple hardware emulation. I bought the Xilinx > Student > > Edition Book with the corresponding software. I also downloaded some > > GPL software for Xilinx that uses XACT. Does the Student Edition come > > with XACT, if not which Xilinx product do I need to use XACT. Thanks. > > > > Ram > > > > PS: What exactly is XACT? > > > > Re-posted as the old subject seemed like I wanted some pirated software. > > Ram > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19879
Latch-up could be caused by feeding in higher than 5.6v on any pin. > >-- Sounds likely to me. Or it might be negative spikes (below 0.6 V). Try to invoke serial resistors of 2-10 ohms at suspected outputs. It might be necessary to at protection circuit (like 2 diodes conducting negative spikes to ground, postive spikes to Vcc) as well. Both positve and negative spikes could be caused by bad layout of the printed circuit board. Beware that FPGA's can hold a lot of flip-flops, that might change state synchronously. Thus the peak current can be huge, causing voltage drops to arise along the paths. Try improving your ground layout by soldering copper wires to and fro. The high peak current can also "cheat" serial regulators in a way, that makes the Vcc unstable. Use a good oscilloscope and see, if there are any ringings. Be careful to measure directly on the power pins of the FPGA - not from a ground reference somewhere else on the board. KrestenArticle: 19880
Does anyone know of an FPGA board with one (or even better, two) ethernet ports? If not, how about a programmable router? Please email if you know of any. Thanks, -DaveArticle: 19881
This is a multi-part message in MIME format. --------------BC2C392A65E8D9DF89D8476A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Barcelo wrote: > Does anyone know of an FPGA board with one (or even better, two) ethernet > ports? If not, how about a programmable router? > > Please email if you know of any. > Thanks, > -Dave Our XSV series of boards has a single Ethernet port. The PHY chip is an LXT970A and then a Virtex FPGA supplies all the higher-level MAC functions. --------------BC2C392A65E8D9DF89D8476A Content-Type: text/x-vcard; charset=us-ascii; name="devb.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave Vanden Bout Content-Disposition: attachment; filename="devb.vcf" begin:vcard n:Vanden Bout;David tel;fax:(919) 387-1302 tel;work:(919) 387-0076 x-mozilla-html:FALSE url:http://www.xess.com org:XESS Corp. adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA version:2.1 email;internet:devb@xess.com title:FPGA Product Manager x-mozilla-cpt:;28560 fn:Dave Vanden Bout end:vcard --------------BC2C392A65E8D9DF89D8476A--Article: 19882
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BF5FB7.454E9036 Content-Type: text/plain David Barcelo wrote: > Does anyone know of an FPGA board with one (or even better, two) ethernet > ports? If not, how about a programmable router? > > Please email if you know of any. > Thanks, > -Dave Our XSV series of boards has a single Ethernet port. The PHY chip is an LXT970A and then a Virtex FPGA supplies all the higher-level MAC functions. ------ =_NextPart_000_01BF5FB7.454E9036 Content-Type: text/x-vcard; name="devb.vcf" Content-Disposition: attachment; filename="devb.vcf" Content-Description: Card for Dave Vanden Bout begin:vcard n:Vanden Bout;David tel;fax:(919) 387-1302 tel;work:(919) 387-0076 x-mozilla-html:FALSE url:http://www.xess.com org:XESS Corp. adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA version:2.1 email;internet:devb@xess.com title:FPGA Product Manager x-mozilla-cpt:;28560 fn:Dave Vanden Bout end:vcard ------ =_NextPart_000_01BF5FB7.454E9036--Article: 19883
Dear All! I wonder if anyone know which FPGAs can be partly reprogrammable, so that one may reconfigure a part of the device while the rest of the device is still functioning. Has anyone of you any experience from this. Also I wonder if anyone knows what kind of research is being done in this area. Has anyone considered the concept of self-modifying blocks in FPGAs. Any information is greatly appreciated! Regards, Arvind Shah Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19884
In article <85r134$era$1@nnrp1.deja.com>, <arsh@x-stream.se> wrote: >Dear All! > >I wonder if anyone know which FPGAs can be partly reprogrammable, so >that one may reconfigure a part of the device while the rest of the >device is still functioning. Has anyone of you any experience from this. The Xilinx 6200 had really nice partial reconfiguration abilities, but the part is no longer being made and was only really interesting as a research tool. The Virtex has a column oriented partial reconfiguration, where you can reconfigure columns on the chip. Look on the Xilinx application notes for more detail. >Also I wonder if anyone knows what kind of research is being done in >this area. Has anyone considered the concept of self-modifying blocks >in FPGAs. Look through back proceedings of FCCM, a lot of work has been done on partial reconfiguration. Nobody that I know of really wants to do self modifying blocks, even though some proposed FPGAs were capable of it. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 19885
In article <38801333.206751B1@ids.net>, Ray Andraka <randraka@ids.net> wrote: > XACT is/was the old place and route software. You can't buy it from Xilinx > anymore. The 4000E series is supported with the current Foundation and > Alliance tools however. Depending on the size of the 4000E series part, you > may be able to use the student edition of the software. > I currently have the student edition and it supports my Xilinx XC4003E. What is the difference between the Alliance & the Foundation. Ram Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19886
In article <387CEE55.949A3FB7@pobox.com>, Marinos J. Yannikos wrote: >Peter da Silva wrote: >> I just checked around my net and while most systems were rebooted the weekend >> of 1/1/00 for political reasons, there's a few who escaped. I haven't found >> a UNIX box with an uptime below 10 days, and most are 50-150 days including >> some that are 10 year old 386 boxes. > >I have to ask out of curiosity: what exactly do you do with those >computers? They must consume an awful lot of power... I'm all for >retro-computing and putting old hardware to good use, but I draw >the border where the cost of operating the old systems is so high >that replacing several of them with a single new system makes sense. A lot of times it's just a machine that was setup way back when and hasn't been touched since since it kept on working. Linux users often like to think they're the only people doing this, but I've seen all sorts of random ancient systems that nobody's bothered with in years because it would take more energy to replace them with their newfangled potentially crashy counterparts than it takes to just let them sit and do hteir routing or print serving or floppy copying or whatever it is they're doing. I left behind a 386 modem server/firewall with my folks when I moved out and they haven't complained yet except that the power supply fan stopped working 6 months go (making an awful noise when it does spin, so they've taken to stopping it when it starts spinning every now and then). If it ain't broke, don't fix it.Article: 19887
In article <387b72f2_1@newsread3.dircon.co.uk>, Ian Kemmish wrote: >In article <387AD481.58C40A0C@ieee.org>, Khatib@ieee.org says... > >>SW programmers now also have high speed processors, large memories >>advanced compilers and visual tools. although all these resources are >>available for programmers, but -as I see- they do not improve their sw >>_in_the_same_ratio_as_the improvements_of_the_resources. For example all >>new sw versions need larger memories and faster processors without the >>increase of the functionality of the new version. This is because they > >This is simply not true. The latest version of Jaws was smaller than the last >previous version, and incpororated PostScript LanguageLevel 3 functionality. >Some people (and especially marketing departments and managers) feel small code >size is not important, but smaller programs do get fewer cache misses and TLB >misses, and depending on what you're running, this can make a perceptible >difference to performance. I don't even think that is the best argument. I mean, improved performance is nice, but the important thing is stability where I come from. So many times I've looked over old programs and realized that I could tear out half the code if I rearranged one datastructure or thought about something differently, and the result was both smaller and a lot easier to debug. Less code means less bugs. Ideally, computers wouldn't run any code at all. :) >Of course, economics being what it is, one only gets the opportunity for a >major code squeeze once or twice a decade. But it is fun to revisit old code >once in a while:-) Yeah, it is quite a pity when old code that was just a hack at the time is left behind because you don't have the time to go back and fix it up. Too bad many managers don't seem to understand that rewriting the old code at the heart of a program will often make the new extensions a thousand times simpler and smaller. >>Do you think like me? Do you know how can we prevent this? >>I think this can be prevented by following the Open Source and open >>Hardware design concepts in the design. You can read more about this >>idea in OpenIPCore Project at http://www.openip.org/oc > >Open Source is a large part of the problem, not part of the solution. > >Compact, fast and robust code is produced by Real Programmers, who either work >alone, or, as described in The Mythical Man Month, with a co-pilot. Ideally, >the Real Programmer develops on the slowest machine in the building and the >co-pilot tracks down bugs on the fastest machine in the building:-) > >Activities like Open Source, on the other hand, have a cast of thousands, and a >strong economic incentive to ship many flakey new versions and fix them on a >time and materials basis later on. If you want to see what results when you >apply a cast of thousands to an otherwise simple problem, look at the ICL 2900 >(my own choice for computer of the century, if only because we should never >forget the Great Disasters Of Computing). I agree 100% with what you have to say about open source there. Open Source is the embodiment of the "okay, it's just a hack, but it works and that's good enough for me, and nobody else has written it, so let's submit this for mass distribution" design methodology. It works, and there's nothing stopping a random third party from going back and cleaning it up, but it certainly doesn't guarantee any better code than popular commercial design methodologies.Article: 19888
Here are the parts that come to mind with partial reconfiguration: Atmel 6K series Atmel 40K series Xilinx 6200 Xilinx Virtex I think one of the Lucent families may also be partially reconfigurable, but I am not very familiar with their parts. Of those listed above, I think the Atmel parts have the best partial reconfiguration support in terms of tools (that's not saying they are very good, though). Partial reconfiguration carries with it a fairly large set of problems, many which have not been adequately solved for general use. Some of these problems include the need to know where not only the logic is placed for each block that is configured at different times, but also where the routing is so that you can connect to existing logic and avoid obliterating operating logic. The current tools make this quite painful to do the necessary partitioning, floorplanning and detailed route necessary. This is not to say it can't be done (it has many times...see my paper discussing a dynamic hardware video processor which takes advantage of partial reconfiguration, or any one of a number of papers on the BYU website). "Nicholas C. Weaver" wrote: > In article <85r134$era$1@nnrp1.deja.com>, <arsh@x-stream.se> wrote: > >Dear All! > > > >I wonder if anyone know which FPGAs can be partly reprogrammable, so > >that one may reconfigure a part of the device while the rest of the > >device is still functioning. Has anyone of you any experience from this. > > The Xilinx 6200 had really nice partial reconfiguration > abilities, but the part is no longer being made and was only really > interesting as a research tool. > > The Virtex has a column oriented partial reconfiguration, > where you can reconfigure columns on the chip. Look on the Xilinx > application notes for more detail. > > >Also I wonder if anyone knows what kind of research is being done in > >this area. Has anyone considered the concept of self-modifying blocks > >in FPGAs. > > Look through back proceedings of FCCM, a lot of work has been > done on partial reconfiguration. Nobody that I know of really wants > to do self modifying blocks, even though some proposed FPGAs were > capable of it. > > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19889
Foundation has design capture tools in the product. Alliance has libraries and the links to use third party tools, which are generally more sophisticated than the tools in the foundation product. rmeenaks@olf.com wrote: > In article <38801333.206751B1@ids.net>, > Ray Andraka <randraka@ids.net> wrote: > > XACT is/was the old place and route software. You can't buy it from > Xilinx > > anymore. The 4000E series is supported with the current Foundation > and > > Alliance tools however. Depending on the size of the 4000E series > part, you > > may be able to use the student edition of the software. > > > > I currently have the student edition and it supports my Xilinx > XC4003E. What is the difference between the Alliance & the > Foundation. > > Ram > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19890
Hi! Does anyone have a clue how to implement random number generator in XC4k family ? Thanks. Domagoj Babic domagoj.babic@fer.hrArticle: 19891
galexand@sietch.bloomington.in.us (Greg Alexander) writes: > I agree 100% with what you have to say about open source there. Open > Source is the embodiment of the "okay, it's just a hack, but it works and > that's good enough for me, and nobody else has written it, so let's submit > this for mass distribution" design methodology. It works, and there's > nothing stopping a random third party from going back and cleaning it up, > but it certainly doesn't guarantee any better code than popular commercial > design methodologies. That's true but irrelevant. The interesting thing is that popular commercial design methodologies certainly don't guarantee any better code than Open Source, despite many peoples expectations to the contrary, and some people's continued denials. -- Chris Morgan <cm at mihalis.net> http://mihalis.net Reply-To: "Kang Liat Chuan" <kanglc@cyberway.com.sg>Article: 19892
Try this site: http://support.xilinx.com/support/techsup/journals/timing/presentation/timin gcsts2_1i/index.htm <elynum@my-deja.com> wrote in message news:84u5lg$sa8$1@nnrp1.deja.com... > Does anyone know where I can get a good book or article on timing > diagrams? I haven't had a lot of experience when it comes to stuff like > timing violations as far as I need something that will explain how to > understand clock to output times, setup and hold times and their > importance in simulation. > > Thanks > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 19893
In article <87ln5qvyt0.fsf@think.mihalis.net>, Chris Morgan wrote: >galexand@sietch.bloomington.in.us (Greg Alexander) writes: > >> I agree 100% with what you have to say about open source there. Open >> Source is the embodiment of the "okay, it's just a hack, but it works and >> that's good enough for me, and nobody else has written it, so let's submit >> this for mass distribution" design methodology. It works, and there's >> nothing stopping a random third party from going back and cleaning it up, >> but it certainly doesn't guarantee any better code than popular commercial >> design methodologies. > >That's true but irrelevant. The interesting thing is that popular >commercial design methodologies certainly don't guarantee any better >code than Open Source, despite many peoples expectations to the >contrary, and some people's continued denials. So? That just means that neither of them alone are a solution to the problem individually. Open Source is good in that it allows any random Joe to use whatever methodology he wants to make someone else's code not bloated, but it does nothing at all to prevent the creation, distribution, and bloated code in the first place. Open Source is good, when combined with other methodologies, at addressing the bloat problem, but alone, it is not related to the bloat problem.Article: 19894
Linear feedback shift register counters will give you a pseudo random sequence of bits. The sequence repeats after 2^(n-1) counts for a maximal length sequence. See xilinx application note xapp052 for more details on implementation and description of the counters. The distribution of the output is uniform, with a slight bias due to the all '1's state being an illegal state of the LFSR counter. Note, that these really only produce one random bit per clock, as the remaining bits are time delayed copies of the first bit. A fairly common approximation is to use more than one bit, but be careful since this colors the spectrum. If you do choose to use more than one bit, the new bit should be the most significant of the output bits, so that the next output is y= b*2^n + 1/2*y(n-1) where b is the new random bit. If you bring the new bit in the lsb position, your output is y=2*y(n-1) + b, which is a noisy ramp function (which becomes a sawtooth because of modular arithmetic). A better generator uses separate LFSR counters for each bit, which care taken to make sure the seed values of the separate LFSRs are not near each other in the sequence. If you need other distributions, the uniform distribution can be used with other logic to generate the desired distribution either algorithmically (ie box-mueller algorithm for gaussian noise), using the uniform value to map to the desired distribution through a cumulative density function table, or by using the central limit theorem for gaussian distributions. Domagoj Babic wrote: > Hi! > > Does anyone have a clue how to implement random number generator > > in XC4k family ? > > Thanks. > > Domagoj Babic > domagoj.babic@fer.hr -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19895
many data sheets have diagrams showing the timing parameters relative to waveforms. Clock to Q is the time from the active clock edge to a valid output (generally we are interested in the max time here). Set-up time is the minimum amount of time required after input data is guaranteed valid and the active edge of the clock to guarantee the register will get the correct data. Hold time specifies the minimum period after the active edge of the clock for which the input data cannot be changed to guarantee the correct data is clocked into the register. In your timing analysis (for synchronous designs), your design will not fail due to timing problems if the correct data is present and stable at all clocked registers during the window defined by the set-up and hold times around the active clock edge. The data will be stable within that window if the sum of the propagation delays from one register to the next is less than the clock period. That sum of delays is the time from clock to output of the first register, the combinatorial and routing delay of any logic and wiring between that output and the next input, and the set-up time of the destination register. A hold time violation occurs if the new data arrives at the next register too soon. If the hold times are zero or negative (and clock has no skew), the hold time becomes a non-issue. There are instances where there are positive hold times, in which case one has to make sure the **minimum** delay on the data path is greater than the hold time. Since minimum delays are difficult to specify, we don't like to see positive hold times. Inside FPGAs, the manufacturer tries to keep the register hold times such that no hold time violations can occur in a synchronous design. Kang Liat Chuan wrote: > Try this site: > http://support.xilinx.com/support/techsup/journals/timing/presentation/timin > gcsts2_1i/index.htm > > <elynum@my-deja.com> wrote in message news:84u5lg$sa8$1@nnrp1.deja.com... > > Does anyone know where I can get a good book or article on timing > > diagrams? I haven't had a lot of experience when it comes to stuff like > > timing violations as far as I need something that will explain how to > > understand clock to output times, setup and hold times and their > > importance in simulation. > > > > Thanks > > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19896
Michael,
there was an article in EDN - May 27, 1999 - called Lies,
damn lies and Benchmarks pag. 54
author: Brian Dipert http://www.ednmag.com
The article should still be on their website! If you cannot locate it, I
will post it on request by e-mail.
(look at: http://www.ednmag.com/ednmag/verticalmarkets/PLD.asp )
regards,
Michel HEUTS
WMU Belgium
"Michael Eisenring" <eisenring@tik.ee.ethz.ch> wrote in message
news:387C9D45.D0EAC273@tik.ee.ethz.ch...
> Hi to everybody
>
> Does somebody know a library of FPGA benchmarks used for
> research?
>
> I would be pleased if I got to know where to look for it.
>
> Thanks.
> Michael
Article: 19897On Sun, 16 Jan 2000 18:01:53 GMT, Ray Andraka <randraka@ids.net> wrote: |Linear feedback shift register counters will give you a pseudo random |sequence of bits. The sequence repeats after 2^(n-1) counts for a |maximal length sequence. See xilinx application note xapp052 for more |details on implementation and description of the counters. The |distribution of the output is uniform, with a slight bias due to the all |'1's state being an illegal state of the LFSR counter. | |Note, that these really only produce one random bit per clock, as the |remaining bits are time delayed copies of the first bit. A fairly |common approximation is to use more than one bit, but be careful since |this colors the spectrum. If you do choose to use more than one bit, |the new bit should be the most significant of the output bits, so that |the next output is y= b*2^n + 1/2*y(n-1) where b is the new random bit. |If you bring the new bit in the lsb position, your output is y=2*y(n-1) |+ b, which is a noisy ramp function (which becomes a sawtooth because of |modular arithmetic). A better generator uses separate LFSR counters for |each bit, which care taken to make sure the seed values of the separate |LFSRs are not near each other in the sequence. | |If you need other distributions, the uniform distribution can be used |with other logic to generate the desired distribution either |algorithmically (ie box-mueller algorithm for gaussian noise), using the |uniform value to map to the desired distribution through a cumulative |density function table, or by using the central limit theorem for |gaussian distributions. | |Domagoj Babic wrote: | |> Hi! |> |> Does anyone have a clue how to implement random number generator |> |> in XC4k family ? |> |> Thanks. |> |> Domagoj Babic |> domagoj.babic@fer.hr Ray, in a similar discussion in comp.arch.embedded, somebody wanted a truly random (non-predictable) number at powerup time. One suggestion that evolved was as follows: Connect an RC (pullup to Vcc, cap to ground) to a pin and spin a counter or linear shift register until the pin goes high sometime after powerup (or after being pulled low tristate-wise.) Use an X7R cap, which has a terrible TC. If the RC time constant is long, the result (PRN reg contents, or some counter LSBs) is fairly random. Refinement: depending on some number of LSBs of the prievious timeout, reset the cap using a reset time scale that results in only partial discharge, then repeat the charge time thing. Serious chaos theory results, and something like real randomness can be had for just the price of one RC. John == A little nonsense now and then, is cherished by the wisest men. - Willy WonkaArticle: 19898
galexand@sietch.bloomington.in.us (Greg Alexander) writes: > >The interesting thing is that popular > >commercial design methodologies certainly don't guarantee any better > >code than Open Source, despite many peoples expectations to the > >contrary, and some people's continued denials. > > So? That just means that neither of them alone are a solution to the > problem individually. Open Source is good in that it allows any random > Joe to use whatever methodology he wants to make someone else's code not > bloated, but it does nothing at all to prevent the creation, distribution, > and bloated code in the first place. Right, this is correct, when a project is launched the code is often just something thrown together to get the ball rolling. The key thing is projects that flourish often have people who care enough to weed out the bad bits and improve the structure, without those people being beholden to any budget or deadline. > Open Source is good, when combined with other methodologies, at > addressing the bloat problem, but alone, it is not related to the > bloat problem. Well, I wouldn't go that far, as Open Source guarantees you the right to replace some bloaty piece of junk with your beautifully spare and elegant replacement ;^) Chris -- Chris Morgan <cm at mihalis.net> http://mihalis.netArticle: 19899
While the LSBs may be random, I think for one particular cap under the same conditions, you will get similar results. I suspect the distribution would be gaussian with a fairly small variance for a given set of conditions. Many many years ago I tried using a blinking incadescent lamp (you know, the kind with the bimetallic strip in it) to generate a random gate for a counter to get random numbers (this was in the mid '70's). While it did get random numbers, the distribution was fairly tight for a given bulb once the bulb had cycled a few times. I would expect the capacitor probably has a tighter distribution. If you can put a real-time clock somewhere in the system, you can use it to seed an LFSR with quite good results. John Larkin wrote: > in a similar discussion in comp.arch.embedded, somebody wanted a truly > random (non-predictable) number at powerup time. One suggestion that > evolved was as follows: > > Connect an RC (pullup to Vcc, cap to ground) to a pin and spin a > counter or linear shift register until the pin goes high sometime > after powerup (or after being pulled low tristate-wise.) Use an X7R > cap, which has a terrible TC. If the RC time constant is long, the > result (PRN reg contents, or some counter LSBs) is fairly random. > > Refinement: depending on some number of LSBs of the prievious timeout, > reset the cap using a reset time scale that results in only partial > discharge, then repeat the charge time thing. Serious chaos theory > results, and something like real randomness can be had for just the > price of one RC. > > John > > == > > A little nonsense now and then, > is cherished by the wisest men. > > - Willy Wonka -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randraka
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