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
Yes, but if a particular edge of the injected signal was just right to push it *into* a MS state (which is quite possible) then the next edge (of that injected signal) is guaranteed to push it *out* of that state. And you won't need a strong signal either, because the MS state is an extremely fine balance between the two energy levels. >It it was in exactly a metastable position. What if it was on its way >to one of the stable states, but then got pushed back to MS state? -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 14051
z80@ds2.com (Peter) writes:
> Yes, but if a particular edge of the injected signal was just right to
> push it *into* a MS state (which is quite possible) then the next edge
> (of that injected signal) is guaranteed to push it *out* of that
> state.
But the same situation could happen at next edge. Just getting out of
MS, when the next edge comes and put it back in there. I'm not saying
it's *likely' to happen, but the entire MS situation isn't either... :-)
> And you won't need a strong signal either, because the MS state is an
> extremely fine balance between the two energy levels.
*If* the F/F was exactly in the MS state when the edge occur. I was
imagining a situation where it was X joule below the MS state, and the
edge adds exactly X joule.
Or I could be completley wrong.
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 14052In a previous article z80@ds2.com (Peter) writes: : ; :Yes, but if a particular edge of the injected signal was just right to ;push it *into* a MS state (which is quite possible) then the next edge :(of that injected signal) is guaranteed to push it *out* of that ;state. : ;And you won't need a strong signal either, because the MS state is an :extremely fine balance between the two energy levels. The worse case is when the first edge drives it across to the other side and then the next edge drives it back. If left along, the FF may be in a state such that it will drift into a legal region by the time you need to sample it, but the noise prolonged its stay in the illegal region.Article: 14053
Silicon Systems Solutions have released 'ED for Windows for HDL EXPERT' for advanced VHDL editing. Features include: -Automatic Hierarchy extraction and display -Automatic Testbench generation -Colorised keyword -automatic language templates Check out http://www.silicon-systems.com/editore.htm for more details, and free evalution of standard version. Be patient, there are a number of detailed screen shots on there! -JohnArticle: 14054
Damn. You are right. I concede defeat. :) Yes, it is right back to the old statistical argument, no matter what you do. >But the same situation could happen at next edge. Just getting out of >MS, when the next edge comes and put it back in there. I'm not saying >it's *likely' to happen, but the entire MS situation isn't either... :-) -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 14055
rk heeft geschreven in bericht <36934FF2.234F64BD@NOSPAMerols.com>... > >independent of what the design flaw is, assuming that a circuit is good until >proven guilty is really a crime against humanity and you shouldn't really have >anything to do with electronics, in my opinion. in practice, one should follow >barto's law: EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL PROVEN INNOCENT! I was reading some postings further down this thread, postings I was not supposed to read... while I actually was skipping posts in this thread for quite a while already. So I started to track the messages backwards, to see what I had missed. Yesterday I picked up a recommended article on metastability, because I had no idea what this was all about. Until this thread started, I never realized that metastability existed (!). The article explained it well enough for me to understand. I suppose if I had to design a *plasma-regenerating-warp-core-stabilizer* for the next generation of *enterprise starships* I would be a bit more careful about my designs, not because of possible metastability but for more down to earth reasons, such as - but not limited to - simply staying within ac/dc specifications to avoid blowing the top of chips. Fact is, I am designing relatively simple uP boards. I even have to write the software for it. My designs aren't 100% reliable, mostly because I haven't removed all software flaws yet. I can understand that one can get excited about metastability, but *I* couldn't care less. The article I have read, showed an example where an improvement was suggested, putting 2 d-flipflops in cascade, resulting in 1 occurence of metastability once every 2 million years. Although very interesting, I am not even considering that advice for my future designs, because I like to see this metastability-thing at least once in my life. Still, I don't think I am irresponsible. I am not designing medical life support systems. I do not design stuff for airplanes. I dont know anything about satellite and spaceships. But I do know my designs are more than adequate for their purposes. My point is, there's nothing wrong about different opinions regarding metastabilty. And why is everbody always designing such delicate apparatus ? I start to feel a bit silly ;-) Met vriendelijke groeten, Frank Bemelman (reageren per email ? verwijder dan de 'x' uit mijn emailadres)Article: 14056
hi frank, interesting post ... well, some of us have seen designs fail when metastability is not taken into account - usually by those engineers who don't believe in it - "it'll be either a '1' or a '0'". these sorts of problems can turn up in various circuits such as synchronizers, arbiters, and interlocks. one case that does come to mind is the young engineer who insisted it would not be a problem when interfacing to dual-port ram chips. he built the board and failure there was quite frequent, couldn't finish loading the board's code up. i've seen other failures in radar systems designs, for example, when each engineer designed his own part of the system with his own clock. failures there were frequent enough that a complete set of tests could never be completed and the entire system was scrapped and redesigned from scratch. with a lot fewer clocks and a minimized number of asynchronous interfaces, each carefully managed. today, with modern technology, a lot of this metastable stuff is more or less academic - if reasonable design rules are followed and even a small amount of settling time is given, the failure rate can be made below that of the base cmos process for chips. some of the manufacturers will quote parameters for their chips and one can run the mtbf formulas and get some comfort. unfortunately, this isn't always done. now, barto's law was quoted w.r.t. the philosophy of design by test - since retracted as error, apparently - and simply trying a design and say, 'hey it works' is not good enough. after all, many systems need to work without stop for 15 years or more without failing. many readers here are involved in military systems design and others do that "plasma-regenerating-warp-core-stabilizer* for the next generation of *enterprise starships* -thing. for example, if one is working on a billion+-dollar, one-of-a-kind product. some care should be taken; same for life support, airplanes, and stuff like that. if you would like to see metastability, it's easy enough to build a test fixture for it (perhaps i'll scan and post some pictures from the literature, if you or others would like). are there different opinions about metastability? sure, some have "proved" that it can't be solved in unbounded time, others try to crack it. personally, i'd like to see a guaranteed circuit and be done with it and every year or so come up with some scheme to try. does your system need to be reliable? that's a question for you to answer. and those that depend on it running correctly. good evening, rk ========================================================= Frank Bemelman wrote: > rk heeft geschreven in bericht > <36934FF2.234F64BD@NOSPAMerols.com>... > > > >independent of what the design flaw is, assuming that a > circuit is good until > >proven guilty is really a crime against humanity and you > shouldn't really have > >anything to do with electronics, in my opinion. in > practice, one should follow > >barto's law: EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL > PROVEN INNOCENT! > > I was reading some postings further down this thread, > postings I was not supposed to read... while I actually was > skipping posts in this thread for quite a while already. So > I started to track the messages backwards, to see what I had > missed. > > Yesterday I picked up a recommended article on > metastability, because I had no idea what this was all > about. Until this thread started, I never realized that > metastability existed (!). The article explained it well > enough for me to understand. > > I suppose if I had to design a > *plasma-regenerating-warp-core-stabilizer* for the next > generation of *enterprise starships* I would be a bit more > careful about my designs, not because of possible > metastability but for more down to earth reasons, such as - > but not limited to - simply staying within ac/dc > specifications to avoid blowing the top of chips. > > Fact is, I am designing relatively simple uP boards. I even > have to write the software for it. My designs aren't 100% > reliable, mostly because I haven't removed all software > flaws yet. I can understand that one can get excited about > metastability, but *I* couldn't care less. The article I > have read, showed an example where an improvement was > suggested, putting 2 d-flipflops in cascade, resulting in 1 > occurence of metastability once every 2 million years. > Although very interesting, I am not even considering that > advice for my future designs, because I like to see this > metastability-thing at least once in my life. > > Still, I don't think I am irresponsible. I am not designing > medical life support systems. I do not design stuff for > airplanes. I dont know anything about satellite and > spaceships. But I do know my designs are more than adequate > for their purposes. > > My point is, there's nothing wrong about different opinions > regarding metastabilty. And why is everbody always designing > such delicate apparatus ? I start to feel a bit silly ;-) > > Met vriendelijke groeten, > Frank Bemelman > (reageren per email ? verwijder dan de 'x' uit mijn > emailadres)Article: 14057
In a previous article "Frank Bemelman" <fbemelx@euronet.nl> writes: : :Still, I don't think I am irresponsible. I am not designing ;medical life support systems. I do not design stuff for :airplanes. I dont know anything about satellite and ;spaceships. But I do know my designs are more than adequate :for their purposes. While metastability can't be completely eliminated, it can be completely compartmentalized to the extent that it is of no concern to most designers. The issue can be restricted to a thin boundary in the part of the circuit that interfaces differing clock domains or between a clocked domain and an asynchronous domain. Techniques exists to arbitrarily reduce the probability of meta-stable state propogating into the core of the circuit. It can be done so at the expense of latency without giving up bandwidth.Article: 14058
Hi Frank. If I were you, I would not brag about my ignorance. Metastability has been a really ugly problem in the past. Companies have gone bancrupt because they could not deliver a reliable product. I was just pointing out that the best of modern CMOS flip-flops have reduced the likelihood of metastability to a point where we can be more relaxed about it. But it still makes for a spirited discussion... Peter Alfke Xilinx Apps. Frank Bemelman wrote: > Until this thread started, I never realized that > metastability existed (!). snip > Still, I don't think I am irresponsible. I am not > designing > medical life support systems. I do not design stuff for > airplanes. I dont know anything about satellite and > spaceships. But I do know my designs are more than > adequate > for their purposes. > > My point is, there's nothing wrong about different > opinions > regarding metastabilty. And why is everbody always > designing > such delicate apparatus ? I start to feel a bit silly ;-)Article: 14059
Hello! I'm working on the hardware inmplementation (with VHDL into an FPGA) of DES decryption. after many searh I did not find any publication or example about this topic. Can anyone point me to some documentation on the subject? Thanks in advance!! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Samer EL HAJJ DotCom-Communication Numérique http://www.dotcom.fr mailto:samer@writeme.com S@merWeb: http://www.chez.com/samerweb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 14060
Problem not eliminated. 1 f/f High 1 f/f Metastable 1 f/f Low How do you decide? Simon ============================================================ On Fri, 08 Jan 1999 09:31:48 -0600, Dan Prysby <dprysby1@email.mot.com> wrote: >Brad Taylor wrote: >> >> Someone claims to be developing a 100% metastable-proof FF. Hmmm.., >> since a FF has to make a decision as to whether a signal is above a >> threshhold or below it and the signal can be exactly on the threshold, >> this would seem unlikely. > >So if a combination of 3 FFs sample 1 signal close enough in time >and each has a different threshold by design, then only 1 will go >metastable. Just a supposition. > >DanArticle: 14061
One of the leading UK distributors has a vacancy for a Xilinx Field Applications Engineer. Based in the South West of the UK you will look after existing accounts as well as generating new business for the company. You will be qualified to degree level in Electronic Engineering and have a background in digital electronics. You must also be capable of working in a pressure situation with a very outgoing personality and good communication skills. You will recieve 2 week 'Boot Camp' training in the US. You will be rewarded for your efforts with an Executive Car, competitive salary, high OTE, and healthcare. For more information please email David Hawke at : dhawke@globalnet.co.ukArticle: 14062
Hal Murray wrote: > > > I think the key parameter is not the metastability recovery time constant > alone, but the ratio of that time to the system clock time. If I have > a system with enough time for multiple levels of logic then it is > probably easy to cleanly process an asynchronous input - just leave out > those levels of logic (and their routing) and you have enough time between > a pairof FFs. But what if I'm running a heavily pipelined system where > the system clock only leaves room for a timy bit of routing? Now there > aren't any extra levels of logic to leave out. The classic FF-no-logic-FF > synchronizer may not have a lot of leftover time. > > Note that designers pushing system clock speed are likely to jump on > the next generation of faster chips as soon as they become available. > That's before the metastability data becomes availability. Assuming > that the metastability recovery time constant speeds up just like > everything else seems like a good first guess but I don't see any > reason to bet much on it. > > -- > These are my opinions, not necessarily my employers. Hi The whole concept of metability does not click to me, dont know why. It is all about the probiblity being reduced by using back to back FF's and reducing the probability of the input hitting the danger zone, ( Setup and hold) But then how do you process data in a synchornous system. almost always at the next clock from the driving FF. So why bother about the first .01 ns of the clock period when data is not defined. It will cause a dynamic current for the circuit a little longer then desired but what else. Please do correct me and send me direct replies, but I think it is just a matter of calculating whether I am consuming more current with the additional FF or by the subnanosecond undefined logic level. Ok the other aspect is that you didnt catch that input, but you will definitly not be sure if it comes so near to the clock edge which level will be caught anyway??? Regards ManishArticle: 14063
hi manish,
Manish_Shrivastava wrote:
> Hi
> The whole concept of metability does not click to me, dont know why.
> It is all about the probiblity being reduced by using back to back FF's and
> reducing the probability of the input hitting the danger zone, ( Setup and hold)
>
> But then how do you process data in a synchornous system. almost always at the
> next clock from the driving FF. So why bother about the first .01 ns of the clock
> period
> when data is not defined. It will cause a dynamic current for the circuit a little
> longer
> then desired but what else.
most systems do not bother with the data right after the clock, in a synchrous system.
assuming ideal clock distribution, and a th of 0 nsec for each flip-flop, the data
right after the clock will be ignored. in real world systems, the skew is, of course,
not zero. but the propagation delay, tclk-q, is a positive non-zero number also along
with any routing delays. the trick is to get the skew time low, as prop delays and
routing times get smaller as processes improve. in the area of fpga's, we have been
getting better and better clocks, making this, for the most part, not too much of a
problem. of course, one must run the timing numbers. and moving between different
clock trees, even for the clocks of the same frequency and phase can still be a
problem, if the clock delays are sensitive to loading. for some older technologies,
you had to run a clock load balancing algorithm, select routing criteria, perhaps
taking over yourself, to make sure the minimum delays were large enough to give
adequate margin against skew time (i never trust the analyzer when it says my margin is
100 psec). of course, in the highest performance circuits, skew may intentionally be
induced into the clock network for performance reasons, but that's another story.
_clock distribution networks in vlsi circuits and systems_, edited by eby friedman, is
a good collection, and has papers dealing with that.
==========================================
> Please do correct me and send me direct replies, but I think it is just a matter of
> calculating whether I am consuming more current with the additional FF or by
> the subnanosecond undefined logic level. Ok the other aspect is that you didnt
> catch that input, but you will definitly not be sure if it comes so near to the
> clock edge which level will be caught anyway???
i think i understood what you said. the problem is, according to theory, is that the
amount of time for a flip-flop to make up it's mind is unbounded and that you can never
say for certain that the flip-flop that synchronizes will be stable by the next clock
edge. while people have come up with various schemes for helping things along, none
has been proven to guarantee anything, and most have been shown to fail. [when i get
time, i will post more on some of that].
on the other hand, most modern flip-flops have small resolution times, making the
additional delay manageable in most situations. of course, system clock rates have
been improving too, as HA has pointed out. but as PA has mentioned, the resolving time
of the flip-flops has improved very fast. as an example, here is some data i just ran,
and most definitely not the greastest and latest xilinx stuff:
***************************************
Manufacturer = Xilinx
F-F Model = XC4005E-3_CLB
Minimum Slack = 1.000
Maximum Slack = 20.000
Slack Increment = 1.000
K1 = 0.100
K2 = 19.400
Clock Frequency = 5.0000E+0007
Data Frequency = 1.0000E+0007
Slack Time MTBF (sec) MTBF (years)
1.00 5.325286E+0003 1.688637E-0004
2.00 1.417934E+0012 4.496238E+0004
3.00 3.775451E+0020 1.197187E+0013
4.00 1.005267E+0029 3.187683E+0021
5.00 2.676669E+0037 8.487663E+0029
6.00 7.127015E+0045 2.259962E+0038
7.00 1.897670E+0054 6.017471E+0046
8.00 5.052817E+0062 1.602238E+0055
9.00 1.345385E+0071 4.266187E+0063
10.00 3.582280E+0079 1.135933E+0072
11.00 9.538332E+0087 3.024585E+0080
12.00 2.539717E+0096 8.053391E+0088
13.00 6.762361E+0104 2.144331E+0097
14.00 1.800575E+0113 5.709587E+0105
15.00 4.794289E+0121 1.520259E+0114
16.00 1.276548E+0130 4.047907E+0122
17.00 3.398992E+0138 1.077813E+0131
18.00 9.050302E+0146 2.869832E+0139
19.00 2.409772E+0155 7.641338E+0147
20.00 6.416364E+0163 2.034616E+0156
MTBF Improvement per increment = 266264304.669
so, for properly designed systems, in most cases [adding appropriate disclaimers], it's
not a problem. for systems with high clock rates, letting the input settle over
multiple periods will help, as it's a far from linear relationship, as you can see by
the above numbers.
good day,
rk
Article: 14064
Hi
I need to access the points 1 and 2 (see figure below) from the
outside of an FPGA. It doesn't matter if the inversors are located
in an I/O element or in a configurable block. I want to use the
invesrors as an amplifier, and for that I need to access the points
1 and 2 to include extra circuit.
Does anybody has any idea if it is possible? If yes, which FPGA
is more suitable (I've been working with Xilinx FPGAs)?
|\ |\
1 | \ 2 | \
--@----| O----@----| O-------> to FPGA configurable blocks
| / | /
^ |/ |/
|
+-- Input signal from outside
Any suggestion would be welcome.
Eduardo.
--
mailto:E.A.Bezerra@sussex.ac.uk
--
+-----------------------+---------------------------------------------+
|Eduardo Augusto Bezerra|mailto:E.A.Bezerra@sussex.ac.uk |
|-----------------------|---------------------------------------------|
|Space Science Centre |http://www.sussex.ac.uk/engg/research/space/ |
|School of Engineering |http://www.sussex.ac.uk/Users/tapu9/ |
|University of Sussex |http://www.inf.pucrs.br/~eduardob |
|Falmer, Brighton |---------------------------------------------|
|BN1 9QT, UK |Phone: +44 (0)1273 877086 Fax: 678399 |
+-----------------------+---------------------------------------------+
Article: 14065Frank Bemelman wrote: > Fact is, I am designing relatively simple uP boards. I even > have to write the software for it. My designs aren't 100% > reliable, mostly because I haven't removed all software > flaws yet. I can understand that one can get excited about > metastability, but *I* couldn't care less. The article I > have read, showed an example where an improvement was > suggested, putting 2 d-flipflops in cascade, resulting in 1 > occurence of metastability once every 2 million years. > Although very interesting, I am not even considering that > advice for my future designs, because I like to see this > metastability-thing at least once in my life. So lets assume that your design has 200 such ff's and you sell 10K units. Voila, you'll be looking at one event per year. Opinions expressed herein are my own and may not represent those of my employer.Article: 14066
Hi,
I'm sory that I don't have the link. But I'm sure I've seen the VHDL
for Ic2 on one
of the free model sites. Hope that helps.
saffary wrote:
> Anyone know where I can find i2c VHDL core.
>
> thank.
--
George Smith
Avalex Technologies
Atlanta, Ga.
404.256.3010
I.R.S. We have what it takes to take what you have.
-- Support the national sales tax.
Article: 14067This topic was recently covered, either here or in comp.lang.vhdl (Sorry, don't remember which). Try searching through back archives of the comp.arch.fpga and .lang.vhdl groups. Was about November/early December time frame. Samer EL HAJJ wrote: > Hello! > I'm working on the hardware inmplementation (with VHDL into an FPGA) of > DES decryption. > after many searh I did not find any publication or example about this > topic. > > Can anyone point me to some documentation on the subject? > Thanks in advance!! > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Samer EL HAJJ > DotCom-Communication Numérique http://www.dotcom.fr > mailto:samer@writeme.com > S@merWeb: http://www.chez.com/samerweb > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14068
My company offers ÿ I2C core in two flavors -- a master-only version and a master-slave version. Both are optimized for FPGAs, specifically Xilinx 4k and Spartan. The Virtex implementation will be released soon. --- Tom Curran Memec Design Services -- Boston url: www.memecdesign.com email: tom_curran@memecdesign_dot_comArticle: 14069
Eduardo Augusto Bezerra wrote: > Hi > > I need to access the points 1 and 2 (see figure below) > from the > outside of an FPGA. Does anybody has any idea if it is > possible? If yes, which FPGA > is more suitable (I've been working with Xilinx FPGAs)? > > |\ |\ > 1 | \ 2 | \ > --@----| O----@----| O-------> to FPGA configurable > blocks > | / | / > ^ |/ |/ > | > +-- Input signal from outside > It's simple. You just route those points to another pin or pins as output(s). But you should be aware that your drawing is deceptive: The buffer or gain stage is really a multi-stage amplifier. So from the input to the output you may have a six-stage amplifier, and if you force that into its linear operating range, you might have nasty gain and phase characteristics. People have done it to build a crystal oscillator, but I have always discouraged this. Buy a canned oscillator, it's almost as cheap as a crystal, it consumes less power and is more reliable. Definitely less headache. Peter Alfke, Xilinx ApplicationsArticle: 14070
Peter Alfke wrote: > [snip} > I was just pointing out that the best of modern CMOS > flip-flops have reduced the likelihood of metastability to a > point where we can be more relaxed about it. > But it still makes for a spirited discussion... > > Peter Alfke > Xilinx Apps. I've heard these sentiments echoed in several posts in this thread and I'm afraid I have to disagree. I am currently involved in a design involving several chips using a 0.25 micron process from a large, respected vendor (who will remain undisclosed due to NDAs) and we have found metastability to be a very real potential problem. The chips in question fall into the "system on a chip" category and as such have several high-speed clock domains. Analysis by the vendor has predicted an MTBF of less than a minute for the standard 2 flip-flop synchronizer when going between a 60 MHz and a 75 MHz clock domain. This is obviously not something "we can be more relaxed about". One of the biggest contributors to this problem turns out to be junction temperature. In these days of systems on a chip, the die will often have a worst case temperature spec of over 100C. The vendor's projections show a 10000-fold difference in MTBF across a die temperature range of 0C to 100C. Your comment may be valid for FPGAs (I defer to your experience here) but I can't agree with it as a blanket statement. -- Tim Hubberstey, P.Eng. . . . . . . . . . . . . . . Marmot Engineering Vancouver, BC, Canada . . . . . Hardware/Software Consulting Engineer Email: marmot@rogers.wave.ca . . . . . . VHDL, ASICs, embedded systemsArticle: 14071
Tim Hubberstey wrote: > The chips in question fall into the "system on a > chip" category and as such have several high-speed clock > domains. > Analysis by the vendor has predicted an MTBF of less than > a minute for > the standard 2 flip-flop synchronizer when going between a > 60 MHz and a > 75 MHz clock domain. This is obviously not something "we > can be more > relaxed about". > > One of the biggest contributors to this problem turns out > to be junction > temperature. In these days of systems on a chip, the die > will often have > a worst case temperature spec of over 100C. The vendor's > projections > show a 10000-fold difference in MTBF across a die > temperature range of > 0C to 100C. Wow, anybody bridging the gap between 60 MHz and 75 MHz *must* not only be concerned about metastability, but should also question the conceptual design.If the bridge is really unavoidable, then use triple or quadruple synchronizers and give these flip-flops some "breathing space", i.e. make sure the routing delays between them use up an inignificant portion of the clock period. I would never recommend a relaxed attitude in *that* kind of environment. Luckily, most asynchronous interfaces operate at a much slower pace. Peter Alfke, Xilinx Applications > >Article: 14072
The problem with a flip-flop or latch in a metastable state is not its output level while it is in this state. It is easy enough to build a level shifter that reliably interprets the balanced condition as High ( or as Low, if that is preferred ). The terrible problem is that the flip-flop or latch will leave the metastable state at a moment that is uncontrolled ( and uncontrollable ) by any external signal, and thus can create a level change at an "awkward" moment. So the unsolvable problem is the unpredictable nature of the metastable recovery delay. And the thread goes on and on... Peter Alfke, Xilinx Applications M.Simon wrote: > Problem not eliminated. > > 1 f/f High > 1 f/f Metastable > 1 f/f Low > > How do you decide? > > SimonArticle: 14073
rk heeft geschreven in bericht <36994A94.C9130453@NOSPAMerols.com>... >if you would like to see metastability, it's easy enough to build a test >fixture for it (perhaps i'll scan and post some pictures from the >literature, if you or others would like). There was a little circuit inside the sdya006.pdf document I downloaded from the Texas Instruments site, couple of d-flipflops, comparators etc. >are there different opinions about metastability? sure, some have >"proved" that it can't be solved in unbounded time, others try to crack >it. personally, i'd like to see a guaranteed circuit and be done with >it and every year or so come up with some scheme to try. > >does your system need to be reliable? that's a question for you to >answer. and those that depend on it running correctly. No complaints from the customers, they judge our stuff as highly reliable - and so do we. Met vriendelijke groeten, Frank Bemelman (reageren per email ? verwijder dan de 'x' uit mijn emailadres)Article: 14074
<369A5718.4D793D87@xilinx.com>, Peter Alfke <peter@xilinx.com> wrote **Please** note that I prefer **not** to receive an e-mail copy: >he problem with a flip-flop or latch in a metastable state >is not its output level while it is in this state. It is >easy enough to build a level shifter that reliably >interprets the balanced condition as High ( or as Low, if >that is preferred ). >The terrible problem is that the flip-flop or latch will >leave the metastable state at a moment that is uncontrolled >( and uncontrollable ) by any external signal, and thus can >create a level change at an "awkward" moment. >So the unsolvable problem is the unpredictable nature of the >metastable recovery delay. Surely, if you can reliably detect the m-state, you can force it whichever way you want in a defined time, if possible short enough not to be of any significance? I would again draw attention to the work of McClintock and Luchinsky at Lancaster University (UK) on the effects of noise on non-linear systems, which seems maybe to offer a novel approach, if not a solution. Go to http://www.newscientist.com. -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. ERROR! OUT OF CORNFLAKES. Please check cereal port configuration.
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