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
On Tue, 09 Dec 1997 15:20:19 -0500, Emmanuel Monnerie <monnerie@oconee.em.slb.com> wrote: >I need a 12 bit analog to digital converter running at 33 Msamples/sec >Do you know a manufacturer able to provide this? > >Thanks >Emmanuel For very fast ADCs look at www.spt.comArticle: 8351
>By all means suggest it, but I'd love to know why this should be so? I am going to get flames for this, I can see it now, but Marketing have been known to do worse things, e.g. charging $1000s for in-house P&R software which cannot be used for anyone else's silicon. I have done a fair bit of FPGA prototyping for ASICs. These had to be very low power, e.g. 500uA at 2MHz for a 5000-gate design. A XC3090 prototype drew about 25mA. Much of the difference is due to the extra capacitance of the FPGA muxes etc. But *most* of it is due to the need to use the *global* clock net in the FPGA version. The key to reducing dynamic Icc is to gate clocks, and this is dangerous in today's fast Xilinx parts. (It used to work fine a few years ago, but not any more). Personally I think an easy dynamic Icc calculator would be a great help, and any sales lost would be those for which an FPGA would be unsuitable anyway. But then I would have thought that one would sell more silicon by charging less for the software, too. Peter. Return address is invalid to help stop junk mail. E-mail replies to z80@digiXYZserve.com but remove the XYZ.Article: 8352
In article <348DFF54.B0B1822F@CatenaryScientific.com>, Chuck Parsons <chuck@CatenaryScientific.com> writes > > O.K. Jay I note your credentials and I'm probably wrong but, I'm >not convinced. In fact, I'm quite sure of the opposite. Specifically, >I agree with your statement if you are calculating the number of >times a metastable event occurs. Or if you will, the integral of >P(t)dt were P(t) is the probability that a signal of fixed rise time >arriving at time t will cause a metastable event. Noise will increase >the width of P(t) by bumping early and late events into the metastable >region and decrease the amplitude of P(t) by bumping events out. For >small noise in a linear region the area will remain constant. > > But if you consider the length of the metastable events the same is >not true. At least not for all forms of noise. Once the system as >been perturbed off of the metastable point _positive_ feedback drives >it farther from the metastable point, and for modern logic in very sub >nanosecond times to the point were the noise can't reach the metastable >region anymore. Metastable events stay around in the sensitive region >by definition, non metastable events do not. Rather like useful and useless electrons in a cavity magnetron. Pity it doesn't apply to NG contributors. >If you bounce a basketball >in a room full of bats the balanced ones fall over, but the ones lying >on the floor do not jump up and balance themselves. Hey, bats are tiny things! If you hit one with a basketball, of course it won't be able to get up off the floor and balance itself! In any case, they are mostly protected species, so you mustn't attack them with basketballs. > -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. It is useless to threaten a strong man - he will ignore you. It is dangerous to threaten a weak man - he will kill you if he can.Article: 8353
Hi, Check out with Analog Devices, we are using their AD6742 (D/A) and AD6640 (A/D) at 52MHz they are 12 bit bipolar TTL compatible circuits. regards, Farhad A. On Tue, 09 Dec 1997 15:20:19 -0500, Emmanuel Monnerie <monnerie@oconee.em.slb.com> wrote: >I need a 12 bit analog to digital converter running at 33 Msamples/sec >Do you know a manufacturer able to provide this? > >Thanks >Emmanuel *-------------------------------------* * Farhad Abdolian * * Stockholm/Sweden * * Please remove NOSPAM_ from e-mail * * address before replying * *-------------------------------------*Article: 8354
Hi,
I'm doing the board level schematics for an XC6264 design, but it will
be a while before I can get my hands on the XC6200 tools in order to
take a look at the chip using the editor. I'm wondering if somebody
can help me out here:
I need two 30-bit busses, north[] and south[], coming from the north
and south sides of an XC6264-HQ240. I note that the package pins are
in a funny order on the edges of the chip, going by their names - for
example:
... n40 n39 n13 n15 ...
In order to make designs downloaded into the chip amenable to
floorplanning, and to ease routing, should I 'sort out' the pins into
ascending name order and assign bus bits accordingly? For example, the
north[] bus:
...
pin n40 = north[22]
pin n39 = north[21]
pin n13 = north[1]
pin n15 = north[3]
...
Or, do I just assign bus bits according to the physical position of
the package pins (seems to defeat the purpose of the funny naming
order).
Can anybody give me some pointers?
Thanks in advance for any help.
Tomas
(apologies for anti-spam e-mail address in header of article, remove
.nospam for correct address)
Article: 8355I'm trying to obtain a combinational multiplier using a Xilinx FPGA. Can anybody give me some references about good structures for the multiplier? Thanks in advance. CarmenArticle: 8356
In article <348DFF54.B0B1822F@catenaryscientific.com>,
Chuck Parsons <chuck@CatenaryScientific.com> writes:
>
> Answer: Far less than 1%
>
As one who has been personally smacked in the head, and spent the
better part of a year in agony over "realized metastability," I
must agree with Jay.
"Far less than 1%" just isn't enough. Take the simple case of an
EDO RAM running at a measly 30 nS CAS cycle time.
1.0% metastability incidence means you fail in 3 uS.
0.1% metastability incidence means you fail in 30 uS.
0.01% metastability incidence means you fail in 300 uS.
Quit using percent, it's time for parts per million.
100 ppm metastability incidence means you fail in 300 uS.
10 ppm metastability incidence means you fail in 3 mS.
1 ppm metastability incidence means you fail in 30 mS.
We're WAY below 1% and we've only gotten to the boundary of
"human time," and you want 24X7 reliability.
There are two other aspects to this:
1: You don't tend to get access to "excess technology." The
technology you get tends to be "just enough" to get the
job done. There just isn't a store of extra speed to spare
to handle metastability problems. That extra nanosecond
you need for resolution has to be bought elsewhere in the
design - potentially very hard work.
2: The biggest injectors of noise into the system - one other
way cited in this thread of getting out of metastability,
tend to be your own power supplies. In this case, the noise
they tend to inject is just the kind that pushes you toward
metastability, not away from it.
3: Murphy is against you. My particular problem I likened to a
tiny hole in an armor wall. Even after discovering the hole,
I still felt it was nowhere near the target where the user
of my part should be shooting. Only problem - people don't
read the specs. They put things together and if it works
with some set of parts from some set of suppliers, hang the
specs. They were shooting at my "armor wall" with a machine
gun - forget the target, just keep the bullets on the wall.
Shoot enough bullets and you'll find any hole, no matter
how tiny.
Theory is nice. Theory is good. Even I use it. But in the real
world, theory must be supplemented with paranoia. (Grove said
something about that too, though not in exactly the same context.)
Dale Pontius
(NOT speaking for IBM)
Article: 8357John Cooley wrote: > Rick, for personal financial reasons I have to disagree with your cautions > about using software engineers to design hardware. As an EDA consultant, > I've made an awful lot of money from projects that used software engineers > to design hardware using Verilog/VHDL to implement some algorthm they > knew which they later tried to just pump through Synopsys. These are > gravy consulting dollars -- please don't "dis" the project managers stupid > enough to slap together a team of mostly software designers to make hardware! > My bank account LOVES managers like these!!!! :^) I've seen it different. I sit here at Siemens, and most of my past experience is software. I constantly say to the product specifiers (which are hardware guys) "Don't put this all in hardware, you can do it in software, it makes live much easier" - they do it anyway. Only few people manage to put the features at the right place in the hierarchy (most of the time the right place is some levels up), and often those are not hardware people. Hardware people often design as if software people were stupid. "Let's do all for them so they can't fail". This leads to bloated hardware and certainly your bank account would love it, since deadlines are hard to meet. Or perhaps it's just that this department is new and the experience level isn't that high. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/Article: 8358
HDL Designers: ED4W-HDL is a Window95/NT productivity Editor, tailored specifically for the VHDL/Verilog design engineer. ED4W-HDL is currently being upgraded to enhance its HDL productivity features. This is YOUR chance to have a say in what features you would like to see in this editor. Obviously, the most requested enhancements will receive the most attention. If you are not sure what ED4W-HDL is, (and there are still some of you left!) then take a quick look at http://www.silicon-systems.com/prod01.htm Please submit your requests to support@silicon-systems.com If you are interested in becoming a beta release site for the new release, please let us know! AtDhVaAnNkCsE -JohnArticle: 8359
Depending on your design environment, you may want to contact your local Xilinx sales guy to obtain their latest core generator. They demonstrated at some seminars last summer. It supports a variety of combinatorial multipliers and even very fast and efficient multiply-by-a-constant functions. The version that I saw ran only on the PC and worked with the Xilinx Foundation Series products. It also has support for DSP-like functions for FIR filters, correlators, etc. ----------------------------------------------------------- Steven K. Knapp OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally" E-mail: sknapp@optimagic.com Web: http://www.optimagic.com ----------------------------------------------------------- Carmen Baena Oliva wrote in message <348E7CE1.EF786F5B@cnm.us.es>... >I'm trying to obtain a combinational multiplier using a Xilinx FPGA. >Can anybody give me some references about good structures for the >multiplier? > >Thanks in advance. >Carmen >Article: 8360
Bernd,
Not to speak for John (not that anybody could or should),
but I think he's talking about a different problem. You're speaking
about the hardware/software partitioning issue which most agree should
involve both sides of the picture, both hardware and software
people, to determine what parts of the functionality should be placed
in either environment. I think your experience is typical,
hardware/software partitioning seems to be the next big hurdle for the
industry. Or at least everybody is talking about it.
The problem comes when one describes an algorithm in VHDL (or
any HDL) without knowing something about how you want it to be built.
Generally, if you do that, the synthesis tools come up with a bad
solution - too big, too slow, or both. If you want an efficient
hardware soultion from todays synthesis tools, you better have some
hardware experience and write the VHDL descriptions such that it drives
the tools in the direction you want them to go.
This is not to say that some software engineers can't do this,
its just that some definitely can't, and that's where John comes in...
Bob
In article <348E9A95.78B5@remove.informatik.this.tu-muenchen.junk.de>, Bernd Paysan <paysan@remove.informatik.this.tu-muenchen.junk.de> writes:
|> John Cooley wrote:
|> > Rick, for personal financial reasons I have to disagree with your cautions
|> > about using software engineers to design hardware. As an EDA consultant,
|> > I've made an awful lot of money from projects that used software engineers
|> > to design hardware using Verilog/VHDL to implement some algorthm they
|> > knew which they later tried to just pump through Synopsys. These are
|> > gravy consulting dollars -- please don't "dis" the project managers stupid
|> > enough to slap together a team of mostly software designers to make hardware!
|> > My bank account LOVES managers like these!!!! :^)
|>
|> I've seen it different. I sit here at Siemens, and most of my past
|> experience is software. I constantly say to the product specifiers
|> (which are hardware guys) "Don't put this all in hardware, you can do it
|> in software, it makes live much easier" - they do it anyway. Only few
|> people manage to put the features at the right place in the hierarchy
|> (most of the time the right place is some levels up), and often those
|> are not hardware people. Hardware people often design as if software
|> people were stupid. "Let's do all for them so they can't fail". This
|> leads to bloated hardware and certainly your bank account would love it,
|> since deadlines are hard to meet.
|>
|> Or perhaps it's just that this department is new and the experience
|> level isn't that high.
|>
|> --
|> Bernd Paysan
|> "Late answers are wrong answers!"
|> http://www.informatik.tu-muenchen.de/~paysan/
--
-------------------------------------------------------------------------
Bob Klenke, Ph.D., Principal Scientist Dept. of Electrical Engineering
University of Virginia
http://csis.ee.virginia.edu/~rhk2j Charlottesville, VA 22903-2442
-------------------------------------------------------------------------
Article: 8361In article <66m579$159i$1@mdnews.btv.ibm.com>, Dale Pontius <pontius@btv.MBI.com> writes > >2: The biggest injectors of noise into the system - one other > way cited in this thread of getting out of metastability, > tend to be your own power supplies. In this case, the noise > they tend to inject is just the kind that pushes you toward > metastability, not away from it. Please enlarge on how there can be two different kinds of noise. This is a serious question, not sarcasm. > >3: Murphy is against you. Murphy is ALWAYS against you. If not, he changes sex and gets a different name. But that is a one-time event. -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. It is useless to threaten a strong man - he will ignore you. It is dangerous to threaten a weak man - he will kill you if he can.Article: 8362
C A L L F O R P A P E R S
THE SIXTH ANNUAL
IEEE SYMPOSIUM ON FIELD PROGRAMMABLE
CUSTOM COMPUTING MACHINES
Napa, California
April 15-17, 1998
http://www.fccm.org
PURPOSE: To bring together researchers to present recent work in the
use of reconfigurable logic as computing elements. This symposium
will focus primarily on the current opportunities and problems in this
new and evolving technology for computing. Contributions are
solicited on all aspects of custom computing, including but not
limited to:
Architecture of reconfigurable computing devices and systems,
including coprocessors, attached processors, and hybrids.
Languages, compilation techniques, tools, and environments for
programming and run time support;
Application domains;
Prototyping for architecture emulation.
SUBMISSIONS: Authors are invited to send submissions for either full
length papers (10 page maximum) or extended abstracts (2 page maximum)
for posters by January 5, 1998, to Jeffrey Arnold. Notification of
acceptance will be sent in early March. Final papers will be due on
the first day of the Symposium. The proceedings will be published
following the Symposium.
Authors are encouraged to submit PostScript, Microsoft Word, or
FrameMaker manuscripts by FTP. For instruction on electronic
submission, please see the Web page or contact Jeffrey Arnold
(jmarnold@znet.com).
SPONSORSHIP: The IEEE Computer Society and the Technical Committee on
Computer Architecture.
CO-CHAIRS:
Kenneth L. Pocek
Intel
Mail Stop RN6-18
2200 Mission College Boulevard
Santa Clara, California 95052
Voice: 408-765-6705 Fax: 408-765-5165
kenneth_pocek@ccm11.sc.intel.com
Jeffrey M. Arnold
10686 Mira Lago Terrace
San Diego, CA 92131
Voice: 619-547-9257 Fax: 619-547-9010
jmarnold@znet.com
PROGRAM COMMITTEE:
Peter Athanas, Virginia Tech.
Donald Bouldin, University of Tennessee, Knoxville
Duncan Buell, Center for Computing Sciences
Michael Butts, Quickturn Design Systems, Inc.
Steve Casselman, Virtual Computer Corp.
Pak Chan, Univ. California, Santa Cruz
Apostolos Dollas, Technical Univ. of Crete
Scott Hauck, Northwestern Univ.
Brad Hutchings, Brigham Young Univ.
Tom Kean, Xilinx, Inc. (U.K).
Phil Kuekes, HP Labs.
Wayne Luk, Imperial College
John McHenry, NSA
Robert Parker, Institute for Information Sciences
Herman Schmit, Carnegie Mellon University
Mark Shand, Digital Equipment (Paris)
Satnam Singh, Xilinx
Stephen Smith, Altera Corp.
--
Jeffrey M. Arnold jma@super.org or jmarnold@znet.com
10686 Mira Lago Terrace Tel: 619-547-9257
San Diego, CA 92131 Fax: 619-547-9010
USA
Article: 8363I've been wondering: If you were to build a Z80 microprocessor in FPGA, what would be the maximum clockspeed the processor could run at? Anyone have some information on this subject? Kind regards, PieterArticle: 8364
In article <SAM.97Dec9201758@colossus.stdavids.picker.com>, sam@stdavids.picker.com (Sam Goldwasser) writes: > Right, but some people would prefer to wait forever than get an incorrect > response. With the synchronizer, you get a response quickly, but it may > be incorrect! :-). In many cases, waiting too long turns into incorrect operations. Consider the simple case of processing a serial data bit. If you don't process it before the next bit arrives the data stream (byte, packet, whatever) gets corrupted. Consider memeory refresh. If you don't refresh memory in time the bits stored there may get corrupted.Article: 8365
Emmanuel Monnerie wrote: > > I need a 12 bit analog to digital converter running at 33 Msamples/sec > Do you know a manufacturer able to provide this? > > Thanks > Emmanuel Try the Analog Devices AD9042. It's 12bits at 41MSPS. Tim -- "...for we could not now take time for further search or considerations: our victuals being much spent, especially our beere." -- from the 1620 diary of a pilgrim on the Mayflower, referring to the rough weather as the ship neared Plymouth Rock please move the dot in my return address to read analog dot comArticle: 8366
In article <SCm4O0AIIsj0Ewzg@jmwa.demon.co.uk>,
John Woodgate <jmw@jmwa.demon.co.uk> writes:
> In article <66m579$159i$1@mdnews.btv.ibm.com>, Dale Pontius
> <pontius@btv.MBI.com> writes
>>
>>2: The biggest injectors of noise into the system - one other
>> way cited in this thread of getting out of metastability,
>> tend to be your own power supplies. In this case, the noise
>> they tend to inject is just the kind that pushes you toward
>> metastability, not away from it.
>
> Please enlarge on how there can be two different kinds of noise. This is
> a serious question, not sarcasm.
The external system may inject noise, or you may make the noise
yourself. Any noise you make is likely to have some correlation
with what you are doing, and according to Murphy will be at the
precisely right time and polarity to hurt you. So one of those
operations, your number will come up.
Someone else asked me to "quantify fail rates" for a DRAM. You
just can't do that, because there is no acceptable fail rate
expressable in ppm. A million operations at 33 MHz only gets
you up to 30 mS, when sometimes you'd like to run 24X7 for an
entire quarter on a server. OK, the math is simple:
13weeks*7days*24hours*60minutes*60seconds*33e6ops/second=2.6e14
Planning for anything other than zero is unacceptable. Time teaches.
Dale Pontius
(NOT speaking for IBM)
Article: 8367In article <34945dda.124293334@news.netcomuk.co.uk> z80@ds.com (Peter) writes: >I think you are right. > >The only factor which guarantees the *eventual* exit from a metastable >state is thermal noise, so injecting some is going to help a lot. > >As to predicting how much it will help, I don't know. Probably many >orders of magnitude. > Unfortunately, noise makes things worse (as with most everything else electronic). The reasons are quite non-intuitive. Very interesting theory (but more importantly measured hard data) can be found in: Portmann, C.L. et al. "Supply noise and CMOS synchronization errors" IEEE JOURNAL OF SOLID-STATE CIRCUITS Sept. 1995. vol.30, no.9, p. 1015-17 My limited understanding of the issue follows (I expect someone from mjohnson.com to correct the innacuracies): The most intuitive reason on why injecting noise does not work, is that if it did work companies would not be still trying to build ms hardened flops. A more hand-waiving argument is that trying to resolve metastability with noise, is similar to trying to resolve it with shifting the threshold of the logic following a metastable flop. It is also similar to trying to resolve metastability by inducing jitter on the sampling clock & data. Precisely timed "noise" might resolve a flop that stayed metastable up to the time instant of the "pre-medidated" noise injection, but it might slow the regeneration of a flop that started to resolve earlier. Since the probablity of metastability drops exponentially with waiting time the obvious conclusion is that you might help few events but you will hurt many more. In addition, supply noise will reduce the transconductance of the regenerating elements with predictably detrimental effects on T0, and tau. My $.02, -- StefanosArticle: 8368
jayl@latticesemi.com (Jay Lessert) writes: >It doesn't matter. By definition, noise is just as likely to bump the >flipflop *into* metastability as to bump it *out*. Think about it. This is probably true, but it might be that noise changes the distribution of the times of metastability. -- glenArticle: 8369
In article <EKw6yH.5C0@world.std.com>, John Cooley <jcooley@world.std.com> wrote: >ram <rmcbain@dynavision.com> wrote: >> >>Your looking for guidance from software engineers makes me nervous :) >> >>Certainly, there's some merging of methodologies that makes sense, but >>let's make sure it's driven by hardware people who understand "big" >>software. In my experience, few software (computing science) people can >>learn or understand hardware (enough to be really useful to a hardware >>type, anyways). I've had too many bad experiences... I have to agree with you (and I am essentially a software person who understands a lot of hardware). On the other hand, finding hardware people who understand BIG software is really *hard*; almost as hard as find software people who understand hardware. >> >>On the software side, I see them still not having a concept on how to >>use pictures to describe a design. It's only in the last year or so >>that state machines became popular there; and they still haven't figured >>out how to link a high level data flow or object model diagram to the >>actual compilable software (at least not in any widely successful >>way).... which is something we've been doing in hardware for years. And the usual example I use is documentation. Hardware people know how, software people don't. Look at the spec sheets for a (trivial) 2-input nand gate, compare to the spec sheet for any software component. Hardware people, as a matter of course, characterize behaviour under extreme conditions and specify limits; software people don't even bother to specify normal bahaviour in detail. >Rick, for personal financial reasons I have to disagree with your cautions >about using software engineers to design hardware. As an EDA consultant, >I've made an awful lot of money from projects that used software engineers >to design hardware using Verilog/VHDL to implement some algorthm they >knew which they later tried to just pump through Synopsys. These are >gravy consulting dollars -- please don't "dis" the project managers stupid >enough to slap together a team of mostly software designers to make hardware! >My bank account LOVES managers like these!!!! :^) Could I join your practice and help clean up the software started by hardware people? Actually, the worse software messes are by software people who *think* they understand big software. Oh well, back to the grind stone. -- Stanley.Chow@pobox.com (613) 763-2831 Me? Represent other people? Don't make them laugh so hard. Yes, it really is Stanley Chow, don't blame Raymond.Article: 8370
John Woodgate wrote:
> In article <66m579$159i$1@mdnews.btv.ibm.com>, Dale Pontius
> <pontius@btv.MBI.com> writes
> >
> >2: The biggest injectors of noise into the system - one other
> > way cited in this thread of getting out of metastability,
> > tend to be your own power supplies. In this case, the noise
> > they tend to inject is just the kind that pushes you toward
> > metastability, not away from it.
>
> Please enlarge on how there can be two different kinds of noise. This is
> a serious question, not sarcasm.
[ Please excuse any accidental similarity between this post and an answer to
John's question. Which I would like to see as well.
His words "different kinds of noise" prompt me to expound on that a bit.]
Sure John, I know you are not directing this question at me, and I'm
not sure how to create noise that pushes you towards metastabilty, if
you don't know the state of the system. But it is possible, to create
noise that on average pushes you away from metastability. Without
knowing the state of the system! But merely its dynamic behavior. I think
a few words on this, are not wasted.
There are many ways noise can be different in this particular problem.
First off I am using the term loosely to include pickup or interference as
well as the intrinsic noise of the circuit components. This is a very
important distinction because it does not have to be random.
Second, the amplitude and frequency of the noise can be significantly
different. Obviously, as we all know putting a capacitor across a
resistor significantly changes the frequency distribution of the Johnson noise
without changing the RMS average value of it.
Why would the frequency of the noise make it different for this problem?
Because of the natural response time of the flip-flop system. Just to pick a
definite number let us say that the flip flop rise times inside a chip are 100ps.
The exact number isn't important. If the noise has a cutoff frequency due to
filtering of 1MHz, then the response of the circuit is very fast compared to the
frequency of the noise. If the noise moves the circuit significantly off the
metastable point, the circuit will have plenty of time to "latch" before the
noise can change sign. On the other hand if we have very high frequency
noise of say 100GHz, the response of the circuit will be slow compared to
the noise and it will effectively become an integrator. The circuit when
disturbed off the metastable point by the noise will not have time to begin
moving before the noise randomly changes sign and pretty much cancels
itself out. For this last kind of noise I can agree that the chances of pushing you
towards metastability are (almost) the same as pushing you away. However,
while the net effect may be small, it will always average out to be a net push
"away from metastability".
Why would the amplitude of the noise make a difference? For two reasons,
one by definition the first order response of any system to perturbations around
a metastable point will be zero. The net positive feedback will therefore be
determined by the second derivative of the response function, and therefore
basically be related to the amplitude squared of the noise, not the amplitude.
Large perturbations well sweep the system quickly out of the metastable region
much more quickly than small ones.
Very important point, for points in the system outside the metastable region
the first derivative of the response function is not zero. This makes the
probability that
the noise puts the system back into the metastable state much less that the
probability
of moving it out of the metastable state. In simple terms, it is because the system
won't "wait" for the noise but is racing for the supply rails.
Another way that the noise amplitude is important is that, we have all been
assuming
that the noise is not enough to transition the system from a latched state into the
metastable state. I don't think there is much point in discussing that situation,
though
it is obviously possible. The math in that situation changes drastically, because
now the non-metastable events will "wait" in the latched condition to be kicked
into the metastable state.
We all remember the random walk problem, and perhaps you have also seen the
problem rendered as a drunk who falls down, and gets up going a random direction.
In this problem, near a metastable point the drunk starts out at the top of a hill,
and
every time he goes down the hill he speed up and starts running but every time he
goes up
the hill he slows down and starts crawling.
Chuck
Article: 8371John Woodgate wrote: > Rather like useful and useless electrons in a cavity magnetron. Pity it > doesn't apply to NG contributors. > Who could he mean ;-) > >If you bounce a basketball > >in a room full of bats the balanced ones fall over, but the ones lying > >on the floor do not jump up and balance themselves. > > Hey, bats are tiny things! If you hit one with a basketball, of course > it won't be able to get up off the floor and balance itself! In any > case, they are mostly protected species, so you mustn't attack them with > basketballs. > > Ahh good point, I am not a bat basher! In fact I would like to build a cozy home for them and encourage them to grow fat on the summer mosquitoes in our yard on the lake. Might be kind of fun to build a down converter and listen to their echo location as well.Article: 8372
Nothing tricky about the installation procedure. You just have the unfortunate bad luck to find out that M1.3 does not support the xc5200 family. M1.4 does, but it is still in beta. I still use XactStep6 for xc3k and xc5200 designs. best of luck, tom --- Tom Curran Memec Design Services Garden Valley, CA Branch url: www.memecdesign.com email: tom_curran@memecdesign_dot_comArticle: 8373
In article <348F33F5.2343F99D@CatenaryScientific.com>, Chuck Parsons <chuck@CatenaryScientific.com> writes > > > Ahh good point, I am not a bat basher! In fact I would like to build a >cozy home for them and encourage them to grow fat on the summer >mosquitoes in our yard on the lake. Might be kind of fun to >build a down converter and listen to their echo location as well. > I can tell you that it is absolutely fascinating. I don't have one myself, but I know someone who has. We get only pipistrelles here at the edge of suburbia, but they put on a flying display most evenings in July. -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. It is useless to threaten a strong man - he will ignore you. It is dangerous to threaten a weak man - he will kill you if he can.Article: 8374
In article <66n2v2$16ve$2@mdnews.btv.ibm.com>, Dale Pontius <pontius@btv.MBI.com> writes >In article <SCm4O0AIIsj0Ewzg@jmwa.demon.co.uk>, > John Woodgate <jmw@jmwa.demon.co.uk> writes: >> In article <66m579$159i$1@mdnews.btv.ibm.com>, Dale Pontius >> <pontius@btv.MBI.com> writes >>> >>>2: The biggest injectors of noise into the system - one other >>> way cited in this thread of getting out of metastability, >>> tend to be your own power supplies. In this case, the noise >>> they tend to inject is just the kind that pushes you toward >>> metastability, not away from it. >> >> Please enlarge on how there can be two different kinds of noise. This is >> a serious question, not sarcasm. > >The external system may inject noise, or you may make the noise >yourself. Any noise you make is likely to have some correlation >with what you are doing, and according to Murphy will be at the >precisely right time and polarity to hurt you. So one of those >operations, your number will come up. H'mm. I agree at the practical level, but it's not an explanation. > >Someone else asked me to "quantify fail rates" for a DRAM. You >just can't do that, because there is no acceptable fail rate >expressable in ppm. A million operations at 33 MHz only gets >you up to 30 mS, when sometimes you'd like to run 24X7 for an >entire quarter on a server. OK, the math is simple: > >13weeks*7days*24hours*60minutes*60seconds*33e6ops/second=2.6e14 That is a useful and important point. > >Planning for anything other than zero is unacceptable. Time teaches. > >Dale Pontius >(NOT speaking for IBM) But you have just pointed out that we are in a situation analoguos to thermodynamics: 1. You cannot win, you can only break even. 2. You can only break even at absoulte zero. 3. You cannot reach absolute zero. For metastability: 1. You cannot avoid metastability, you can only escape from it quickly. 2. You can only escape quickly by using noise perturbation. 3. Noise perturbation can create metastability. Perhpas we should give up digital altogether, and go back to analogue. -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. It is useless to threaten a strong man - he will ignore you. It is dangerous to threaten a weak man - he will kill you if he can.
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