From: "Theron Hicks" Newsgroups: comp.arch.fpga Subject: glitchless clock enable/disable in spartanII Date: Mon, 28 Jan 2002 16:17:26 -0500 Organization: Michigan State University Lines: 13 Message-ID: NNTP-Posting-Host: dfti.egr.msu.edu 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 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeeds.belnet.be!news.belnet.be!newsfeed.stanford.edu!info1.fnal.gov!nntp.upenn.edu!msunews!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13733 I am looking for some code to define a glitch less clock enable/disable circuit. The clock frequency is 100MHz. What I am trying to say is that I have a counter with a 100MHz clock and I want to avoid runt pulses on the clock. This could either be a clock mux switching between 0 and clock on the output or a "safe" clock enable that would eliminate (or at least minimize) the possibility of metastability. The counter could be asynchronous if that simplifies things. Any ideas, suggestions, sources, etc. Thanks, Theron ###### Message-ID: <3C55E0AE.9070002@quartz.net.nz> From: David Miller Organization: Endace Measurement Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en,en-GB,en-* MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cache-Post-Path: clint.its.waikato.ac.nz!unknown@alba.cs.waikato.ac.nz X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) Lines: 32 Date: Tue, 29 Jan 2002 12:37:18 +1300 NNTP-Posting-Host: 130.217.66.28 X-Complaints-To: newsadmin@xtra.co.nz X-Trace: news.xtra.co.nz 1012261001 130.217.66.28 (Tue, 29 Jan 2002 12:36:41 NZDT) NNTP-Posting-Date: Tue, 29 Jan 2002 12:36:41 NZDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!newsfeed01.tsnz.net!news.xtra.co.nz!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13672 > I am looking for some code to define a glitch less clock > enable/disable circuit. The clock frequency is 100MHz. What I am > trying to say is that I have a counter with a 100MHz clock and I > want to avoid runt pulses on the clock. This could either be a > clock mux switching between 0 and clock on the output or a "safe" > clock enable that would eliminate (or at least minimize) the > possibility of metastability. The counter could be asynchronous if > that simplifies things. Any ideas, suggestions, sources, SpartanIIs have dedicated clock enable inputs on all flops. You should use those rather than gating clocks (which is very bad practice anyway) with logic[1]. Consult your synthesis guide for more info on how to do that in your HDL. Judging from your email address, I assume that you're a student. An interesting exercise is to run the tool fpga_editor, create an empty, small fpga and play with the CLBs. You can learn alot about how the fpgas actually implement logic in this way. [1] PAR will complain loudly if you do this, because you are no longer able to use dedicated clock routing resources so, glitches aside, you'll have big problems with skew. -- David Miller, BCMS (Hons) | When something disturbs you, it isn't the Endace Measurement Systems | thing that disturbs you; rather, it is Mobile: +64-21-704-djm | your judgement of it, and you have the Fax: +64-21-304-djm | power to change that. -- Marcus Aurelius ###### Message-ID: <3C5638AA.13435A95@earthlink.net> From: Peter Alfke X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 27 Date: Tue, 29 Jan 2002 05:52:47 GMT NNTP-Posting-Host: 216.244.43.53 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1012283567 216.244.43.53 (Mon, 28 Jan 2002 21:52:47 PST) NNTP-Posting-Date: Mon, 28 Jan 2002 21:52:47 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Mon, 28 Jan 2002 21:52:47 PST (newsmaster1.prod.itd.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!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13680 The worst thing you might build would be a synchronous counter with the clock enable fed to every bit in parallel. Don't do that! My sugestion is to build any counter you want, synchronous or ripple, but have a one-bit prescaler toggle-flip-flop generate the clock. This prescaler must use the Xilinx CE feature, which really is a multiplexer in the D input. Since CE changes asynchronously, but does not affect the clock, you never get a runt clock pulse, but you might ( once in a blue moon) get a longer Q delay. It will be many thousands (millions?) of years between the worst happening, when this extra metastable delay swallows one incoming clock tick. Peter Alfke, Xilinx Applications ================================== Theron Hicks wrote: > I am looking for some code to define a glitch less clock enable/disable > circuit. The clock frequency is 100MHz. What I am trying to say is that I > have a counter with a 100MHz clock and I want to avoid runt pulses on the > clock. This could either be a clock mux switching between 0 and clock on > the output or a "safe" clock enable that would eliminate (or at least > minimize) the possibility of metastability. The counter could be > asynchronous if that simplifies things. Any ideas, suggestions, sources, > etc. > > Thanks, > Theron ###### From: Theron Hicks Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Tue, 29 Jan 2002 09:25:47 -0500 Organization: Michigan State University Lines: 41 Message-ID: <3C56B0EB.E1E93CAC@egr.msu.edu> References: <3C5638AA.13435A95@earthlink.net> NNTP-Posting-Host: dfti.egr.msu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!solaris.cc.vt.edu!news.vt.edu!msunews!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13652 Peter, Your response is probably what I would have done, but I wanted some verification that I hadn't missed a better solution. Your timely and accurate response is one of the reasons why I personally rate Xilinx so high. (The product quality doesn't hurt either.) It is so rare that a "little guy" can get a response from someone at your level. BTW, thanks to all the others who hang out on this newsgroup and provide such timely and accurate responses. I hope you know who you are. Thanks, Theron Peter Alfke wrote: > The worst thing you might build would be a synchronous counter with the clock > enable fed to every bit in parallel. Don't do that! > > My sugestion is to build any counter you want, synchronous or ripple, but have > a one-bit prescaler toggle-flip-flop generate the clock. This prescaler must > use the Xilinx CE feature, which really is a multiplexer in the D input. > Since CE changes asynchronously, but does not affect the clock, you never get > a runt clock pulse, but you might ( once in a blue moon) get a longer Q > delay. It will be many thousands (millions?) of years between the worst > happening, when this extra metastable delay swallows one incoming clock tick. > > Peter Alfke, Xilinx Applications > ================================== > Theron Hicks wrote: > > > I am looking for some code to define a glitch less clock enable/disable > > circuit. The clock frequency is 100MHz. What I am trying to say is that I > > have a counter with a 100MHz clock and I want to avoid runt pulses on the > > clock. This could either be a clock mux switching between 0 and clock on > > the output or a "safe" clock enable that would eliminate (or at least > > minimize) the possibility of metastability. The counter could be > > asynchronous if that simplifies things. Any ideas, suggestions, sources, > > etc. > > > > Thanks, > > Theron ###### From: Theron Hicks Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Tue, 29 Jan 2002 10:34:13 -0500 Organization: Michigan State University Lines: 49 Message-ID: <3C56C0F5.2C0A4437@egr.msu.edu> References: <3C55E0AE.9070002@quartz.net.nz> NNTP-Posting-Host: dfti.egr.msu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!news.stealth.net!solaris.cc.vt.edu!news.vt.edu!msunews!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13611 David Miller wrote: > > I am looking for some code to define a glitch less clock > > enable/disable circuit. The clock frequency is 100MHz. What I am > > trying to say is that I have a counter with a 100MHz clock and I > > want to avoid runt pulses on the clock. This could either be a > > clock mux switching between 0 and clock on the output or a "safe" > > clock enable that would eliminate (or at least minimize) the > > possibility of metastability. The counter could be asynchronous if > > that simplifies things. Any ideas, suggestions, sources, > > SpartanIIs have dedicated clock enable inputs on all flops. You should > use those rather than gating clocks (which is very bad practice anyway) > with logic[1]. Consult your synthesis guide for more info on how to do > that in your HDL. > > Judging from your email address, I assume that you're a student. Reasonable assumption, but actually I am working on a R & D project for a university development of an instrumentation project. I am working on a graduate level degree (MSEE) on a part time basis, but my primary function is as an engineer not a student. Maybe I should get a different non-university E-Mail so people won't automatically assume that my questions are trying to get homework answers. However, your idea of "playing" with the CLBs still has a great deal of merit, and I have used it to study DCMs, DLLs, and SRL16s with substantial benefit. Actually, I had thought I would probably use the CE input, but I just wanted to verify that I had not missed some type of clock gate circuit such as exists on the VirtexII series. Thanks for your help and advice, Theron Hicks > An > interesting exercise is to run the tool fpga_editor, create an empty, > small fpga and play with the CLBs. You can learn alot about how the > fpgas actually implement logic in this way. > > [1] PAR will complain loudly if you do this, because you are no longer > able to use dedicated clock routing resources so, glitches aside, you'll > have big problems with skew. > > -- > David Miller, BCMS (Hons) | When something disturbs you, it isn't the > Endace Measurement Systems | thing that disturbs you; rather, it is > Mobile: +64-21-704-djm | your judgement of it, and you have the > Fax: +64-21-304-djm | power to change that. -- Marcus Aurelius ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Tue, 29 Jan 2002 17:15:51 -0000 Message-ID: <1012335814.15711.0.nnrp-02.9e9832fa@news.demon.co.uk> References: <3C55E0AE.9070002@quartz.net.nz> <3C56C0F5.2C0A4437@egr.msu.edu> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1012335814 nnrp-02:15711 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.clara.net!heighliner.fr.clara.net!freenix!gitoyen!nerim.net!diablo.netcom.net.uk!netcom.net.uk!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13861 "Theron Hicks" wrote > Actually, I had thought I would > probably use the CE input, but I just wanted to verify that I had not missed > some type of clock gate circuit such as exists on the VirtexII series. If you look (via fpga_editor) at the clock buffers you will see that there is a clock gate circuit in SpartanII. At least there is a control pin which looks like a gate input (comp.pin = K.BUFn.CE). There must be some problem with using it and we will have to wait for Peter's memoirs before we get the story. Has anyone managed to (manually) use this resource? ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Tue, 29 Jan 2002 17:09:23 -0800 Organization: Xilinx Lines: 80 Message-ID: <3C5747C4.2ABDC337@xilinx.com> References: <3C55E0AE.9070002@quartz.net.nz> <3C56C0F5.2C0A4437@egr.msu.edu> <1012335814.15711.0.nnrp-02.9e9832fa@news.demon.co.uk> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F7940E67EBE3F98EDA2E06EE" X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Tim@xilinx.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!Amsterdam.Infonet!News.Amsterdam.UnisourceCS!news.telia-iberia.com!out.nntp.be!propagator-SanJose!in.nntp.be!xmission!news-out.spamkiller.net!propagator-maxim!feed.newsfeeds.com!news-in.spamkiller.net!tethys.csu.net!csulb.edu!enews.sgi.com!nntp.wetware.com!attbt1!attbt2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13600 --------------F7940E67EBE3F98EDA2E06EE Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Tim wrote: > If you look (via fpga_editor) at the clock buffers you will see > that there is a clock gate circuit in SpartanII. At least there > is a control pin which looks like a gate input (comp.pin = K.BUFn.CE). > > There must be some problem with using it and we will have to wait > for Peter's memoirs before we get the story. Talking about memoirs, I just finished reading "Spin-Off" by Charlie Sporck of NSC fame, and "Swimming Across" by Andy Grove of Intel fame. Both very different, and both very good reading. I can never compete with that kind of substance. Clock gating: I remember once having a "brilliant" idea and publishing a clock multiplexer circuit in XCell http://www.xilinx.com/xcell/xl24/xl24_20.pdf (Got me some flak from the high priests of metastability, but I think I managed to defend myself.) I then conned our circuit designers to implement it in XC4000XL, but it could not be supported in software, not even in fpga editor. Thus it effectively was not there, even though it was there. It was less than virtual, more like a ghost... We legitimized the circuit for Virtex and Spartan-II, although I have a hard time finding the data book description. For Virtex-II, the circuit was significantly revamped and also described in the data sheet and the manual. Yes, you can use this circuit to gate the clock. It is really an overkill, and I still prefer the simple one-bit prescaler. But both approaches will work. Peter Alfke, Xilinx Applications --------------F7940E67EBE3F98EDA2E06EE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tim wrote:

If you look (via fpga_editor) at the clock buffers you will see
that there is a clock gate circuit in SpartanII.  At least there
is a control pin which looks like a gate input (comp.pin = K.BUFn.CE).

There must be some problem with using it and we will have to wait
for Peter's memoirs before we get the story.

Talking about memoirs, I just finished reading "Spin-Off" by Charlie Sporck of NSC fame, and "Swimming Across" by Andy Grove of Intel fame. Both very different, and both very good reading. I can never compete with that kind of substance.

Clock gating:
I remember once having a "brilliant" idea and publishing a clock multiplexer circuit in XCell
http://www.xilinx.com/xcell/xl24/xl24_20.pdf
(Got me some flak from the high priests of metastability, but I think I managed to defend myself.)
I then conned our circuit designers to implement it in XC4000XL, but it could not be supported in software, not even in fpga editor. Thus it effectively was not there, even though it was there. It was less than virtual, more like a ghost...
We legitimized the circuit for Virtex and Spartan-II, although I have a hard time finding the data book description.
For Virtex-II, the circuit was significantly revamped and also described in the data sheet and the manual.

Yes, you can use this circuit to gate the clock. It is really an overkill, and I still prefer the simple one-bit prescaler. But both approaches will work.

Peter Alfke, Xilinx Applications
  --------------F7940E67EBE3F98EDA2E06EE-- ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Wed, 30 Jan 2002 02:02:41 -0000 Message-ID: <1012356389.17687.0.nnrp-12.9e9832fa@news.demon.co.uk> References: <3C55E0AE.9070002@quartz.net.nz> <3C56C0F5.2C0A4437@egr.msu.edu> <1012335814.15711.0.nnrp-02.9e9832fa@news.demon.co.uk> <3C5747C4.2ABDC337@xilinx.com> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1012356389 nnrp-12:17687 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 47 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13870 Peter - Many thanks. "Peter Alfke" wrote > > > Tim wrote: > > > If you look (via fpga_editor) at the clock buffers you will see > > that there is a clock gate circuit in SpartanII. At least there > > is a control pin which looks like a gate input (comp.pin = K.BUFn.CE). > > > > There must be some problem with using it and we will have to wait > > for Peter's memoirs before we get the story. > > Talking about memoirs, I just finished reading "Spin-Off" by Charlie Sporck of > NSC fame, and "Swimming Across" by Andy Grove of Intel fame. Both very different, > and both very good reading. I can never compete with that kind of substance. > > Clock gating: > I remember once having a "brilliant" idea and publishing a clock multiplexer > circuit in XCell > http://www.xilinx.com/xcell/xl24/xl24_20.pdf > (Got me some flak from the high priests of metastability, but I think I managed > to defend myself.) > I then conned our circuit designers to implement it in XC4000XL, but it could not > be supported in software, not even in fpga editor. Thus it effectively was not > there, even though it was there. It was less than virtual, more like a ghost... > We legitimized the circuit for Virtex and Spartan-II, although I have a hard time > finding the data book description. > For Virtex-II, the circuit was significantly revamped and also described in the > data sheet and the manual. > > Yes, you can use this circuit to gate the clock. It is really an overkill, and I > still prefer the simple one-bit prescaler. But both approaches will work. > > Peter Alfke, Xilinx Applications > > ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> References: <3C5638AA.13435A95@earthlink.net> X-Newsreader: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 40 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr21.news.prodigy.com 1012419240 ST000 216.103.85.188 (Wed, 30 Jan 2002 14:34:00 EST) NNTP-Posting-Date: Wed, 30 Jan 2002 14:34:00 EST X-UserInfo1: [[PAPDCA[S@_BPLX^BN@^QLAUKXD@D@MGPW^OBPLAH[\RYIBK^RAQFW[ML\THRCKV^GGZKJMGV^^_JSCFFUA_QXFGVSCYRPILH]TRVKC^LSN@DX_HCAFX__@J\DAJBVMY\ZWZCZLPA^MVH_P@\\EOMW\YSXHG__IJQY_@M[A[[AXQ_XDSTAR]\PG]NVAQUVM Date: Wed, 30 Jan 2002 19:34:00 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeeds.belnet.be!news.belnet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!newscon02.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr21.news.prodigy.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13813 On Tue, 29 Jan 2002 05:52:47 GMT, Peter Alfke wrote: > >My sugestion is to build any counter you want, synchronous or ripple, but have >a one-bit prescaler toggle-flip-flop generate the clock. So the clock is divided by 2 in the prescaler, and the Q is the clock to the rest of the counter (via a BUFG, if it is a synchronous counter, or nothing special if it is a ripple counter). >This prescaler must >use the Xilinx CE feature, which really is a multiplexer in the D input. Right. >Since CE changes asynchronously, but does not affect the clock, you never get >a runt clock pulse, but you might ( once in a blue moon) get a longer Q >delay. It will be many thousands (millions?) of years between the worst >happening, when this extra metastable delay swallows one incoming clock tick. > >Peter Alfke, Xilinx Applications >================================== Tragically, I disagree. The asynchronous CE signal is just as bad to a FF as an asynchronous D signal. The FF can go metastable, and you can get runt low or high pulses from the FF. Since this feeds your follow on counter as its clock, the results will be sub-optimal. The only safe way to use the CE is with a synchronous signal, so the asynchronous control signal should be passed through a multi stage synchronizer, before being presented to the CE pin. Philip Freidin Philip Freidin Fliptronics ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Wed, 30 Jan 2002 14:50:30 -0800 Organization: Xilinx Lines: 35 Message-ID: <3C5878B6.C5D9B101@xilinx.com> References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.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: philip@fliptronics.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeeds.belnet.be!news.belnet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!newshub.sdsu.edu!newspeer.cts.com!news.aloha.net!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13591 As usual, I agree with Phil in principle. His statements are 100% correct, but we disagree on the seriousness of the problem. Metastability "usually" resolves itself in a small fraction of the 10 ns period ( 100 MHz clock rate). So the issue is: How often does it not resolve itself, and would you ever see oscillations ? Phil thinks it can happen more often than I think it might happen. In the deplorable absence of quantitative data, the argument must remain unresolved. Every time you enable or disable CE asynchronously, you are playing Russian Roulette. But how many chambers are empty in the revolver ? A million, a trillion, or a gazillion? And where is it pointed, at your brains or at your shoes? ( How serious is a failure?) Peter Alfke ========== Philip Freidin wrote: > The asynchronous CE signal is just as bad to a FF as an asynchronous D > signal. The FF can go metastable, and you can get runt low or high > pulses from the FF. Since this feeds your follow on counter as its > clock, the results will be sub-optimal. > > The only safe way to use the CE is with a synchronous signal, so the > asynchronous control signal should be passed through a multi stage > synchronizer, before being presented to the CE pin. > > Philip Freidin > > Philip Freidin > Fliptronics ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 30 Jan 2002 15:25:40 -0800 Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 30 Jan 2002 15:40:28 -0800, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!26289!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!hub1.nntpserver.com!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!enews.sgi.com!news.spies.com!ruckus.brouhaha.com Xref: chonsp.franklin.ch comp.arch.fpga:13786 Peter Alfke writes: > As usual, I agree with Phil in principle. > His statements are 100% correct, but we disagree on the seriousness of the > problem. > Metastability "usually" resolves itself in a small fraction of the 10 ns period ( > 100 MHz clock rate). > So the issue is: How often does it not resolve itself, and would you ever see > oscillations ? > Phil thinks it can happen more often than I think it might happen. > In the deplorable absence of quantitative data, the argument must remain > unresolved. > > Every time you enable or disable CE asynchronously, you are playing Russian > Roulette. But how many chambers are empty in the revolver ? A million, a trillion, > or a gazillion? > And where is it pointed, at your brains or at your shoes? ( How serious is a > failure?) By your argument, it should be fine to feed async data directly into the D input, since the probablity of failure will be the same (or very close) to the probability of failure with an async CE input. If it's a problem for the D input, it's also a problem for the CE input. Unless there's some other reason why the window of vulnerability for the D and CE inputs are significantly different? ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Wed, 30 Jan 2002 16:45:29 -0800 Organization: Xilinx Lines: 117 Message-ID: <3C5893A8.B4ABC0E1@xilinx.com> References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7AC5AFAD48903FB8B63B142A" X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Eric Smith Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!fu-berlin.de!news.maxwell.syr.edu!newsfeed.cwix.com!prairie.attcanada.net!newsfeed.attcanada.net!12.127.17.144!attbt1!attbt2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13609 --------------7AC5AFAD48903FB8B63B142A Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Eric Smith wrote: > Peter Alfke writes: > > As usual, I agree with Phil in principle. > > His statements are 100% correct, but we disagree on the seriousness of the > > problem. > > Metastability "usually" resolves itself in a small fraction of the 10 ns period ( > > 100 MHz clock rate). > > So the issue is: How often does it not resolve itself, and would you ever see > > oscillations ? > > Phil thinks it can happen more often than I think it might happen. > > In the deplorable absence of quantitative data, the argument must remain > > unresolved. > > > > Every time you enable or disable CE asynchronously, you are playing Russian > > Roulette. But how many chambers are empty in the revolver ? A million, a trillion, > > or a gazillion? > > And where is it pointed, at your brains or at your shoes? ( How serious is a > > failure?) > > By your argument, it should be fine to feed async data directly into > the D input, since the probablity of failure will be the same (or very > close) to the probability of failure with an async CE input. > There is no reason to assume that they are any different. But there are mitigating circumstances: The clock rate is modest, only 100 MHz, which allows for an extra 5 ns of metastable delay. The CE changes are most likely less than 1 MHz (I assume) The Q output only clocks one flip-flop.(Note that I shift my position a bit, now assuming a 2-bit ripple prescaler, not just one bit). ;-) What is the likelyhood ( expressed as MTBF) for an extra 5 ns of metastable delay when the clock is 100 MHz and the asynchronous input changes about 1 million times per second? The 1997 Xilinx app note XAPP094 documents the archaic XC4005-3 at an MTBF of 100 000 years for metastable delay of 2 ns, ( really 1 million years at 10 MHz clock and 1 MHz data, but that translates to 100 000 years at the ten times higher clock rate) and the MTBF increases ten decimal orders of magnitude for every additional ns. That's three additional ns in this case. That means an MTBF of 10exp35, which is many times the age of the universe. I am willing to take that risk. Walking across the parking lot tonight is a much bigger risk... Peter Alfke, Xilinx Applications --------------7AC5AFAD48903FB8B63B142A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Eric Smith wrote:

Peter Alfke <peter.alfke@xilinx.com> writes:
> As usual, I agree with Phil in principle.
> His statements are 100% correct, but we disagree on the seriousness of the
> problem.
> Metastability "usually" resolves itself in a small fraction of the 10 ns period (
> 100 MHz clock rate).
> So the issue is: How often does it not resolve itself, and would you ever see
> oscillations ?
> Phil thinks it can happen more often than I think it might happen.
> In the deplorable absence of quantitative data, the argument must remain
> unresolved.
>
> Every time you enable or disable CE asynchronously, you are playing Russian
> Roulette. But how many chambers are empty in the revolver ? A million, a trillion,
> or a gazillion?
> And where is it pointed, at your brains or at your shoes? ( How serious is a
> failure?)

By your argument, it should be fine to feed async data directly into
the D input, since the probablity of failure will be the same (or very
close) to the probability of failure with an async CE input.
 

There is no reason to assume that they are any different.
But there are mitigating circumstances:
The clock rate is modest, only 100 MHz, which allows for an extra 5 ns of metastable delay.
The CE changes are most likely less than 1 MHz (I assume)
The Q output only clocks one flip-flop.(Note that I shift my position a bit, now assuming a 2-bit ripple prescaler, not just one bit).  ;-)

What is the likelyhood ( expressed as MTBF) for an extra 5 ns of metastable delay when the clock is 100 MHz and the asynchronous input changes about 1 million times per second?

The 1997 Xilinx app note XAPP094 documents the archaic XC4005-3 at an MTBF of 100 000 years for metastable delay of 2 ns, ( really 1 million years at 10 MHz clock and 1 MHz data, but that translates to 100 000 years at the ten times higher clock rate) and the MTBF increases ten decimal orders of magnitude for every additional ns. That's three additional ns in this case.
That means an MTBF of 10exp35, which is many times the age of the universe.

I am willing to take that risk. Walking across the parking lot tonight is a much bigger risk...

Peter Alfke, Xilinx Applications --------------7AC5AFAD48903FB8B63B142A-- ###### Message-ID: <3C58EC93.6D5CBD17@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: glitchless clock enable/disable in spartanII References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!unknown@rfhome.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 19 Date: Thu, 31 Jan 2002 07:04:51 +0000 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 1012460693 62.254.210.251 (Thu, 31 Jan 2002 07:04:53 GMT) NNTP-Posting-Date: Thu, 31 Jan 2002 07:04:53 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!lon1-news.nildram.net!peernews!peer.cwci.net!news5-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13637 Peter Alfke wrote: > > Phil thinks it can happen more often than I think it might happen. > In the deplorable absence of quantitative data, the argument must remain > unresolved. > > Peter, I seem to remember you saying on this very NG that when the Virtex-2 arrived you'd be able to play games with the DCM to get some hard data on the metastability parameters ? ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: <8svh5usn1t002n57bfp2pjdbkfoffktu5k@4ax.com> References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> X-Newsreader: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 108 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr21.news.prodigy.com 1012466715 ST000 216.103.85.188 (Thu, 31 Jan 2002 03:45:15 EST) NNTP-Posting-Date: Thu, 31 Jan 2002 03:45:15 EST X-UserInfo1: OXXKRZGGARRMBQH]^JKBOW@@YJ_ZTB\MV@BL\QMIWIWTEPIB_NVUAH_[BL[\IRKIANGGJBFNJF_DOLSCENSY^U@FRFUEXR@KFXYDBPWBCDQJA@X_DCBHXR[C@\EOKCJLED_SZ@RMWYXYWE_P@\\GOIW^@SYFFSWHFIXMADO@^[ADPRPETLBJ]RDGENSKQQZN Date: Thu, 31 Jan 2002 08:45:15 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!207.115.63.138!newscon04.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr21.news.prodigy.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13871 Peter's original post on the topic: >My sugestion is to build any counter you want, synchronous or ripple, but have >a one-bit prescaler toggle-flip-flop generate the clock. This prescaler must >use the Xilinx CE feature, which really is a multiplexer in the D input. >Since CE changes asynchronously, but does not affect the clock, you never get >a runt clock pulse, but you might ( once in a blue moon) get a longer Q >delay. It will be many thousands (millions?) of years between the worst >happening, when this extra metastable delay swallows one incoming clock tick. > >Peter Alfke, Xilinx Applications On Wed, 30 Jan 2002 14:50:30 -0800, Peter Alfke wrote: >As usual, I agree with Phil in principle. A man of Principals! >His statements are 100% correct, but we disagree on the seriousness >of the problem. Metastability "usually" resolves itself in a small >fraction of the 10 ns period (100 MHz clock rate). >So the issue is: How often does it not resolve itself, and would you >ever see oscillations ? Tragically, in this case you need to read the your solution (above), and my reply more carefully. The output of the FF with the CE being driven by the asynchronous signal is being used as the clock for the following counter. Therefore there is NO resolution time available, and runt output pulses WILL cause problems. >Phil thinks it can happen more often than I think it might happen. >In the deplorable absence of quantitative data, the argument must remain >unresolved. Not in this case, as there is no resolution time. Things would be different if the main counter was clocked by the 100MHz, and the control FF output was used as the CE for the main counter, or the control FF was a two stage prescaler circuit, that had some metastability resolution time built in. But your recommendation (above) has the single FF prescaler output used as the clock of the main counter. >Peter Alfke and later: >There is no reason to assume that they are any different (CE or D). >But there are mitigating circumstances: >The clock rate is modest, only 100 MHz, which allows for an extra 5 ns of metastable >delay. No. No resolution time available. Q is clock to following counter >The CE changes are most likely less than 1 MHz (I assume) >The Q output only clocks one flip-flop.(Note that I shift my position a bit, now >assuming a 2-bit ripple prescaler, not just one bit). ;-) Good back peddle :-) >What is the likelyhood ( expressed as MTBF) for an extra 5 ns of metastable delay when >the clock is 100 MHz and the asynchronous input changes about 1 million times per >second? I agree that this is better. >The 1997 Xilinx app note XAPP094 documents the archaic XC4005-3 at an MTBF of 100 000 >years for metastable delay of 2 ns, ( really 1 million years at 10 MHz clock and 1 MHz >data, but that translates to 100 000 years at the ten times higher clock rate) and the >MTBF increases ten decimal orders of magnitude for every additional ns. That's three >additional ns in this case. "ten decimal orders of magnitude" ???? I seem to remember the slope is more like an improvement of a factor of 40 per each additional ns. When di the slope change to 10^30 ????? >That means an MTBF of 10exp35, which is many times the age of the universe. > >Peter Alfke, Xilinx Applications >Philip Freidin wrote: > >> The asynchronous CE signal is just as bad to a FF as an asynchronous D >> signal. The FF can go metastable, and you can get runt low or high >> pulses from the FF. Since this feeds your follow on counter as its >> clock, the results will be sub-optimal. >> >> The only safe way to use the CE is with a synchronous signal, so the >> asynchronous control signal should be passed through a multi stage >> synchronizer, before being presented to the CE pin. >> >> Philip Freidin >> >> Philip Freidin >> Fliptronics Still having fun, Philip Philip Freidin Fliptronics ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Thu, 31 Jan 2002 10:01:12 -0800 Organization: Xilinx Lines: 62 Message-ID: <3C598667.7C0753FB@xilinx.com> References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> <3C58EC93.6D5CBD17@algor.co.uk> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4A4120E531E913F44D21FFB7" X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Rick Filipkiewicz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!8686!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!news!nntp.wetware.com!attbt1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13589 --------------4A4120E531E913F44D21FFB7 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Rick Filipkiewicz wrote: > > Peter, > > I seem to remember you saying on this very NG that when the Virtex-2 arrived you'd be > able to play games with the DCM to get some hard data on the metastability parameters > ? Still on my "to do" list. Kind of embarrassing. But, although Philip seems not to believe it, the old 1997 documentation shows that even the now-obsolete XC4005-3 increases the MTBF by ten decimal orders of magnitude for every extra ns of acceptable delay. This XAPP094 data has been publicly available for 4 years and has never been challenged. http://www.xilinx.com/xapp/xapp094.pdf The modern flip-flops must be doing so much better that measuring might again be a challenge. Let's try ! Metastability exists and is a devious problem, but modern flip-flops resolve it surprisingly fast. Peter Alfke, Xilinx Applications --------------4A4120E531E913F44D21FFB7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Rick Filipkiewicz wrote:

 
Peter,

I seem to remember you saying on this very NG that when the Virtex-2 arrived you'd be
able to play games with the DCM to get some hard data on the metastability parameters
?

Still on my "to do" list. Kind of embarrassing.

But, although Philip seems not to believe it, the old 1997 documentation shows that even the now-obsolete XC4005-3  increases the MTBF by ten decimal orders of magnitude for every extra ns of acceptable delay. This XAPP094 data has been publicly available for 4 years and has never been challenged.
http://www.xilinx.com/xapp/xapp094.pdf
The modern flip-flops must be doing so much better that measuring might again be a challenge. Let's try !
Metastability exists and is a devious problem, but modern flip-flops resolve it surprisingly fast.

Peter Alfke, Xilinx Applications
  --------------4A4120E531E913F44D21FFB7-- ###### Message-ID: <3C59EACC.38CD0AB7@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: glitchless clock enable/disable in spartanII References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> <8svh5usn1t002n57bfp2pjdbkfoffktu5k@4ax.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!unknown@rfhome.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 43 Date: Fri, 01 Feb 2002 01:09:32 +0000 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 1012525775 62.254.210.251 (Fri, 01 Feb 2002 01:09:35 GMT) NNTP-Posting-Date: Fri, 01 Feb 2002 01:09:35 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news2.euro.net!newsfeed.freenet.de!lon1-news.nildram.net!peernews!peer.cwci.net!news5-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13649 Philip Freidin wrote: > > > >The 1997 Xilinx app note XAPP094 documents the archaic XC4005-3 at an MTBF of 100 000 > >years for metastable delay of 2 ns, ( really 1 million years at 10 MHz clock and 1 MHz > >data, but that translates to 100 000 years at the ten times higher clock rate) and the > >MTBF increases ten decimal orders of magnitude for every additional ns. That's three > >additional ns in this case. > > "ten decimal orders of magnitude" ???? I seem to remember the slope is more like > an improvement of a factor of 40 per each additional ns. When di the slope > change to 10^30 ????? > > >That means an MTBF of 10exp35, which is many times the age of the universe. > > > >Peter Alfke, Xilinx Applications Nice app note that XAPP094, it was the first good discussion of metastability from a chip maker I'd seen since a very early Lattice GAL data book [IIRC there was also one in the red Fairchild `F' series TTL data book, and one in the MMI PAL handbook]. From it we have the `K2' per nsec. scale factors for metastab resolution: XC4005E-3 IOB FF = exp(16.1) =~ 9.8 * 10^6. XC4005E-3 CLB FF = exp(19.4) =~ 2.6 * 10^8. Not quite 10 orders of mag per nsec. but I was quite happy with 7. Now I derate the delay for Virtex-E synchroniser FFs in CLBs by 5 nsec so, assuming the V-E is no worse than the 4005Es, I get an MTBF between the 33MHz PCI domain and a main 100MHz domain of: about 8.8 * 10^21 years That'll do for me. *BUT* I've always had one caveat about that apps note. The `metastab catching window' is quoted as 0.1nsec but the data book setup times for the XC4005E FFs were much larger. Does this mean that the hold times quoted as 0 were/are in fact negative ? ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Date: Thu, 31 Jan 2002 18:44:49 -0800 Organization: Xilinx Lines: 37 Message-ID: <3C5A0120.FE61312F@xilinx.com> References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> <8svh5usn1t002n57bfp2pjdbkfoffktu5k@4ax.com> <3C59EACC.38CD0AB7@algor.co.uk> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.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: Rick Filipkiewicz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!nntp.wetware.com!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13586 Rick Filipkiewicz wrote: > > Nice app note that XAPP094, it was the first good discussion of metastability from a chip > maker I'd seen since a very early Lattice GAL data book [IIRC there was also one in the red > Fairchild `F' series TTL data book, and one in the MMI PAL handbook]. Thanks > > *BUT* > > I've always had one caveat about that apps note. The `metastab catching window' is quoted > as 0.1nsec but the data book setup times for the XC4005E FFs were much larger. Does this > mean that the hold times quoted as 0 were/are in fact negative ? Well, that is a different subject. Metastability is concerned with one devive at one temperature and supply voltage, whatever it is at the magic moment of making the decision. The data sheet is a worst-case specification that has to cover everything, process, temperature, and voltage variation plus tester guardband ( the tester alone adds 0.5 ns inaccuracy ) So the max set-up time is the longest set-up time that might ever occur anytime anywhere, and the quoted negative hold time would be the shortest possible set-up time. But since that smallest set-up time is difficult to measure, and, if guaranteed, would preclude future process improvement, the manufacturers tend to say: 0 ns hold time, which means: "The hold time is guaranteed to be NOT positive, but we are not specifying how negative it really is". ( Negative is good when hold time is concerned). The spread between set-up and hold time has nothing whatsoever to do with the metastability catching window, which obviously is only a fraction of a picosecond. Peter Alfke ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: glitchless clock enable/disable in spartanII Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: <5rvj5usnjlg3dthdcbsvggtkldc5o4536d@4ax.com> References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> <8svh5usn1t002n57bfp2pjdbkfoffktu5k@4ax.com> <3C59EACC.38CD0AB7@algor.co.uk> X-Newsreader: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 41 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr21.news.prodigy.com 1012531991 ST000 216.103.85.188 (Thu, 31 Jan 2002 21:53:11 EST) NNTP-Posting-Date: Thu, 31 Jan 2002 21:53:11 EST X-UserInfo1: [[PGG]WD\BR[C_TX@BCD^VX@WB]^PCPDLXUNNH\KMAVNDQUBLNTC@AWZWDXZXQ[K\FFSKCVM@F_N_DOBWVWG__LG@VVOIPLIGX\\BU_B@\P\PFX\B[APHTWAHDCKJF^NHD[YJAZMCY_CWG[SX\Y]^KC\HSZRWSWKGAY_PC[BQ[BXAS\F\\@DMTLFZFUE@\VL Date: Fri, 01 Feb 2002 02:53:11 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!10668!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!newscon02.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr21.news.prodigy.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13882 On Fri, 01 Feb 2002 01:09:32 +0000, Rick Filipkiewicz wrote: >*BUT* > >I've always had one caveat about that apps note. The `metastab catching window' is quoted >as 0.1nsec but the data book setup times for the XC4005E FFs were much larger. Does this >mean that the hold times quoted as 0 were/are in fact negative ? The `metastab catching window' is also the window in which the FF actually samples the D (and CE) input and decides what to do. If new data is valid before the start of the window, the FF catches the new data. If the new data changes after the window, the FF catches the data value prior to the new data. The window slides around based on temp, voltage, device age, phase of moon, Dv/Dt of the data signal, Dv/Dt of the clock signal, what the async reset has done recently, and what the current FF state is. The data sheet numbers for setup and hold give a bounded limit for how far the window can wander. ( it wanders around during normal operation, but within these limits). So reality is that 'setup' and 'hold' do not actually exist. By specifying these values, and designing to them, you get reliable system behaviour regardless as to where the window is at the time of the clock signal. So getting to your question, the FFs are designed so that if every thing conspires to make the window as late as possible, the end of the window will be no later than 0.0 ns after the clock (which gives hold time of 0.0 ns). Similarly, if everything conspires to make the window as early as possible, the beginnining of the windo will be no earlier than the setup time before the clock. You could read more on this at: http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm Philip Philip Freidin Fliptronics ###### Message-ID: <3C5BE3A4.3868EE0E@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: glitchless clock enable/disable in spartanII References: <3C5638AA.13435A95@earthlink.net> <62ig5u4tldsg2iqk0nja10t9v162dd2f4s@4ax.com> <3C5878B6.C5D9B101@xilinx.com> <8svh5usn1t002n57bfp2pjdbkfoffktu5k@4ax.com> <3C59EACC.38CD0AB7@algor.co.uk> <5rvj5usnjlg3dthdcbsvggtkldc5o4536d@4ax.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!unknown@rfhome.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 79 Date: Sat, 02 Feb 2002 13:03:32 +0000 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 1012655016 62.254.210.251 (Sat, 02 Feb 2002 13:03:36 GMT) NNTP-Posting-Date: Sat, 02 Feb 2002 13:03:36 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!17367935!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!colt.net!newspeer.clara.net!news.clara.net!peernews!peer.cwci.net!news5-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13633 Philip Freidin wrote: > On Fri, 01 Feb 2002 01:09:32 +0000, Rick Filipkiewicz wrote: > >*BUT* > > > >I've always had one caveat about that apps note. The `metastab catching window' is quoted > >as 0.1nsec but the data book setup times for the XC4005E FFs were much larger. Does this > >mean that the hold times quoted as 0 were/are in fact negative ? > > The `metastab catching window' is also the window in which the FF actually > samples the D (and CE) input and decides what to do. If new data is valid > before the start of the window, the FF catches the new data. If the new > data changes after the window, the FF catches the data value prior to the > new data. > > The window slides around based on temp, voltage, device age, phase of moon, > Dv/Dt of the data signal, Dv/Dt of the clock signal, what the async reset > has done recently, and what the current FF state is. > The data sheet numbers for setup and hold give a bounded limit for how far > the window can wander. ( it wanders around during normal operation, but > within these limits). > > So reality is that 'setup' and 'hold' do not actually exist. By specifying > these values, and designing to them, you get reliable system behaviour > regardless as to where the window is at the time of the clock signal. > > So getting to your question, the FFs are designed so that if every thing > conspires to make the window as late as possible, the end of the window > will be no later than 0.0 ns after the clock (which gives hold time of > 0.0 ns). > > Similarly, if everything conspires to make the window as early as possible, > the beginnining of the windo will be no earlier than the setup time before > the clock. > > You could read more on this at: > > http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm > > Philip > Philip Freidin > Fliptronics I'd read that, IMO real nice, FAQ some while ago. My query was not that the `catching window' was shorter than the nominal setup time but that it was so much shorter. Re-reading the FAQ reminded me that, of course, the real window size is largely determined by the charging time of the `input' under whatever conditions are present at the time the `D' signal changes. Clearly this is going to be a lot smaller than the worst case Tsu+Thld esp. for modern fine geometry devices. If Peter's claim of a few picosec. for modern Virtex devices is correct then XAPP094 understates the MTBF (assuming K2 unchanged) by an order of magnitude or so but this largely irrelevant as the MTBF is completely dominated by the resolution time function. Going back to my PCISignal-> 100MHz clock domain case and: o Assuming that the PCI signal is not happening at PCI rate but, say, 1/6th of this. o The `catching window' has come down to 20psec from the 100 in XAPP094. o There has been a modest K2 increase to 25. o I make a 1.2nsec allowance for metastab decay [in the real system its much bigger than this]. I get an MTBF of about 62 years. Hence, while knowing full well that metstability is always with us, I do tend to align myself with Peter A's pragmatic approach to the seriousness of the problem. For example a well placed & routed double synchoniser running at 200MHz is still likely to have 2-3 nsec. of slack and the MTBF in the test case is now (for 2 nsec.) going to be 1.4*10^10 years. Exponentials are wonderful things when they're on your side. Against all this is, of course, Mr. Murphy who will ensure that, no matter how unlikely, the 1-in-10billion error happens just at the critical point of V2 for an aircraft taking off or when the surgeon really needs to know the patients blood pressure or ...