From: rickman Newsgroups: comp.arch.fpga Subject: Thinking out loud about metastability Date: Sat, 23 Aug 2003 00:05:42 -0400 Organization: Arius, Inc Lines: 57 Message-ID: <3F46E816.96EF198B@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbbmizXqXn4q2ExffqjzCykYgdBf0JuMvZ934cSaBW1CacODRnIq5X6 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 23 Aug 2003 04:05:39 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!nntp.abs.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32040 I am designing a FPGA interface for an MCU which uses only async strobes. However they are not truely async, in reality the timing to the clock is simply not spec'd. So if I understand metastability correctly, I can not use the standard circuit to reduce the failure rate to insignificant rates. Since there is a fixed relationship between the clock and the command strobes (even though it is unknown) no matter how I choose to clock the circuit, I may end up balancing the pencil well enough on end that I will see a much higher failure rate than predicted by the standard formula. My understanding is that the standard formula assumes that the two signals are not related in frequency. So the probability that they will be at the right point to cause a failure depends on the rate of each and the width of the "failure window". In my case the probability of the event being in the failure window can be very high if the timing is just right. Other than the obvious of using a separate clock for the FPGA, how can I design this circuit and get a low enough failure rate? I guess adding more time will reduce the failure rate, but how do I know how much time is enough since the standard formula does not apply? In this particular circuit I expect the strobes to change on the rising edge of the clock at about 50 MHz. Since I know nothing about the actual relationship between the clock and the strobes, I have picked the falling edge to clock the strobes into the chip. I assume that if the outputs change slightly before the clock rising edge, it will not be much and if they change later, it may be short enough to still give me close to the 3 ns setup time I need. Then a rising edge FF syncs the signal to the rest of the circuit and provides some 7 ns (out of 10 ns clock difference) for settling. I have no idea how good of an assumption this is. The output delays on the CPU may be enough to put the strobe edge right in the critical point to cause a failure. Even if I use an emperical approach and see which edge to clock on to make the circuit work, I don't know that this will operate over temperature, process, etc... I believe that some of the posts here have indicated that the "failure window" in terms of time is in the low ps (or was it fs?) range. If my circuit allows some 7 ns for settling, will this be enough to put the MTBF above 100 years in a worse case situation? Is it possible to balance the pencil well enough to make a circuit like this fail frequently? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Jon Elson Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Fri, 22 Aug 2003 23:59:24 -0500 Organization: Pico Systems Lines: 36 Message-ID: <3F46F4AC.8040209@pico-systems.com> References: <3F46E816.96EF198B@yahoo.com> NNTP-Posting-Host: h-69-3-230-106.chcgilgm.covad.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sun-news.laserlink.net 1061614489 12788 69.3.230.106 (23 Aug 2003 04:54:49 GMT) X-Complaints-To: abuse@covad.net NNTP-Posting-Date: Sat, 23 Aug 2003 04:54:49 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!news-out1.nntp.be!propagator2-sterling!In.nntp.be!news-out.visi.com!petbe.visi.com!ash.uu.net!sun-news.laserlink.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32086 rickman wrote: >I am designing a FPGA interface for an MCU which uses only async >strobes. However they are not truely async, in reality the timing to >the clock is simply not spec'd. So if I understand metastability >correctly, I can not use the standard circuit to reduce the failure rate >to insignificant rates. Since there is a fixed relationship between the >clock and the command strobes (even though it is unknown) no matter how >I choose to clock the circuit, I may end up balancing the pencil well >enough on end that I will see a much higher failure rate than predicted >by the standard formula. > > I think you need to make some measurements, if you can't get info from the manufacturer. Most likely, the timing will be pretty simple to figure out, as signals, especially strobes, will almost certainly either be clocked through a flip-flop right at the output, or have a minimum of gates between the last FF and the output. You really CAN'T work with so little information. What is the setup time of data and address signals from the CPU, relative to the strobes? What is the required setup and hold time of data and addresses presented to the CPU from outside? Or, do they provide all this in great detail, just never referencing any of this to the CPU clock? If you can't beat this information out of the manufacturer, then you should be able to measure it fairly easily. Jon ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 23 Aug 2003 11:47:15 -0400 Organization: Arius, Inc Lines: 64 Message-ID: <3F478C83.E7EA5466@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVaoHRWBWkgCi7tbSsgKlUYxGlvlTx1GjZoXws1U76YzRLbZMF3EZ9kc X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 23 Aug 2003 15:47:11 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32136 Jon Elson wrote: > > rickman wrote: > > >I am designing a FPGA interface for an MCU which uses only async > >strobes. However they are not truely async, in reality the timing to > >the clock is simply not spec'd. So if I understand metastability > >correctly, I can not use the standard circuit to reduce the failure rate > >to insignificant rates. Since there is a fixed relationship between the > >clock and the command strobes (even though it is unknown) no matter how > >I choose to clock the circuit, I may end up balancing the pencil well > >enough on end that I will see a much higher failure rate than predicted > >by the standard formula. > > > > > I think you need to make some measurements, if you can't get info from > the manufacturer. Most likely, the timing will be pretty simple to figure > out, as signals, especially strobes, will almost certainly either be clocked > through a flip-flop right at the output, or have a minimum of gates between > the last FF and the output. > > You really CAN'T work with so little information. What is the setup time > of data and address signals from the CPU, relative to the strobes? What is > the required setup and hold time of data and addresses presented to the > CPU from outside? > > Or, do they provide all this in great detail, just never referencing any > of this > to the CPU clock? Exactly. I have found that although all MCUs and DSPs are synchronous, unless they are interfacing to synchronous memory, they don't provide info on timing in relation to the clock. > If you can't beat this information out of the manufacturer, then you > should be > able to measure it fairly easily. I can't measure it for two reasons; one, the chips are not available except as samples (no eval boards yet); two, even if I measure it, there is no guarantee that the chips will not change since this is not a spec'd parameter. Processes are improved constantly and many aspects of timing can change. I don't want to design to an early chip only to find that in six months they change. For now I am working with the assumption that if I provide enough settling time, the timing of the signals will not matter. The window of failure is pretty small. The more time allowed for settling, the smaller the window. I may expand the time to a full clock cycle (20ns - 5 ns routing) which should make the window way too small to hit with any frequency. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 23 Aug 2003 16:01:31 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 15 Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1061654491 44766 128.32.112.203 (23 Aug 2003 16:01:31 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Sat, 23 Aug 2003 16:01:31 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.news2me.com!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!news.he.net!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32141 In article <3F478C83.E7EA5466@yahoo.com>, rickman wrote: >> Or, do they provide all this in great detail, just never referencing any >> of this >> to the CPU clock? > >Exactly. I have found that although all MCUs and DSPs are synchronous, >unless they are interfacing to synchronous memory, they don't provide >info on timing in relation to the clock. Silly question: Does it ever CROSS the clock boundry, or is it always before or always after? Or is it always CLOSE, in which case you could use the 180 out-of-phase clock to clock it in? -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 23 Aug 2003 13:30:00 -0400 Organization: Arius, Inc Lines: 55 Message-ID: <3F47A498.B7FF581B@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYnpYCWbP53bhBkJX6+/ce5m8T7MsvTbKLf4zt5L4SXbRcJmLv6jVdl X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 23 Aug 2003 17:29:55 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!wn13feed!worldnet.att.net!199.184.165.233!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32137 "Nicholas C. Weaver" wrote: > > In article <3F478C83.E7EA5466@yahoo.com>, > rickman wrote: > >> Or, do they provide all this in great detail, just never referencing any > >> of this > >> to the CPU clock? > > > >Exactly. I have found that although all MCUs and DSPs are synchronous, > >unless they are interfacing to synchronous memory, they don't provide > >info on timing in relation to the clock. > > Silly question: Does it ever CROSS the clock boundry, or is it always > before or always after? Or is it always CLOSE, in which case you > could use the 180 out-of-phase clock to clock it in? > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu I don't know, it is not spec'd and I don't have samples. But even if I had samples to test, if it is not spec'd, I would have no way of knowing it won't change. For now I am using the falling edge to clock it in and the rising edge to reclock to allow for settling. This gives me some 5 ns or more for settling. The problem is that if the chip changes (or even wanders over temperature, voltage, phase of the moon) it could put me right smack in the critical window to cause a failure. But after hashing it around I think this is still a very, very remote possibility given enough settling time. I don't know if 5 ns is enough, but certainly 10 ns is. I may consider using the same edge for clocking it in and the second reg. This would give me some 15 ns which certainly should be way more than enough. Another result of them not specing the clock relationship is the async nature of the WAIT input. My circuit requires using this signal to make sure the cycle ends after the data setup time. Since there is no way of knowing when the signal is sampled (and the fact that the setup time is about the same as the clock period) I will not be able to design the circuit to work in a fixed number of clock cycles. I will be able to define a max value, but not set it to a fixed number. I guess this is not a big issue, but I like to be able to do calulations on throughput and the bus cycle will determine that. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Jon Elson Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 23 Aug 2003 14:32:07 -0500 Organization: Pico Systems Lines: 45 Message-ID: <3F47C137.5030806@pico-systems.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> NNTP-Posting-Host: h-69-3-230-106.chcgilgm.covad.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sun-news.laserlink.net 1061666852 27871 69.3.230.106 (23 Aug 2003 19:27:32 GMT) X-Complaints-To: abuse@covad.net NNTP-Posting-Date: Sat, 23 Aug 2003 19:27:32 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!nntp.abs.net!ash.uu.net!sun-news.laserlink.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32139 rickman wrote: >"Nicholas C. Weaver" wrote: > > >>In article <3F478C83.E7EA5466@yahoo.com>, >>rickman wrote: >> >> >>>>Or, do they provide all this in great detail, just never referencing any >>>>of this >>>>to the CPU clock? >>>> >>>> >>>Exactly. I have found that although all MCUs and DSPs are synchronous, >>>unless they are interfacing to synchronous memory, they don't provide >>>info on timing in relation to the clock. >>> >>> >>Silly question: Does it ever CROSS the clock boundry, or is it always >>before or always after? Or is it always CLOSE, in which case you >>could use the 180 out-of-phase clock to clock it in? >>-- >>Nicholas C. Weaver nweaver@cs.berkeley.edu >> >> > >I don't know, it is not spec'd and I don't have samples. But even if I >had samples to test, if it is not spec'd, I would have no way of knowing >it won't change. For now I am using the falling edge to clock it in and >the rising edge to reclock to allow for settling. This gives me some 5 >ns or more for settling. > > This is insane! What imbecile wrote the data sheets? Is it impossible that someone would ever want to build a synchronous memory controller or other peripheral for this MCU? Can you get hold of someone at the manufacturer to help you with this? I've never run into this problem, where the timing of the strobes, etc. was so vague. Is this chip real, or is it vaporware, where the only physical reality is a piece of paper? Jon ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sun, 24 Aug 2003 08:36:24 -0400 Organization: Arius, Inc Lines: 43 Message-ID: <3F48B148.6F43063@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYKC0MXdzh98gqOj5aq93OUtRA9TdjyHVVyy3z5jzXro6msfQFxyI+T X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 24 Aug 2003 12:36:16 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!nntp.theplanet.net!inewsm1.nntp.theplanet.net!peer1.news.newnet.co.uk!peer1.news.newnet.co.uk!in.100proofnews.com!in.100proofnews.com!elnk-atl-nf1!newsfeed.earthlink.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32146 Jon Elson wrote: > > rickman wrote: > >I don't know, it is not spec'd and I don't have samples. But even if I > >had samples to test, if it is not spec'd, I would have no way of knowing > >it won't change. For now I am using the falling edge to clock it in and > >the rising edge to reclock to allow for settling. This gives me some 5 > >ns or more for settling. > > > > > This is insane! What imbecile wrote the data sheets? Is it impossible that > someone would ever want to build a synchronous memory controller or > other peripheral for this MCU? Can you get hold of someone at the > manufacturer to help you with this? I've never run into this problem, where > the timing of the strobes, etc. was so vague. Is this chip real, or is it > vaporware, where the only physical reality is a piece of paper? > > Jon I don't think this is uncommon. In fact, I believe most devices that use an async interface to memory don't spec timing to the CPU clock. This chip does have an SDRAM interface, but they provide separate control strobes and clock. As to reaching support at the manufacturer, I have had no luck contacting them directly. I have to go through my local sales rep (who is an engineer, not just another pretty face). But this makes it even harder to get a question and answer communicated than going through the entry level people they have manning most support lines. I got one email that had been handled by some 4 or 5 people in each direction. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### Reply-To: "John_H" From: "John_H" Newsgroups: comp.arch.fpga References: <3F46E816.96EF198B@yahoo.com> Subject: Re: Thinking out loud about metastability Lines: 86 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Mon, 25 Aug 2003 16:03:36 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1061827416 192.65.17.17 (Mon, 25 Aug 2003 10:03:36 MDT) NNTP-Posting-Date: Mon, 25 Aug 2003 10:03:36 MDT Organization: Xerox Officeprinting NewsReader Service Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border3.nntp.aus1.giganews.com!nntp.giganews.com!newsfeed1.easynews.com!easynews.com!easynews!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32158 "rickman" wrote in message news:3F46E816.96EF198B@yahoo.com... > I am designing a FPGA interface for an MCU which uses only async > strobes. However they are not truely async, in reality the timing to > the clock is simply not spec'd. So if I understand metastability > correctly, I can not use the standard circuit to reduce the failure rate > to insignificant rates. Since there is a fixed relationship between the > clock and the command strobes (even though it is unknown) no matter how > I choose to clock the circuit, I may end up balancing the pencil well > enough on end that I will see a much higher failure rate than predicted > by the standard formula. > > My understanding is that the standard formula assumes that the two > signals are not related in frequency. So the probability that they will > be at the right point to cause a failure depends on the rate of each and > the width of the "failure window". In my case the probability of the > event being in the failure window can be very high if the timing is just > right. > > Other than the obvious of using a separate clock for the FPGA, how can I > design this circuit and get a low enough failure rate? I guess adding > more time will reduce the failure rate, but how do I know how much time > is enough since the standard formula does not apply? The formula assumes independent clocks. What you end up with is an even distribution of edges sampling times across the window. If there's absolutely no noise in your clocks (femtosecond jitter?) and there's no thermal, schottky, or johnson noise in your circuit, you might be able to balance the pencil just on the edge. If you can make a jitter assumption, you might come up with an equivalent "fraction" of the clock period where your sample will be landing. Assuming this window is centered directly at the indecision point, you might get an idea what failure rates to expect from that formula. > In this particular circuit I expect the strobes to change on the rising > edge of the clock at about 50 MHz. Since I know nothing about the > actual relationship between the clock and the strobes, I have picked the > falling edge to clock the strobes into the chip. I assume that if the > outputs change slightly before the clock rising edge, it will not be > much and if they change later, it may be short enough to still give me > close to the 3 ns setup time I need. Then a rising edge FF syncs the > signal to the rest of the circuit and provides some 7 ns (out of 10 ns > clock difference) for settling. If metastability were an issue, every nanosecond you wait to do the second sample in your input register pair is a huge difference in failure rates. Rather than falling edge input, rising edge resample, then about 7ns for settling, consider moving the gap to the front end so all your "settling" takes place there. This way the logic following the second flop can have multiple destinations that are all properly covered by the timing constraints; only the gap between the two flops needs special treatment for settling. > I have no idea how good of an assumption this is. The output delays on > the CPU may be enough to put the strobe edge right in the critical point > to cause a failure. Even if I use an emperical approach and see which > edge to clock on to make the circuit work, I don't know that this will > operate over temperature, process, etc... > > I believe that some of the posts here have indicated that the "failure > window" in terms of time is in the low ps (or was it fs?) range. If my > circuit allows some 7 ns for settling, will this be enough to put the > MTBF above 100 years in a worse case situation? Is it possible to > balance the pencil well enough to make a circuit like this fail > frequently? If you're using Virtex-II, you could use the DCM to nudge the sampling clock by about 50ps increments to try to force some instability into the sampling. You can sample with the 90 degree before and 90 degree after phases to braket the value to figure out when your sampling is on the before side or the after side. > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Mon, 25 Aug 2003 09:49:33 -0700 Organization: Xilinx,Inc Lines: 14 Message-ID: <3F4A3E1E.E3A9E335@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: John_H Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32150 Looking at our recent Virtex-IIPro metastability tests, I figured out the metastability capture window: Using a 300 MHz clock, and a roughly 50 MHz data rate, we get one 1.5 ns delay ( that is clock-to-Q plus short routing plus set-up time) per second. And similarily one 2.0 ns delay per million seconds. For the 1.5 ns delay, the capture window is thus 3.3 ns / 50 million = 0.07 femtosecond For the 2.0 ns delay, the capture window is a million times smaller, and for 2.5 ns it's another million times smaller ... Light travels 0.3 m in a ns, 0.3 mm in one ps, and 0.3 micron in one femtosecond. Peter Alfke, Xilinx Applications ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Mon, 25 Aug 2003 17:09:18 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 25 Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F4A3E1E.E3A9E335@xilinx.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1061831358 62168 128.32.112.203 (25 Aug 2003 17:09:18 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Mon, 25 Aug 2003 17:09:18 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32160 In article <3F4A3E1E.E3A9E335@xilinx.com>, Peter Alfke wrote: >Looking at our recent Virtex-IIPro metastability tests, I figured out >the metastability capture window: >Using a 300 MHz clock, and a roughly 50 MHz data rate, we get one 1.5 ns >delay ( that is clock-to-Q plus short routing plus set-up time) per >second. And similarily one 2.0 ns delay per million seconds. Does this mean that, thanks to routing delay, you could just do a 3 flip-flops in parallel for capturing, voting circuit on the other side, and not have to worry about it? >For the 1.5 ns delay, the capture window is thus 3.3 ns / 50 million = >0.07 femtosecond >For the 2.0 ns delay, the capture window is a million times smaller, >and for 2.5 ns it's another million times smaller ... > >Light travels 0.3 m in a ns, 0.3 mm in one ps, and 0.3 micron in one >femtosecond. > >Peter Alfke, Xilinx Applications -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F4A3E1E.E3A9E335@xilinx.com> <3F4A4A96.18037049@xilinx.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 24 Date: Mon, 25 Aug 2003 19:43:04 GMT NNTP-Posting-Host: 67.121.247.215 X-Complaints-To: abuse@sonic.net X-Trace: typhoon.sonic.net 1061840584 67.121.247.215 (Mon, 25 Aug 2003 12:43:04 PDT) NNTP-Posting-Date: Mon, 25 Aug 2003 12:43:04 PDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!sjc70.webusenet.com!sjc72.webusenet.com!news.webusenet.com!feed.news.sonic.net!typhoon.sonic.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32177 On Mon, 25 Aug 2003 18:25:30 +0000 (UTC), nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: >In article <3F4A4A96.18037049@xilinx.com>, >Peter Alfke wrote: >>Sounds reasonable to me... >>Peter Alfke > >Just realized. How does a LUT input react to a metastable input (to >do the voting circuit)? Voting circuits don't work as a metastability cure. Imagine a 2-out-of-3 circuit that's looking at three flip-flops. If one FF is HIGH, another is LOW, and the third is metastable, what's the output of the voting circuit? Back in the early 80's, UCSD professor Leonard Marino wrote a paper in which he very thoroughly analyzed a number of alleged metastability cures, one of which was the voting circuit. I can't find my copy of the paper, but it must have appeared in IEEE Transactions on Computers. Bob Perlman Cambrian Design Works ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Mon, 25 Aug 2003 21:31:53 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 34 Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1061847113 73841 128.32.112.203 (25 Aug 2003 21:31:53 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Mon, 25 Aug 2003 21:31:53 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32184 In article , Bob Perlman wrote: >On Mon, 25 Aug 2003 18:25:30 +0000 (UTC), >nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: > >>In article <3F4A4A96.18037049@xilinx.com>, >>Peter Alfke wrote: >>>Sounds reasonable to me... >>>Peter Alfke >> >>Just realized. How does a LUT input react to a metastable input (to >>do the voting circuit)? > >Voting circuits don't work as a metastability cure. Imagine a >2-out-of-3 circuit that's looking at three flip-flops. If one FF is >HIGH, another is LOW, and the third is metastable, what's the output >of the voting circuit? As long as the voting circuit output is consistant LOW or HIGH, it doesn't really matter, at least in the context given. If the voting circuit output is metastable, then thats problematic. >Back in the early 80's, UCSD professor Leonard Marino wrote a paper in >which he very thoroughly analyzed a number of alleged metastability >cures, one of which was the voting circuit. I can't find my copy of >the paper, but it must have appeared in IEEE Transactions on >Computers. > >Bob Perlman >Cambrian Design Works -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 34 Date: Mon, 25 Aug 2003 21:41:41 GMT NNTP-Posting-Host: 67.121.247.215 X-Complaints-To: abuse@sonic.net X-Trace: typhoon.sonic.net 1061847701 67.121.247.215 (Mon, 25 Aug 2003 14:41:41 PDT) NNTP-Posting-Date: Mon, 25 Aug 2003 14:41:41 PDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!sjc70.webusenet.com!sjc72.webusenet.com!news.webusenet.com!feed.news.sonic.net!typhoon.sonic.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32192 On Mon, 25 Aug 2003 21:31:53 +0000 (UTC), nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: >In article , >Bob Perlman wrote: >>On Mon, 25 Aug 2003 18:25:30 +0000 (UTC), >>nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote: >> >>>In article <3F4A4A96.18037049@xilinx.com>, >>>Peter Alfke wrote: >>>>Sounds reasonable to me... >>>>Peter Alfke >>> >>>Just realized. How does a LUT input react to a metastable input (to >>>do the voting circuit)? >> >>Voting circuits don't work as a metastability cure. Imagine a >>2-out-of-3 circuit that's looking at three flip-flops. If one FF is >>HIGH, another is LOW, and the third is metastable, what's the output >>of the voting circuit? > >As long as the voting circuit output is consistant LOW or HIGH, it >doesn't really matter, at least in the context given. If the voting >circuit output is metastable, then thats problematic. True on both counts. But how do you do make the output stable? This is the point at which folks have tried adding hysteresis, etc. And we've all been down that road before, I think. Bob Perlman Cambrian Design Works ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Mon, 25 Aug 2003 14:53:01 -0700 Organization: Xilinx,Inc Lines: 15 Message-ID: <3F4A853E.BC7A5575@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A3E1E.E3A9E335@xilinx.com> <3F4A4A96.18037049@xilinx.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: "Nicholas C. Weaver" Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32179 I have never seen strange levels or oscillations ( well, 25 years ago we had TTL oscillations). Metastability just affects the delay on the Q output. Your suggestion seems to be to do exactly what one "should not do," namely use multiple synchronization flip-flops with tiny input routing delay differences, and then do majority voting on the three outputs. Seems like a smart idea, because it does not waste extra latency. Peter Alfke, Xilinx ====================== "Nicholas C. Weaver" wrote: > > Just realized. How does a LUT input react to a metastable input (to > do the voting circuit)? > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu ###### Message-ID: <3F4A877C.6BC0FC8@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 38 Date: Mon, 25 Aug 2003 18:02:36 -0400 NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: lakeread05 1061848466 68.15.41.165 (Mon, 25 Aug 2003 17:54:26 EDT) NNTP-Posting-Date: Mon, 25 Aug 2003 17:54:26 EDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news-fra1.dfn.de!news-mue1.dfn.de!newsfeed.stueberl.de!peer01.cox.net!cox.net!p01!lakeread05.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32180 Rickman et al, This is indeed fairly common. The manufacturer specifies the interface timing only relative to signals on that interface, not relative to the DSP clock. This often shows up on memory interfaces intended for static async RAM memory, for example. In that case, the timing is all relative to the address, write pulse and data and nearly never in relation to a clock. As Rickman points out, there is no valid assumption you can make about the relationship to the DSP clock other than the fact that these signals are synchronous to the clock unless it is specified in the data sheet. Where it is not, even the manufacturer can't tell you what the timing is because they don't characterize it. OK, so how do you deal with it? The trick is to make your interface look like the intended device, which can be tricky with an FPGA. For writes, you can use write strobe as a clock signal into the FPGA, and use that then to clock the address/data coming in from the CPU. I use an additional toggle flip-flop to indicate when data has written by changing state. Sync the toggle signal to your local clock, then use a state machine to produce a 1 clock pulse in response to the toggle changing state, and that 1 clock pulse then enables registers that copy the input registers to locally clocked registers. Works fine like that if the input rate is lower than the local clock by a factor of 3 or more. If less, then you need to be a bit more clever about catching multiple writes then transferring more than one word on one local clock. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### Message-ID: <3F4ABCF1.499F150E@attbi.com> From: Phil Hays Organization: phil-hays at above domain X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F4A3E1E.E3A9E335@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 12 NNTP-Posting-Host: 12.207.238.193 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1061862502 12.207.238.193 (Tue, 26 Aug 2003 01:48:22 GMT) NNTP-Posting-Date: Tue, 26 Aug 2003 01:48:22 GMT Date: Tue, 26 Aug 2003 01:48:22 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!skynet.be!skynet.be!freenix!deine.net!news-out1.nntp.be!propagator2-sterling!news-in-sterling.nuthinbutnews.com!cyclone1.gnilink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32195 "Nicholas C. Weaver" wrote: > Does this mean that, thanks to routing delay, you could just do a 3 > flip-flops in parallel for capturing, voting circuit on the other > side, and not have to worry about it? What if one FF says '1', one FF says '0' and the last is someplace inbetween? -- Phil Hays ###### Message-ID: <3F4ABDA9.8EA0C302@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> <3F4A877C.6BC0FC8@andraka.com> <3F4A92F7.6060909@artsci.wustl.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 58 Date: Mon, 25 Aug 2003 21:53:45 -0400 NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: lakeread05 1061862335 68.15.41.165 (Mon, 25 Aug 2003 21:45:35 EDT) NNTP-Posting-Date: Mon, 25 Aug 2003 21:45:35 EDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!peer01.cox.net!cox.net!p01!lakeread05.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32201 Good luck even getting the structure out of the manufacturer though. Even if you do, I think you'll find a good part of the delay is in the clock tree. Unless that is characterized, you probably won't be able to infer much more than what the data sheet tells you. Jon Elson wrote: > Ray Andraka wrote: > > >Rickman et al, > > > >This is indeed fairly common. The manufacturer specifies the interface timing > >only relative to signals on that interface, not relative to the DSP clock. This > >often shows up on memory interfaces intended for static async RAM memory, for > >example. In that case, the timing is all relative to the address, write pulse > >and data and nearly never in relation to a clock. As Rickman points out, there > >is no valid assumption you can make about the relationship to the DSP clock > >other than the fact that these signals are synchronous to the clock unless it is > >specified in the data sheet. Where it is not, even the manufacturer can't tell > >you what the timing is because they don't characterize it. > > > Well, just because the manufacturer isn't putting the info in the data > sheets, and don't > test for it, I suspect that you could get a rough description that could > be quite helpful. > Knowing, for instance, that the strobes will always follow a CPU clock > by at least > 1 ns, and never change than 5 nS after the clock, would make designing a > synchronous > memory/peripheral controller running from the same clock a lot simpler. > > If you can just get the roughest of descriptions of the clock vs. > strobes circuitry, you > can improve the system performance greatly, because you don't have to > have ranked > FFs on every strobe. > > Now, on the high speed stuff, with clock multipliers, etc. it can get > quite complex, and > a CPU swap to the next higher speed can throw everything off due to a > change in clock > multiplier. But, I gathered from the initial post that this wasn't a > clock multiplied CPU. > > Jon -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Tue, 26 Aug 2003 07:13:55 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> X-Complaints-To: abuse@supernews.com Lines: 27 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:32212 >As long as the voting circuit output is consistant LOW or HIGH, it >doesn't really matter, at least in the context given. If the voting >circuit output is metastable, then thats problematic. Everything I know about metastability says that looking for things like voting circuits is barking up the wrong tree. If anybody has a good example of some "fix", "kludge" or "hack" that actually works, please tell me/us and explain why. We all agree that waiting longer helps. Right? (Helps lots!) Consider a voting circuit. It adds a few gates between the first bank of 3 FFs and the next FF that captures the output of the voting logic. Compare that with the clean/simple case of FF-FF with minimal routing delays. The delay through the gates is working against an exponential in increased settling time. Even if the normal no-logic path used a LUT so the voting logic is free, there is still the extra delay of routing from nearby FFs over to the LUT. (The other two FFs won't be quite so close.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Tue, 26 Aug 2003 09:32:02 -0700 Organization: Xilinx,Inc Lines: 24 Message-ID: <3F4B8B82.D32E620@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Hal Murray Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!peernews-us.colt.net!newsfeed.news2me.com!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32223 I am embarrassed. I fell into the "fix metastability trap". To quote a German proverb: "Alter schuetzt vor Torheit nicht" (Age is no protection against stupidity). So, before anybody starts experimenting: Three or more flip-flops with majority voting are no cure for metastability, they just protract the agony. And so do all sorts of other schemes. All of them! But, as Hal wrote, just waiting helps. And you do not have to wait very long. Clocking the synchronizer result at 300 MHz into a second flip-flop gives you the "wrong" result once in a billion years. ( and we can debate what is actually right or wrong ). The uncertainty of 0 or 1 is never the issue in metastability ( either answer is as good as the other), it is the unpredictable timing that is the bummer. Since that range of unpredictability (is that a word?) is statistically less than 2 ns for any reasonable probability, we can ignore metastability in all but the very fastest applications. But we cannot fix it, not with voting, nor with hysteresis, nor with any other contraptions. My thanks to Bob Perlman for kicking me in the shins. It's good to have friends. :-) Peter Alfke ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 04:16:21 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <43snkv40agdhn30u8jn5n8imc5ap4tng0b@4ax.com> X-Complaints-To: abuse@supernews.com Lines: 22 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!peer2.news.opaltelecom.net!zen.net.uk!in.100proofnews.com!in.100proofnews.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:32249 >I proposed some time ago that injecting a high frequency signal into the FF >feedback path would limit metastabilty maximum duration. >You drop a pin onto a table now and then it will land perfectly balanced on >its point, how long it stays upright depends on how well it was balanced. >Vibrate the table and it will stay upright for less time. I don't think so. This is another example of a "fix". They don't work. The only question is can you see why they don't work? In this case, the vibrations will kick some pins that have started to fall back to the ballancing point. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### Message-ID: <3F4C4201.733C@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <43snkv40agdhn30u8jn5n8imc5ap4tng0b@4ax.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 42 Date: Wed, 27 Aug 2003 17:30:41 +1200 NNTP-Posting-Host: 210.246.4.192 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1061962247 210.246.4.192 (Wed, 27 Aug 2003 17:30:47 NZST) NNTP-Posting-Date: Wed, 27 Aug 2003 17:30:47 NZST Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!in.100proofnews.com!in.100proofnews.com!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32243 Hal Murray wrote: > > >I proposed some time ago that injecting a high frequency signal into the FF > >feedback path would limit metastabilty maximum duration. With a virtual aperture of 0.07fs, that may have to be an especially high frequency :) Illuminating the die with light, could test your theory. Another test, would be to create a placement matrix of 3x3 FF's, and take the output only from the very centre one - the others are there to disturb(vibrate) the lead inductances. If the virtual aperture does not change, with/without the extra 8 FF's then the theory does not look good. > >You drop a pin onto a table now and then it will land perfectly balanced on > >its point, how long it stays upright depends on how well it was balanced. > > >Vibrate the table and it will stay upright for less time. > > I don't think so. > > This is another example of a "fix". They don't work. The only question > is can you see why they don't work? > > In this case, the vibrations will kick some pins that have started to > fall back to the ballancing point. If you take this physical analogy, then there will be a vibration that will speed collapse of the most perfectly balanced pin. Taking an almost ideal balance, the movement from balance is VERY slow initially, and a skew movement will accelerate that portion of the curve. If it DOES move to balance the pin, the it also moves to unbalance in the next half period. At some time in the period, the pin fall becomes regenerative, and accelerates away from any vibration effect. Key question : Does a metastable FF follow this model ? - jg ###### Message-ID: <3F4C4201.733C@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <43snkv40agdhn30u8jn5n8imc5ap4tng0b@4ax.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 42 Date: Wed, 27 Aug 2003 17:30:41 +1200 NNTP-Posting-Host: 210.246.4.192 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1061962247 210.246.4.192 (Wed, 27 Aug 2003 17:30:47 NZST) NNTP-Posting-Date: Wed, 27 Aug 2003 17:30:47 NZST Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!in.100proofnews.com!in.100proofnews.com!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32257 Hal Murray wrote: > > >I proposed some time ago that injecting a high frequency signal into the FF > >feedback path would limit metastabilty maximum duration. With a virtual aperture of 0.07fs, that may have to be an especially high frequency :) Illuminating the die with light, could test your theory. Another test, would be to create a placement matrix of 3x3 FF's, and take the output only from the very centre one - the others are there to disturb(vibrate) the lead inductances. If the virtual aperture does not change, with/without the extra 8 FF's then the theory does not look good. > >You drop a pin onto a table now and then it will land perfectly balanced on > >its point, how long it stays upright depends on how well it was balanced. > > >Vibrate the table and it will stay upright for less time. > > I don't think so. > > This is another example of a "fix". They don't work. The only question > is can you see why they don't work? > > In this case, the vibrations will kick some pins that have started to > fall back to the ballancing point. If you take this physical analogy, then there will be a vibration that will speed collapse of the most perfectly balanced pin. Taking an almost ideal balance, the movement from balance is VERY slow initially, and a skew movement will accelerate that portion of the curve. If it DOES move to balance the pin, the it also moves to unbalance in the next half period. At some time in the period, the pin fall becomes regenerative, and accelerates away from any vibration effect. Key question : Does a metastable FF follow this model ? - jg ###### From: Muzaffer Kal Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Organization: DSPIA Inc. Message-ID: <7lqokvk0qei16hui42a7s5763a3p8md8bg@4ax.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 34 NNTP-Posting-Host: 64.169.92.159 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr29.news.prodigy.com 1061972974 ST000 64.169.92.159 (Wed, 27 Aug 2003 04:29:34 EDT) NNTP-Posting-Date: Wed, 27 Aug 2003 04:29:34 EDT X-UserInfo1: FKPO@MC@@S@IB\\Y\RHFO_TDFZ\@@FXLM@TDOCQDJ@_@FNHCYFWUQBKZQLYJX\_ITFD_KFVLUN[DOM_A_NSYNWPFWNS[XV\I]PZ@BQ[@CDQDPCL^FKCBIPC@KLGEZEFNMDYMKHRL_YYYGDSSODXYN@[\BK[LVTWI@AXGQCOA_SAH@TPD^\AL\RLGRFWEARBM Date: Wed, 27 Aug 2003 08:29:34 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr29.news.prodigy.com.POSTED!857c7983!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32252 On Tue, 26 Aug 2003 07:13:55 -0000, hmurray@suespammers.org (Hal Murray) wrote: >>As long as the voting circuit output is consistant LOW or HIGH, it >>doesn't really matter, at least in the context given. If the voting >>circuit output is metastable, then thats problematic. > >Everything I know about metastability says that looking for things >like voting circuits is barking up the wrong tree. If anybody has >a good example of some "fix", "kludge" or "hack" that actually works, >please tell me/us and explain why. > >We all agree that waiting longer helps. Right? (Helps lots!) > >Consider a voting circuit. It adds a few gates between the first >bank of 3 FFs and the next FF that captures the output of the voting >logic. Compare that with the clean/simple case of FF-FF with minimal >routing delays. The delay through the gates is working against an >exponential in increased settling time. > >Even if the normal no-logic path used a LUT so the voting logic is free, >there is still the extra delay of routing from nearby FFs over to the >LUT. (The other two FFs won't be quite so close.) How about sampling the data with multiple clocks which are slightly apart and detecting a transition ? If you have enough clocks and the rise/fall time of the input is limited you can safely decide whether a transition has happened and if any flop has the potential of going MS and not even use the output of that flop. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 08:20:03 -0400 Organization: Arius, Inc Lines: 44 Message-ID: <3F4CA1F3.57E0DB4D@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> <3F4A877C.6BC0FC8@andraka.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZmZ92z6Iw4S85d6H50Y95dNZkoHhQ6hZtLBzEf/3grwk7IHLSX5i6j X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 27 Aug 2003 12:20:36 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!skynet.be!skynet.be!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32241 Ray Andraka wrote: > > The trick is to make your interface look like the intended device, which can be > tricky with an FPGA. For writes, you can use write strobe as a clock signal > into the FPGA, and use that then to clock the address/data coming in from the > CPU. I use an additional toggle flip-flop to indicate when data has written by > changing state. Sync the toggle signal to your local clock, then use a state > machine to produce a 1 clock pulse in response to the toggle changing state, and > that 1 clock pulse then enables registers that copy the input registers to > locally clocked registers. Works fine like that if the input rate is lower than > the local clock by a factor of 3 or more. If less, then you need to be a bit > more clever about catching multiple writes then transferring more than one word > on one local clock. This is all true. But my point is that even once you do all this, you have not reduced the metastability problem to near zero as in the case with the async clocks. Since I am using the *same* clock as the MCU, I have a relatively fixed timing relationship between my signals and my clock. The standard metastability model assumes two independant clocks with a random distribution of signficant edge timing. So you can analyze the likelyhood of the two edges being close enough to cause a failure and allow enough delay in the settling circuit to reduce the failure rate to acceptable levels (since we all know you can't *eliminate* failures). But with a fixed timing relationship, if the timing is just right (or wrong) the sync circuit does not reduce the failure rate enough. In fact you can not analyze the problem without a characterization of the random elements in the timing. I have allowed a lot more delay than needed and will be counting on the FFs being able to resolve the metastable state even in the worse case conditions. I don't see where I can do much else. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 08:20:03 -0400 Organization: Arius, Inc Lines: 44 Message-ID: <3F4CA1F3.57E0DB4D@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> <3F4A877C.6BC0FC8@andraka.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZmZ92z6Iw4S85d6H50Y95dNZkoHhQ6hZtLBzEf/3grwk7IHLSX5i6j X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 27 Aug 2003 12:20:36 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!skynet.be!skynet.be!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32255 Ray Andraka wrote: > > The trick is to make your interface look like the intended device, which can be > tricky with an FPGA. For writes, you can use write strobe as a clock signal > into the FPGA, and use that then to clock the address/data coming in from the > CPU. I use an additional toggle flip-flop to indicate when data has written by > changing state. Sync the toggle signal to your local clock, then use a state > machine to produce a 1 clock pulse in response to the toggle changing state, and > that 1 clock pulse then enables registers that copy the input registers to > locally clocked registers. Works fine like that if the input rate is lower than > the local clock by a factor of 3 or more. If less, then you need to be a bit > more clever about catching multiple writes then transferring more than one word > on one local clock. This is all true. But my point is that even once you do all this, you have not reduced the metastability problem to near zero as in the case with the async clocks. Since I am using the *same* clock as the MCU, I have a relatively fixed timing relationship between my signals and my clock. The standard metastability model assumes two independant clocks with a random distribution of signficant edge timing. So you can analyze the likelyhood of the two edges being close enough to cause a failure and allow enough delay in the settling circuit to reduce the failure rate to acceptable levels (since we all know you can't *eliminate* failures). But with a fixed timing relationship, if the timing is just right (or wrong) the sync circuit does not reduce the failure rate enough. In fact you can not analyze the problem without a characterization of the random elements in the timing. I have allowed a lot more delay than needed and will be counting on the FFs being able to resolve the metastable state even in the worse case conditions. I don't see where I can do much else. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 08:24:57 -0400 Organization: Arius, Inc Lines: 48 Message-ID: <3F4CA319.4023CD33@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> <3F4A877C.6BC0FC8@andraka.com> <3F4A92F7.6060909@artsci.wustl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZGKhk8K/7EEdOtsS3ih8GP1e7k/E7roKmXhgKe9SEYq1rj4y+WpmyR X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 27 Aug 2003 12:25:31 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-out1.nntp.be!propagator2-sterling!news-in-sterling.newsfeed.com!news-out.cwix.com!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32254 Jon Elson wrote: > > Well, just because the manufacturer isn't putting the info in the data > sheets, and don't > test for it, I suspect that you could get a rough description that could > be quite helpful. > Knowing, for instance, that the strobes will always follow a CPU clock > by at least > 1 ns, and never change than 5 nS after the clock, would make designing a > synchronous > memory/peripheral controller running from the same clock a lot simpler. Except that you don't know that this won't change if they tweek the chip design. It could very easily be 1 to 5 ns delay now and then change to 5 to 10 ns when they switch to a new process for cost savings. The 5 to 10 ns delay will put it right at the falling edge where I would likely be clocking it in with the old numbers. > If you can just get the roughest of descriptions of the clock vs. > strobes circuitry, you > can improve the system performance greatly, because you don't have to > have ranked > FFs on every strobe. > > Now, on the high speed stuff, with clock multipliers, etc. it can get > quite complex, and > a CPU swap to the next higher speed can throw everything off due to a > change in clock > multiplier. But, I gathered from the initial post that this wasn't a > clock multiplied CPU. Actually, yes the MCU runs at 8x or 4x the input clock. But the output is at the MCU rate and I will be clocking the FPGA with the 8x MCU output clock. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 08:35:37 -0700 Organization: Xilinx,Inc Lines: 25 Message-ID: <3F4CCFC9.69DB6A48@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <43snkv40agdhn30u8jn5n8imc5ap4tng0b@4ax.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!ctu-gate!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32261 Well, the "pin is falling over" in 2 ns anyhow, so how fast can you "shake the table"? We are not worried about microseconds of metastability anymore... Peter Alfke nospam wrote: > > Peter Alfke wrote: > > >I am embarrassed. I fell into the "fix metastability trap". > >To quote a German proverb: > > "Alter schuetzt vor Torheit nicht" (Age is no protection against stupidity). > > > >So, before anybody starts experimenting: > >Three or more flip-flops with majority voting are no cure for > >metastability, they just protract the agony. And so do all sorts of > >other schemes. All of them! > > I proposed some time ago that injecting a high frequency signal into the FF > feedback path would limit metastabilty maximum duration. > > You drop a pin onto a table now and then it will land perfectly balanced on > its point, how long it stays upright depends on how well it was balanced. > > Vibrate the table and it will stay upright for less time. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 08:52:39 -0700 Organization: Xilinx,Inc Lines: 15 Message-ID: <3F4CD3C7.42C72EFE@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> <3F4A877C.6BC0FC8@andraka.com> <3F4CA1F3.57E0DB4D@yahoo.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32260 Rick: as I mentioned, the metastability-catching is so small, that you may not hit it consistently even if you try ( 0.07 femtoseconds width for a 1.5 ns metastable delay. If you can accomodate 3 ns of delay, the probability gets so small, you can forget about it. Every extra half nanosecond increases the MTBF a million times. If you are still not convinced, you could develop a training ( adaptive ) search for a safe clock phase. Virtex-II DCMs do this exceptionally well with their fine phase control, but there are also other, less elegant methods. Metastably yours Peter Alfke ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 27 Aug 2003 11:35:04 -0700 Organization: http://groups.google.com/ Lines: 16 Message-ID: <8471ba54.0308271035.13f12cb@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062009305 3142 127.0.0.1 (27 Aug 2003 18:35:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 27 Aug 2003 18:35:05 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32266 Peter Alfke wrote in message news: > > But we cannot fix it, not with voting, nor with hysteresis, nor with any > other contraptions. > > My thanks to Bob Perlman for kicking me in the shins. It's good to have > friends. :-) > Peter Alfke Question: When a D-type flip-flop is in meta-stability, is it's output (Q pin) voltage equal to the input (D pin) voltage? If it's not the same voltage, then a cascaded flip-flop, clocked just after the first one, would not be in meta-stability! Isn't it? Luiz Carlos ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 13:43:05 -0700 Organization: Xilinx,Inc Lines: 32 Message-ID: <3F4D17D9.5CFD8B91@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Luiz Carlos Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!npeer.de.kpn-eurorings.net!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32279 The output level of a flip-flop during its metastable time is irrelevant. If it were in the middle ( which it isn't) we could easily fix this with a zener diode. The problem is timing. The Q output can - and will - change to the opposite state at a totally unpredictable time. That's the problem: unpredictable timing, not unknown levels. Cascading flip-flops is the standard remedy, but it introduces latency. Remember: Metastability causes an extra 3 ns of unpredictable delay once in a billion years... Seems to be an affordable risk. Peter Alfke ========================= Luiz Carlos wrote: > > Peter Alfke wrote in message news: > > > > But we cannot fix it, not with voting, nor with hysteresis, nor with any > > other contraptions. > > > > My thanks to Bob Perlman for kicking me in the shins. It's good to have > > friends. :-) > > Peter Alfke > > Question: When a D-type flip-flop is in meta-stability, is it's output > (Q pin) voltage equal to the input (D pin) voltage? > > If it's not the same voltage, then a cascaded flip-flop, clocked just > after the first one, would not be in meta-stability! Isn't it? > > Luiz Carlos ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 61 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr13.news.prodigy.com 1062032738 ST000 216.103.85.188 (Wed, 27 Aug 2003 21:05:38 EDT) NNTP-Posting-Date: Wed, 27 Aug 2003 21:05:38 EDT X-UserInfo1: Q[R_PJONSBUAB^X[\ZHXOFTBTR\B@GXLN@GZ_GYO^JWTEPIB_NVUAH_[BL[\IRKIANGGJBFNJF_DOLSCENSY^U@FRFUEXR@KFXYDBPWBCDQJA@X_DCBHXR[C@\EOKCJLED_SZ@RMWYXYWE_P@\\GOIW^@SYFFSWHFIXMADO@^[ADPRPETLBJ]RDGENSKQQZN Date: Thu, 28 Aug 2003 01:05:38 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr13.news.prodigy.com.POSTED!7ae961dc!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32303 Maybe the following would help some people: http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm Let me be dogmatic: Flip flops may go metastable when input signals do not meet the setup and hold specifications with regard to the clock signal. These inputs include D, CE, CLR, PRE, S, R, T, J, K. There is no cure for metastability. What you can do is trade latency of your system for higher MTBF. People that have found a cure are wrong. Circuits that purport to solve metastability through hysteresis fail because the hysteresis circuit itself can go metastable Circuits that purport to solve metastability with injected noise fail because the noise is as likely to push a non-metastable event into being a metastable event as it is to helping to resolve such an event. Just because current flip flops are better than stuff of a few years ago, and the probability and resolution time of metastable events is better, does not mean you can ignore this stuff. If someone says that things are so good now that "you almost don't have to worry about this anymore", what it means is that you absolutely need to understand it and design for it. If you don't, you will have unreliable systems. Nothing improves the MTBF of a metastable synchronizer better than just waiting longer. Not clocking the intermediate signal on the negative clock edge. Not voting. Not threshold testing. Not adding noise. Not fancy SPICE simulations. Not predicting circuits. Not circuits designed to bias the outcome to either 1 or 0. Not clocking it twice as fast through twice as many flip flops. Nothing. From Thomas Cheney, October 1979: "In closing, there is a great deal of theoretical and experimental evidence that a region of anomalous behavior exists for every device that has two stable states. The maturity of this topic is now such that papers making contrary claims without theoretical or experimental support should not be accepted for publication". Philip Freidin Philip Freidin Fliptronics ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 21:10:26 -0400 Organization: Arius, Inc Lines: 49 Message-ID: <3F4D5682.AA13889@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F46F4AC.8040209@pico-systems.com> <3F478C83.E7EA5466@yahoo.com> <3F47A498.B7FF581B@yahoo.com> <3F47C137.5030806@pico-systems.com> <3F4A877C.6BC0FC8@andraka.com> <3F4CA1F3.57E0DB4D@yahoo.com> <3F4CD3C7.42C72EFE@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbZIeY8jfIdw0xImbVpRxoKiCRb73/XEBdfHGMwaTjDwSvVHOx9d86B X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 28 Aug 2003 01:11:13 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!solnet.ch!solnet.ch!newsfeed.tiscali.ch!feed.news.nacamar.de!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32308 Peter Alfke wrote: > > Rick: > as I mentioned, the metastability-catching is so small, that you may not > hit it consistently even if you try ( 0.07 femtoseconds width for a 1.5 > ns metastable delay. > If you can accomodate 3 ns of delay, the probability gets so small, you > can forget about it. Every extra half nanosecond increases the MTBF a > million times. I understand how the resolution time affects the failure rate. I also understand that the timing window is so small that it is very hard to hit even if you try. My point is that the analysis has been done assuming a random distribution of timing which is not valid for this case. If you have an MTBF of 100 years with the standard model, you may well see an MTBF of an hour or less with this situation. I will be using a half clock cycle (10 ns) minus some 5 ns of delay which should give me lots of room for settling. But unless I acutally know something about my timing distribution it will be hard to say what my expected MTBF is. Of course, it is actually very unlikely that the timing of my circuit will be such that the problem shows even without the resolution time. But this sort of circuit does not prevent the worse case timing if all the planets line up and the constellations are aligned. > If you are still not convinced, you could develop a training ( adaptive > ) search for a safe clock phase. Virtex-II DCMs do this exceptionally > well with their fine phase control, but there are also other, less > elegant methods. Unfortunately this design is in the 5 volt tolerant chip I am using. I won't mention any brands, but if you remember our previous conversations about such chips you will realize that it is not a Xilinx part. Too bad, I actually prefer the Xilinx parts and tools. :( -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Thu, 28 Aug 2003 03:04:30 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 17 Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F4CA1F3.57E0DB4D@yahoo.com> <3F4CD3C7.42C72EFE@xilinx.com> <3F4D5682.AA13889@yahoo.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1062039870 15377 128.32.112.203 (28 Aug 2003 03:04:30 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Thu, 28 Aug 2003 03:04:30 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32290 In article <3F4D5682.AA13889@yahoo.com>, rickman wrote: >I understand how the resolution time affects the failure rate. I also >understand that the timing window is so small that it is very hard to >hit even if you try. My point is that the analysis has been done >assuming a random distribution of timing which is not valid for this >case. If you have an MTBF of 100 years with the standard model, you may >well see an MTBF of an hour or less with this situation. I will be >using a half clock cycle (10 ns) minus some 5 ns of delay which should >give me lots of room for settling. But unless I acutally know something >about my timing distribution it will be hard to say what my expected >MTBF is. Then add random jitter into your CLOCK, and now you are back into the randomized model, no? -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 27 Aug 2003 23:35:20 -0400 Organization: Arius, Inc Lines: 66 Message-ID: <3F4D7878.1A6BFF75@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYnqGfVkNJbLXTgF98kbEzrihCrAUIG8yRus5hx/rcvtgUbXkgJjAFy X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 28 Aug 2003 03:36:13 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!nntp.abs.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32272 Philip Freidin wrote: > > Maybe the following would help some people: > > http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm > > Let me be dogmatic: > > Flip flops may go metastable when input signals do not meet the setup > and hold specifications with regard to the clock signal. These inputs > include D, CE, CLR, PRE, S, R, T, J, K. > > There is no cure for metastability. What you can do is trade latency > of your system for higher MTBF. > > People that have found a cure are wrong. > > Circuits that purport to solve metastability through hysteresis fail > because the hysteresis circuit itself can go metastable > > Circuits that purport to solve metastability with injected noise fail > because the noise is as likely to push a non-metastable event into > being a metastable event as it is to helping to resolve such an > event. > > Just because current flip flops are better than stuff of a few years > ago, and the probability and resolution time of metastable events > is better, does not mean you can ignore this stuff. If someone > says that things are so good now that "you almost don't have to > worry about this anymore", what it means is that you absolutely > need to understand it and design for it. If you don't, you will > have unreliable systems. > > Nothing improves the MTBF of a metastable synchronizer better than > just waiting longer. Not clocking the intermediate signal on the > negative clock edge. Not voting. Not threshold testing. Not adding > noise. Not fancy SPICE simulations. Not predicting circuits. Not > circuits designed to bias the outcome to either 1 or 0. Not > clocking it twice as fast through twice as many flip flops. > Nothing. > > From Thomas Cheney, October 1979: > > "In closing, there is a great deal of theoretical and experimental > evidence that a region of anomalous behavior exists for every device > that has two stable states. The maturity of this topic is now such that > papers making contrary claims without theoretical or experimental support > should not be accepted for publication". > > Philip Freidin Very well put. I think it is so well said that it sould be added to the FPGA FAQ. There is a comp.arch.fpga FAQ, right? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 28 Aug 2003 04:02:32 -0700 Organization: http://groups.google.com/ Lines: 28 Message-ID: <8471ba54.0308280302.63e7e710@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062068553 10262 127.0.0.1 (28 Aug 2003 11:02:33 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 28 Aug 2003 11:02:33 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32295 Peter Alfke wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>... > The output level of a flip-flop during its metastable time is > irrelevant. If it were in the middle ( which it isn't) we could easily > fix this with a zener diode. > The problem is timing. The Q output can - and will - change to the > opposite state at a totally unpredictable time. That's the problem: > unpredictable timing, not unknown levels. > > Cascading flip-flops is the standard remedy, but it introduces latency. > > Remember: Metastability causes an extra 3 ns of unpredictable delay once > in a billion years... Seems to be an affordable risk. > > Peter Alfke Peter, kind of disagree. Of course for the designer, the problem is timing. But the timing problem is caused by the voltage problem. If we had a well defined voltage behavior (as I thought, but now I know I were wrong), we could fix the timing problem (as you said for the "in the middle" problem). Anyway, I undestood what you said. I also disagree that the problem has no solution. As an engineer I don't believe in no solution problems, we just don't know the solutions yet. But this is philosophy! Luiz Carlos ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 28 Aug 2003 04:08:55 -0700 Organization: http://groups.google.com/ Lines: 5 Message-ID: <8471ba54.0308280308.232c7bfe@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062068936 10505 127.0.0.1 (28 Aug 2003 11:08:56 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 28 Aug 2003 11:08:56 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32299 Thankyou Philip. But as I said, I don't believe "There is no cure for metastability", or any other problem. It's just a question of time. Luiz Carlos. ###### Message-ID: <3F4DED0E.574A03F9@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 50 Date: Thu, 28 Aug 2003 07:52:46 -0400 NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: lakeread05 1062071068 68.15.41.165 (Thu, 28 Aug 2003 07:44:28 EDT) NNTP-Posting-Date: Thu, 28 Aug 2003 07:44:28 EDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!peer01.cox.net!cox.net!p01!lakeread05.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32281 You sound like a good candidate to spend you time pursuing a perpetual motion machine. The physics stipulate that you'll have a probability of hitting a metastable state. As processes improve, we can narrow the width of the window, but we can't eliminate it. Narrowing the width reduces the probability of hitting it for a fixed clock rate. Trouble is, as the process improvements occur that permit narrowing the window, the clock speeds also increase, so unless the designer designs for metastbility, the odds may not improve. Luiz Carlos wrote: > Peter Alfke wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>... > > The output level of a flip-flop during its metastable time is > > irrelevant. If it were in the middle ( which it isn't) we could easily > > fix this with a zener diode. > > The problem is timing. The Q output can - and will - change to the > > opposite state at a totally unpredictable time. That's the problem: > > unpredictable timing, not unknown levels. > > > > Cascading flip-flops is the standard remedy, but it introduces latency. > > > > Remember: Metastability causes an extra 3 ns of unpredictable delay once > > in a billion years... Seems to be an affordable risk. > > > > Peter Alfke > > Peter, kind of disagree. > > Of course for the designer, the problem is timing. But the timing > problem is caused by the voltage problem. If we had a well defined > voltage behavior (as I thought, but now I know I were wrong), we could > fix the timing problem (as you said for the "in the middle" problem). > Anyway, I undestood what you said. > > I also disagree that the problem has no solution. As an engineer I > don't believe in no solution problems, we just don't know the > solutions yet. But this is philosophy! > > Luiz Carlos -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Thu, 28 Aug 2003 10:02:59 -0400 Organization: Arius, Inc Lines: 39 Message-ID: <3F4E0B93.AA62129B@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4CA1F3.57E0DB4D@yahoo.com> <3F4CD3C7.42C72EFE@xilinx.com> <3F4D5682.AA13889@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZeMClOFU0XNiHtYxISb7XrLtZQHtBlZuaBWVuiD4M9psqSgscxHFT3 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 28 Aug 2003 14:03:03 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newshosting.com!news-xfer2.atl.newshosting.com!diablo.voicenet.com!199.184.165.233.MISMATCH!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32270 "Nicholas C. Weaver" wrote: > > In article <3F4D5682.AA13889@yahoo.com>, > rickman wrote: > >I understand how the resolution time affects the failure rate. I also > >understand that the timing window is so small that it is very hard to > >hit even if you try. My point is that the analysis has been done > >assuming a random distribution of timing which is not valid for this > >case. If you have an MTBF of 100 years with the standard model, you may > >well see an MTBF of an hour or less with this situation. I will be > >using a half clock cycle (10 ns) minus some 5 ns of delay which should > >give me lots of room for settling. But unless I acutally know something > >about my timing distribution it will be hard to say what my expected > >MTBF is. > > Then add random jitter into your CLOCK, and now you are back into the > randomized model, no? There is already jitter in any clock you pick. I expect this jitter is much larger than the fs window that Peter has calculated for the metastable time window. But unless all values of delay are equally likely, the original equations do not apply. If your clock cycle period is p and your jitter is j, the occurance of failure compared to the standard model is p/j times more likely. I think knowing this helps a lot since it should be easy to add enough extra delay to offset any fixed value for this ratio. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Thu, 28 Aug 2003 08:48:23 -0700 Organization: Xilinx,Inc Lines: 42 Message-ID: <3F4E2447.C2B41336@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Luiz Carlos Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!zen.net.uk!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32277 Luiz, you need to read up on metastability. There are things even in physics that have no solution. Perpetual motion is one. If you want to get philosophical about metastability, read Heisenberg's Uncertainty papers. Phil Freidin has described the problem very well. He and I agree 100% on the problem. But I have made quantitative tests and know the (very low) probability. Everybody has an opinion, very few have performed measurements... Peter Alfke ================================= Luiz Carlos wrote: > > Peter Alfke wrote in message news:<3F4D17D9.5CFD8B91@xilinx.com>... > > The output level of a flip-flop during its metastable time is > > irrelevant. If it were in the middle ( which it isn't) we could easily > > fix this with a zener diode. > > The problem is timing. The Q output can - and will - change to the > > opposite state at a totally unpredictable time. That's the problem: > > unpredictable timing, not unknown levels. > > > > Cascading flip-flops is the standard remedy, but it introduces latency. > > > > Remember: Metastability causes an extra 3 ns of unpredictable delay once > > in a billion years... Seems to be an affordable risk. > > > > Peter Alfke > > Peter, kind of disagree. > > Of course for the designer, the problem is timing. But the timing > problem is caused by the voltage problem. If we had a well defined > voltage behavior (as I thought, but now I know I were wrong), we could > fix the timing problem (as you said for the "in the middle" problem). > Anyway, I undestood what you said. > > I also disagree that the problem has no solution. As an engineer I > don't believe in no solution problems, we just don't know the > solutions yet. But this is philosophy! > > Luiz Carlos ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: <9scskv82ee51brah4qefbqvefprvtra65r@4ax.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280308.232c7bfe@posting.google.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 28 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr25.news.prodigy.com 1062090062 ST000 216.103.85.188 (Thu, 28 Aug 2003 13:01:02 EDT) NNTP-Posting-Date: Thu, 28 Aug 2003 13:01:02 EDT X-UserInfo1: [[PAPDONSBUAB^X[\ZHXOFTBTR\B@GXLN@GZ_GYO^ZWZUYICD^RAQBKZQTZTX\_I[^G_KGFNON[ZOE_AZNVO^\XGGNTCIRPIJH[@RQKBXLRZ@CD^HKANYVW@RLGEZEJN@\_WZJBNZYYKVIOR]T]MNMG_Z[YVWSCH_Q[GPC_A@CARQVXDSDA^M]@DRVUM@RBM Date: Thu, 28 Aug 2003 17:01:02 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newshosting.com!news-xfer1.atl.newshosting.com!diablo.voicenet.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr25.news.prodigy.com.POSTED!7ae961dc!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32307 On 28 Aug 2003 04:08:55 -0700, oen_br@yahoo.com.br (Luiz Carlos) wrote: >Thankyou Philip. >But as I said, I don't believe "There is no cure for metastability", >or any other problem. It's just a question of time. Yep, you are right, it is just a matter of time. In this case it is infinite. When you do your designs do you A) Do nothing special for async signals entering a synchronous domain, because some day someone will solve this problem. or B) Use multistage synchronizers to move signals from one clock domain to another, because some day someone will solve this problem, but it hasn't happened yet. or C) Not sure, because I haven't ever seen this problem. >Luiz Carlos. Philip ###### From: "Glen Herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> Subject: Re: Thinking out loud about metastability Lines: 29 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: NNTP-Posting-Host: 12.207.204.17 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc04 1062102359 12.207.204.17 (Thu, 28 Aug 2003 20:25:59 GMT) NNTP-Posting-Date: Thu, 28 Aug 2003 20:25:59 GMT Organization: Comcast Online Date: Thu, 28 Aug 2003 20:25:59 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc04.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32312 "Ray Andraka" wrote in message news:3F4DED0E.574A03F9@andraka.com... > You sound like a good candidate to spend you time pursuing a perpetual motion machine. > The physics stipulate that you'll have a probability of hitting a metastable state. As > processes improve, we can narrow the width of the window, but we can't eliminate it. > Narrowing the width reduces the probability of hitting it for a fixed clock rate. Trouble > is, as the process improvements occur that permit narrowing the window, the clock speeds > also increase, so unless the designer designs for metastbility, the odds may not improve. Really the problem is insisting on synchronous designs. Asynchronous (self-timed) logic doesn't have this problem. Well, metastability is still there, but the logic will wait, however long it takes, for it to resolve. I used to hear stories, though I am not sure that I believe them, of people seeing metastability effects on the PDP-10 (KA10), which used self timed logic. Supposedly they could see it stop processing, and then start again with no ill effect. How they know it wasn't in I/O wait, or some other such state, I have no idea. -- glen ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 28 Aug 2003 14:44:57 -0700 Organization: http://groups.google.com/ Lines: 41 Message-ID: <8471ba54.0308281344.364a2a0d@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280308.232c7bfe@posting.google.com> <9scskv82ee51brah4qefbqvefprvtra65r@4ax.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062107098 6698 127.0.0.1 (28 Aug 2003 21:44:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 28 Aug 2003 21:44:58 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32317 Philip Freidin wrote in message news:<9scskv82ee51brah4qefbqvefprvtra65r@4ax.com>... > > Yep, you are right, it is just a matter of time. In this case > it is infinite. > > When you do your designs do you > > A) Do nothing special for async signals entering a synchronous > domain, because some day someone will solve this problem. > > or > > B) Use multistage synchronizers to move signals from one clock > domain to another, because some day someone will solve this > problem, but it hasn't happened yet. > > or > > C) Not sure, because I haven't ever seen this problem. > > > Philip Actually I use the option B). Sorry if you are disappointed! (You were sarcastic first!) But I remember people saying CMOS is slow, copper can't be used as metal layer, and a better example: "We are reaching the silicon physical limits"! This is a kind of religion, I don't believe in "not possible", only in "I don't know how to do". Anyway, I don't claim to know everything. If you get more persuasive I can change my mind. At last, I really liked your first post, I found it very elucidative (really, no joke). Luiz Carlos ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Thu, 28 Aug 2003 21:54:26 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 23 Message-ID: References: <3F46E816.96EF198B@yahoo.com> <8471ba54.0308280308.232c7bfe@posting.google.com> <9scskv82ee51brah4qefbqvefprvtra65r@4ax.com> <8471ba54.0308281344.364a2a0d@posting.google.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1062107666 60221 128.32.112.203 (28 Aug 2003 21:54:26 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Thu, 28 Aug 2003 21:54:26 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32315 In article <8471ba54.0308281344.364a2a0d@posting.google.com>, Luiz Carlos wrote: >But I remember people saying CMOS is slow, copper can't be used as >metal layer, and a better example: "We are reaching the silicon >physical limits"! > >This is a kind of religion, I don't believe in "not possible", only in >"I don't know how to do". However, there are many thing which are "NOT POSSIBLE" barring a massive change in our understanding of basic physics and math. It is not possible to build a perpetual motion machine ("In this house we obey the laws of thermodynamics!"). It is not possible to measure a particle's position and velocity with perfect precision (heisenberg uncertanty principle). It is not possible to have two energetically stable local-minima without an energetically-stable local maxima between them: a point of metastibility. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: Andrew Paule User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> In-Reply-To: <3F4E7FBC.FAD@designtools.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 42 Message-ID: <8Ow3b.56$qq3.26603@news.uswest.net> Date: Thu, 28 Aug 2003 19:09:55 -0500 NNTP-Posting-Host: 63.229.199.24 X-Trace: news.uswest.net 1062115588 63.229.199.24 (Thu, 28 Aug 2003 19:06:28 CDT) NNTP-Posting-Date: Thu, 28 Aug 2003 19:06:28 CDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!newspeer1.nwr.nac.net!ply1.onvoy!onvoy.com!feed.news.qwest.net!news.uswest.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32324 Hi Jim - this has nothing to do with quantization, until you get into QED, but is a matter of statistical thermal noise on two cells that are used to jam the outputs of a flop. You need the noise, but that has nothing to do with undergrad quantum mechanics. Read Peter's stuff - he's quite good and knowledgable. Andrew Jim Granville wrote: >Andrew Paule wrote: > > >>Hi Peter: >> >>the problem with metastability is probably best understood by looking >>through some of the ieee papers by Dike and Burton - these guys did the >>measurements and there is no solution - metastability requires thermal >>noise on two nodes inside a flop(including the Xilinx model that I saw a >>couple years ago) to force the output change, and that's a statistical >>quantity - metastability can reign out to infinity, although the >>probability is small. No solution known to us under device physics as >>we know it now, just getting the probabilities smaller. This is why >>hold time is just a statistic, and much like we qualify things under >>BERT and jitter (more statistical quantities), we are human and guessing >>our best. >> >> > > The (simple) statistical models must fall down when they hit >the quantization of single electrons. > How close are we to that ? > Has anyone tried to actually plot the tail of time/probability, >to see what law it follows ? > How does this actual tail vary with temperature. > >-jg > > ###### From: "Glen Herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> Subject: Re: Thinking out loud about metastability Lines: 28 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: NNTP-Posting-Host: 12.207.204.17 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc53 1062127434 12.207.204.17 (Fri, 29 Aug 2003 03:23:54 GMT) NNTP-Posting-Date: Fri, 29 Aug 2003 03:23:54 GMT Organization: Comcast Online Date: Fri, 29 Aug 2003 03:23:54 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!nntp-server.caltech.edu!attla2!ip.att.net!attbi_feed3!attbi.com!rwcrnsc53.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32318 "Richard Iachetta" wrote in message news:MPG.19b83b577df3e40d989823@ausnews.austin.ibm.com... > In article , gah@ugcs.caltech.edu says... > > I used to hear stories, though I am not sure that I believe them, of people > > seeing metastability effects on the PDP-10 (KA10), which used self timed > > logic. Supposedly they could see it stop processing, and then start again > > with no ill effect. How they know it wasn't in I/O wait, or some other such > > state, I have no idea. > > Sorry for being skeptical, but they "saw" it stop processing for approximately > 10 to 100 ns that the metastability would resolve and then they saw it start > again? Well, I am skeptical, too, but logic was somewhat slower in those days, and the resolving time may be much longer. Not that logic speed and resolution time are proportional. Also, the metastability pathways in self-timed logic are somewhat different. -- glen ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 29 Aug 2003 07:37:05 -0700 Organization: http://groups.google.com/ Lines: 48 Message-ID: <8471ba54.0308290637.13e755c7@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <8471ba54.0308281152.64fe5e56@posting.google.com> <500tkvsfnsmioddjf8j50opt5qir5p9j45@4ax.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062167826 32115 127.0.0.1 (29 Aug 2003 14:37:06 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 29 Aug 2003 14:37:06 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32338 > This is the classic defense of otherwise indefensible ideas. "They > said that a flying machine was impossible." "They said that Einstein > was crazy." Statements like these ignore certain realities, namely: > > (a) Much of what was said to be impossible still is, and shows every > sign of remaining so. If you believe that there are laws of physics, > even laws that are somewhat at odds with the ones we now hold true, > then those laws must say that certain things can happen and others > cannot. If they don't, they aren't laws. > Hi Bob, Which laws? Classical physics laws, like every other, have a domain where they give better approximations. We are still trying to find the Theory Of Everything. Peter has mentioned the "Heisenberg's Uncertainty Principle", but I read somewhere, althought we can't know where a particle is in a momentum, we can know where it is not, so, we can infer where it is. If we take the electron spin, there is no metastability. It changes it's direction in one "fundamental" clock cycle (time is not continuous). I think there is also no metastability problems in Single Electron Devices. So, Virtex436 possibly will not have metastability problems. > (b) In all of human history, most of the people "they" called crazy > were, in fact, crazy. > > Luiz, it's fine with me if you want to believe that metastability can > be prevented. But for all of you folks who have been reading this > thread and wondering just what to do about metastability in your > designs, just read Philip Freidin's excellent summary and follow the > link he pointed to for more information. > > Do we really want to keep repeating the same old mistakes? Woudn't it > be more fun to make some new ones? > > Bob Perlman > Cambrian Design Works Bob, I know that everything I said don't help us with our today metastability problems. I spent a lot of time trying to defend my opion about something that is not related to the topic, fruitless! I'll try to not repeat the same mistake. I agree with you about Philip, it really looks like he knows a lot. Thanks to everybody, I learned a lot about metastability. Luiz Carlos ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 30 Aug 2003 09:01:32 -0400 Organization: Arius, Inc Lines: 58 Message-ID: <3F50A02C.1BE45972@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <8471ba54.0308281152.64fe5e56@posting.google.com> <500tkvsfnsmioddjf8j50opt5qir5p9j45@4ax.com> <8471ba54.0308290637.13e755c7@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVacpfc2osUGHs82eDyWEy1HJwChySe6t9xnURNEN+2qsHuxsA2zmUxh X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 30 Aug 2003 13:01:50 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!peer01.cox.net!cox.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32360 Luiz Carlos wrote: > > > This is the classic defense of otherwise indefensible ideas. "They > > said that a flying machine was impossible." "They said that Einstein > > was crazy." Statements like these ignore certain realities, namely: > > > > (a) Much of what was said to be impossible still is, and shows every > > sign of remaining so. If you believe that there are laws of physics, > > even laws that are somewhat at odds with the ones we now hold true, > > then those laws must say that certain things can happen and others > > cannot. If they don't, they aren't laws. > > > > Hi Bob, > Which laws? > Classical physics laws, like every other, have a domain where they > give better approximations. We are still trying to find the Theory Of > Everything. > Peter has mentioned the "Heisenberg's Uncertainty Principle", but I > read somewhere, althought we can't know where a particle is in a > momentum, we can know where it is not, so, we can infer where it is. > If we take the electron spin, there is no metastability. It changes > it's direction in one "fundamental" clock cycle (time is not > continuous). I think there is also no metastability problems in Single > Electron Devices. So, Virtex436 possibly will not have metastability > problems. If you think there is no uncertanty in measuring the spin of an electron, you need to go back to school. You also need to learn the effect of measuring things like spin and other sub-atomic properties, namely changing the state of the quantity being measured. That is what the uncertanty principle is about. When you make a measurement, you change the quantity being measured. Many quantities interact, such as velocity and position, so that measuring one more accurately interferes with measuring the other. The bottom line is that it was quantum mechanics that taught us the limits of measurement. Even though quantum properties are discreet, there is still uncertainty in any measurement. BTW, the position of an electron can be measured, but it really is not in one place like a book. It has a finite probability of being pretty much anywhere and the total of this probability over all space sums to 1. There is a non-zero probability of it being anywhere. So you can't measure "where it is not". -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 30 Aug 2003 09:04:40 -0400 Organization: Arius, Inc Lines: 46 Message-ID: <3F50A0E8.15AAA082@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZzYugBBSGHi9QyYr6qi//iQ1Elad9XGKW0DXg9g4w8u/WOOTqwCgSC X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 30 Aug 2003 13:04:58 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!demon!newspeer.monmouth.com!nntp.abs.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32361 Glen Herrmannsfeldt wrote: > > "Richard Iachetta" wrote in message > news:MPG.19b83b577df3e40d989823@ausnews.austin.ibm.com... > > In article , gah@ugcs.caltech.edu > says... > > > I used to hear stories, though I am not sure that I believe them, of > people > > > seeing metastability effects on the PDP-10 (KA10), which used self timed > > > logic. Supposedly they could see it stop processing, and then start > again > > > with no ill effect. How they know it wasn't in I/O wait, or some other > such > > > state, I have no idea. > > > > Sorry for being skeptical, but they "saw" it stop processing for > approximately > > 10 to 100 ns that the metastability would resolve and then they saw it > start > > again? > > Well, I am skeptical, too, but logic was somewhat slower in those days, and > the resolving time may be much longer. Not that logic speed and resolution > time are proportional. Also, the metastability pathways in self-timed > logic are somewhat different. I am no expert in async logic, but I have never heard of a circuit that can even detect metastability. I also thought that async logic did not "measure" the time it took for a calculation, it simply allowed different times for different calculations. The control path for a given circuit has a longer delay than the data path and would be dependant on the calculation being performed. How exactly would a circuit detect when an async calculation is complete? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ####### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 30 Aug 2003 09:11:27 -0400 Organization: Arius, Inc Lines: 33 Message-ID: <3F50A27F.2B211E9E@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280308.232c7bfe@posting.google.com> <9scskv82ee51brah4qefbqvefprvtra65r@4ax.com> <8471ba54.0308281344.364a2a0d@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYcR1Rp3NsFgIIi5g3tQXKmk1hX28KePYrX4iJHM3tEQZ625x3pwteC X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 30 Aug 2003 13:11:45 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!news-out.cwix.com!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32350 Luiz Carlos wrote: > > But I remember people saying CMOS is slow, copper can't be used as > metal layer, and a better example: "We are reaching the silicon > physical limits"! > > This is a kind of religion, I don't believe in "not possible", only in > "I don't know how to do". This has nothing to do with the problem. There is nothing you can do with gates or noise or voltage to solve it. But to understand that, you need to go beyond these things and consider the problem from a theoretical viewpoint. Take a look at a graph of energy (or voltage) levels of a bi-stable function. If you analyze the behavior of varying amount of energy being applied, you will find that the time it takes to return to one of the minimum energy level states is indeterminate. There is nothing you can do to add gates or noise or voltage, this is a basic property of bi-stable systems... even quantum mechanical ones! -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sun, 31 Aug 2003 00:11:04 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280308.232c7bfe@posting.google.com> <9scskv82ee51brah4qefbqvefprvtra65r@4ax.com> <8471ba54.0308281344.364a2a0d@posting.google.com> X-Complaints-To: abuse@supernews.com Lines: 20 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!proxad.net!freenix!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:32370 >This is a kind of religion, I don't believe in "not possible", only in >"I don't know how to do". Yes, but there are several types of problems. A few of them are "well known" to be impossible. Examples include traveling faster than light and perpetual motion machines. I think metastability is one of these. Sure, I'll keep an eye open for new results, but I won't waste any time if I'm working on an engineering problem with current technology and I will use claims/suggestions of a solution as an idiot filter unless they are backed up by some amazing evidence. A usenet post isn't good enough. We're talking Nobel Prize class work. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sun, 31 Aug 2003 00:32:19 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> X-Complaints-To: abuse@supernews.com Lines: 17 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:32371 >this has nothing to do with quantization, until you get into QED, but is >a matter of statistical thermal noise on two cells that are used to jam >the outputs of a flop. You need the noise, but that has nothing to do >with undergrad quantum mechanics. Read Peter's stuff - he's quite good >and knowledgable. Do I need noise? Why? I thought the normal exponential decay was well modeled (Spice?) without noise. Perhaps you need it if the FF is "perfectly" ballanced but that has a vanishingly small probability in the real world. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 30 Aug 2003 23:15:18 -0400 Organization: Arius, Inc Lines: 32 Message-ID: <3F516846.72D5F5CA@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZ+8lNFiWUwZ7SpvOnXtCh7CL0W6vHn0OCFqsitYQ50lR5VYRpIZHmj X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 31 Aug 2003 03:15:48 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-out1.nntp.be!propagator2-sterling!news-in-sterling.newsfeed.com!news-out.cwix.com!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32362 Hal Murray wrote: > > >this has nothing to do with quantization, until you get into QED, but is > >a matter of statistical thermal noise on two cells that are used to jam > >the outputs of a flop. You need the noise, but that has nothing to do > >with undergrad quantum mechanics. Read Peter's stuff - he's quite good > >and knowledgable. > > Do I need noise? Why? I thought the normal exponential decay > was well modeled (Spice?) without noise. Perhaps you need > it if the FF is "perfectly" ballanced but that has a vanishingly > small probability in the real world. I think you are right. There is only one point on a continuous range that will be perfectly balanced. The probability of that is in essence the inverse of infinity which I don't know that it even has meaning. If you require noise to shift you out of metastability, then the people who argue that more noise will get you out quicker could then be right. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Message-ID: <72r2lvks28t0j2381h2ih54h2vrov1fkr9@4ax.com> References: <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> <3F516846.72D5F5CA@yahoo.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 36 Date: Sun, 31 Aug 2003 03:40:09 GMT NNTP-Posting-Host: 64.175.66.17 X-Complaints-To: abuse@sonic.net X-Trace: typhoon.sonic.net 1062301209 64.175.66.17 (Sat, 30 Aug 2003 20:40:09 PDT) NNTP-Posting-Date: Sat, 30 Aug 2003 20:40:09 PDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!sjc70.webusenet.com!sjc72.webusenet.com!news.webusenet.com!feed.news.sonic.net!typhoon.sonic.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32372 On Sat, 30 Aug 2003 23:15:18 -0400, rickman wrote: >Hal Murray wrote: >> >> >this has nothing to do with quantization, until you get into QED, but is >> >a matter of statistical thermal noise on two cells that are used to jam >> >the outputs of a flop. You need the noise, but that has nothing to do >> >with undergrad quantum mechanics. Read Peter's stuff - he's quite good >> >and knowledgable. >> >> Do I need noise? Why? I thought the normal exponential decay >> was well modeled (Spice?) without noise. Perhaps you need >> it if the FF is "perfectly" ballanced but that has a vanishingly >> small probability in the real world. > >I think you are right. There is only one point on a continuous range >that will be perfectly balanced. The probability of that is in essence >the inverse of infinity which I don't know that it even has meaning. > >If you require noise to shift you out of metastability, then the people >who argue that more noise will get you out quicker could then be right. A metastable failure doesn't require that you land exactly on the balance point. There may be only one point that keeps you in the metastable state forever, but there's a range of points that will delay FF settling long enough to make your design fail. The more time you give the design to settle, the shorter that range of points is. Accordingly, noise doesn't have to kick the FF to that perfect balance point. It need only force you close enough that the FF output transition is sufficiently delayed to hose over the circuit. Bob Perlman Cambrian Design Works ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sun, 31 Aug 2003 10:55:19 -0400 Organization: Arius, Inc Lines: 55 Message-ID: <3F520C57.3EC84F99@yahoo.com> References: <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> <3F516846.72D5F5CA@yahoo.com> <72r2lvks28t0j2381h2ih54h2vrov1fkr9@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYncNgaFmy2ikBzCLoAnXvB56qMkcjA3EN26ihY0wOQo4WmUI6wBFbD X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 31 Aug 2003 14:56:09 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!wn13feed!worldnet.att.net!199.184.165.233!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32376 Bob Perlman wrote: > > On Sat, 30 Aug 2003 23:15:18 -0400, rickman > wrote: > > >Hal Murray wrote: > >> > >> >this has nothing to do with quantization, until you get into QED, but is > >> >a matter of statistical thermal noise on two cells that are used to jam > >> >the outputs of a flop. You need the noise, but that has nothing to do > >> >with undergrad quantum mechanics. Read Peter's stuff - he's quite good > >> >and knowledgable. > >> > >> Do I need noise? Why? I thought the normal exponential decay > >> was well modeled (Spice?) without noise. Perhaps you need > >> it if the FF is "perfectly" ballanced but that has a vanishingly > >> small probability in the real world. > > > >I think you are right. There is only one point on a continuous range > >that will be perfectly balanced. The probability of that is in essence > >the inverse of infinity which I don't know that it even has meaning. > > > >If you require noise to shift you out of metastability, then the people > >who argue that more noise will get you out quicker could then be right. > > A metastable failure doesn't require that you land exactly on the > balance point. There may be only one point that keeps you in the > metastable state forever, but there's a range of points that will > delay FF settling long enough to make your design fail. The more time > you give the design to settle, the shorter that range of points is. > > Accordingly, noise doesn't have to kick the FF to that perfect balance > point. It need only force you close enough that the FF output > transition is sufficiently delayed to hose over the circuit. I don't think you understand the point. We are not saying that balance or noise are required to demonstrate metastability. It was pointed out that in a simulation of the effect, something would be needed to move the FF off the balance point and noise was suggested. But in the real world the "balance point" is so vanishing small, it would never actually happen. That is not saying that the FF can not go metastable without being balanced. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Message-ID: References: <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> <3F516846.72D5F5CA@yahoo.com> <72r2lvks28t0j2381h2ih54h2vrov1fkr9@4ax.com> <3F520C57.3EC84F99@yahoo.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 56 Date: Sun, 31 Aug 2003 15:10:54 GMT NNTP-Posting-Host: 67.120.84.77 X-Complaints-To: abuse@sonic.net X-Trace: typhoon.sonic.net 1062342654 67.120.84.77 (Sun, 31 Aug 2003 08:10:54 PDT) NNTP-Posting-Date: Sun, 31 Aug 2003 08:10:54 PDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!newsfeed.vmunix.org!news.ticon.net!feed.news.sonic.net!typhoon.sonic.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32380 On Sun, 31 Aug 2003 10:55:19 -0400, rickman wrote: >Bob Perlman wrote: >> >> On Sat, 30 Aug 2003 23:15:18 -0400, rickman >> wrote: >> >> >Hal Murray wrote: >> >> >> >> >this has nothing to do with quantization, until you get into QED, but is >> >> >a matter of statistical thermal noise on two cells that are used to jam >> >> >the outputs of a flop. You need the noise, but that has nothing to do >> >> >with undergrad quantum mechanics. Read Peter's stuff - he's quite good >> >> >and knowledgable. >> >> >> >> Do I need noise? Why? I thought the normal exponential decay >> >> was well modeled (Spice?) without noise. Perhaps you need >> >> it if the FF is "perfectly" ballanced but that has a vanishingly >> >> small probability in the real world. >> > >> >I think you are right. There is only one point on a continuous range >> >that will be perfectly balanced. The probability of that is in essence >> >the inverse of infinity which I don't know that it even has meaning. >> > >> >If you require noise to shift you out of metastability, then the people >> >who argue that more noise will get you out quicker could then be right. >> >> A metastable failure doesn't require that you land exactly on the >> balance point. There may be only one point that keeps you in the >> metastable state forever, but there's a range of points that will >> delay FF settling long enough to make your design fail. The more time >> you give the design to settle, the shorter that range of points is. >> >> Accordingly, noise doesn't have to kick the FF to that perfect balance >> point. It need only force you close enough that the FF output >> transition is sufficiently delayed to hose over the circuit. > >I don't think you understand the point. We are not saying that balance >or noise are required to demonstrate metastability. It was pointed out >that in a simulation of the effect, something would be needed to move >the FF off the balance point and noise was suggested. But in the real >world the "balance point" is so vanishing small, it would never actually >happen. That is not saying that the FF can not go metastable without >being balanced. Whoever said, "If you require noise to shift you out of metastability, then the people who argue that more noise will get you out quicker could then be right," could you explain further? Are you saying that noise is required to resolve the metastable state, or is this a counter-argument to the "noise may get you out faster" claim? Or is it something else entirely? Bob Perlman Cambrian Design Works ###### From: Andrew Paule User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> <3F516846.72D5F5CA@yahoo.com> <72r2lvks28t0j2381h2ih54h2vrov1fkr9@4ax.com> <3F520C57.3EC84F99@yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 92 Message-ID: Date: Sun, 31 Aug 2003 22:31:39 -0500 NNTP-Posting-Host: 63.229.196.110 X-Trace: news.uswest.net 1062386888 63.229.196.110 (Sun, 31 Aug 2003 22:28:08 CDT) NNTP-Posting-Date: Sun, 31 Aug 2003 22:28:08 CDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!nycmny1-snh1.gtei.net!news.gtei.net!news-out.visi.com!petbe.visi.com!feed.news.qwest.net!news.uswest.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32386 Hi Bob: guess I'm flattered that Hal is getting to defend some of the aspects here - what I am pointing out is that in a standard flop design, there are two balanced P/N nodes (assuming you're building a MOS flop - very few done otherwise anymore) that are used to jam another pair that sets the output. The balancing that takes place will only force the output if there is thermal noise - this is how Fiarchild, Intel, and most others build the things. Take a poke around the net for articles by Dike and Burton - they have done more work on metastability that almost anyone else out there, and IEEE uses their work as a standard for this stuff. I'm not the author, just parroting what others have done. The amount of noise is not a factor (this is thermal noise, and all gates exhibit about 9nV per root kT) - thanks boltzman - but the effects of Miller coupling is as of yet not well understood, at least by me. Andrew Bob Perlman wrote: >On Sun, 31 Aug 2003 10:55:19 -0400, rickman >wrote: > > > >>Bob Perlman wrote: >> >> >>>On Sat, 30 Aug 2003 23:15:18 -0400, rickman >>>wrote: >>> >>> >>> >>>>Hal Murray wrote: >>>> >>>> >>>>>>this has nothing to do with quantization, until you get into QED, but is >>>>>>a matter of statistical thermal noise on two cells that are used to jam >>>>>>the outputs of a flop. You need the noise, but that has nothing to do >>>>>>with undergrad quantum mechanics. Read Peter's stuff - he's quite good >>>>>>and knowledgable. >>>>>> >>>>>> >>>>>Do I need noise? Why? I thought the normal exponential decay >>>>>was well modeled (Spice?) without noise. Perhaps you need >>>>>it if the FF is "perfectly" ballanced but that has a vanishingly >>>>>small probability in the real world. >>>>> >>>>> >>>>I think you are right. There is only one point on a continuous range >>>>that will be perfectly balanced. The probability of that is in essence >>>>the inverse of infinity which I don't know that it even has meaning. >>>> >>>>If you require noise to shift you out of metastability, then the people >>>>who argue that more noise will get you out quicker could then be right. >>>> >>>> >>>A metastable failure doesn't require that you land exactly on the >>>balance point. There may be only one point that keeps you in the >>>metastable state forever, but there's a range of points that will >>>delay FF settling long enough to make your design fail. The more time >>>you give the design to settle, the shorter that range of points is. >>> >>>Accordingly, noise doesn't have to kick the FF to that perfect balance >>>point. It need only force you close enough that the FF output >>>transition is sufficiently delayed to hose over the circuit. >>> >>> >>I don't think you understand the point. We are not saying that balance >>or noise are required to demonstrate metastability. It was pointed out >>that in a simulation of the effect, something would be needed to move >>the FF off the balance point and noise was suggested. But in the real >>world the "balance point" is so vanishing small, it would never actually >>happen. That is not saying that the FF can not go metastable without >>being balanced. >> >> > >Whoever said, "If you require noise to shift you out of metastability, >then the people who argue that more noise will get you out quicker >could then be right," could you explain further? Are you saying that >noise is required to resolve the metastable state, or is this a >counter-argument to the "noise may get you out faster" claim? Or is >it something else entirely? > >Bob Perlman >Cambrian Design Works > > > ###### Message-ID: <3F52D891.2226@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 35 Date: Mon, 01 Sep 2003 17:26:45 +1200 NNTP-Posting-Host: 210.246.4.222 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1062394013 210.246.4.222 (Mon, 01 Sep 2003 17:26:53 NZST) NNTP-Posting-Date: Mon, 01 Sep 2003 17:26:53 NZST Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!in.100proofnews.com!in.100proofnews.com!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32385 > > > > The (simple) statistical models must fall down when they hit > >the quantization of single electrons. > > How close are we to that ? > > Has anyone tried to actually plot the tail of time/probability, > >to see what law it follows ? > > How does this actual tail vary with temperature. > Hi Jim - > > this has nothing to do with quantization, until you get into QED, but is > a matter of statistical thermal noise on two cells that are used to jam > the outputs of a flop. You need the noise, but that has nothing to do > with undergrad quantum mechanics. Read Peter's stuff - he's quite good > and knowledgable. I understand the (dominant) thermal aspects, but my physics teacher taught me that all extrapolation is dangerous :) - hence the question about the quantize effects, on the tail. Problem is, the tail is by nature hard to measure, and so mostly we get the statisical arm waving of a continuous 'vanishingly small' curve of Time/Probability. With each FPGA generation, we must be getting closer to being able to look for these more subtle effects. eg Electron charge is in region of 10^-19, and Gate charge of a MOS FET is measured in some fC/um^2 (femto = 10^-15), so in 90nm devices we should be in the 10^-17/10^-18 region. Does anyone have a real value for Qc in 90nm process ? -jg ###### From: "Glen Herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> Subject: Re: Thinking out loud about metastability Lines: 29 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <8NC4b.240107$cF.77428@rwcrnsc53> NNTP-Posting-Host: 12.207.204.17 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc53 1062402244 12.207.204.17 (Mon, 01 Sep 2003 07:44:04 GMT) NNTP-Posting-Date: Mon, 01 Sep 2003 07:44:04 GMT Organization: Comcast Online Date: Mon, 01 Sep 2003 07:44:04 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-out1.nntp.be!propagator2-sterling!news-in-sterling.nuthinbutnews.com!cyclone1.gnilink.net!wn14feed!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc53.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32383 "rickman" wrote in message news:3F50A0E8.15AAA082@yahoo.com... (snip regarding the DEC KA-10, metastability, and self-timed logic) > I am no expert in async logic, but I have never heard of a circuit that > can even detect metastability. I also thought that async logic did not > "measure" the time it took for a calculation, it simply allowed > different times for different calculations. The control path for a > given circuit has a longer delay than the data path and would be > dependant on the calculation being performed. How exactly would a > circuit detect when an async calculation is complete? Well, I agree with the skepticism in the first place, but consider a CPU with lights indicating the current contents of the registers. Normally, the values will be changing very fast. If they suddenly stop changing, it could be because of unresolved metastability. The logic will wait quietly for it to resolve, and then continue. It might be, though, that the machine is in I/O wait, and there really is nothing to do. I never got to actually see the machine, but at the time many machines had console lights, at least for the instruction counter and a few other important registers. (Though I don't believe that the PDP-10 had a wait state like IBM S/360 did, where no instructions were executed.) -- glen ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 1 Sep 2003 05:41:53 -0700 Organization: http://groups.google.com/ Lines: 18 Message-ID: <8471ba54.0309010441.16aec23c@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <8471ba54.0308281152.64fe5e56@posting.google.com> <500tkvsfnsmioddjf8j50opt5qir5p9j45@4ax.com> <8471ba54.0308290637.13e755c7@posting.google.com> <3F50A02C.1BE45972@yahoo.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062420114 12843 127.0.0.1 (1 Sep 2003 12:41:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 1 Sep 2003 12:41:54 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32393 > If you think there is no uncertanty in measuring the spin of an > electron, you need to go back to school. Rick, I din't say that. I said electron spin does not presents metastability. Anyway, did you hear about spintronics? Maybe the scientists behind this idea may go back to school too! Look at http://www.eetimes.com/story/OEG20001221S0035 Cut and paste please, I don't know how to include hypertexts. I think that shows my whole point of view: if you believe, insist! Unhappily (for me) I could not find the text about the electron position. Luiz Carlos ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Message-ID: References: <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> <3F516846.72D5F5CA@yahoo.com> <72r2lvks28t0j2381h2ih54h2vrov1fkr9@4ax.com> <3F520C57.3EC84F99@yahoo.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 102 Date: Mon, 01 Sep 2003 14:56:25 GMT NNTP-Posting-Host: 67.120.84.80 X-Complaints-To: abuse@sonic.net X-Trace: typhoon.sonic.net 1062428185 67.120.84.80 (Mon, 01 Sep 2003 07:56:25 PDT) NNTP-Posting-Date: Mon, 01 Sep 2003 07:56:25 PDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!npeer.de.kpn-eurorings.net!news.ticon.net!feed.news.sonic.net!typhoon.sonic.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32406 Andrew - Thanks for the reply. The Burton/Dike 1999 paper on Miller Effect sounds interesting; I'll try to get a copy. Bob Perlman On Sun, 31 Aug 2003 22:31:39 -0500, Andrew Paule wrote: >Hi Bob: > >guess I'm flattered that Hal is getting to defend some of the aspects >here - what I am pointing out is that in a standard flop design, there >are two balanced P/N nodes (assuming you're building a MOS flop - very >few done otherwise anymore) that are used to jam another pair that sets >the output. The balancing that takes place will only force the output >if there is thermal noise - this is how Fiarchild, Intel, and most >others build the things. Take a poke around the net for articles by >Dike and Burton - they have done more work on metastability that almost >anyone else out there, and IEEE uses their work as a standard for this >stuff. I'm not the author, just parroting what others have done. > >The amount of noise is not a factor (this is thermal noise, and all >gates exhibit about 9nV per root kT) - thanks boltzman - but the effects >of Miller coupling is as of yet not well understood, at least by me. > >Andrew > >Bob Perlman wrote: > >>On Sun, 31 Aug 2003 10:55:19 -0400, rickman >>wrote: >> >> >> >>>Bob Perlman wrote: >>> >>> >>>>On Sat, 30 Aug 2003 23:15:18 -0400, rickman >>>>wrote: >>>> >>>> >>>> >>>>>Hal Murray wrote: >>>>> >>>>> >>>>>>>this has nothing to do with quantization, until you get into QED, but is >>>>>>>a matter of statistical thermal noise on two cells that are used to jam >>>>>>>the outputs of a flop. You need the noise, but that has nothing to do >>>>>>>with undergrad quantum mechanics. Read Peter's stuff - he's quite good >>>>>>>and knowledgable. >>>>>>> >>>>>>> >>>>>>Do I need noise? Why? I thought the normal exponential decay >>>>>>was well modeled (Spice?) without noise. Perhaps you need >>>>>>it if the FF is "perfectly" ballanced but that has a vanishingly >>>>>>small probability in the real world. >>>>>> >>>>>> >>>>>I think you are right. There is only one point on a continuous range >>>>>that will be perfectly balanced. The probability of that is in essence >>>>>the inverse of infinity which I don't know that it even has meaning. >>>>> >>>>>If you require noise to shift you out of metastability, then the people >>>>>who argue that more noise will get you out quicker could then be right. >>>>> >>>>> >>>>A metastable failure doesn't require that you land exactly on the >>>>balance point. There may be only one point that keeps you in the >>>>metastable state forever, but there's a range of points that will >>>>delay FF settling long enough to make your design fail. The more time >>>>you give the design to settle, the shorter that range of points is. >>>> >>>>Accordingly, noise doesn't have to kick the FF to that perfect balance >>>>point. It need only force you close enough that the FF output >>>>transition is sufficiently delayed to hose over the circuit. >>>> >>>> >>>I don't think you understand the point. We are not saying that balance >>>or noise are required to demonstrate metastability. It was pointed out >>>that in a simulation of the effect, something would be needed to move >>>the FF off the balance point and noise was suggested. But in the real >>>world the "balance point" is so vanishing small, it would never actually >>>happen. That is not saying that the FF can not go metastable without >>>being balanced. >>> >>> >> >>Whoever said, "If you require noise to shift you out of metastability, >>then the people who argue that more noise will get you out quicker >>could then be right," could you explain further? Are you saying that >>noise is required to resolve the metastable state, or is this a >>counter-argument to the "noise may get you out faster" claim? Or is >>it something else entirely? >> >>Bob Perlman >>Cambrian Design Works >> >> >> ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Tue, 02 Sep 2003 17:21:35 -0400 Organization: Arius, Inc Lines: 30 Message-ID: <3F5509DF.EF545C87@yahoo.com> References: <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> <3F516846.72D5F5CA@yahoo.com> <72r2lvks28t0j2381h2ih54h2vrov1fkr9@4ax.com> <3F520C57.3EC84F99@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVarGEqeD+6cXepvfb49AXi2iW5ljvLRVA5iKHUeHQ/UCA0bB67Dc6jz X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 2 Sep 2003 21:22:36 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32439 Bob Perlman wrote: > > Whoever said, "If you require noise to shift you out of metastability, > then the people who argue that more noise will get you out quicker > could then be right," could you explain further? Are you saying that > noise is required to resolve the metastable state, or is this a > counter-argument to the "noise may get you out faster" claim? Or is > it something else entirely? I guess this was not well stated. This was in response to someone else who seemed to be saying that noise is needed to get out of metastability. Just before this I believe I spoke about the perfect balance point being so small that it was not significant. So noise is not really needed. The quote above was to say that if noise really is required, then the advocates of more noise may be right. But my point is that noise is not needed since there is virtually never a "perfect" balance. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Tue, 02 Sep 2003 17:29:15 -0400 Organization: Arius, Inc Lines: 47 Message-ID: <3F550BAB.DDC4F718@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <8471ba54.0308281152.64fe5e56@posting.google.com> <500tkvsfnsmioddjf8j50opt5qir5p9j45@4ax.com> <8471ba54.0308290637.13e755c7@posting.google.com> <3F50A02C.1BE45972@yahoo.com> <8471ba54.0309010441.16aec23c@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVa/EWHXdM+Gwdfi+hryoS8IWDu/L0119zcSBtiAFSMph9RCx1EORHEN X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 2 Sep 2003 21:30:09 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32440 Luiz Carlos wrote: > > > If you think there is no uncertanty in measuring the spin of an > > electron, you need to go back to school. > > Rick, I din't say that. I said electron spin does not presents > metastability. It does not matter in the least what state the electron is in. Metastability is a measurement problem. When you try to measure the state of a FF with a gate or second FF, that is where metastability is an issue. The first FF is in a state where the voltage will ultimately resolve itself to a final value. So the issue of metastability is really one of measuring the state well enough to resolve the final state of the FF. Just like the metastability was created by the inability of the FF to measure the state of the input at the sampling time. Electron spin has all the same measurement issues that a FF has. If the state of the electron spin is changing as the measurement is made, then what state is it in? What will be the result of the measurement? > Anyway, did you hear about spintronics? Maybe the scientists behind > this idea may go back to school too! > > Look at > http://www.eetimes.com/story/OEG20001221S0035 > Cut and paste please, I don't know how to include hypertexts. > I think that shows my whole point of view: if you believe, insist! > > Unhappily (for me) I could not find the text about the electron > position. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Tue, 02 Sep 2003 17:32:46 -0400 Organization: Arius, Inc Lines: 50 Message-ID: <3F550C7E.6A451965@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> <8NC4b.240107$cF.77428@rwcrnsc53> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYgzh/pdDr8TLUU4KXW5FqzRX6JJ3MF3tYCV/I7dL0zyUA/06wRC2xy X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 2 Sep 2003 21:33:41 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newshosting.com!news-xfer2.atl.newshosting.com!207.69.154.101.MISMATCH!elnk-atl-nf1!newsfeed.earthlink.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32509 Glen Herrmannsfeldt wrote: > > "rickman" wrote in message > news:3F50A0E8.15AAA082@yahoo.com... > > (snip regarding the DEC KA-10, metastability, and self-timed logic) > > > I am no expert in async logic, but I have never heard of a circuit that > > can even detect metastability. I also thought that async logic did not > > "measure" the time it took for a calculation, it simply allowed > > different times for different calculations. The control path for a > > given circuit has a longer delay than the data path and would be > > dependant on the calculation being performed. How exactly would a > > circuit detect when an async calculation is complete? > > Well, I agree with the skepticism in the first place, but consider a CPU > with lights indicating the current contents of the registers. Normally, the > values will be changing very fast. If they suddenly stop changing, it could > be because of unresolved metastability. The logic will wait quietly for it > to resolve, and then continue. I don't see how this is possible. You are assuming that the CPU has some way to measure that a FF output is metastable. I don't know of any way of doing that. How is this circuit designed? > It might be, though, that the machine is in I/O wait, and there really is > nothing to do. I never got to actually see the machine, but at the time > many machines had console lights, at least for the instruction counter and a > few other important registers. (Though I don't believe that the PDP-10 had > a wait state like IBM S/360 did, where no instructions were executed.) It is also possible that the lights are not a valid indication of the state of the CPU. Since the CPU runs at thousands of times faster than the eye can see, it is entirely possible that a loop is being executed that makes the lights appear to be lit, but are actually flashing much faster than you could see. If the duty cycle is high for each light that is flashing you would not see a dimming either. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### Message-ID: <3F556A8E.A21A15C1@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4E2447.C2B41336@xilinx.com> <3F4E7FBC.FAD@designtools.co.nz> <8Ow3b.56$qq3.26603@news.uswest.net> <3F516846.72D5F5CA@yahoo.com> <72r2lvks28t0j2381h2ih54h2vrov1fkr9@4ax.com> <3F520C57.3EC84F99@yahoo.com> <3F5509DF.EF545C87@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 51 Date: Wed, 03 Sep 2003 00:14:06 -0400 NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: lakeread05 1062561937 68.15.41.165 (Wed, 03 Sep 2003 00:05:37 EDT) NNTP-Posting-Date: Wed, 03 Sep 2003 00:05:37 EDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!irazu.switch.ch!switch.ch!npeer.de.kpn-eurorings.net!news-xfer.cox.net!peer01.cox.net!cox.net!p01!lakeread05.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32455 Noise is not needed, but it may help to accelerate departure from the balance point shortening the metastable period. On the other hand, noise can also work the other way pushing the Q point closer to the balance point thereby delaying recovery. As a result, noise has no net effect on the metastable probabilities. rickman wrote: > Bob Perlman wrote: > > > > Whoever said, "If you require noise to shift you out of metastability, > > then the people who argue that more noise will get you out quicker > > could then be right," could you explain further? Are you saying that > > noise is required to resolve the metastable state, or is this a > > counter-argument to the "noise may get you out faster" claim? Or is > > it something else entirely? > > I guess this was not well stated. This was in response to someone else > who seemed to be saying that noise is needed to get out of > metastability. Just before this I believe I spoke about the perfect > balance point being so small that it was not significant. So noise is > not really needed. The quote above was to say that if noise really is > required, then the advocates of more noise may be right. But my point > is that noise is not needed since there is virtually never a "perfect" > balance. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: "Glen Herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> <8NC4b.240107$cF.77428@rwcrnsc53> <3F550C7E.6A451965@yahoo.com> Subject: Re: Thinking out loud about metastability Lines: 21 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: NNTP-Posting-Host: 12.207.204.17 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1062565101 12.207.204.17 (Wed, 03 Sep 2003 04:58:21 GMT) NNTP-Posting-Date: Wed, 03 Sep 2003 04:58:21 GMT Organization: Comcast Online Date: Wed, 03 Sep 2003 04:58:21 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32463 "rickman" wrote in message news:3F550C7E.6A451965@yahoo.com... (snip) > I don't see how this is possible. You are assuming that the CPU has > some way to measure that a FF output is metastable. I don't know of any > way of doing that. How is this circuit designed? There are books, and probably web sites explaining self timed logic, or asynchronous logic. There are no clocks, but it takes more wires for each signal. Designing is completely different than synchronous logic designs, which means that the current design tools don't help very much. I don't know it well enough to explain here, though. -- glen ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 03 Sep 2003 03:37:35 -0400 Organization: Arius, Inc Lines: 54 Message-ID: <3F559A3F.91184B1A@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> <8NC4b.240107$cF.77428@rwcrnsc53> <3F550C7E.6A451965@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZpOPhn/D/LPgw9acmiLHM2Aecvy3EeIjIQckkhF8AwFVf3vPIOGrYy X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 3 Sep 2003 07:37:42 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news-out1.nntp.be!propagator2-sterling!news-in-sterling.nuthinbutnews.com!cyclone1.gnilink.net!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32437 Glen Herrmannsfeldt wrote: > > "rickman" wrote in message > news:3F550C7E.6A451965@yahoo.com... > > (snip) > > > I don't see how this is possible. You are assuming that the CPU has > > some way to measure that a FF output is metastable. I don't know of any > > way of doing that. How is this circuit designed? > > There are books, and probably web sites explaining self timed logic, or > asynchronous logic. > > There are no clocks, but it takes more wires for each signal. Designing is > completely different than synchronous logic designs, which means that the > current design tools don't help very much. I don't know it well enough to > explain here, though. Yes, everything I have read (which is not a lot) simply relies on the control path (the clock) to have a longer delay than the data path. So the data will always reach the next stage before the control saying the data is ready. There is no way to determine when a circuit is metastable or not. Async circuits are not magic, they just depend on predictable delays, just like any other circuit. The design is different because there is no common clock so each circuit can run with its own delay. Since the next circuit will take the output when it is ready, there is no problem with synchronization. One problem I do see is that if each stage has a different delay, then it can not accept a new input from the preceding stage until the output has been taken by the following stage. It seems in the end the async circuit will run no faster than the slowest stage, which is what the sync clocked circuit will do. But I have not read about it much, so perhaps there is more to it than just this. But without design tools or any expectation of using it soon, there is not much incentive to spend much time reading up on it now. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 3 Sep 2003 03:04:18 -0700 Organization: http://groups.google.com/ Lines: 10 Message-ID: <8471ba54.0309030204.5ba7f38f@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <8471ba54.0308281152.64fe5e56@posting.google.com> <500tkvsfnsmioddjf8j50opt5qir5p9j45@4ax.com> <8471ba54.0308290637.13e755c7@posting.google.com> <3F50A02C.1BE45972@yahoo.com> <8471ba54.0309010441.16aec23c@posting.google.com> <3F550BAB.DDC4F718@yahoo.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062583459 12009 127.0.0.1 (3 Sep 2003 10:04:19 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 3 Sep 2003 10:04:19 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32500 > Electron spin has all the same measurement issues that a FF has. If the > state of the electron spin is changing as the measurement is made, then > what state is it in? What will be the result of the measurement? > Rick, the electron spin is +1/2 or -1/2, there is no in between state, it changes instantaneously (in one fundamental clock tick, ~10^-43 seconds). Luiz Carlos ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 3 Sep 2003 13:48:28 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 36 Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F550C7E.6A451965@yahoo.com> <3F559A3F.91184B1A@yahoo.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1062596908 94438 128.32.112.203 (3 Sep 2003 13:48:28 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Wed, 3 Sep 2003 13:48:28 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!newsfeed.gol.com!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32476 In article <3F559A3F.91184B1A@yahoo.com>, rickman wrote: > >There is no way to determine when a circuit is metastable or not. Async >circuits are not magic, they just depend on predictable delays, just >like any other circuit. The design is different because there is no >common clock so each circuit can run with its own delay. Since the next >circuit will take the output when it is ready, there is no problem with >synchronization. Silly question: I don't see why an ANALOG flip-flop couldn't determine that it is in the intermediate state at some fixed interval after the clock, and then force the flop one way or another. Of course, it might double-glitch in the meantime (flop goes up before logic forces it down), but it would make a flop with a fixed-maximum metastabel interval. Of course, it seems like such a massive headache to do. >One problem I do see is that if each stage has a different delay, then >it can not accept a new input from the preceding stage until the output >has been taken by the following stage. It seems in the end the async >circuit will run no faster than the slowest stage, which is what the >sync clocked circuit will do. The trick with asynchronous logic is that the longest stage WHICH IS IN THE COMPUTATION is the critical path. EG, if 9 of the stages take 1 ns, and the last takes 2ns, but the last only affects 1/2 the data, with the asynchronous circuitry doing the shortcutting, it will be considerably faster than the synchronous one. The problem is: You can automatically balance the pipelining (retiming) for a synchronous circuit, while asynchronous really playes havoc with the CAD flow and testing. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 03 Sep 2003 15:02:55 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3F46E816.96EF198B@yahoo.com> <3F550C7E.6A451965@yahoo.com> <3F559A3F.91184B1A@yahoo.com> X-Complaints-To: abuse@supernews.com Lines: 22 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!irazu.switch.ch!switch.ch!in.100proofnews.com!in.100proofnews.com!cycny01.gnilink.net!cyclone1.gnilink.net!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:32486 >Silly question: I don't see why an ANALOG flip-flop couldn't determine >that it is in the intermediate state at some fixed interval after the >clock, and then force the flop one way or another. Of course, it >might double-glitch in the meantime (flop goes up before logic forces >it down), but it would make a flop with a fixed-maximum metastabel >interval. DING DING DING Nobody has been able to fix metastability yet. If you really have a fix, it's worth a Nobel Prize. The usual problem with that sort of approach is that you get a runt pulse on the fix-it signal in cases that would have worked correctly without it. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 3 Sep 2003 15:17:12 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 31 Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F559A3F.91184B1A@yahoo.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1062602232 97647 128.32.112.203 (3 Sep 2003 15:17:12 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Wed, 3 Sep 2003 15:17:12 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32477 In article , Hal Murray wrote: >>Silly question: I don't see why an ANALOG flip-flop couldn't determine >>that it is in the intermediate state at some fixed interval after the >>clock, and then force the flop one way or another. Of course, it >>might double-glitch in the meantime (flop goes up before logic forces >>it down), but it would make a flop with a fixed-maximum metastabel >>interval. > >DING DING DING > >Nobody has been able to fix metastability yet. If you really have >a fix, it's worth a Nobel Prize. > >The usual problem with that sort of approach is that you get >a runt pulse on the fix-it signal in cases that would have worked >correctly without it. Yes, but the point is it would fix the maximum metastability window, which is the key requirement, as "did the data come before or after the clock edge" is really an irrelevant question at the metastable capture point, you jsut want it to go to ONE or the other (not stick around and make up its mind a half clock cycle later), and possibly to tell you. This isn't FIXING metastability, this is detecting and responding to it, changing an exponentially decaying bounds into a fixed bounds. Of course, it seems like way too big a headache to bother with. -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 03 Sep 2003 13:40:03 -0400 Organization: Arius, Inc Lines: 29 Message-ID: <3F562773.EC0F14B8@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <8471ba54.0308281152.64fe5e56@posting.google.com> <500tkvsfnsmioddjf8j50opt5qir5p9j45@4ax.com> <8471ba54.0308290637.13e755c7@posting.google.com> <3F50A02C.1BE45972@yahoo.com> <8471ba54.0309010441.16aec23c@posting.google.com> <3F550BAB.DDC4F718@yahoo.com> <8471ba54.0309030204.5ba7f38f@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbw2on5+1JJZrEkQ4IUwvLU89HyykjMrJQV74NxIOiWD8mO6Muuoohy X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 3 Sep 2003 17:40:03 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32438 Luiz Carlos wrote: > > > Electron spin has all the same measurement issues that a FF has. If the > > state of the electron spin is changing as the measurement is made, then > > what state is it in? What will be the result of the measurement? > > > > Rick, the electron spin is +1/2 or -1/2, there is no in between state, > it changes instantaneously (in one fundamental clock tick, ~10^-43 > seconds). > > Luiz Carlos But the measurement is not instantaneous. So the transistion could occur during a measurement. Result... inconclusive measurement which is what metastability is all about. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Wed, 03 Sep 2003 15:47:49 -0400 Organization: Arius, Inc Lines: 86 Message-ID: <3F564565.7B06E523@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F559A3F.91184B1A@yahoo.com> <3F56292C.E9F89B7F@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZLNP7NO+ic1L4xl2PCINCmkVQMxiyZ3aUKkFdvNsD4V/7dKabUynj6 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 3 Sep 2003 19:47:50 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32546 "Nicholas C. Weaver" wrote: > > In article <3F56292C.E9F89B7F@yahoo.com>, > rickman wrote: > >"Nicholas C. Weaver" wrote: > >If you don't see the problem it is because you are not looking hard > >enough. The issue with metastability comes from trying to measure the > >state of a FF or other digital voltage. When a signal is at an > >intermediate value a measurement can be inconclusive. Your ANALOG FF > >can be just as inconclusive as the digital FF. Besides, the result is > >always digital (or more accurately, discreet instead of continuous). > > > >You are suggesting that you add a third state to the measurement, but > >you get the same inconclusive measurement between the metastable state > >and either the one or the zero states. The result is that the output of > >your ANALOG FF would be indeterminate which could result in > >metastability in the next stage. > > > >If I am not grasping your idea, then please provide more details. > > The flip flop core exists in one of THREE states: Vdd, Vss (the stable > points) and Vms +/- epsilon (the metastable range, in between Vdd and > Vss). > > The analog circuitry in the flip flop measures the flip-flop state at > Tdelay after the clock edge. > > If it is within Vms +/- a large epsilon (that is, metastable at this > point in time), the analog circuitry forces the flip-flop to Vss, and > also signals that a metastable capture/correction was performed. > > This may cause a spurrious transition (eg, the metastable state is > measured, it goes high, and then the post-measurement kick drags it > back down to Vss). You are not accounting for the fact that the voltage is being measured by the analog circuit and it can not distinguish between the metastable state and the non-metastable states any better than the original FF could distinguish the two valid states. If the voltage is at the cusp of the metastable range, the analog circuit will have an invalid or indeterminate output and will not drive the FF to a valid state. In fact, it may drive the FF back toward a state with an even longer transistion time. This is very circular. Each measurement has a range in which the measurement is indeterminate within a given amout of time. That is the nature of metastability. It is not just the state of the FF. The FF became metastable because it could not measure the input to be either a 1 or a 0. Trying to measure the state of the FF has the same problem, ad infinitum. > >> The trick with asynchronous logic is that the longest stage WHICH IS > >> IN THE COMPUTATION is the critical path. EG, if 9 of the stages take > >> 1 ns, and the last takes 2ns, but the last only affects 1/2 the data, > >> with the asynchronous circuitry doing the shortcutting, it will be > >> considerably faster than the synchronous one. > > > >Except that sync designs can do the same thing. A multiply accumulate > >typically takes twice as long as the other ops in a calculation. So > >they split it into two stages running at full speed. Or if only half > >the data needs the MAC, then they can do nothing since this will run at > >full speed. > > The promise of the asynchronous is that this can occur on a much finer > grain, eg if all the ops are 1 ns, but the final one is either 1 or > 1.5 ns. > > Of couse, it has never really lived up to this promise, mostly because > the handshaking overhead can be severe, as well as the other problems > (CAD, testing). > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### Message-ID: <3F564D7F.C187A50B@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability References: <3F46E816.96EF198B@yahoo.com> <3F559A3F.91184B1A@yahoo.com> <3F56292C.E9F89B7F@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 82 Date: Wed, 03 Sep 2003 16:22:23 -0400 NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: lakeread05 1062620032 68.15.41.165 (Wed, 03 Sep 2003 16:13:52 EDT) NNTP-Posting-Date: Wed, 03 Sep 2003 16:13:52 EDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!peer01.cox.net!cox.net!p01!lakeread05.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32515 The problem is with your three level "analog ff", instead of one metastable region, you now have two, one at each side of your middle state. All it accomplishes is a redistribution of the metastable state at a cost of considerably more complexity. It doesn't fix anything at all. As rickman and others have stated, it comes down to a fundamental limitation in measuring a quantity. Measurement takes a finite amount of time to do. If the transition happens within that measurement window, you have a metastable event, which is to say the measurement was indeterminate. Works for digital logic, works for electron spins and so on. If you really believe you have a work-around, then you should publish it. Be prepared to nurture your wounds though. The paths to the holy metastability grail is littered with bloodied bodies, many of whom have followed the same trail you are considering. "Nicholas C. Weaver" wrote: > In article <3F56292C.E9F89B7F@yahoo.com>, > rickman wrote: > >"Nicholas C. Weaver" wrote: > >If you don't see the problem it is because you are not looking hard > >enough. The issue with metastability comes from trying to measure the > >state of a FF or other digital voltage. When a signal is at an > >intermediate value a measurement can be inconclusive. Your ANALOG FF > >can be just as inconclusive as the digital FF. Besides, the result is > >always digital (or more accurately, discreet instead of continuous). > > > >You are suggesting that you add a third state to the measurement, but > >you get the same inconclusive measurement between the metastable state > >and either the one or the zero states. The result is that the output of > >your ANALOG FF would be indeterminate which could result in > >metastability in the next stage. > > > >If I am not grasping your idea, then please provide more details. > > The flip flop core exists in one of THREE states: Vdd, Vss (the stable > points) and Vms +/- epsilon (the metastable range, in between Vdd and > Vss). > > The analog circuitry in the flip flop measures the flip-flop state at > Tdelay after the clock edge. > > If it is within Vms +/- a large epsilon (that is, metastable at this > point in time), the analog circuitry forces the flip-flop to Vss, and > also signals that a metastable capture/correction was performed. > > This may cause a spurrious transition (eg, the metastable state is > measured, it goes high, and then the post-measurement kick drags it > back down to Vss). > > >> The trick with asynchronous logic is that the longest stage WHICH IS > >> IN THE COMPUTATION is the critical path. EG, if 9 of the stages take > >> 1 ns, and the last takes 2ns, but the last only affects 1/2 the data, > >> with the asynchronous circuitry doing the shortcutting, it will be > >> considerably faster than the synchronous one. > > > >Except that sync designs can do the same thing. A multiply accumulate > >typically takes twice as long as the other ops in a calculation. So > >they split it into two stages running at full speed. Or if only half > >the data needs the MAC, then they can do nothing since this will run at > >full speed. > > The promise of the asynchronous is that this can occur on a much finer > grain, eg if all the ops are 1 ns, but the final one is either 1 or > 1.5 ns. > > Of couse, it has never really lived up to this promise, mostly because > the handshaking overhead can be severe, as well as the other problems > (CAD, testing). > -- > Nicholas C. Weaver nweaver@cs.berkeley.edu -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: "Glen Herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3F46E816.96EF198B@yahoo.com> <3F550C7E.6A451965@yahoo.com> <3F559A3F.91184B1A@yahoo.com> Subject: Re: Thinking out loud about metastability Lines: 25 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: NNTP-Posting-Host: 12.207.204.17 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc52.ops.asp.att.net 1062638620 12.207.204.17 (Thu, 04 Sep 2003 01:23:40 GMT) NNTP-Posting-Date: Thu, 04 Sep 2003 01:23:40 GMT Organization: Comcast Online Date: Thu, 04 Sep 2003 01:23:40 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-out1.nntp.be!propagator2-sterling!news-in-sterling.nuthinbutnews.com!cyclone1.gnilink.net!wn14feed!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32544 "Hal Murray" wrote in message news:vlc0kv1m4flm5f@corp.supernews.com... > >Silly question: I don't see why an ANALOG flip-flop couldn't determine > >that it is in the intermediate state at some fixed interval after the > >clock, and then force the flop one way or another. Of course, it > >might double-glitch in the meantime (flop goes up before logic forces > >it down), but it would make a flop with a fixed-maximum metastabel > >interval. > > DING DING DING > > Nobody has been able to fix metastability yet. If you really have > a fix, it's worth a Nobel Prize. It might be that you can change the shape of the probability vs. time curve, while keeping the area constant. That could reduce the probability of metastability lasting too long for a given clock rate. I don't know the physics well enough to say. Also, it might be pretty expensive to do that. -- glen ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Thu, 04 Sep 2003 01:26:06 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3F46E816.96EF198B@yahoo.com> <3F559A3F.91184B1A@yahoo.com> X-Complaints-To: abuse@supernews.com Lines: 42 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!sn-xit-02!sn-xit-04!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:32522 >This isn't FIXING metastability, this is detecting and responding to >it, changing an exponentially decaying bounds into a fixed bounds. If you could build a circuit with a "fixed bounds", that would solve the metastability problem and you would be a hero. (Just set your clock period to that fixed bounds.) I put metastability in the same category as perpetual motion. I assume any proposal is wrong, even if I can't spot the problem right away. Best one I've ever heard of was a bicycle wheel that ran off changes in air pressure. >Yes, but the point is it would fix the maximum metastability window, >which is the key requirement, as "did the data come before or after >the clock edge" is really an irrelevant question at the metastable >capture point, you jsut want it to go to ONE or the other (not stick >around and make up its mind a half clock cycle later), and possibly to >tell you. If you have a circuit that you think will work, please send me the schematic. There is a reasonable chance I (or somebody here) can find the bug in it. No promises. The thing I would look for is runt pulses. The best non EE-geek example of metastability I have seen is rolling a ball over a speed bump. Left of the bump is 0. Right of it is 1. Give it a good shove and it goes over. Give it a gentle shove and it bounces back. For some speed, the ball will teeter on the top for a while, then fall off one side or the other. The initial speed of the ball corresponds to meeting setup/hold times. If the system is continuous, there is some value in the middle that will cause troubles. Setup/hold times and ball speed both seem continuous to me. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: "Glen Herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3F46E816.96EF198B@yahoo.com> <3F559A3F.91184B1A@yahoo.com> Subject: Re: Thinking out loud about metastability Lines: 43 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: NNTP-Posting-Host: 12.207.204.17 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc51.ops.asp.att.net 1062660263 12.207.204.17 (Thu, 04 Sep 2003 07:24:23 GMT) NNTP-Posting-Date: Thu, 04 Sep 2003 07:24:23 GMT Organization: Comcast Online Date: Thu, 04 Sep 2003 07:24:23 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-out1.nntp.be!propagator2-sterling!news-in-sterling.nuthinbutnews.com!cyclone1.gnilink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32543 "Hal Murray" wrote in message news:vld55e7r7pvj2e@corp.supernews.com... > >This isn't FIXING metastability, this is detecting and responding to > >it, changing an exponentially decaying bounds into a fixed bounds. > > If you could build a circuit with a "fixed bounds", that would solve > the metastability problem and you would be a hero. (Just set your > clock period to that fixed bounds.) (snip) > If you have a circuit that you think will work, please send me > the schematic. There is a reasonable chance I (or somebody here) > can find the bug in it. No promises. The thing I would look for is > runt pulses. > > The best non EE-geek example of metastability I have seen is > rolling a ball over a speed bump. Left of the bump is 0. Right of > it is 1. Give it a good shove and it goes over. Give it a gentle > shove and it bounces back. For some speed, the ball will teeter on > the top for a while, then fall off one side or the other. > > The initial speed of the ball corresponds to meeting setup/hold times. > If the system is continuous, there is some value in the middle that will > cause troubles. Setup/hold times and ball speed both seem continuous > to me. One thing that I still remember from the first discussions about metastability was that the sharper you make the peak, the smaller the chance of getting into the metastable state, but the longer it stays when you get there. I don't know if the analogy is quite right, but consider a very sharp speed bump. It will deform the ball as it goes over, such that it sticks more. Not so long after that, I was taking a shower at a pool with a valve designed not to stay on. I managed to get it into the metastable (stay on) state, so that I could wash with both hands. (It worked just like the speed bump, where on top of the bump the valve was on.) -- glen ###### From: oen_br@yahoo.com.br (Luiz Carlos) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 4 Sep 2003 04:14:16 -0700 Organization: http://groups.google.com/ Lines: 10 Message-ID: <8471ba54.0309040314.1951abb5@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <8471ba54.0308281152.64fe5e56@posting.google.com> <500tkvsfnsmioddjf8j50opt5qir5p9j45@4ax.com> <8471ba54.0308290637.13e755c7@posting.google.com> <3F50A02C.1BE45972@yahoo.com> <8471ba54.0309010441.16aec23c@posting.google.com> <3F550BAB.DDC4F718@yahoo.com> <8471ba54.0309030204.5ba7f38f@posting.google.com> <3F562773.EC0F14B8@yahoo.com> NNTP-Posting-Host: 200.102.50.240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062674058 5444 127.0.0.1 (4 Sep 2003 11:14:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 4 Sep 2003 11:14:18 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32528 > But the measurement is not instantaneous. So the transistion could > occur during a measurement. Result... inconclusive measurement which is > what metastability is all about. You just need to measure the spins to see the results. You can maintain they stable during this. To carry out the operations the spins interact and you don't need to measure them. But, if you imply a measure in the interaction process, so the measure is instantaneous. Luiz Carlos ###### From: H. Peter Anvin Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Organization: Transmeta Corporation, Santa Clara CA Lines: 37 Sender: hpa@cesium.transmeta.com Message-ID: References: <3F46E816.96EF198B@yahoo.com> <3F550BAB.DDC4F718@yahoo.com> <8471ba54.0309030204.5ba7f38f@post <3F562773.EC0F14B8@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Comment-To: rickman Disclaimer: Not speaking for Transmeta in any way, shape, or form. Copyright: Copyright 2003 H. Peter Anvin - All Rights Reserved Cache-Post-Path: palladium.transmeta.com!unknown@cesium.transmeta.com X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) Date: 5 Sep 2003 09:01:56 -0700 NNTP-Posting-Host: 63.209.4.196 X-Complaints-To: news@globix.net X-Trace: news.sjc.globix.net 1062777695 63.209.4.196 (Fri, 05 Sep 2003 09:01:35 PDT) NNTP-Posting-Date: Fri, 05 Sep 2003 09:01:35 PDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.he.net!cyclone-sf.pbi.net!209.10.34.151!newsfeed.sjc.globix.net!news.sjc.globix.net!cesium.transmeta.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32591 Followup to: <3F562773.EC0F14B8@yahoo.com> By author: rickman In newsgroup: comp.arch.fpga > > Luiz Carlos wrote: > > > > > Electron spin has all the same measurement issues that a FF has. If the > > > state of the electron spin is changing as the measurement is made, then > > > what state is it in? What will be the result of the measurement? > > > > > > > Rick, the electron spin is +1/2 or -1/2, there is no in between state, > > it changes instantaneously (in one fundamental clock tick, ~10^-43 > > seconds). > > > > Luiz Carlos > > But the measurement is not instantaneous. So the transistion could > occur during a measurement. Result... inconclusive measurement which is > what metastability is all about. > Well, actually it is. It might *affect* the spin (Heisenberg wins again) but unlike classical measurements there shouldn't be any ifs about the result. There is a lot of things in the quantum world which is completely counterintuitive to everything we have learned. If you look at quantum teleportation, for example, you'd have to conclude information was conducted backwards in time... This is of course, impossible. -- at work, in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 ###### From: Ron Cline Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Fri, 05 Sep 2003 11:36:07 -0600 Organization: Xilinx, Inc. Lines: 16 Message-ID: <3F58C987.41B42E6F@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> <8NC4b.240107$cF.77428@rwcrnsc53> <3F550C7E.6A451965@yahoo.com> <3F559A3F.91184B1A@yahoo.com> NNTP-Posting-Host: 149.199.109.74 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32557 rickman wrote: > There is no way to determine when a circuit is metastable or not. It is possible -- I did it once for a FF design for another company. It requires a separate, combinational output signal ("metastable flag-out"). But, of course, there's no way to use this to kick the FF circuit itself out of metastability. All previous comments about this being a no-fix are true. The flag is generated by taking advantage of the fact that the latch going metastable has a cross-coupled gate with a known threshold point during metastability. A 2-input logic gate with a different threshold can detect that both inputs (ie, Q and Q-bar) are above (or below) it's own (different by design) threshold point. Cheers, Ron Cline ###### From: soar2morrow@yahoo.com (Tom Seim) Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: 5 Sep 2003 14:17:07 -0700 Organization: http://groups.google.com/ Lines: 23 Message-ID: <6c71b322.0309051317.61674cb6@posting.google.com> References: <3F46E816.96EF198B@yahoo.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> <8NC4b.240107$cF.77428@rwcrnsc53> <3F550C7E.6A451965@yahoo.com> <3F559A3F.91184B1A@yahoo.com> <3F58C987.41B42E6F@xilinx.com> NNTP-Posting-Host: 130.20.230.13 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062796628 704 127.0.0.1 (5 Sep 2003 21:17:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 5 Sep 2003 21:17:08 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32609 Ron Cline wrote in message news:<3F58C987.41B42E6F@xilinx.com>... > rickman wrote: > > There is no way to determine when a circuit is metastable or not. > > It is possible -- I did it once for a FF design for another company. It > requires a separate, combinational output signal ("metastable flag-out"). > But, of course, there's no way to use this to kick the FF circuit itself out > of metastability. All previous comments about this being a no-fix are true. > > The flag is generated by taking advantage of the fact that the latch going > metastable has a cross-coupled gate with a known threshold point during > metastability. A 2-input logic gate with a different threshold can detect > that both inputs (ie, Q and Q-bar) are above (or below) it's own (different by > design) threshold point. Why can't you use this flag to generate another (delayed) clock to the same FF? It would continue to retrigger itself until it was in a stable state. If you ORed all of these flags together in a register you would have a data valid output. Nothin like async logic to get your blood flowing! Tom ###### From: Ron Cline Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Fri, 05 Sep 2003 15:30:40 -0600 Organization: Xilinx, Inc. Lines: 24 Message-ID: <3F590080.15245960@xilinx.com> References: <3F46E816.96EF198B@yahoo.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> <8NC4b.240107$cF.77428@rwcrnsc53> <3F550C7E.6A451965@yahoo.com> <3F559A3F.91184B1A@yahoo.com> <3F58C987.41B42E6F@xilinx.com> <6c71b322.0309051317.61674cb6@posting.google.com> NNTP-Posting-Host: 149.199.109.74 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32549 Tom Seim wrote: > > Ron Cline wrote in message news:<3F58C987.41B42E6F@xilinx.com>... > > The flag is generated by taking advantage of the fact that the latch going > > metastable has a cross-coupled gate with a known threshold point during > > metastability. A 2-input logic gate with a different threshold can detect > > that both inputs (ie, Q and Q-bar) are above (or below) it's own (different by > > design) threshold point. > > Why can't you use this flag to generate another (delayed) clock to the > same FF? It would continue to retrigger itself until it was in a > stable state. This newly-created feedback loop would have a much longer metastable time-constant than had the original latch. Better to leave well enough alone, I think. > If you ORed all of these flags together in a register > you would have a data valid output. The flag wouldn't indicate a logic state (valid or not), only the presence of metastability. The logic state is indeterminant while the flag is active. - Ron ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Thinking out loud about metastability Date: Sat, 06 Sep 2003 10:53:08 -0400 Organization: Arius, Inc Lines: 36 Message-ID: <3F59F4D4.26BD6BB4@yahoo.com> References: <3F46E816.96EF198B@yahoo.com> <3F4A4A96.18037049@xilinx.com> <3F4B8B82.D32E620@xilinx.com> <8471ba54.0308271035.13f12cb@posting.google.com> <3F4D17D9.5CFD8B91@xilinx.com> <8471ba54.0308280302.63e7e710@posting.google.com> <3F4DED0E.574A03F9@andraka.com> <3F50A0E8.15AAA082@yahoo.com> <8NC4b.240107$cF.77428@rwcrnsc53> <3F550C7E.6A451965@yahoo.com> <3F559A3F.91184B1A@yahoo.com> <3F58C987.41B42E6F@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYyEYdA3id6bHjgBqEAIRGE2WT/TBd94nudkJECTKQlMJHhynlGGgq/ X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 6 Sep 2003 14:53:12 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32634 Ron Cline wrote: > > rickman wrote: > > There is no way to determine when a circuit is metastable or not. > > It is possible -- I did it once for a FF design for another company. It > requires a separate, combinational output signal ("metastable flag-out"). > But, of course, there's no way to use this to kick the FF circuit itself out > of metastability. All previous comments about this being a no-fix are true. > > The flag is generated by taking advantage of the fact that the latch going > metastable has a cross-coupled gate with a known threshold point during > metastability. A 2-input logic gate with a different threshold can detect > that both inputs (ie, Q and Q-bar) are above (or below) it's own (different by > design) threshold point. And what happens to the output of this MS-detector gate if one of the voltages is right at the threshold of the gate? Is it possible that the output of the gate is at an intermediate voltage and is therefore indeterminate? Once again the problem comes from the measurement. There is no knife that is sharp enough to split every hair known to man or nature. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX