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
<76v9qq$dqp@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote, preferably NOT having sent me a copy by e-mail: >In article <S4WnzrBY0ok2EwBJ@jmwa.demon.co.uk>, John Woodgate ><jmw@jmwa.demon.co.uk> writes: >> <76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote: >> >If the problem is "irrelevant" for "most applications", how do I tell >> >if I'm working on one where it is relevant? >> >> Assume that it is, until you prove that it isn't. In other words, if it >> works, OK; if it doesn't, don't rule out metastability as the cause. > > >That's the sort of attitude that gets people burned. Testing >a design doesn't tell you it doesn't have any metastability problems. >It only tells you that they don't happen often enough for your >tests to catch them. I was trying to answer a rather paradoxical question briefly. I mean that even though metastability is rare, ***if you find a problem***, don't discount metastability as the cause. I didn't mean to imply that any finite number of working units is a *guarantee* that the next one will work. Of course, testing a design, even for an infinite time, does not tell you that another sample won't fail, but that is not much help. It does not mean that testing is pointless. I don't know whether you have been following this thread, but much of it, AIUI, is about how difficult it can be to determine *if* a design is vulnerable to metastability. In such a case, your philosophy of 'design it right and be sure' cannot be applied. Of course, if it can, it should be, without question. -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. You can fool all of the people some of the time, but you can't please some of the people any of the time.Article: 14001
<36934FF2.234F64BD@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com> wrote, preferably NOT having sent me a copy by e-mail: >ah, the russian roullette [spell] theory of electronics design. See my reply in this thread to a much politer critique of what I wrote. You don't have to be insulting to make your point. In fact, the more you bluster, the less strong your case seems. I've survived in electronics for 43 years, and so have my designs: AFAIK none has failed seriously. It's a bit late for a career change now. -- Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. OOO - Own Opinions Only. You can fool all of the people some of the time, but you can't please some of the people any of the time.Article: 14002
Does anyone know the IEEE or Synopsys library that must be added to use bit string literals with std_logic_vectors? Thanks. AdamArticle: 14003
Hi, Is there anyone who can tell me how to assign a signal to the special pin on Xilinx FPGA. I am using XC4028 device and want to use TDO (special pin) as an output signal in my design. I can not lock this pin using UCF file. Design is in verilog HDL and I am using leonardo for synthesis. Any help would be greatly appreciated. -- Amit Saxena MTS GDA Tech. Inc San Jose, CA -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14004
rk <stellare@NOSPAMerols.com> writes: Regarding metastability-proof logic... >i believe the delivery data has slipped ... until just after delivery of the >perpetual motion machine. >while modern flip-flops have quite good metastable state characteristics, it >is impossible to design a guaranteed by law metastable state proof flip-flop. >the best you can do is describe it statistcally; and you can get good >performance, making the failure rate insignificant w.r.t. normal cmos device >failure rates. As I understood, for a given technology there is an invariant quantity, something like (probability of going metastable)*(length of stay in the metastable state) You can improve one at the expense of the other. For example, adding noise can reduce the time in the metastable state, but will increase the chance of it happening. Actually, it is probably a continuous curve with constant area, where you can reduce the probability of long metastability while increasing shorter metastability. If short is short enough, then you have solved the problem. Hope this helps, -- glenArticle: 14005
A lot depends on your data rates. For bit parallel arithmetic (DSP) Xilinx 4K is still a hands down winner. I've posted several times here regarding the shortcomings of Altera 10K in this type of application. Actel has the advantage/disadvantage of being a one-time programmable part. From a reconfiguration for test or functionality standpoint the one time programmables are a non-starter. Actel introduced its SPGA last year which is RAM based. I have not used that part. Atmel has some nice offerings if you are working bit serially or intend to use partial reconfiguration. For parallel arithmetic, the lack of a carry chain is a considerable handicap. For a microprocessor run ACG, it is quite likely that you can get away with a bit serial circuit and a very small device. If that is the case, you might look either at the Atmel 40K (The 6K is not a good device for the neophyte) or Xilinx Spartan (basically a economy version of the 4K). ekuria01@kepler.poly.edu wrote: > Hello, I must convert a microcontroller based digital AGC to an FPGA. The > AGC in question uses relatively simple math (adds, shifts, and Look up > Tables). I also need to implement digital peak detectors that peak detect > using and A/D converter. > > I am a novice with FPGAs and my expertiese only extends to micro coding > for controllers. Any help on how to choose FPGAs, and what company FPGAs sound > apt for my application will be greatly appreciated. > > Thank you all in advance. > > Eldho Kuriakose > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own -- -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: 14006
glen herrmannsfeldt, from caltech, writes:
> rk <stellare@NOSPAMerols.com> writes:
>
> Regarding metastability-proof logic...
>
> >i believe the delivery data has slipped ... until just after delivery of the
> >perpetual motion machine.
>
> >while modern flip-flops have quite good metastable state characteristics, it
> >is impossible to design a guaranteed by law metastable state proof flip-flop.
> >the best you can do is describe it statistcally; and you can get good
> >performance, making the failure rate insignificant w.r.t. normal cmos device
> >failure rates.
>
> As I understood, for a given technology there is an invariant quantity,
> something like
> (probability of going metastable)*(length of stay in the metastable state)
the formula generally used is: mtbf = e^(k2*t) / ( k1 * fclk * fdata)
the key here is that it's an exponential function, with w.r.t. t. no diminishing
returns, here.
an example from chipx, cx2001 (just happen to have the book open)
clk = 50 MHz
data = 10 MHz
time available for nutso behaviour = 10 nsec (1/2 clock period in this case)
====> mtbf = 4 x 10^12 years.
as they say, good enough for government work. and i believe you can find better
flip-flops, too.
===============================================================
> You can improve one at the expense of the other. For example, adding
> noise can reduce the time in the metastable state, but will increase
> the chance of it happening. Actually, it is probably a continuous curve
> with constant area, where you can reduce the probability of long
> metastability while increasing shorter metastability. If short is short
> enough, then you have solved the problem.
yes, run the numbers, and you can make estimates. but, there is no "solution"
that guarantees that the problem is solved. everyonce in a while somebody
publishes a "solution" and they quickly get hammerred and confess their sins.
good evening,
rk
=======================================
> Hope this helps,
>
> -- glen
Article: 14007Hi! Has anyone had any good or bad experience using a socket for a XILINX 160-PIN PQFP? I think I found one in ALLIED Catalog that could work. any suggestion? Antonio Moreno schaltung@hotmail.com -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14008
And why is it that you want to socket a Xilinx ? Using a socket is asking for trouble. First, you increase the pin inductance so that the bypassing is not as effective. More importantly, you greatly reduce the reliability of the connections. I recently dealt with a customer that socketed a bunch of Xilinx. Almost all of the debug problems were eventually traced to bad connections either at the socket-chip interface or at the socket board interface (the socket covers the pads so it is very difficult to properly mount or inspect the joints). The xilinx is infinitely programmable, and from my experience not very prone to failure. If you screw up board layout, you can re-assign pins. schaltung@hotmail.com wrote: > Hi! > > Has anyone had any good or bad experience using a socket for a XILINX 160-PIN > PQFP? > > I think I found one in ALLIED Catalog that could work. any suggestion? -- -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: 14009
Ray Andraka <randraka@ids.net> writes: > The xilinx is infinitely programmable I think you must have more patience than me, Ray :) Chris -- Chris Eilbeck mailto:chris@yordas.demon.co.uk Linux - Don't fear the PenguinArticle: 14010
Why would adding noise increase the chance of it happening? I am talking about noise whose spectrum is *below* that of the frequency response of the feedback loop of the latch in question. I think adding noise will **not change** the MS behaviour, and depending on how the noise is made up it might even put an upper limit on it, e.g. a square wave at 100MHz, injected into the feedback loop, ought to set an upper limit on the metastable condition of 5ns. >You can improve one at the expense of the other. For example, adding >noise can reduce the time in the metastable state, but will increase >the chance of it happening. Actually, it is probably a continuous curve >with constant area, where you can reduce the probability of long >metastability while increasing shorter metastability. If short is short >enough, then you have solved the problem. -- 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: 14011
John Woodgate wrote:
> <36934FF2.234F64BD@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com>
> wrote, preferably NOT having sent me a copy by e-mail:
> >ah, the russian roullette [spell] theory of electronics design.
>
> See my reply in this thread to a much politer critique of what I wrote.
why? what you proposed is EXACTLY the equivalent of russian roullette [still
can't spell] and so, by analogy, makes a point. of course, in real russian
roullette, a head gets blown off and someone dies; in critical systems for life
support, say, much the same things happen. and us here in the states saw that
sort of attitude back in '86 in the space program where people did get blown up.
unfortunately, the red reset button has become more or less a universal component
of equipment design and leads to a what i would call "bad" design attitude such
as this:
>> In
other words, if it
>> works, OK; if it doesn't, don't rule out metastability as the cause.
hey, it works, OK, cool. of course, we saw another engineer who perhaps said it
a tad more elegantly:
>That's the sort of attitude that gets people burned. Testing
>a design doesn't tell you it doesn't have any metastability problems.
>It only tells you that they don't happen often enough for your
>tests to catch them.
with respect to polite, Professor, i remember asking a question in another group
(sci.electronics.design) for information to help me in an area out of my field.
you PUBLICLY RIDICULED ME FOR ASKING what you thought was A STUPID QUESTION,
ALTHOUGH IT BECAME APPARRENT [spell?] THAT YOU HAD NO IDEA WHAT YOU ARE TALKING
ABOUT. additionally, you publicly talk down and ridicule people quite
frequently, and i really don't participate in that group any more, partly because
of dealing with worthless but embarrassing comments from people like you. so, if
YOU don't like it now, well, too bad. sorry to burst your ego bubble. well, no,
not sorry at all.
==================================================
> I was trying to answer a rather paradoxical question briefly.
sorry, no paradox here at all:
>> >If the problem is "irrelevant" for "most applications", how do I tell
>> >if I'm working on one where it is relevant?
i don't see this as a terribly difficult problem or a paradox. one designs the
system with knowledge about metastable states and architects it accordingly, run
some calculations on the devices in question (or better, choose them
appropriately - say, an appropriate logic family, the best flip-flop macro in the
asic vendor's guide w.r.t. metastability, etc., etc.), and you obtain a failure
rate that you consider acceptable for your application. then you test it as hard
as you can, giving some evidence that your design is correct, just like any other
parameter. better yet, when possible, get rid of the asynchronous interfaces, be
done with it. not really a paradox at all. as from your previous posts in other
threads, it is apparent that you're not that up on digital logic as your claims
about output drive capability for a simple HCxx buffer were way off, perhaps you
should start with the basics, first, before you continue your blabbering.
=======================================================
>
I mean
>that even though metastability is rare, ***if you find a problem***,
>don't discount metastability as the cause. I didn't mean to imply that
>any finite number of working units is a *guarantee* that the next one
>will work.
>> In
other words, if it
>> works, OK; if it doesn't, don't rule out metastability as the cause.
well, that's exactly the opposite of what you said. of course, it doesn't
exactly take a seymour cray to figure out "if it fails, then don't discount x as
a cause automagically." puh-lease.
========================================
> You don't have to be insulting to make your point.
me insulting? go look at what you blabber around the internet. i was just
getting warmed up.
=========================================
> In fact, the more you
> bluster, the less strong your case seems.
sorry, Professor. i don't need to bluster and i don't need to make a case. your
attitude of "if it works, OK" is just bad engineering and that is a fact; no case
to be made. unless one decides to apply clintonian logic, distinctly different
from the boolean variety.
===========================================
> I've survived in electronics for 43 years, and so have my designs: AFAIK
> none has failed seriously.
hmmm ... i guess that depends on what you consider serious. of course, one can
read the above as you've been designing stuff with annoying and quirky bugs in it
for a long time but nothing fatal. i've seen a lot of those sorts of engineers.
============================================
> It's a bit late for a career change now.
it's never too late to change; i do it all the time. the problems and the
technologies keep on changing. and the skills needed to succeed keep growing.
on the other hand, perhaps it's time for you to retire.
==============================================
> Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124.
> OOO - Own Opinions Only. You can fool all of the people some of the time, but
> you can't please some of the people any of the time.
yeah, and when YOU learn some manners and stop YOUR rudeness, perhaps you will do
better with of the people that you have trouble with.
rk
Article: 14012Chris Eilbeck wrote: > > The xilinx is infinitely programmable > > I think you must have more patience than me, Ray :) > No, possibly more experience though. While I've seen people use the programmability as a crutch to bolster bad design practice, it is not something I do. A functional simulation followed by a thorough static timing analysis leads to a near 100% record of first time successes with xilinx designs. I have taken advantage of reconfiguration on many occasions to do very thorough board testing...100% interconnect and at speed worst case memory pattern testing that would be difficult any other way. -- -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: 14013
I am aware of the statistical calc for a basic transmission gate FF. What I am asking is if anyone has heard of facts relating to a recent effort on a true 100% metastable-proof FF. Also, until someone does it, it is OK to say it is impossible. However, I will not put effort into a perpetual motion machine. Dan Prysby rk wrote: > > Dan Prysby wrote: > > > I have read that there is effort to design a metastable-proof > > flip-flop. Anyone have any facts to share? > > i believe the delivery data has slipped ... until just after delivery of the > perpetual motion machine. > > while modern flip-flops have quite good metastable state characteristics, it > is impossible to design a guaranteed by law metastable state proof flip-flop. > the best you can do is describe it statistcally; and you can get good > performance, making the failure rate insignificant w.r.t. normal cmos device > failure rates. > > also, about 10 years ago, amd (and perhaps signetics) produced > metastable-state hardened flip-flops. > > rkArticle: 14014
rk wrote: > EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL PROVEN INNOCENT! Nice in pricipal, but very difficult to apply in practice. Opinions expressed herein are my own and may not represent those of my employer.Article: 14015
I used them on a project 5-6 years ago before ISP was built into Altera CPLDs. The sockets were an absolute nightmare. I ended up ripping off the sockets and soldering the 160-pin and 208-pin QFP parts directly to the board. If a part needed to be reprogrammed we had to unsolder it and replace it with a new programmed part. This was expensive, and after a couple of times on the same part you start to lift pads off the board, but it was inifinitely better than dealing with the sockets. Bob S. schaltung@hotmail.com wrote: > > Hi! > > Has anyone had any good or bad experience using a socket for a XILINX 160-PIN > PQFP? > > I think I found one in ALLIED Catalog that could work. any suggestion? > > Antonio Moreno > schaltung@hotmail.com > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14016
Ray Andraka wrote: > > Chris Eilbeck wrote: > > > > The xilinx is infinitely programmable > > > > I think you must have more patience than me, Ray :) > > > > No, possibly more experience though. While I've seen people use the > programmability as a crutch to bolster bad design practice, it is not > something I do. A functional simulation followed by a thorough static > timing analysis leads to a near 100% record of first time successes with > xilinx designs. I have taken advantage of reconfiguration on many > occasions to do very thorough board testing...100% interconnect and at > speed worst case memory pattern testing that would be difficult any > other way. Ray, I think this was just a joke about the idea of spending the rest of your life programming a Xilinx part "infinitely". =8^) -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 14017
I know, I'm sure you are right about this, but I can't help trying! I guess I shouldn't speculate in so public a forum. At least there is someone around to catch it. There is another flaw, since the "integrating" window detector has to detect a transition near threshold and then remember that for say a few ns, it is in effect a sampling system which can go metastable. If the Clock enable's value is undefined, the FF cannot work of course. So we have speed of light, law of gravity, time travel, perpetual motion and metastable free sampling. I might also add Rob's law of hardware which states that you cannot install and configure a PC add-in card without losing a day. Best Wishes, Brad Hal Murray 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. > > It's like the second law of thermo. There is no way to make a > metastable-proof FF. Your alarm bells should ring whenever anybody > even hints in that direction. > > > Now that I think about it though, perhaps you could use an integrating > > window detector to determine is a signal was anywhwere near threshold > > around the sampling window. If so, the FF's clock enable could be > > disabled. (The delay through the threshold detector could be balanced by > > a fixed delay of the signal to be sampled using speed of light delay). > > That's a typical example of the sort of kludges that people come up > with. In this case, I think I can find the flaw. > > You have just moved the problem. Remember, you also have to meet > the setup and hold times for the clock enable. What if the input > signal changes a bit earlier so the clock enable is changing at > the wrong time? > > -- > These are my opinions, not necessarily my employers.Article: 14018
Renzo,
Check out our site at http://www.associatedpro.com . Also you might want
to check with the specific vendors to see if they will give you
materials if your affiliated with a University.
renzo.arce@st.com wrote:
> Hi,
>
> I am implementing a hardware lab. for our research's group and
> I must to make a decision on whish FPGA development system to buy
> (Altera, Xilinx, etc).
>
> We develop research's projects and we need a system hw/sw to
> simulate, debbuging and hardware implementation of advanced
> algorithm applications.
>
> Somebody can give me some suggest?
>
> Best regards
>
> Renzo Arce
> STMicroelectronics
> Italy
> renzo.arce@st.com
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 14019
schaltung@hotmail.com wrote:
> Has anyone had any good or bad experience using a socket
IC sockets are evil. Solder it in.
-Mike Treseler
Article: 14020Peter writes: > I think adding noise will **not change** the MS behaviour, and > depending on how the noise is made up it might even put an upper limit > on it, e.g. a square wave at 100MHz, injected into the feedback loop, > ought to set an upper limit on the metastable condition of 5ns. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think you're being optimistic here. A simple 100MHz signal will reduce the likelihood of the metastable condition exceeding 5ns, but won't, as far as I know, guarantee to limit it. I don't know if it's possible to construct a device that guarantees a metastability time limit. I am not convinced by the hand-waving arguments around here that say it's impossible -- but the maths is not simple. A real device does not have one or two continuous state parameters, but infinitely many (think of the internal energy flows). -- JamieArticle: 14021
Yeah, I got the joke now. When I first read it, I was a bit bleary-eyed and it went right over my head. Nice to see others think sockets are the devil's work. I'm working with a customer right now that is insisting on socketing memories and a xilinx. No amount of convincing is changing his mind. Guess I'll be spending time in the lab! Rickman wrote: > Ray Andraka wrote: > > > > Chris Eilbeck wrote: > > > > > > The xilinx is infinitely programmable > > > > > > I think you must have more patience than me, Ray :) > > > > > > > No, possibly more experience though. While I've seen people use the > > programmability as a crutch to bolster bad design practice, it is not > > something I do. A functional simulation followed by a thorough static > > timing analysis leads to a near 100% record of first time successes with > > xilinx designs. I have taken advantage of reconfiguration on many > > occasions to do very thorough board testing...100% interconnect and at > > speed worst case memory pattern testing that would be difficult any > > other way. > > Ray, I think this was just a joke about the idea of spending the rest of > your life programming a Xilinx part "infinitely". =8^) > > -- > > Rick Collins > > redsp@XYusa.net > > remove the XY to email me. -- -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: 14022
<3694B15A.83DA0E4D@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com> wrote, having noted that I prefer NOT to receive an e-mail copy: >John Woodgate wrote: > >> <36934FF2.234F64BD@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com> >> wrote, preferably NOT having sent me a copy by e-mail: >> >ah, the russian roullette [spell] theory of electronics design. >> >> See my reply in this thread to a much politer critique of what I wrote. > >why? what you proposed is EXACTLY the equivalent of russian roullette [still >can't spell] rest of diatribe snipped. For every one of these rabid ravings, I get a number of thank-you messages. Maybe we should have a referendum on whether I or 'rk' should be banned from this NG? -- 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.Article: 14023
This is a multi-part message in MIME format. --------------DF023B657AD628E5B009B72B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Sefton wrote: > > I used them on a project 5-6 years ago before ISP was built into > Altera CPLDs. The sockets were an absolute nightmare. I ended up > ripping off the sockets and soldering the 160-pin and 208-pin QFP > parts directly to the board. If a part needed to be reprogrammed > we had to unsolder it and replace it with a new programmed part. > This was expensive, and after a couple of times on the same part > you start to lift pads off the board, but it was inifinitely > better than dealing with the sockets. > There is really nothing wrong with occasional desoldering if the pads don't lift. As I recall using the better grades of epoxy-fiberglass or polyamide will eliminate the lifted pads. You do need to find a good experienced re-work shop though. - Brad > Bob S. > > schaltung@hotmail.com wrote: > > > > Hi! > > > > Has anyone had any good or bad experience using a socket for a XILINX 160-PIN > > PQFP? > > > > I think I found one in ALLIED Catalog that could work. any suggestion? > > > > Antonio Moreno > > schaltung@hotmail.com > > > > -----------== Posted via Deja News, The Discussion Network ==---------- > > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own -- --------------DF023B657AD628E5B009B72B Content-Type: text/x-vcard; charset=us-ascii; name="blt.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brad Taylor Content-Disposition: attachment; filename="blt.vcf" begin:vcard n:Taylor;Brad tel;work:1-408-730-3300 ext108 x-mozilla-html:FALSE url:www.cmln.com org:Chameleon Systems;Applications version:2.1 email;internet:blt@cmln.com title:Director of Applications adr;quoted-printable:;;1195 W. Fremont Ave=0D=0A;Sunnyvale;CA;94087-3825;USA note;quoted-printable:Chameleon Systems is a fabless semiconductor company. Chameleon=0D=0Ais developing a new class of devices known as ASPPs for=0D=0A"Application Specific Programmable Device". Please contact me=0D=0Adirectly for more information about our product line at=0D=0Ablt@cmln.com=0D=0A=0D=0A fn:Brad Taylor end:vcard --------------DF023B657AD628E5B009B72B--Article: 14024
This is a multi-part message in MIME format.
--------------3CFBDA44DDDCFB9D24338EF5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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.
Now that I think about it though, perhaps you could use an integrating
window detector to determine is a signal was anywhwere near threshold
around the sampling window. If so, the FF's clock enable could be
disabled. (The delay through the threshold detector could be balanced by
a fixed delay of the signal to be sampled using speed of light delay).
I'm used to thinking of sampling being a metastable functions as a law
of the universe, so I must be missing something.
Best Wishes,
Brad
Dan Prysby wrote:
>
> I am aware of the statistical calc for a basic transmission gate FF.
>
> What I am asking is if anyone has heard of facts relating to
> a recent effort on a true 100% metastable-proof FF.
>
> Also, until someone does it, it is OK to say it is impossible.
> However, I will not put effort into a perpetual motion machine.
>
> Dan Prysby
>
> rk wrote:
> >
> > Dan Prysby wrote:
> >
> > > I have read that there is effort to design a metastable-proof
> > > flip-flop. Anyone have any facts to share?
> >
> > i believe the delivery data has slipped ... until just after delivery of the
> > perpetual motion machine.
> >
> > while modern flip-flops have quite good metastable state characteristics, it
> > is impossible to design a guaranteed by law metastable state proof flip-flop.
> > the best you can do is describe it statistcally; and you can get good
> > performance, making the failure rate insignificant w.r.t. normal cmos device
> > failure rates.
> >
> > also, about 10 years ago, amd (and perhaps signetics) produced
> > metastable-state hardened flip-flops.
> >
> > rk
--
-------------------------------------------
Brad Taylor Chameleon Systems
Phone: 1-408-730-3300 ext 108
Fax: 1-408-730-3303
Email: <Brad Taylor>blt@cmln.com
WWW: www.cmln.com
Location: 1195 W. Fremont Ave
Sunnyvale, CA 94087-3825
-------------------------------------------
--------------3CFBDA44DDDCFB9D24338EF5
Content-Type: text/x-vcard; charset=us-ascii;
name="blt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brad Taylor
Content-Disposition: attachment;
filename="blt.vcf"
begin:vcard
n:Taylor;Brad
tel;work:1-408-730-3300 ext108
x-mozilla-html:FALSE
url:www.cmln.com
org:Chameleon Systems;Applications
version:2.1
email;internet:blt@cmln.com
title:Director of Applications
adr;quoted-printable:;;1195 W. Fremont Ave=0D=0A;Sunnyvale;CA;94087-3825;USA
note;quoted-printable:Chameleon Systems is a fabless semiconductor company. Chameleon=0D=0Ais developing a new class of devices known as ASPPs for=0D=0A"Application Specific Programmable Device". Please contact me=0D=0Adirectly for more information about our product line at=0D=0Ablt@cmln.com=0D=0A=0D=0A
fn:Brad Taylor
end:vcard
--------------3CFBDA44DDDCFB9D24338EF5--
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