From: "Xanatos" Newsgroups: comp.arch.fpga Subject: Sync Reset without clocks Lines: 20 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Thu, 10 Oct 2002 23:46:51 GMT NNTP-Posting-Host: 24.157.159.133 X-Complaints-To: abuse@rogers.com X-Trace: news02.bloor.is.net.cable.rogers.com 1034293611 24.157.159.133 (Thu, 10 Oct 2002 19:46:51 EDT) NNTP-Posting-Date: Thu, 10 Oct 2002 19:46:51 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news.stealth.net!news.stealth.net!prodigy.com!rip!newsfeeds-atl2!news.webusenet.com!news03.bloor.is.net.cable.rogers.com!news02.bloor.is.net.cable.rogers.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21888 Hey All, The subject is probably a tad confusing. Anyways, here is my problem: I have 2 input clocks from an external sources. There is one chip reset, which is sync to one of the input clocks. The reset should be sync'd to the second clock domain (#1 to avoid metastability issues). However, while clock #1 always exists, clock #2 may not occur until after the reset. So, when the second clock starts up, the reset has already been negated, and I've missed the @negedge of the reset. Any hints or suggestions? Cheers, Xanatos ###### From: "Xanatos" Newsgroups: comp.arch.fpga References: <3DA61E31.6042CFCB@mail.com> Subject: Re: Sync Reset without clocks Lines: 44 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <09np9.8830$vX.6320@news04.bloor.is.net.cable.rogers.com> Date: Thu, 10 Oct 2002 22:27:08 GMT NNTP-Posting-Host: 24.157.159.133 X-Complaints-To: abuse@rogers.com X-Trace: news04.bloor.is.net.cable.rogers.com 1034288828 24.157.159.133 (Thu, 10 Oct 2002 18:27:08 EDT) NNTP-Posting-Date: Thu, 10 Oct 2002 18:27:08 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!proxad.net!63.210.96.66.MISMATCH!ps01-chi1!newsfeeds-atl2!news.webusenet.com!news03.bloor.is.net.cable.rogers.com!news04.bloor.is.net.cable.rogers.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21882 Super. Thanks John. -Xanatos "John_H" wrote in message news:3DA61E31.6042CFCB@mail.com... > Use two registers to store the reset signal. The first register clears after n > clock #1 events and the other register clears after m clock #2 events. A Xilinx > SRL can be configured to give a nice delay so the power-on allows everything to > be ready to go by the time the reset flop deasserts for either time domain. > > The technique should provide the delays you need to use the asynchronous > @negedge or the synchronous logical version. > > > Xanatos wrote: > > > Hey All, > > > > The subject is probably a tad confusing. Anyways, here is my problem: > > > > I have 2 input clocks from an external sources. There is one chip reset, > > which is sync to one of the input clocks. > > > > The reset should be sync'd to the second clock domain (#1 to avoid > > metastability issues). However, while clock #1 always exists, clock #2 may > > not occur until after the reset. > > > > So, when the second clock starts up, the reset has already been negated, and > > I've missed the @negedge of the reset. > > > > Any hints or suggestions? > > > > Cheers, > > Xanatos > ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Sync Reset without clocks Date: Thu, 10 Oct 2002 17:19:58 -0700 Organization: Xilinx,Inc Lines: 39 Message-ID: <3DA6192E.9C43A78E@xilinx.com> References: 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: Xanatos 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!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!12.120.28.17!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21868 You mentioned metastability, and that caught my attention. Metastability is a reality, but it (and the fear of it) is highly overrated. We recently tested Virtex-IIPro flip-flops, made on 130 nm technology. You might call that cutting edge technology, but not exotic. When a 330 MHz clock synchronized a ~50 MHz input, there was a 200 ps extra metastable delay ( causing a clock-to-out + short routing + set-up total of 1.5 ns) once every second. That translates into a metastable capture window that has a width of 3 ns divided by 100 million ( since we looked at both edges of the 50 MHz signal). So the window for a 200 ps extra delay is 0.03 femtoseconds. If you can tolerate 500 ps more, the MTBF increases 100 000 times, and the capture window gets that much smaller. Metastability is a real, but highly overrated problem. Peter Alfke, Xilinx Applications Xanatos wrote: > Hey All, > > The subject is probably a tad confusing. Anyways, here is my problem: > > I have 2 input clocks from an external sources. There is one chip reset, > which is sync to one of the input clocks. > > The reset should be sync'd to the second clock domain (#1 to avoid > metastability issues). However, while clock #1 always exists, clock #2 may > not occur until after the reset. > > So, when the second clock starts up, the reset has already been negated, and > I've missed the @negedge of the reset. > > Any hints or suggestions? > > Cheers, > Xanatos ###### Message-ID: <3DA61E31.6042CFCB@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Sync Reset without clocks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 30 Date: Fri, 11 Oct 2002 00:41:19 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1034296879 192.65.17.17 (Thu, 10 Oct 2002 18:41:19 MDT) NNTP-Posting-Date: Thu, 10 Oct 2002 18:41:19 MDT Organization: Xerox Officeprinting NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!logbridge.uoregon.edu!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21931 Use two registers to store the reset signal. The first register clears after n clock #1 events and the other register clears after m clock #2 events. A Xilinx SRL can be configured to give a nice delay so the power-on allows everything to be ready to go by the time the reset flop deasserts for either time domain. The technique should provide the delays you need to use the asynchronous @negedge or the synchronous logical version. Xanatos wrote: > Hey All, > > The subject is probably a tad confusing. Anyways, here is my problem: > > I have 2 input clocks from an external sources. There is one chip reset, > which is sync to one of the input clocks. > > The reset should be sync'd to the second clock domain (#1 to avoid > metastability issues). However, while clock #1 always exists, clock #2 may > not occur until after the reset. > > So, when the second clock starts up, the reset has already been negated, and > I've missed the @negedge of the reset. > > Any hints or suggestions? > > Cheers, > Xanatos ###### From: kayrock66@yahoo.com (Jay) Newsgroups: comp.arch.fpga Subject: Re: Sync Reset without clocks Date: 11 Oct 2002 23:04:25 -0700 Organization: http://groups.google.com/ Lines: 7 Message-ID: References: NNTP-Posting-Host: 66.81.72.185 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1034402665 8472 127.0.0.1 (12 Oct 2002 06:04:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 12 Oct 2002 06:04:25 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.frii.net!newsfeed.frii.net!HSNX.atgi.net!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21920 Ya, in an FPGA, use async reset. Besides, using sync resets sucks up one of your 4 inputs for your LUTs feeding resetable flops. > Any hints or suggestions? > > Cheers, > Xanatos ###### Message-ID: <3DA82568.76F5C883@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: Sync Reset without clocks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 56 Date: Sat, 12 Oct 2002 13:37:13 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034429833 68.15.41.165 (Sat, 12 Oct 2002 09:37:13 EDT) NNTP-Posting-Date: Sat, 12 Oct 2002 09:37:13 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21941 I heartily disagree. First, modern FPGAs have an option for synchronous direct resets, so you don't lose a LUT pin. Even in the older families, we used sync resets where possible, and when we couldn't we did the async resets to small amounts at a time (eg one accumulator) and drove it with a flip-flop floorplanned to be right where it is needed. The problem with async resets is the critical timing is from driver of the reset pin THROUGH the flip flop you are resetting and to the next flip-flop in the chain. Not only that, but the timing tools did not consistently find that timing path. As to the original inquiry, you need to work up a circuit that holds the reset in the first clock domain until the reset in the second domain also happens, something like this: process(clk1) begin if rising_edge(clk1) then if reset_input='1' then reset1<='1'; elsif resync_reset2='1' then reset1<='0'; end if; resync_reset2<= reset2; end if; end process; process(clk2) begin if rising_edge(clk2) then reset2<=reset1; --resync reset to this clock domain end if; end process; Jay wrote: > Ya, in an FPGA, use async reset. Besides, using sync resets sucks up > one of your 4 inputs for your LUTs feeding resetable flops. > > > Any hints or suggestions? > > > > Cheers, > > Xanatos -- --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: John_H Newsgroups: comp.arch.fpga Subject: Re: Sync Reset without clocks Date: Sat, 12 Oct 2002 11:06:41 -0700 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <3DA864B1.4040506@mail.com> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@supernews.com Lines: 39 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21961 Actually, a synchronous reset in the Xilinx architecture can (though doesn't have to) be implemented through the S/R line. No LUT input is used up. In the original post, a mention of @nedgedge resetn suggests the actual implementation would be an asynchronous control to each flop, BUT... When a reset is applied without any coherence to the local clocks, some elements in the design will release the reset in one clock period, the other elements will release on the next. By registering the reset signals in the local clock domains, the reset will be applied to all elements within that clock domain in one clock cycle and be subject to the timing constraints for the clock period constraint. The timing analysis is clean in the Xilinx design flow for synchronous resets without doubt. There *may* be a timing analysis switch for the async reset but I think I'm confusing this with propagating timing *through* an async reset rather than meeting the reset inactive setup time. Thankfully, many designs are tolerant of a reset inactive taking two (or more?) clock cycles for an async reset that is truly asynchronous to the clock domain. For those who are concerned about dependencies - getting a state machine out of alignment without a "safe" return-to-idle condition for instance - proper attention paid to the reset timing is a very good thing. Jay wrote: > Ya, in an FPGA, use async reset. Besides, using sync resets sucks up > one of your 4 inputs for your LUTs feeding resetable flops. > > >>Any hints or suggestions? >> >>Cheers, >>Xanatos >> ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Sync Reset without clocks Date: Tue, 15 Oct 2002 07:57:11 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3DA6192E.9C43A78E@xilinx.com> X-Complaints-To: abuse@supernews.com Lines: 18 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news.stealth.net!news.stealth.net!telocity-west!TELOCITY!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:22030 >You mentioned metastability, and that caught my attention. >Metastability is a reality, but it (and the fear of it) is highly overrated. ... >Metastability is a real, but highly overrated problem. When is Xilinx going to put numbers into the data sheets? Worst case? I wouldn't say "overrated". It might be less of a problem now than it was a while ago. But users demands/expectations are going up too. -- 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. ###### Reply-To: "Nial Stewart" From: "Nial Stewart" Newsgroups: comp.arch.fpga References: <3DA864B1.4040506@mail.com> Subject: Re: Sync Reset without clocks Date: Tue, 15 Oct 2002 16:25:59 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Lines: 33 Message-ID: <3dac2f9e$0$5811$fa0fcedb@lovejoy.zen.co.uk> Organization: Zen Internet NNTP-Posting-Host: 217.155.72.198 X-Trace: 1034694558 lovejoy.zen.co.uk 5811 217.155.72.198 X-Complaints-To: abuse@zen.co.uk Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!proxad.net!peer1.news.newnet.co.uk!shale.ftech.net!news.ftech.net!peernews.cix.co.uk!zen.net.uk!lovejoy.zen.co.uk.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22033 > By registering the reset > signals in the local clock domains, the reset will be applied to all > elements within that clock domain in one clock cycle and be subject to > the timing constraints for the clock period constraint. John, Does this apply if you synchronise your reset net at the top level and then use it throughout your design with 'standard' asynch reset declarations.... process(clk,rst) begin if(rst = '1') then signal <= reset_val; elsif(rising_edge(clk)) then ..and so on, or do you have to use process(clk) begin if(rising_edge(clk)) then if(rst = '1') then signal <= reset_val; elsif....... ? Nial. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- To email remove spamno from address. ###### Message-ID: <3DAC456C.55C77A9D@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Sync Reset without clocks References: <3DA864B1.4040506@mail.com> <3dac2f9e$0$5811$fa0fcedb@lovejoy.zen.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 61 Date: Tue, 15 Oct 2002 16:42:20 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1034700140 192.65.17.17 (Tue, 15 Oct 2002 10:42:20 MDT) NNTP-Posting-Date: Tue, 15 Oct 2002 10:42:20 MDT Organization: Xerox Officeprinting NewsReader Service 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!logbridge.uoregon.edu!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22039 If the tools do the proper timing analysis for reset inactive to clock setup time, then yes - a registered reset at the top of the hierarchy can be distributed throughout the design as a standard asynchronous reset. The reset signal is synchronous. The reset is applied through an asynchronous mechanism. The reset event is still synchronous. There's a switch in the Xilinx timing analysis - reg_sr_q - which will include the paths for reset-to-clk for both the active and inactive transitions. Without the switch checked (default is off) neither of these paths are included. The activation of reset (timing parameters such as Trq mid-path) isn't so much of an issue for me because I don't have events that would get confused by a reset flop that doesn't propagate to its destination before the next clock since - gosh - the destination's getting reset, too. I would only include the paths through appropriate timing constraints to show me that the reset gets to my register with the appropriate setup (timing parameters such as Trck) to allow my system to start properly after the reset deasserts. Care should be taken that events not controlled by the reset (processor interrupt, for instance) are covered by the timing analysis for the invocation of reset or that the signals are otherwise safe. It's not the cleanest timing analysis from the auto-generated constraints standpoint but I imagine I could get the constraints to look good. Personally, I prefer to stick with true synchronous resets through the synchronous reset mechanism. Nial Stewart wrote: > > By registering the reset > > signals in the local clock domains, the reset will be applied to all > > elements within that clock domain in one clock cycle and be subject to > > the timing constraints for the clock period constraint. > > John, > > Does this apply if you synchronise your reset net at the top level and then > use it throughout your design with 'standard' asynch reset declarations.... > > process(clk,rst) > begin > if(rst = '1') then > signal <= reset_val; > elsif(rising_edge(clk)) then > > ..and so on, or do you have to use > > process(clk) > begin > if(rising_edge(clk)) then > if(rst = '1') then > signal <= reset_val; > elsif....... > > ? > > Nial. > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- To email remove spamno from address. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Sync Reset without clocks Date: Tue, 15 Oct 2002 09:48:20 -0700 Organization: Xilinx,Inc Lines: 103 Message-ID: <3DAC46D4.6102B9D1@xilinx.com> References: <3DA6192E.9C43A78E@xilinx.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AB075A85A52036C41662103A" 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!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.vmunix.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!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:22012 --------------AB075A85A52036C41662103A Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Here are the K2 values for Virtex-IIPro: CLB @1.50V: K2 = 27.2, i.e. 1/K2 = tau = 36.8 picoseconds CLB @1.35V: K2 = 23.3, i.e. 1/K2 = tau = 42.9 picoseconds CLB @1.65V: K2 = 35.7, i.e. 1/K2 = tau = 28.0 picoseconds IOB @1.50V: K2 = 24.4, i.e. 1/K2 = tau = 41.0 picoseconds IOB @1.35V: K2 = 19.24, i.e. 1/K2 = tau = 52.0 picoseconds IOB @1.65V: K2 = 44.05, i.e. 1/K2 = tau = 22.7 picoseconds For each extra 100 ps of acceptable metastable delay, the MTBF increases by a factor 10.3 for CLB @ 1.35 V, or a factor 6.85 for IOB @ 1.35 V. Much better values, of course, at nominal or high Vcc. Klick on http://support.xilinx.com/support/techxclusives/techX-home.htm in early November. Here is the worst-case data point: 50 MHz asynchronous data rate, 330 MHz clock , single-stage synchronizer in IOB, Vcc = 1.35 V: clock-to-Q + short routing + set-up time + metastable delay exceeds clock period once per 30,000 years. At nominal Vcc: once per 100 million years. At a 250 MHz clock rate, delay exceeds clock period less often than once per billion years. Peter Alfke, Xilinx Applications ==================================== Hal Murray wrote: > > When is Xilinx going to put numbers into the data sheets? Worst case? > > I wouldn't say "overrated". It might be less of a problem now > than it was a while ago. But users demands/expectations are going > up too. > > -- > 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. --------------AB075A85A52036C41662103A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Here are the K2 values for Virtex-IIPro:

CLB @1.50V: K2 = 27.2, i.e. 1/K2 = tau = 36.8 picoseconds
CLB @1.35V: K2 = 23.3, i.e. 1/K2 = tau = 42.9 picoseconds
CLB @1.65V: K2 = 35.7, i.e. 1/K2 = tau = 28.0 picoseconds

IOB @1.50V: K2 = 24.4,  i.e. 1/K2 = tau = 41.0 picoseconds
IOB @1.35V: K2 = 19.24, i.e. 1/K2 = tau = 52.0 picoseconds
IOB @1.65V: K2 = 44.05, i.e. 1/K2 = tau = 22.7 picoseconds

For each extra 100 ps of acceptable metastable delay,
the MTBF increases by a factor 10.3 for CLB @ 1.35 V,
or a factor 6.85 for IOB @ 1.35 V.
Much better values, of course, at nominal or high Vcc.

Klick on
http://support.xilinx.com/support/techxclusives/techX-home.htm
in early November.

Here is the worst-case data point:

50 MHz asynchronous data rate, 330 MHz clock , single-stage synchronizer in IOB, Vcc = 1.35 V:
clock-to-Q + short routing + set-up time + metastable delay exceeds clock period once per 30,000 years.

At nominal Vcc: once per 100 million years.

At a 250 MHz clock rate, delay exceeds clock period less often than once per billion years.

Peter Alfke, Xilinx Applications
====================================
Hal Murray wrote:

 
When is Xilinx going to put numbers into the data sheets?  Worst case?

I wouldn't say "overrated".  It might be less of a problem now
than it was a while ago.  But users demands/expectations are going
up too.

--
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.

--------------AB075A85A52036C41662103A--