From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Metastability numbers Date: Fri, 06 Sep 2002 17:15:36 -0700 Organization: Xilinx,Inc Lines: 61 Message-ID: <3D794527.2CF5AA@xilinx.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" 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!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.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:20706 We finally got around to measuring metastabity. We used the CLB flip-flops in our newest Virtex-IIPro device (130 nm technolgy, 1.5 Vcc) and clocked them at around 350 MHz with an asynchronous input of roughly 50 MHz. This should represent agressive modern operating conditions. We then measured the number of metastable events per minute as a function of the time between clocking the flip-flop under test, and a variable clock delay at the observation flip-flop that checks for metastable events. This method is described in detail in XAPP094, and I first used and documented it in 1988 (!). The concept seems to have passed the test of time. Here are the measured results: Metastable events for a clock-to-clock delay of 1300 ps: ~ 30,000 errors per minute 1400 ps: ~ 2,000 errors per minute 1500 ps: ~ 100 errors per minute 1600 ps: = 10 errors per minute These are short-time measurements of a statistical event, but I am willing to estimate that the time between metastable events increases by a factor of roughly 200 for every 200 picoseconds of extra delay between the two clocks. That leads to the following extrapolation: If you synchronize a 50 MHz asynchronous event with a roughly 350 MHz clock, and you allow only 1.2 ns for clock-to-out plus set-up time plus routing to the flip-flop in the adjacent CLB, your design will go metastable very often; the Mean Time Between Failure will be about 0.1 ms. But watch what happens when the timing gets more relaxed: Changing the total delay of 1.2ns to 1.4 ns leads to MTBF=30 ms 1.6 ns leads to MTBF= 6 sec 1.8 ns leads to MTBF= 20 min 2.0 ns leads to MTBF= 4000 min = 66 hrs 2.2 ns leads to MTBF= 13,000 hrs = 18 months 2.4 ns leads to MTBF= 3,600 months = 300 years 2.6 ns leads to MTBF= 60,000 years 2.8 ns leads to MTBF= 12 million years In other words, you can synchronize ~50 MHz with a 350 MHz clock, take advantage of the difference between the inherent 1.2 ns and the 350 MHz clock period of 2.8 ns, and your design will exceed the allowed propagation delay of one clock period only once every 12 million years. For lower clock rates and less frequent asynchronous events, MTBF increases with the inverse of the product of the two frequencies, i.e. for a 100 MHz clock synchronizing a ~ 10 MHz asynchronous event, multiply the MTBF by a factor 3.5 x 5 = 17.5 More details will be published soon. The lack of modern quantative data has been a thorn in my side, and I want to let you know these encouraging results immediately. I think we can say that modern CMOS flip-flops recover extremely fast from any metastable event. :-) I want to thank Yiding Wu for his enthusiastic help and patience doing these measurements. Peter Alfke, Xilinx Applications ###### Message-ID: <3D7A69E4.3B47072F@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: Metastability numbers References: <3D794527.2CF5AA@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 6 NNTP-Posting-Host: 12.230.119.143 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc01 1031432466 12.230.119.143 (Sat, 07 Sep 2002 21:01:06 GMT) NNTP-Posting-Date: Sat, 07 Sep 2002 21:01:06 GMT Date: Sat, 07 Sep 2002 21:01:06 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!wn3feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc01.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20772 Thank you, Peter. This information is valuable. -- Phil Hays ###### From: rk Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: 8 Sep 2002 04:12:34 GMT Organization: Just an OldEngineer Lines: 20 Message-ID: References: <3D794527.2CF5AA@xilinx.com> X-Trace: UmFuZG9tSVZCS9F9pELMrJjD7Sddyo/9GLZmzWZP/5qPhhqdwSa6MNpoGbSdek4v X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 8 Sep 2002 04:12:34 GMT X-No-Archive: yes User-Agent: Xnews/4.06.22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!feedme.news.mediaways.net!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:20708 Peter Alfke wrote: > We finally got around to measuring metastabity. [ snip good data set ] Peter, thanks! [rk climbs on soapbox] All manufacturers should publish metastability information for their flip-flops, so designers can do the computations. And over worst-case voltage and temperature, too. ;-) -- rk, Just an OldEngineer The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. -- from Akin's Laws of Spacecraft Design ###### Message-ID: <3D7C04C4.73F2@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: Metastability numbers References: <3D794527.2CF5AA@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 54 Date: Mon, 09 Sep 2002 14:17:40 +1200 NNTP-Posting-Host: 203.79.98.206 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1031537999 203.79.98.206 (Mon, 09 Sep 2002 14:19:59 NZST) NNTP-Posting-Date: Mon, 09 Sep 2002 14:19:59 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.he.net!news-out.spamkiller.net!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20733 Peter Alfke wrote: > > We finally got around to measuring metastabity. > We used the CLB flip-flops in our newest Virtex-IIPro device (130 nm > technolgy, 1.5 Vcc) and clocked them at around 350 MHz with an > asynchronous input of roughly 50 MHz. This should represent agressive > modern operating conditions. > We then measured the number of metastable events per minute as a > function of the time between clocking the flip-flop under test, and a > variable clock delay at the observation flip-flop that checks for > metastable events. This method is described in detail in XAPP094, and I > first used and documented it in 1988 (!). The concept seems to have > passed the test of time. > > Here are the measured results: > Metastable events for a clock-to-clock delay of > 1300 ps: ~ 30,000 errors per minute > 1400 ps: ~ 2,000 errors per minute > 1500 ps: ~ 100 errors per minute > 1600 ps: = 10 errors per minute Very interesting. This shows the 'finite lifetime' nature, and agressive settling slope. > These are short-time measurements of a statistical event, but I am > willing to estimate that the time between metastable events increases by > a factor of roughly 200 for every 200 picoseconds of extra delay between > the two clocks. But is that safe ? What about numbers < 1300ps, ( Interesting for completeness, and for curve-fitting ) and > 1600ps - ie a run for a day should confirm at least the 1800ps lifetime, (predicted at 20mins/event), and a run for a fortnight should get info on the 2000ps lifetime. ( instead of furlongs/fortnight, you would specify MetaEvents/2000ps lifetime/fortnight ;) How about testing this as well : Check the lifetime curve for double edged syncroniser: +---------+----------< CLK | +---+ | +---+ +-|> | +-o|> | | | | | ----|D Q|------|D Q|--- Qo | | | | +---+ +---+ -jg ###### Message-ID: <3D7C176F.D6CA850F@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,de,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 36 Date: Mon, 09 Sep 2002 03:37:04 GMT NNTP-Posting-Host: 209.179.199.164 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1031542624 209.179.199.164 (Sun, 08 Sep 2002 20:37:04 PDT) NNTP-Posting-Date: Sun, 08 Sep 2002 20:37:04 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!news.stealth.net!central.cox.net!cox.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20728 Jim Granville wrote: > > > What about numbers < 1300ps, > ( Interesting for completeness, and for curve-fitting ) > > and > 1600ps > - ie a run for a day should confirm at least the 1800ps lifetime, > Will do. We have had only 3 days at this. And they seem to have been fruitful. :-) > How about testing this as well : > Check the lifetime curve for double edged syncroniser: > > +---------+----------< CLK > | +---+ | +---+ > +-|> | +-o|> | > | | | | > ----|D Q|------|D Q|--- Qo > | | | | > +---+ +---+ If I can decypher your drawing, thta's exactly what we use for measuring. Look at XAPP094... BTW, the billions of years were somwhat tongue-in-cheek. But that's what you get with exponential functions...If there is no better explanation, I take math anytime. Peter Alfke ###### Message-ID: <3D7C3B58.512E@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: Metastability numbers References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 57 Date: Mon, 09 Sep 2002 18:10:32 +1200 NNTP-Posting-Host: 203.79.98.38 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1031551970 203.79.98.38 (Mon, 09 Sep 2002 18:12:50 NZST) NNTP-Posting-Date: Mon, 09 Sep 2002 18:12:50 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!news.he.net!news-out.spamkiller.net!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20734 Peter Alfke wrote: > > Jim Granville wrote: > > How about testing this as well : > > Check the lifetime curve for double edged syncroniser: > > > > +---------+----------< CLK > > | +---+ | +---+ > > +-|> | +-o|> | > > | | | | > > ----|D Q|------|D Q|--- Qo > > | | | | > > +---+ +---+ > > If I can decypher your drawing, thta's exactly what we use for measuring. > Look at XAPP094... I meant this as a alternative for the first, single D register - ie the clock domain syncroniser - wondering if there was benefit in two registers, over one with a longer delay. I have also seen this topology, would be interesting to compare this too : +---------+----------< CLK | +---+ | +---+ +-|LE | +--|> | | | | | ----|L Q|------|D Q|--- Qo | | | | +---+ +---+ here, the pre-latch trys to avoid D change within Tsu, so avoiding the metastable-lifetime trigger aperture.( Of course, L-Q can go metastable ) Since you test using both clock edges, these might be a challenge to link to your test circuit. I think your test tabulates lifetime errors, but does not distinguish between a (rare) runt pulse, and a (more common) 'delayed decision' - ie where the OP went one way, then changed its mind, and went the other. Does this _ever_ occur ? Would just need more result capture logic, to count pulses << Lower Freq PW. :) That could be important in some systems, as you could get a single SyncCLK width pulse launched into a downstream state engine, which it was never designed/tested for... -jg ###### Message-ID: <3D7A75D3.D65535CC@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,de,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers, even better! References: <3D794527.2CF5AA@xilinx.com> Content-Type: multipart/alternative; boundary="------------F4B1AC24AB158F3B66864746" Lines: 201 Date: Sat, 07 Sep 2002 21:55:15 GMT NNTP-Posting-Host: 216.244.42.162 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1031435715 216.244.42.162 (Sat, 07 Sep 2002 14:55:15 PDT) NNTP-Posting-Date: Sat, 07 Sep 2002 14:55:15 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!enews.sgi.com!nntp1.phx1.gblx.net!nntp.gblx.net!nntp.gblx.net!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20727 --------------F4B1AC24AB158F3B66864746 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Let me point out a misleading sentence in my previous posting: "For lower clock rates and less frequent asynchronous events, MTBF increases with the inverse of the product of the two frequencies..." This is not correct, it is the frequency of any specific metastable delay that increases with the product of clock and input frequency. For the more practical case, where you are concerned about (not) exceeding a full clock period, things are much better, since you get the benefit of the longer clock period. In my example, a 350 MHz clock synchronizing a 50 MHz input, the data connection between the input flip-flop and a following flip-flop clocked by the same clock will result in an error statistically once every 12 million years. If you lower the clock frequency to 250 MHz, you gain more than 1 ns in clock period, which means five multiplications by 200. That makes the MTBF 320 billion times larger, i.e. roughly 4 billion billion years ( 4 exp18 ). That is roughly 200 million times the highest estimate for the life of the Universe (20 billion years) or about a billion times the age of our dear old planet (4 billion years). Most people would call that a very low probability. Brave souls might even dare to call it zero. Metastability is real, but its impact on modern CMOS logic has been highly exaggerated. It's nice to finally have hard data to prove that. Peter Alfke, Xilinx Applications for the age of the universe, click on http://www.astro.ucla.edu/~wright/age.html ================================================================ Peter Alfke wrote: > We finally got around to measuring metastabity. > We used the CLB flip-flops in our newest Virtex-IIPro device (130 nm > technolgy, 1.5 Vcc) and clocked them at around 350 MHz with an > asynchronous input of roughly 50 MHz. This should represent agressive > modern operating conditions. > We then measured the number of metastable events per minute as a > function of the time between clocking the flip-flop under test, and a > variable clock delay at the observation flip-flop that checks for > metastable events. This method is described in detail in XAPP094, and I > first used and documented it in 1988 (!). The concept seems to have > passed the test of time. > > Here are the measured results: > Metastable events for a clock-to-clock delay of > 1300 ps: ~ 30,000 errors per minute > 1400 ps: ~ 2,000 errors per minute > 1500 ps: ~ 100 errors per minute > 1600 ps: = 10 errors per minute > > These are short-time measurements of a statistical event, but I am > willing to estimate that the time between metastable events increases by > a factor of roughly 200 for every 200 picoseconds of extra delay between > the two clocks. > > That leads to the following extrapolation: > If you synchronize a 50 MHz asynchronous event with a roughly 350 MHz > clock, > and you allow only 1.2 ns for clock-to-out plus set-up time plus routing > to the flip-flop in the adjacent CLB, your design will go metastable > very often; the Mean Time Between Failure will be about 0.1 ms. > But watch what happens when the timing gets more relaxed: > Changing the total delay of 1.2ns to > 1.4 ns leads to MTBF=30 ms > 1.6 ns leads to MTBF= 6 sec > 1.8 ns leads to MTBF= 20 min > 2.0 ns leads to MTBF= 4000 min = 66 hrs > 2.2 ns leads to MTBF= 13,000 hrs = 18 months > 2.4 ns leads to MTBF= 3,600 months = 300 years > 2.6 ns leads to MTBF= 60,000 years > 2.8 ns leads to MTBF= 12 million years > > In other words, you can synchronize ~50 MHz with a 350 MHz clock, take > advantage of the difference between the inherent 1.2 ns and the 350 MHz > clock period of 2.8 ns, and your design will exceed the allowed > propagation delay of one clock period only once every 12 million years. > > For lower clock rates and less frequent asynchronous events, MTBF > increases with the inverse of the product of the two frequencies, i.e. > for a 100 MHz clock synchronizing a ~ 10 MHz asynchronous event, > multiply the MTBF by a factor 3.5 x 5 = 17.5 > More details will be published soon. > > The lack of modern quantative data has been a thorn in my side, and I > want to let you know these encouraging results immediately. > I think we can say that modern CMOS flip-flops recover extremely fast > from any metastable event. :-) > I want to thank Yiding Wu for his enthusiastic help and patience doing > these measurements. > Peter Alfke, Xilinx Applications --------------F4B1AC24AB158F3B66864746 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Let me point out a misleading sentence in my previous posting:

"For lower clock rates and less frequent asynchronous events, MTBF
increases with the inverse of the product of the two frequencies..."

This is not correct, it is the frequency of any specific metastable delay that increases with the product of clock and input frequency.
For the more practical case, where you are concerned about (not) exceeding a full clock period, things are much better, since you get the benefit of the longer clock period.

In my example, a 350 MHz clock synchronizing a 50 MHz input, the data connection between the input flip-flop and a following flip-flop clocked by the same clock will result in an error statistically once every 12 million years.

If you lower the clock frequency to 250 MHz, you gain more than 1 ns in clock period, which means five multiplications by 200. That makes the MTBF  320 billion times larger, i.e. roughly 4 billion billion years ( 4 exp18 ).
That is roughly 200 million times the highest estimate for the life of the Universe (20 billion years) or about a billion times the age of our dear old planet (4 billion years).

Most people would call that a very low probability. Brave souls might even dare to call it zero.

Metastability is real, but its impact on modern CMOS logic has been highly exaggerated.
It's nice to finally have hard data to prove that.

Peter Alfke, Xilinx Applications
for the age of the universe, click on
http://www.astro.ucla.edu/~wright/age.html
================================================================

Peter Alfke wrote:

We finally got around to measuring metastabity.
We used the CLB flip-flops in our newest Virtex-IIPro device (130 nm
technolgy, 1.5 Vcc) and clocked them at around 350 MHz with an
asynchronous input of roughly 50 MHz. This should represent agressive
modern operating conditions.
We then measured the number of metastable events per minute as a
function of the time between clocking the flip-flop under test, and a
variable clock delay at the observation flip-flop that checks for
metastable events. This method is described in detail in XAPP094, and I
first used and documented it in 1988 (!). The concept seems to have
passed the test of time.

Here are the measured results:
Metastable events for a clock-to-clock delay of
1300 ps:  ~ 30,000 errors per minute
1400 ps: ~ 2,000 errors per minute
1500 ps: ~ 100 errors per minute
1600 ps:  = 10 errors per minute

These are short-time measurements of a statistical event, but I am
willing to estimate that the time between metastable events increases by
a factor of roughly 200 for every 200 picoseconds of extra delay between
the two clocks.

That leads to the following extrapolation:
If you synchronize a 50 MHz asynchronous event with a roughly 350 MHz
clock,
and you allow only 1.2 ns for clock-to-out plus set-up time plus routing
to the flip-flop in the adjacent CLB, your design will go metastable
very often; the Mean Time Between Failure will be about  0.1 ms.
But watch what happens when the timing gets more relaxed:
Changing the total delay of 1.2ns to
1.4 ns leads to MTBF=30 ms
1.6 ns leads to MTBF= 6 sec
1.8 ns leads to MTBF= 20 min
2.0 ns leads to MTBF=  4000 min = 66 hrs
2.2 ns leads to MTBF=  13,000 hrs = 18 months
2.4 ns leads to MTBF= 3,600 months = 300 years
2.6 ns leads to MTBF= 60,000 years
2.8 ns leads to MTBF= 12 million years

In other words, you can synchronize ~50 MHz with a 350 MHz clock, take
advantage of the difference between the inherent 1.2 ns and the 350 MHz
clock period of 2.8 ns, and your design will exceed the allowed
propagation delay of one clock period only once every 12 million years.

For lower clock rates and less frequent asynchronous events, MTBF
increases with the inverse of the product of the two frequencies, i.e.
for a 100 MHz clock synchronizing a ~ 10 MHz asynchronous event,
multiply the MTBF by a factor 3.5 x 5 = 17.5
More details will be published soon.

The lack of modern quantative data has been a thorn in my side, and I
want to let you know these encouraging results immediately.
I think we can say that modern CMOS flip-flops recover extremely fast
from any metastable event.  :-)
I want to thank Yiding Wu for his enthusiastic help and patience doing
these measurements.
Peter Alfke, Xilinx Applications

--------------F4B1AC24AB158F3B66864746-- ###### Message-ID: <3D7B1FFC.A5F5742B@algor.co.uk> From: Rick Filipkiewicz X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers, even better! References: <3D794527.2CF5AA@xilinx.com> <3D7A75D3.D65535CC@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: MIPS Technologies (UK) Ltd Cache-Post-Path: mudchute.algor.co.uk!unknown@poplar.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 57 Date: Sun, 08 Sep 2002 11:01:32 +0100 NNTP-Posting-Host: 62.254.210.129 X-Complaints-To: abuse@ntlworld.com X-Trace: newsfep2-win.server.ntli.net 1031479293 62.254.210.129 (Sun, 08 Sep 2002 11:01:33 BST) NNTP-Posting-Date: Sun, 08 Sep 2002 11:01:33 BST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!newspeer1-gui.server.ntli.net!ntli.net!newsfep2-win.server.ntli.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20723 Peter Alfke wrote: > Let me point out a misleading sentence in my previous posting: > > "For lower clock rates and less frequent asynchronous events, MTBF > increases with the inverse of the product of the two frequencies..." > > This is not correct, it is the frequency of any specific metastable > delay that increases with the product of clock and input frequency. > For the more practical case, where you are concerned about (not) > exceeding a full clock period, things are much better, since you get > the benefit of the longer clock period. > > In my example, a 350 MHz clock synchronizing a 50 MHz input, the data > connection between the input flip-flop and a following flip-flop > clocked by the same clock will result in an error statistically once > every 12 million years. > > If you lower the clock frequency to 250 MHz, you gain more than 1 ns > in clock period, which means five multiplications by 200. That makes > the MTBF 320 billion times larger, i.e. roughly 4 billion billion > years ( 4 exp18 ). > That is roughly 200 million times the highest estimate for the life of > the Universe (20 billion years) or about a billion times the age of > our dear old planet (4 billion years). > > Most people would call that a very low probability. Brave souls might > even dare to call it zero. > > Metastability is real, but its impact on modern CMOS logic has been > highly exaggerated. > It's nice to finally have hard data to prove that. > > Peter Alfke, Xilinx Applications > for the age of the universe, click on > http://www.astro.ucla.edu/~wright/age.html > ================================================================ > This means, roughly, that if your critical path, the one that just squeaks past STA, is from a synchroniser then you're in trouble - otherwise not. On another note: (1) We now have a number of Xilinx metastab data points - XC3K, XC4K, V2Pro. (2) I believe its been said before that the metastab resolution time (the x200/200ps figure above) depends on the "speed of the master latch"; which in turn depends on both the FF design and the process geometry. Is it not possible to combine these to get an estimate for Virtex-E ? ###### Message-ID: <3D7B7210.852F0F77@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,de,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers, even better! References: <3D794527.2CF5AA@xilinx.com> <3D7A75D3.D65535CC@earthlink.net> <3D7B1FFC.A5F5742B@algor.co.uk> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 33 Date: Sun, 08 Sep 2002 15:51:27 GMT NNTP-Posting-Host: 209.179.192.146 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1031500287 209.179.192.146 (Sun, 08 Sep 2002 08:51:27 PDT) NNTP-Posting-Date: Sun, 08 Sep 2002 08:51:27 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!freenix!proxad.net!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20726 Rick Filipkiewicz wrote: > This means, roughly, that if your critical path, the one that just > squeaks past STA, is from a synchroniser then you're in trouble - > otherwise not. Yes, "don't do that". BTW, we will also measure the input flip-flop in the IOB. > On another note: > > (1) We now have a number of Xilinx metastab data points - XC3K, XC4K, > V2Pro. > > (2) I believe its been said before that the metastab resolution time > (the x200/200ps figure above) depends on the "speed of the master > latch"; which in turn depends on both the FF design and the process > geometry. Yes > Is it not possible to combine these to get an estimate for Virtex-E ? I will much rather do the measurements on Virtex-II, VirtexE and Spartan-II, now that we have a working set-up. Virtex-II, the biggest subject of new designs, is especially important. It has been a fun week, actually only three days... Peter Alfke, Xilinx Applications ###### Message-ID: <3D7C0629.2943@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: Metastability numbers, even better! References: <3D794527.2CF5AA@xilinx.com> <3D7A75D3.D65535CC@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 21 Date: Mon, 09 Sep 2002 14:23:37 +1200 NNTP-Posting-Host: 203.79.98.206 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1031538354 203.79.98.206 (Mon, 09 Sep 2002 14:25:54 NZST) NNTP-Posting-Date: Mon, 09 Sep 2002 14:25:54 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!news-out.newsfeeds.com!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20732 Peter Alfke wrote: > > If you lower the clock frequency to 250 MHz, you gain more than 1 ns > in clock period, which means five multiplications by 200. That makes > the MTBF 320 billion times larger, i.e. roughly 4 billion billion > years ( 4 exp18 ). > That is roughly 200 million times the highest estimate for the life of > the Universe (20 billion years) or about a billion times the age of > our dear old planet (4 billion years). > > Most people would call that a very low probability. Brave souls might > even dare to call it zero. What would happen if you considered the electrons involved as quantized charges - would there not be a limit, beyond which you cannot 'balance' the register any more, and so cannot extend the lifetime any further ? Knowing the nQ/fQ in the gates, should give an electron count ? -jg ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: Mon, 09 Sep 2002 12:39:13 -0700 Organization: Xilinx,Inc Lines: 64 Message-ID: <3D7CF8E2.6FE7242E@xilinx.com> References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Falk Brunner Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!newshub.sdsu.edu!newspeer.cts.com!130.94.89.10.MISMATCH!news-out.spamkiller.net!propagator-la!news-in.superfeed.net!news-in-la.newsfeeds.com!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:20776 Falk Brunner wrote: > Hmmm. > If I got it right, you have a free running clock with 50 MHz and another > free running 350 Mhz clock for sampling. > Both clock are NOT related to each other True, one is a canned crystal oscillator of 50 MHz, the other one is an hp pulse generator. Since the measurements give repeatable results that fit the exponential relationship between extra settling time and MTBF, I like this method. But I will look up the Howard Johnson "bible", it's right here on my bookshelf. Peter > So how is this handeled in the setup? The application note just speaks about > unrelated clocks. But with such a setup, is it possible to reproduce the > measurement results? May it be possible that you just catch a (un)lucky > canned oscillator and measure house numbers, since the "crash" frequency is > totaly random. No, I vary the hp output frequency around 350 MHz. We have changed the chip-internal design, giving us different interconnect delays, and the results have moved accordingly. All very repeatable, albeit statistical. > > In the "bible" of Graham & Johnson, there is a circuit for metastability > experiments. Why not using this one (or something similar). In my eyes, this > cicuit gives much more possibilities to do repeatable mesurements. Mine are repeatable already. > Yes, the > original circuit produces metastable events with every sampling edge, No, I sample 50 MHz with a >300 MHz clock. Most samples are naturally far away from the metastability-inducing window. > which > is not the case in real applications. What happens in a "real" application? I think I am close to a real synchronizing case. > But wouldnt it be better to do a > maximum stress test and after this scale down to real application numbers, I think that's what I am doing, when the circuit goes matastable many times a minute... Mit freundlichen Gruessen, that's what MfG stands for in German :-) Peter > > just as it is done with power consumtion (average toggle rate)? > > Just some ideas. > > -- > MfG > Falk ###### From: nospam Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: Mon, 09 Sep 2002 20:45:52 +0100 Organization: http://extra.newsguy.com Lines: 31 Message-ID: References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> NNTP-Posting-Host: p-045.newsdawg.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.92/32.572 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!pln-e!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews2 Xref: chonsp.franklin.ch comp.arch.fpga:20773 "Falk Brunner" wrote: >"Peter Alfke" schrieb im Newsbeitrag >news:3D7C176F.D6CA850F@earthlink.net... > >> If I can decypher your drawing, thta's exactly what we use for measuring. >> Look at XAPP094... > >Hmmm. >If I got it right, you have a free running clock with 50 MHz and another >free running 350 Mhz clock for sampling. >Both clock are NOT related to each other by deriving them from the same >clock source or by use of a PLL. >In this case, the phase drift between the two clocks is undefined, random. I don't see it matters. As long as the clocks beat and the beat period is small compared to the measurement time. During a measurement period the number of times both clock edges occur within a given metastability window only depends on the ratio of the clocks, a few ppm off frequency gives a few ppm measurement error. I would be concerned about the clocks interacting with each other, a minute amount of jitter induced in one clock by the other could really distort the measurement. I think I would keep the clock generators physically separate with the device under test in the middle that way the device gets to see both clocks before the generators get to see each other. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: Mon, 09 Sep 2002 13:19:05 -0700 Organization: Xilinx,Inc Lines: 15 Message-ID: <3D7D0239.D75382A5@xilinx.com> References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" 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!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!news-out.visi.com!hermes.visi.com!attcg2!attdv2!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20774 nospam wrote: > > I think I would keep the clock generators physically separate with the > device under test in the middle that way the device gets to see both clocks > before the generators get to see each other. Sure, done that. Remember, I have been at this, on and off, for 14 years... Ciao Peter Alfke ###### Message-ID: <3D7D0B24.36C0@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: Metastability numbers References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> <3D7CF8E2.6FE7242E@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 22 Date: Tue, 10 Sep 2002 08:57:08 +1200 NNTP-Posting-Host: 203.79.98.196 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1031605165 203.79.98.196 (Tue, 10 Sep 2002 08:59:25 NZST) NNTP-Posting-Date: Tue, 10 Sep 2002 08:59:25 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!news.stealth.net!news.stealth.net!telocity-west!TELOCITY!news-out.spamkiller.net!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20777 Peter Alfke wrote: > Falk Brunner wrote: > True, one is a canned crystal oscillator of 50 MHz, the other one is an hp > pulse generator. > > So how is this handeled in the setup? The application note just speaks about > > unrelated clocks. But with such a setup, is it possible to reproduce the > > measurement results? May it be possible that you just catch a (un)lucky > > canned oscillator and measure house numbers, since the "crash" frequency is > > totaly random. > > No, I vary the hp output frequency around 350 MHz. We have changed the > chip-internal design, giving us different interconnect delays, and the results > have moved accordingly. All very repeatable, albeit statistical. Maybe you should document this as 50Mhz[Xtal], and 350MHz+dF[Generator] - one problem with saying 50MHz and 350MHz is the (possible) inference of a x7 integer ratio. or quoting as : 50.000Mhz and 350.010MHz ? -jg ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: Mon, 09 Sep 2002 14:09:47 -0700 Organization: Xilinx,Inc Lines: 26 Message-ID: <3D7D0E1C.D15C83F1@xilinx.com> References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Falk Brunner Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!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:20775 Falk Brunner wrote: > In the "bible" of Graham & Johnson, there is a circuit for metastability > experiments. Why not using this one (or something similar). In my eyes, this > cicuit gives much more possibilities to do repeatable mesurements. With all due respect to Howard Johnson ( we know each other and have met twice ), his book is nine years old, and his examples are even older. Maybe he could successfully conduct such experiments when natural delays were 10 ns, and even longer in the case of TTL. Now we are talking about hundred picoseconds, and I see no way of balancing a circuit under these circumstances. And why even try to do it, when the statistical approach gives repeatable and justifyable results ? It worked in 1988 and 1995. Later I had a problem and got discouraged. Now, with much better clocking structures, we do it again. It's tough to argue against a successful set-up, isn't it? But, "this is a free country" and the chips are programmable. Anybody with minimal resources is capable to verify the results, or come up with a different set-up. I am amazed that some university hasn't done it already. I haven't heard from Washington U. (Dick Chaney) lately, they sure know a lot about metastability... Peter Alfke, Xilinx Applications ###### From: nospam Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: Tue, 10 Sep 2002 02:13:01 +0100 Organization: http://extra.newsguy.com Lines: 16 Message-ID: References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> <3D7D0239.D75382A5@xilinx.com> NNTP-Posting-Host: p-558.newsdawg.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.92/32.572 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.news2me.com!arclight.uoregon.edu!logbridge.uoregon.edu!pln-e!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews2 Xref: chonsp.franklin.ch comp.arch.fpga:20842 Peter Alfke wrote: > > >nospam wrote: > >> >> I think I would keep the clock generators physically separate with the >> device under test in the middle that way the device gets to see both clocks >> before the generators get to see each other. > >Sure, done that. >Remember, I have been at this, on and off, for 14 years... So I didn't do so bad for 10 minutes of thought then :) ###### From: "glen herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> Subject: Re: Metastability numbers 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.228.58.87 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc02 1031633248 12.228.58.87 (Tue, 10 Sep 2002 04:47:28 GMT) NNTP-Posting-Date: Tue, 10 Sep 2002 04:47:28 GMT Organization: AT&T Broadband Date: Tue, 10 Sep 2002 04:47:28 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!wn2feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!sccrnsc02.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20798 "Peter Alfke" wrote in message news:3D7C176F.D6CA850F@earthlink.net... > (snip) > BTW, the billions of years were somwhat tongue-in-cheek. But that's what you > get with exponential functions...If there is no better explanation, I take > math anytime. Do you consider the case where an alpha particle comes through at just the wrong time? When your MTBF gets that long, it might matter. I have noticed MTBF for hard disk drives in the hundreds of years range, yet I don't think anyone would still want to use one then. I do remember when I used to use mainframe machines, and they would report the current value of the MTBF on the wall for all to see. -- glen ###### From: "glen herrmannsfeldt" Newsgroups: comp.arch.fpga References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> Subject: Re: Metastability numbers Lines: 27 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: <5Sef9.267430$aA.46679@sccrnsc02> NNTP-Posting-Host: 12.228.58.87 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc02 1031633409 12.228.58.87 (Tue, 10 Sep 2002 04:50:09 GMT) NNTP-Posting-Date: Tue, 10 Sep 2002 04:50:09 GMT Organization: AT&T Broadband Date: Tue, 10 Sep 2002 04:50:10 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!logbridge.uoregon.edu!ihnp4.ucsd.edu!sdd.hp.com!usc.edu!attla2!ip.att.net!attbi_feed3!attbi_feed4!attbi.com!sccrnsc02.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20797 "Falk Brunner" wrote in message news:aliref$1pp18i$1@ID-84877.news.dfncis.de... > "Peter Alfke" schrieb im Newsbeitrag > news:3D7C176F.D6CA850F@earthlink.net... > > > If I can decypher your drawing, thta's exactly what we use for measuring. > > Look at XAPP094... > > Hmmm. > If I got it right, you have a free running clock with 50 MHz and another > free running 350 Mhz clock for sampling. > Both clock are NOT related to each other by deriving them from the same > clock source or by use of a PLL. > In this case, the phase drift between the two clocks is undefined, random. > What does it mean? I remember from the TTL days someone explaining that, I believe it is the 74S124, dual oscillator, you could only use one because they would phase lock even if you didn't want them to. Keeping two oscillators from locking is not always easy. -- glen ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: Tue, 10 Sep 2002 05:30:50 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> X-Complaints-To: abuse@supernews.com Lines: 55 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!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:20817 >How about testing this as well : >Check the lifetime curve for double edged syncroniser: > > +---------+----------< CLK > | +---+ | +---+ > +-|> | +-o|> | > | | | | >----|D Q|------|D Q|--- Qo > | | | | > +---+ +---+ [note bubble on second clock input] What are you trying to do? I don't see any point in testing this circuit. That is I think we understand things well enough to predict the answer. I'd much rather have Peter collecting data at low voltage and high temperatures or working on other types of chips. Sure, if he runs out of other things to try, checking this would be good. This is potentially interesting if CLK is running slowly. Peter's numbers show that you need ~2000 pS, and that assumes tight routing. If your clock is twice that and you know it's a 50-50 duty cycle, then the above circuit is safe and it saves a half cycle. I would normally put the bubble on the first FF. This way you only get a 1/2 cycle for Qo to get to the rest of the logic and that might be a long path. (But the tools should be able to check that.) In general, being tricky around metastability is asking for troubles. It's much safer to have a clean circuit that is easy to check by eye. If you try to be tricky, you might forget things like the 50-50 clock requirement, or somebody who takes over your design might miss it... Yes, I've done things like the above to save a half cycle. But I'm real careful because the first time we did that we got burned. That was back in the old TTL days and the chip we picked to get the falling edge clock was no good for metastability. (And we thought we understood metastability.) -- 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: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> Subject: Re: Metastability numbers Lines: 45 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.228.58.87 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc01 1031720875 12.228.58.87 (Wed, 11 Sep 2002 05:07:55 GMT) NNTP-Posting-Date: Wed, 11 Sep 2002 05:07:55 GMT Organization: AT&T Broadband Date: Wed, 11 Sep 2002 05:07:55 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.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_feed4!attbi.com!sccrnsc01.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:20847 "Hal Murray" wrote in message news:unr0sa79g80m4f@corp.supernews.com... (snip of diagram impossible to read on a proportionally spaced font) > > What are you trying to do? > > I don't see any point in testing this circuit. That is I > think we understand things well enough to predict the > answer. > > I'd much rather have Peter collecting data at low voltage and > high temperatures or working on other types of chips. Sure, > if he runs out of other things to try, checking this would > be good. > > > This is potentially interesting if CLK is running slowly. > Peter's numbers show that you need ~2000 pS, and that assumes > tight routing. If your clock is twice that and you know it's a > 50-50 duty cycle, then the above circuit is safe and it saves > a half cycle. > > I would normally put the bubble on the first FF. This way > you only get a 1/2 cycle for Qo to get to the rest > of the logic and that might be a long path. (But the tools > should be able to check that.) > > > In general, being tricky around metastability is asking > for troubles. It's much safer to have a clean circuit > that is easy to check by eye. If you try to be tricky, > you might forget things like the 50-50 clock requirement, > or somebody who takes over your design might miss it... > This reminds me of the 8086, 8087, 8088 which use a 33% duty cycle clock. I wonder which tricks they used. Note that the 80287 also uses a 33% duty cycle clock, asynchronous to the 80286's 50% clock. -- glen ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Metastability numbers Date: Wed, 11 Sep 2002 08:05:36 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3D794527.2CF5AA@xilinx.com> <3D7C04C4.73F2@designtools.co.nz> <3D7C176F.D6CA850F@earthlink.net> <3D7C3B58.512E@designtools.co.nz> X-Complaints-To: abuse@supernews.com Lines: 54 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:20857 > I meant this as a alternative for the first, single D register - ie the > clock domain syncroniser - wondering if there was benefit in two > registers, over one with a longer delay. I didn't see any comments on this so I'll take a try... Suppose you have the classic pair of FFs as a synchronizer. Use that as a straw man, a base case for goodness. Now suppose you put some logic in there. How about a simple AND gate. Does that make things better? Take the simple case of tying one side of the AND gate high. That prop time through the gate subtracts from the metastability settling time. That settling time is in an exponent in the goodness formula. It's hard to beat something in an exponent. Go back and check Peter's numbers that started this thread. More time is good. Kludgery is not good. Anything other than a wire is probably kludgery. You might be able to do something by putting a FF in there. But that takes an extra clock cycle. Then you would be better off with a slower clock or clocking on every other cycle. Suppose you clocked the middle FF on the falling edge so it didn't cost you an extra cycle. Now the clock-out time through the FF gets subtracted off from the settling time. Again, that's exponential and a step in the wrong direction. Back to the simple AND gate... If things are going to get better, the other side of that AND gate has to be connected to something "good". Well, if we could do that, we could solve the metastability problem. You have to take my word for it that we can't solve that. The classic picture is rolling a ball over a bump. If you push the ball hard it easily goes over. If you push it gently, it goes up to the bump and bounces off. But in the middle it might get stuck on top for a while. The important point about metastability is that you can't win. There is some time or some energy-of-push for the ball that is the "bad" case that turns into metastability. There is no free lunch. Fixing metastability takes time. -- 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.